J.E.D.I
the number of links an object has and by the degree of interaction it has with other objects. For object-oriented design, two types of coupling are used.
1. Interaction Coupling is the measure of the number of message types an
object sends to another object, and the number of parameters passed with these message types. Good interaction coupling is kept to a minimum to
avoid possible change ripples through the interface.
2. Inheritance Coupling is the degree to which a subclass actually needs the
features attributes and operations it inherits from its base class. One minimize the number of attributes and operations that are unnecessarily
inherited.
Cohesion is the measure to which an element attribute, operation, or class within a package contributes to a single purpose. For object-oriented design, three types of
cohesion are used.
1. Operation Cohesion is the degree to which an operation focuses on a single
functional requirement. Good design produces highly cohesive operations.
2. Class Cohesion is the degree to which a class is focused on a single
requirement.
3. Specialization Cohesion address the semantic cohesion of inheritance.
Inheritance definition should reflect true inheritance rather than sharing syntactic structure.
Refinement Refinement is also known as the process of elaboration. Abstraction complements
refinement as they enable a software engineer to specify the behavior and data of a class or module yet suppressing low levels of detail. It helps the software engineer in creating
a complete design model as the design evolves. Refinement helps the software engineer to uncover the details as the development progresses.
Refactoring Refactoring is a technique that simplifies the design of the component without changing
its function and behavior. It is a process of changing the software so that the external behavior remains the same and the internal structures are improved. During
refactoring, the design model is checked for redundancy, unused design elements, inefficient or unnecessary algorithms, poorly constructed or inappropriate data structures
or any other design failures. These are corrected to produce a better design.
4.1.2 The Design Model
The work product of the design engineering phase is the design model which consists of the architectural design, data design, interface design and component-level design.
Architectural Design
This refers to the overall structure of the software. It includes the ways in which it provides conceptual integrity for a system. It represents layers, subsystems and
components. It is modeled using the package diagram of UML.
Software Engineering 123
J.E.D.I
Data Design
This refers to the design and organization of data. Entity classes that are defined in the requirements engineering phase are refined to create the logical database design.
Persistent classes are developed to access data from a database server. It is modeled using the class diagram.
Interface Design
This refers to the design of the interaction of the system with its environment, particularly, the human-interaction aspects. It includes the dialog and screen designs.
Report and form layouts are included. It uses the class diagram and state transition diagrams.
Component-level Design
This refers to the design of the internal behavior of each classes. Of particular interest are the control classes. This is the most important design because the functional
requirements are represented by these classes. It uses the class diagrams and component diagrams.
Deployment-level Design
This refers to the design of the how the software will be deployed for operational use. Software functionality, subsystems and components are distributed to the physical
environment that will support the software. The deployment diagram will be used to represent this model.
Software Engineering 124
J.E.D.I
4.2 Software Architecture
There is no general agreed definition for the term software architecture. It is interpreted differently depending upon the context. Some would describe it in terms of class
structures and the ways in which they are grouped together. Others used it to describe the overall organization of a system into subsystem. Buschmann et al.
5
defined it as follows:
A software architecture is a description of the sub-systems and components of a software system and the relationships between them. Subsystems and
components are typically specified in different views to show the relevant functional and non-functional properties of a software system. The software
architecture of a system is an artifact. It is the result of software design activity.
It is this definition that is being followed by this section. Software architecture is the layered structure of software components and the manner in which these components
interact, and the structure of the data that are used by these components. It involves making decisions on how the software is built, and normally, controls the iterative and
incremental development of the software.
Defining the architecture is important for several reasons. First, representation of software architecture enables communication between stakeholders end-users and
developers. Second, it enables design decisions that will have a significant effect on all software engineering work products for the softwares interoperability. Lastly, it gives an
intellectual view of how the system is structured and how its components work together.
It is modeled using the Package Diagram of UML. A package is a model element that can contain other elements. It is a mechanism used to organize design elements and
allows modularization of the software components.
4.2.1 Describing the Package Diagram
The Package Diagram shows the breakdown of larger systems into logical groupings of smaller subsystems. It shows groupings of classes and dependencies among them. A
dependency exists between two elements if changes to the definition of one element may cause changes to other elements. Figure 4.1 shows the basic notation of the package
diagram.
5 Buschmann, F., Meunier, R., Rohnert, H., Sommerland, P. and Stal, M., Pattern Oriented Software Architecture Volume 1, Chichester:John Wiley,
1996.
Software Engineering 125
