Design Concepts | Abstraction | Architecture | Patterns | Separation | Modularity | Information Hiding | Functional Independence | Refinement | Aspects | Refactoring | Object-Oriented Design Concepts | Design Classes | Cohesion | Coupling

Design Concepts

• Introduction : A set of fundamental software design concepts have developed over the history of software engineering. 
• Although the degree of interest in each concept has varied over the years, each has stood the test of time. 
• Each provides the software designer with a foundation from which more sophisticated design methods can be applied. 
• The following important software design concepts that span both traditional and object-oriented software development. 
• (1) Abstraction [data, procedure, control]
• (2) Architecture [The overall structure of the software] 
• (3) Patterns [conveys the essence” of a proven design solution] 
• (4) Separation of Concerns [Divide complex problem in small parts] 
• (5) Modularity [Small Components] 
• (6) Information Hiding [controlled interfaces] 
• (7) Functional Independence
• (8) Refinement
• (9) Aspects
• (10) Refactoring
• (11) Object-Oriented Design Concepts
• (12) Design Classes

(1) Abstraction  (Concept / Generalization)

• Introduction : When you consider a modular solution to any problem, many levels of abstraction can be created. 
• At the highest level of abstraction, a solution is stated in broad terms using the language of the problem environment. 
• At lower levels of abstraction, a more detailed description of the solution is provided. 
• Finally, at the lowest level of abstraction, the solution is stated in a manner that can be directly implemented. 
• As different levels of abstraction are developed, you work to create both 
• Procedural abstractions 
• Data abstractions.
• A procedural abstraction refers to a sequence of instructions that have a specific and limited function. The name of a procedural abstraction implies these functions, but specific details are suppressed.
• An example of a procedural abstraction would be the word open for a door. Open implies a long sequence of procedural steps (e.g., walk to the door, reach out and grasp knob, turn knob and pull door, step away from moving door, etc.)

• A data abstraction is a named collection of data that describes a data object. 
• In the context of the procedural abstraction open, we can define a data abstraction called door. 
• A set of attributes that describe the door (e.g., door type, swing direction, opening mechanism, weight, dimensions). 
• It follows that the procedural abstraction open would make use of information contained in the attributes of the data abstraction door.

(2) Architecture

[The overall structure of the software]

• Software architecture refers to “the overall structure of the software and the ways in which that structure provides conceptual integrity for a system” [Sha95a]
• Architecture is the structure or organization of program components (modules), the manner in which these components interact, and the structure of data that are used by the components.
• The following set of properties that should be specified as part of an architectural design.
• Structural properties.
• Extra-functional properties
• Families of related systems
• Structural properties : This representation defines the components of a system e.g., modules, objects, filters
• The manner in which those components are packaged and interact with one another.
• For example, objects are packaged to encapsulate both data and methods.
• Extra-functional properties : The architectural design description should address the following.
• How the design architecture achieves requirements for performance, capacity, reliability, security, adaptability, and other system characteristics.
• Families of related systems : The architectural design should draw upon repeatable patterns that are commonly encountered in the design of families of similar systems.
• The design should have the ability to reuse architectural building blocks.

(3) Pattern [”conveys the essence (Fundamental nature) ” of a proven design solution]

• Design pattern describes a design structure that solves a particular design problem within a specific context.
• The objective of each design pattern is to provide a description that enables a designer to determine 
• (1) whether the pattern is applicable to the current work,
• (2) whether the pattern can be reused (hence, saving design time),
• (3) whether the pattern can serve as a guide for developing a similar, but functionally or structurally different pattern.

(4) Separation of Concerns
[Divide complex problem in small parts]

• Separation of concerns is a design concept, that suggests any complex problem can be more easily handled if it is subdivided into pieces that can each be solved and/or optimized independently.
• A concern is a feature or behavior that is specified as part of the requirements model for the software. By separating concerns into smaller, and therefore more manageable pieces, a problem takes less effort and time to solve. 
• Separation of concern is manifested (Marked / Visible) in other related design concepts: 
• Modularity,
• Aspects, 
• Functional independence, 
• Refinement.

(5) Modularity
[Divide complex problem in small parts]

• Modularity is the most common manifestation of separation of concerns. Software is divided into separately named and addressable components, sometimes called modules, that are integrated to satisfy problem requirements. 
• It has been stated that “modularity is the single attribute of software that allows a program to be intellectually manageable” [Mye78].
• Monolithic software (i.e., a large program composed of a single module) cannot be easily grasped by a software engineer. 
• You modularize a design (and the resulting program) so that 
• Development can be more easily planned; 
• Software increments can be defined and delivered;
• Changes can be more easily accommodated;
• Testing and debugging can be conducted more efficiently, 
• Long-term maintenance can be conducted without serious side effects

(6) Information Hiding[Controlled interfaces]

• The concept of modularity leads you to a fundamental question: “How do I decompose a software solution to obtain the best set of modules?”
• The principle of information hiding [Par72] suggests that modules be “characterized by design decisions that (each) hides from all others.” In other words, modules should be specified and designed so that information (algorithms and data) contained within a module is inaccessible to other modules that have no need for such information. 
• Hiding implies that effective modularity can be achieved by defining a set of independent modules that communicate with one another only that information necessary to achieve software function.
• The use of information hiding as a design criterion for modular systems provides the greatest benefits when modifications are required during testing and later during software maintenance. Because most data and procedural detail are hidden from other parts of the software

(7) Functional Independence

• The concept of functional independence is a direct result of separation of concerns, modularity, and the concepts of abstraction and information hiding.
• Functional independence is achieved by developing modules with “singleminded” function.
• Functional independence is a key to good design, and design is the key to software quality. 
• Independence is assessed using two qualitative criteria which evaluate quality of design : 
• Cohesion
• Coupling

Cohesion :

• Cohesion measures how strongly each of the functions are related within a program module.
• Well structured classes guide to highly cohesive programs. If a certain class is performing a set of highly related functions, that class is said to be cohesive.
• On the other hand, if a class is performing a bunch of totally unrelated functionalities that means the class is not cohesive at all.

Coupling:

• Coupling measures how much each of the program modules are dependent on the other program modules.
• Interactions between two objects occur because there is coupling.
• Loosely-coupled programs are high in flexibility and extensibility.
• Strong coupling is never good because one object can be highly dependent on some other object.

Difference of Cohesion - Coupling

(8) Refinement

(Modification / Improvement)

• Stepwise refinement is a top-down design strategy originally proposed by Niklaus Wirth. 
• Refinement is actually a process of elaboration. You begin with a statement of function (or description of information) that is defined at a high level of abstraction. That is, the statement describes function or information conceptually but provides no information about the internal workings of the function or the internal structure of the information. 
• You then elaborate on the original statement, providing more and more detail as each successive refinement (elaboration) occurs.

• Abstraction and refinement are complementary concepts. 
• Abstraction enables you to specify procedure and data internally but suppress the need for “outsiders” to have knowledge of low-level details. 
• Refinement helps you to reveal (disclose) low-level details as design progresses. Both concepts allow you to create a complete design model as the design develops.

(9) Aspects

( Features / phases )

• A representation of a cross-cutting concern that must be accommodated as refinement and modularization occur.
• For example : (Module A cross cut Module B means B cannot be satisfied without considering A).

(10)Refactoring

( Features / phases )

• Refactoring is a reorganization technique that simplifies the design (or code) of a component without changing its function or behavior.
• Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code [design] yet improves its internal structure.
• When software is refactored, the existing design is examined for redundancy, unused design elements, inefficient or unnecessary algorithms, poorly constructed or inappropriate data structures, or any other design failure that can be corrected to yield a better design.

(11) Object-Oriented Design Concepts 

• The object-oriented (OO) paradigm is widely used in modern software engineering. 
• OO design concepts such as classes and objects, inheritance, messages, and polymorphism, among others are the different features of oo paradigm.

(12) Design Class 

• Refine analysis classes by providing detail needed to implement the classes and implement a software infrastructure the support the business solution 
• Five types of design classes can be developed to support the design architecture…..
• User interface classes – abstractions needed for human-computer interaction (HCI) 
• Business domain classes – refinements of earlier analysis classes 
• Process classes – implement lower level business abstractions required to fully manage the business domain classes. 
• Persistent classes – represents data stores that will persist beyond software execution 
• System classes – implement software management and control functions…