- TIE-0240x
- 2. Working in a Software Team
- 2.1 Programming in the Large
Programming in the Large¶
We will start the course by looking into the basic principles of modularity: dividing a large program into parts. We will discuss object-oriented programming and responsibilities, and encapsulation in modularity. Locality principle is covered.
(Source: Rintala, Jokinen - Olioiden ohjelmointin C++lla)
Developing Quality Software¶
Programmers need to both understand the formal principles of the field and be able to use this knowledge to create and form new software products that need to be efficient, robust, economical, clear, portable, maintainable and easy to use. The problem lies in the size of modern software - the limit of human abilites to handle the whole is reached with a relatively small program when it comes to the amount of code needed.
Abstraction as a Tool¶
One of the basic principles behind solving large problems is dividing the problem into manageable pieces. This principle of division and simplification through abstraction is seen throughout software development in the tools we use, in the development processes and in modern programming languages.
Abstraction is the idea of creating a term to describe a new thing or collection of things.
Objects¶
In Object-oriented programming an object is and independent element with a specific, exact responsibility within the software. The responsibility of an object covers everything the object is set to implement. The responsibility is more than just variables and functions. It can, for example, cover the responsibility of allocating and deallocating of resources or other objects.
Components¶
Modules, a collection of data and the functionality that handles it, and object together work as components. The idea is that software developers can use components as building blocks for their implementation by combining them. A software component is an independent unit that can be used as a part of a larger unit through its public interface.
Design of Objects¶
Abstraction is behind modularity. This means that the software needs to be divided into independent pieces with either top-down or bottom-up approach.
- Top down: finding larger, typically functional, units such as the user interface, database and input and output, and then dividing these further into smaller pieces that eventually form modules and classes.
- Bottom up: Starting the module planning from the subsystems already known and building the larger unit on top of them.
Locality Principle¶
The need of communication between software modules needs to be kept as small as possible to ensure that the communication between objects doesn’t end up resembling cooked spaghetti. A module references another module if it needs something from the other modules public interface. Bottom up design aims at collecting all closely related modules into one upper level unit. This packaging of strongly connected modules behind a new, simpler interface, is called the locality principle. It maintains locality throughout design.
Locality principle aims to reduce the links between software components and through this also controlling the complexity of the entire program. This simplifies the structure of the program.