1.

Design Process and Design Quality

Design Process

The design process is a crucial stage in software engineering, involving the systematic
transformation of specified requirements into a blueprint for constructing a software product.
According to Ranjib Mall, the design process aims to ensure that the software meets its
functional and performance requirements while adhering to constraints such as cost, time,
and technical feasibility.

Phases of the Design Process

The software design process can be divided into two key levels:

1. High-Level Design (HLD)

This stage involves the architectural design of the software system, focusing on:
○ System structure: Defining the modules, their responsibilities, and
interactions.
○ Data flow: Establishing the flow of data between system components using
tools like Data Flow Diagrams (DFDs).
○ Interface design: Specifying the interfaces between modules and external
systems.
2. Key outputs include architectural diagrams, module specifications, and interface
definitions.
3. Detailed Design (Low-Level Design)
This phase zooms in on the internal details of each module or component, covering:
○ Algorithms: Logical steps for each functionality.
○ Data structures: Selection of appropriate data representations.
○ Class and object definitions: In object-oriented designs, this includes
identifying classes, objects, and their interactions.
4. Deliverables at this stage include detailed flowcharts, pseudocode, and class
diagrams.

Iterative Nature of Design

The design process is iterative and often revisited to refine and optimize solutions. Early
designs might focus on achieving functionality, while subsequent iterations improve
performance, reliability, and maintainability.

Design Quality

Design quality ensures that the software product is robust, maintainable, and aligns with
user expectations. Ranjib Mall identifies several attributes that define design quality:
 1. Correctness:
The design should accurately meet the specifications and requirements set forth in
the analysis phase.
2. Understandability:
The design should be easy for developers to comprehend, facilitating maintenance
and further development.
3. Efficiency:
Resources like memory, CPU, and bandwidth should be utilized optimally.
4. Reusability:
Components of the design should be general enough to be reused in other projects
or modules.
5. Modifiability:
The design should allow for easy modifications to accommodate changes in
requirements or enhancements.
6. Completeness:
All specified functionalities should be addressed, leaving no ambiguous or
incomplete aspects.
7. Testability:
The design should make it easy to write test cases and validate the system against
requirements.

2. Design Concepts
Ranjib Mall emphasizes key design concepts that serve as principles to guide the creation
of software designs. These are foundational ideas that ensure the design process remains
consistent and effective.

Key Design Concepts

1. Abstraction
Abstraction is the process of simplifying complex systems by focusing on relevant
details while ignoring irrelevant ones. It is achieved through hierarchical
representation, such as high-level abstractions (system-level) and low-level
abstractions (module-level).
2. Modularity
○ Definition: Dividing the software system into smaller, manageable
components or modules.
○ Benefits: Improves maintainability, enhances reusability, and isolates faults.
○ Each module should follow the principle of high cohesion (focused
responsibility) and low coupling (minimal dependencies).
3. Encapsulation
○ Bundling data and methods that operate on the data into a single unit,
typically a class in object-oriented design.
○ Ensures data hiding, meaning that internal details of a module are not
exposed to the outside.
 4. Separation of Concerns
○ The design should separate different functionalities into distinct modules.
○ For instance, business logic, data access, and presentation layers should be
designed independently.
5. Hierarchy and Layering
○ A hierarchical structure organizes modules in levels, ensuring a clear
relationship between components.
○ Examples include the layered architecture in web applications (e.g.,
presentation, application, and data layers).
6. Refinement
○ Gradually elaborating on the design by moving from abstract concepts to
concrete details.
○ Refinement aligns with iterative development models.
7. Structural Design Concepts
These include organizing modules based on their control and data flow, such as call
and return mechanisms, and the use of shared data.

3. Design Models
Design models are representations used to visualize, specify, construct, and document the
software architecture and components.

Types of Design Models

1. Data Design
○ Focuses on designing the data structures and database models.
○ Tools: Entity-Relationship Diagrams (ERDs), data dictionaries, and
normalization techniques.
2. Architectural Design
○ Represents the high-level structure of the system, including components and
their interactions.
○ Examples include layered architecture, microservices, and client-server
models.
3. Component-Level Design
○ Defines the internal structure of each module, such as its methods, data
attributes, and interfaces.
○ Tools: UML class diagrams, pseudocode, and flowcharts.
4. Interface Design
○ Specifies how modules communicate with one another and with external
systems.
○ Focuses on APIs, user interfaces (UI), and external hardware interfaces.
5. Behavioral Design
○ Describes the dynamic behavior of the system using tools like state diagrams
and sequence diagrams.
○ Explains how the system responds to various inputs and conditions.
4. Object-Oriented Design (OOD)
Overview

Object-Oriented Design is a methodology where the software system is modeled as a

collection of interacting objects. Each object represents a real-world entity, encapsulating
data and the methods to manipulate that data.

Principles of OOD

1. Encapsulation:
○ Bundling data and behavior into a single unit (object).
○ Ensures data hiding, exposing only necessary details.
2. Inheritance:
○ Allows one class (child) to inherit attributes and methods from another class
(parent).
○ Promotes code reuse and hierarchical relationships.
3. Polymorphism:
○ Enables a single interface to represent different data types or behaviors.
○ Example: A Shape class might define a draw() method, implemented
differently by Circle and Rectangle.
4. Abstraction:
○ Hiding implementation details while exposing only essential features.
○ Example: A user interacting with a Car object needs to know how to drive, not
the internal workings of the engine.

Object-Oriented Design Process

1. Identify Classes and Objects:

○ Use tools like CRC (Class-Responsibility-Collaboration) cards to identify
entities.
2. Define Relationships:
○ Establish associations like inheritance (is-a), composition (has-a), and
dependencies.
3. Design Attributes and Methods:
○ Define what data each object holds and what operations it performs.
4. Model Interactions:
○ Use sequence diagrams and collaboration diagrams to model how objects
interact.
5. Iterate and Refine:
○ Refactor classes to optimize design principles like cohesion and coupling.
5. UML Class Diagram
The UML Class diagram is a graphical notation used to construct and visualize

object oriented systems. A class diagram in the Unified Modeling Language (UML) is

a type of static structure diagram that describes the structure of a system by showing

the system's:

● classes,

● their attributes,

● operations (or methods),

● and the relationships among objects.

What is a Class?

A Class is a blueprint for an object. Objects and classes go hand in hand. We can't

talk about one without talking about the other. And the entire point of Object-Oriented

Design is not about objects, it's about classes, because we use classes to create

objects. So a class describes what an object will be, but it isn't the object itself.

In fact, classes describe the type of objects, while objects are usable instances of

classes. Each Object was built from the same set of blueprints and therefore

contains the same components (properties and methods). The standard meaning is

that an object is an instance of a class and object - Objects have states and

behaviors.

Example

A dog has states - color, name, breed as well as behaviors -wagging, barking,

eating. An object is an instance of a class.

UML Class Notation

A class represent a concept which encapsulates state (attributes) and behavior

(operations). Each attribute has a type. Each operation has a signature. The class

name is the only mandatory information.

Class Name:

● The name of the class appears in the first partition.

Class Attributes:

● Attributes are shown in the second partition.

● The attribute type is shown after the colon.

● Attributes map onto member variables (data members) in code.

Class Operations (Methods):

● Operations are shown in the third partition. They are services the class

provides.

● The return type of a method is shown after the colon at the end of the method

signature.

● The return type of method parameters are shown after the colon following the

parameter name. Operations map onto class methods in code

Class Visibility

The +, - and # symbols before an attribute and operation name in a class denote the

visibility of the attribute and operation.

 ● + denotes public attributes or operations

● - denotes private attributes or operations

● # denotes protected attributes or operations

Parameter Directionality

Each parameter in an operation (method) may be denoted as in, out or inout which

specifies its direction with respect to the caller. This directionality is shown before the

parameter name.

Perspectives of Class Diagram

The choice of perspective depends on how far along you are in the development

process. During the formulation of a domain model, for example, you would seldom

move past the conceptual perspective. Analysis models will typically feature a

mix of conceptual and specification perspectives. Design model development

will typically start with heavy emphasis on the specification perspective, and

evolve into the implementation perspective.

A diagram can be interpreted from various perspectives:

● Conceptual: represents the concepts in the domain

● Specification: focus is on the interfaces of Abstract Data Type (ADTs) in the

software

● Implementation: describes how classes will implement their interfaces

The perspective affects the amount of detail to be supplied and the kinds of

relationships worth presenting. As we mentioned above, the class name is the only

mandatory information.

Relationships between classes

UML is not just about pretty pictures. If used correctly, UML precisely conveys how

code should be implemented from diagrams. If precisely interpreted, the

implemented code will correctly reflect the intent of the designer. Can you describe

what each of the relationships mean relative to your target programming language

shown in the

Figure below?

If you can't yet recognize them, no problem this section is meant to help you to

understand UML class relationships. A class may be involved in one or more

relationships with other classes. A relationship can be one of the following types:
Inheritance (or Generalization):

A generalization is a taxonomic relationship between a more general classifier and a

more specific classifier. Each instance of the specific classifier is also an indirect

instance of the general classifier. Thus, the specific classifier inherits the features of

the more general classifier.

● Represents an "is-a" relationship.

● An abstract class name is shown in italics.

● SubClass1 and SubClass2 are specializations of SuperClass.

The figure below shows an example of inheritance hierarchy. SubClass1 and

SubClass2 are derived from SuperClass. The relationship is displayed as a solid line

with a hollow arrowhead that points from the child element to the parent element.
Inheritance Example - Shapes

The figure below shows an inheritance example with two styles. Although the

connectors are drawn differently, they are semantically equivalent.

Association

Associations are relationships between classes in a UML Class Diagram. They are

represented by a solid line between classes. Associations are typically named using

a verb or verb phrase which reflects the real world problem domain.

Simple Association

● A structural link between two peer classes.

 ● There is an association between Class1 and Class2

The figure below shows an example of simple association. There is an association

that connects the <<control>> class Class1 and <<boundary>> class Class2. The

relationship is displayed as a solid line connecting the two classes.

Cardinality

Cardinality is expressed in terms of:

● one to one

● one to many

● many to many

Aggregation

A special type of association.

● It represents a "part of" relationship.

● Class2 is part of Class1.

 ● Many instances (denoted by the *) of Class2 can be associated with Class1.

● Objects of Class1 and Class2 have separate lifetimes.

The figure below shows an example of aggregation. The relationship is displayed as

a solid line with a unfilled diamond at the association end, which is connected to the

class that represents the aggregate.

Composition

● A special type of aggregation where parts are destroyed when the whole is

destroyed.

● Objects of Class2 live and die with Class1.

● Class2 cannot stand by itself.

The figure below shows an example of composition. The relationship is displayed as

a solid line with a filled diamond at the association end, which is connected to the

class that represents the whole or composite.

Dependency

An object of one class might use an object of another class in the code of a method.

If the object is not stored in any field, then this is modeled as a dependency

relationship.

● A special type of association.

 ● Exists between two classes if changes to the definition of one may cause

changes to the other (but not the other way around).

● Class1 depends on Class2

The figure below shows an example of dependency. The relationship is displayed as

a dashed line with an open arrow.

The figure below shows another example of dependency. The Person class might

have a hasRead method with a Book parameter that returns true if the person has

read the book (perhaps by checking some database).

Realization

Realization is a relationship between the blueprint class and the object containing its

respective implementation level details. This object is said to realize the blueprint

class. In other words, you can understand this as the relationship between the

interface and the implementing class.

For example, the Owner interface might specify methods for acquiring property and

disposing of property. The Person and Corporation classes need to implement these

methods, possibly in very different ways.

Class Diagram Example: Order System

Class Diagram Example: GUI

A class diagram may also have notes attached to classes or relationships.

6. UML Sequence Diagram
What is a sequence diagram in UML?
To understand what a sequence diagram is, it's important to know the role of the Unified
Modeling Language, better known as UML. UML is a modeling toolkit that guides the
creation and notation of many types of diagrams, including behavior diagrams, interaction
diagrams, and structure diagrams.

A sequence diagram is a type of interaction diagram because it describes how—and in what

order—a group of objects works together. These diagrams are used by software developers
and business professionals to understand requirements for a new system or to document an
existing process. Sequence diagrams are sometimes known as event diagrams or event
scenarios.

Note that there are two types of sequence diagrams: UML diagrams and code-based
diagrams. The latter is sourced from programming code and will not be covered in this guide.
Lucidchart’s UML diagramming software is equipped with all the shapes and features you
will need to model both. And with our diagram as code feature, it’s faster and easier than
ever. You can create a custom sequence diagram on your Lucidchart document using
Mermaid coding.

Benefits of sequence diagrams

Sequence diagrams can be useful references for businesses and other organizations. Try
drawing a sequence diagram to:
● Represent the details of a UML use case.
● Model the logic of a sophisticated procedure, function, or operation.
● See how objects and components interact with each other to complete a process.
 ● Plan and understand the detailed functionality of an existing or future scenario.

Use cases for sequence diagrams

The following scenarios are ideal for using a sequence diagram:
● Usage scenario: A usage scenario is a diagram of how your system could potentially
be used. It's a great way to make sure that you have worked through the logic of
every usage scenario for the system.
● Method logic: Just as you might use a UML sequence diagram to explore the logic of
a use case, you can use it to explore the logic of any function, procedure, or complex
process.
● Service logic: If you consider a service to be a high-level method used by different
clients, a sequence diagram is an ideal way to map that out.
● Sequence diagram Visio - Any sequence diagram that you create with Visio can also
be uploaded into Lucidchart. Lucidchart supports .vsd and .vdx file import and is a
great Microsoft Visio alternative. Almost all of the images you see in the UML section
of this site were generated using Lucidchart.

7. UML Collaboration Diagram

What is UML Collaboration Diagram?
Collaboration diagrams (known as Communication Diagram in UML 2.x) are used
to show how objects interact to perform the behavior of a particular use
case, or a part of a use case. Along with sequence diagrams, collaboration
are used by designers to define and clarify the roles of the objects that
perform a particular flow of events of a use case. They are the primary
source of information used to determining class responsibilities and
interfaces.

What is a Collaboration?

● A Collaboration is a collection of named objects and actors with

links connecting them. They collaborate in performing some task.
● A Collaboration defines a set of participants and relationships that
are meaningful for a given set of purposes
● A Collaboration between objects working together provides emergent
desirable functionalities in Object-Oriented systems
● Each object (responsibility) partially supports emergent
functionalities
● Objects are able to produce (usable) high-level functionalities by
working together
● Objects collaborate by communicating (passing messages) with one
another in order to work together
Why Collaboration Diagram?
Unlike a sequence diagram, a collaboration diagram shows the relationships
among the objects. Sequence diagrams and collaboration diagrams express
similar information, but show it in different ways.
Because of the format of the collaboration diagram, they tend to better
suited for analysis activities (see Activity: Use-Case Analysis).
Specifically, they tend to be better suited to depicting simpler
interactions of smaller numbers of objects. However, if the number of
objects and messages grows, the diagram becomes increasingly hard to read.
In addition, it is difficult to show additional descriptive information
such as timing, decision points, or other unstructured information that can
be easily added to the notes in a sequence diagram. So, here are some use
cases that we want to create a collaboration diagram for:

● Model collaborations between objects or roles that deliver the

functionalities of use cases and operations
● Model mechanisms within the architectural design of the system
● Capture interactions that show the messages passing between objects
and roles within the collaboration
● Model alternative scenarios within use cases or operations that
involve the collaboration of different objects and interactions
● Support the identification of objects (hence classes) that
participate in use cases
● Each message in a collaboration diagram has a sequence number.
● The top-level message is numbered 1. Messages sent during the same
call have the same decimal prefix but suffixes of 1, 2, etc.
according to when they occur.

Notations of Collaboration Diagram

Objects
An object is represented by an object symbol showing the name of the object
and its class underlined, separated by a colon:
Object_name : class_name
You can use objects in collaboration diagrams in the following ways:

● Each object in the collaboration is named and has its class specified
● Not all classes need to appear
● There may be more than one object of a class
● An object’s class can be unspecified. Normally you create a
collaboration diagram with objects first and specify their classes
later.
 ● The objects can be unnamed, but you should name them if you want to
discriminate different objects of the same class.

Actors
Normally an actor instance occurs in the collaboration diagram, as the
invoker of the interaction. If you have several actor instances in the same
diagram, try keeping them in the periphery of the diagram.

● Each Actor is named and has a role

● One actor will be the initiator of the use case

Links
Links connect objects and actors and are instances of associations and each
link corresponds to an association in the class diagram
Links are defined as follows:

● A link is a relationship among objects across which messages can be

sent. In collaboration diagrams, a link is shown as a solid line
between two objects.
● An object interacts with, or navigates to, other objects through its
links to these objects.
● A link can be an instance of an association, or it can be anonymous,
meaning that its association is unspecified.
● Message flows are attached to links, see Messages.

Messages
A message is a communication between objects that conveys information with
the expectation that activity will ensue. In collaboration diagrams, a
message is shown as a labeled arrow placed near a link.

● The message is directed from sender to receiver

● The receiver must understand the message
● The association must be navigable in that direction

Steps for Creating Collaboration Diagrams

1. Identify behavior whose realization and implementation is specified
2. Identify the structural elements (class roles, objects, subsystems)
necessary to carry out the functionality of the collaboration
● Decide on the context of interaction: system, subsystem, use
case and operation
 3. Model structural relationships between those elements to produce a
diagram showing the context of the interaction
4. Consider the alternative scenarios that may be required
● Draw instance level collaboration diagrams, if required.
● Optionally draw a specification level collaboration diagram to
summarize the alternative scenarios in the instance level
sequence diagrams

Collaboration Diagram Example

Collaboration Diagram in Robustness Diagram Format

You can have objects and actor instances in collaboration diagrams,
together with links and messages describing how they are related and how
they interact. The Receive Deposit Item in the Recycling-Machine System
diagram shown below describes what takes place in the participating
objects, in terms of how the objects communicate by sending messages to one
another. You can make a collaboration diagram for each variant of a use
case’s flow of events.