Chapter 05

1
Software Design
Software Engineering - Le Vu Hao 8/2/2023

2 Content
✓ Design Concepts
✓ Architecture Design
✓ Component-Level Design

Design Concepts
3

4 What is Software Design?
 Software design is a process to transform user requirements into some

suitable form, which helps the programmer in software coding and
implementation.
 It is concerned with converting the client's requirements as defined in the
SRS (Software Requirement Specification) document into a form that can
be easily implemented using a programming language.
 The software design phase shifts the focus from the problem domain to the
solution domain.
 In software design, the system is viewed as a collection of components or
modules with clearly defined behaviors and bounds.

5

6 Fundamental Software Design
Concepts

7 Abstraction
 Abstraction is one of the fundamental ways that we as humans cope with

complexity.

8 Procedural abstraction
 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.

9 Abstraction
 A data abstraction is a
named collection of data
that describes a data object.

10 Architecture
 Software architecture: the overall structure of the software and the ways in
which that structure provides conceptual integrity for a system.

11 Structural properties
 Representation defines the

components of a system (e.g.,
modules, objects, filters) and
the manner in which those
components are packaged
and interact with one another.

12 Extra-functional properties
 Address how the design architecture achieves requirements for

performance, capacity, reliability, security, adaptability, and other system
characteristics.

13 Families of related systems
 Upon repeatable patterns

that are commonly
encountered in the design
of families of similar systems.
In essence, the design
should have the ability to
reuse architectural building
blocks.

14 Patterns
 Each pattern describes a problem which

occurs over and over again in our
environment, and then describes the core of
the solution to that problem, in such a way
that you can use this solution a million times
over, without ever doing it the same way
twice.

15 Separation of Concerns
 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

16 Modularity
 Software is divided into

separately named and
addressable components,
sometimes called modules,
that are integrated to satisfy
problem requirements.

17 Information Hiding
 The intent of information hiding is

to hide the details of data
structures and procedural
processing behind a module
interface. Knowledge of the
details need not be known by
users of the module.

18 Why Information Hiding?
 reduces the likelihood of “side effects”

 limits the global impact of local design decisions
 emphasizes communication through controlled interfaces
 discourages the use of global data
 leads to encapsulation - an attribute of high quality design
 results in higher quality software

19 Functional Independence
 Each module addresses a specific subset of requirements and has a simple

interface when viewed from other parts of the program structure.
 Independent modules are easier to maintain (and test) because
secondary effects caused by design or code modification are limited, error
propagation is reduced, and reusable modules are possible.

20 Cohesion
 Cohesion is a qualitative indication of the degree to which a module

focuses on just one thing.
 High cohesion means that elements are closely related and focused on a
single purpose, while low cohesion means that elements are loosely related
and serve multiple purposes.

21 Coupling
 Coupling is a qualitative indication of the degree to which a module is

connected to other modules and to the outside world.
 High coupling means that modules are closely connected and changes in
one module may affect other modules.
 Low coupling means that modules are independent and changes in one
module have little impact on other modules.

22 Cohesion vs. Coupling
 Both coupling and cohesion are important factors in determining the

maintainability, scalability, and reliability of a software system. High
coupling and low cohesion can make a system difficult to change and test,
while low coupling and high cohesion make a system easier to maintain
and improve.

23 Refinement
 Stepwise refinement is a top-down design

strategy originally proposed by Niklaus.
 A program is developed by successively
refining levels of procedural detail.
 A hierarchy is developed by
decomposing a macroscopic statement
of function (a procedural abstraction) in
a stepwise fashion until programming
language statements are reached.

24 Aspects
 A crosscutting concern is
some characteristic of the
system that applies across
many different
requirements.
 An aspect is a
representation of a
crosscutting concern.
 The design architecture
should support a
mechanism for defining an
aspect—a module that
enables the concern to be
implemented across all
other concerns that it
crosscuts.

25 Refactoring
 Refactoring is the process of reorganizing code without affecting its original

functionality.
 Refactoring aims to improve internal code by making modest changes that
do not affect the code's exterior behavior.
 Computer programmers and software developers refactor code to
improve the software's design, structure, and implementation.

26 OO Design Concepts
 Inheritance: A subclass Y inherits all of the attributes and operations

associated with its superclass X. This means that all data structures and
algorithms originally designed and implemented for X are immediately
available for Y – no further work need be done.
 Messages: Classes must interact with one another to achieve design goals.
A message stimulates some behavior to occur in the receiving object. The
behavior is accomplished when an operation is executed.
 Polymorphism - means "many forms", and it occurs when we have many
classes that are related to each other by inheritance.

27 Design Classes
 User interface classes define all abstractions that are necessary for human
computer interaction (HCI).
 Business domain classes are often refinements of the analysis classes
defined earlier. The classes identify the attributes and services (methods)
that are required to implement some element of the business domain.
 Process classes implement lower-level business abstractions required to fully
manage the business domain classes.
 Persistent classes represent data stores (e.g., a database) that will persist
beyond the execution of the software.
 System classes implement software management and control functions
that enable the system to operate and communicate within its computing
environment and with the outside world.

28 “well formed” Design Classes
 Complete and sufficient: complete encapsulation of all attributes and

methods that can reasonably be expected (based on a knowledgeable
interpretation of the class name) to exist for the class.
 Primitiveness: methods associated with a design class should be focused on
accomplishing one specific function for the class.
 High cohesion: single minded: a small, focused set of responsibilities and
single-mindedly applies attributes and methods to implement those
responsibilities.
 Low coupling: within the design model, it is necessary for design classes to
collaborate with one another. However, collaboration should be kept to an
acceptable minimum.

29 The Design Model

Architectural Design
30

31 Attribute-Driven Design (ADD)

32
Architectural Genres
Architecture in application domains

33 Application domains
 Artificial intelligence - Systems that simulate or augment human cognition,

locomotion, or other organic processes.
 Commercial and nonprofit - Systems that are fundamental to the operation of a
business enterprise.
 Communications - Systems that provide the infrastructure for transferring and
managing data, for connecting users of that data, or for presenting data at the
edge of an infrastructure.
 Content authoring - Systems that are used to create or manipulate textual or
multimedia artifacts.
 Devices - Systems that interact with the physical world to provide some point
service for an individual.
 Entertainment and sports - Systems that manage public events or that provide a
large group entertainment experience.

 Financial - Systems that provide the infrastructure for transferring and managing
money and other securities.
 Games—Systems that provide an entertainment experience for individuals or
groups.
 Government - Systems that support the conduct and operations of a local,
state, federal, global, or other political entity.
 Industrial - Systems that simulate or control physical processes.
 Legal - Systems that support the legal industry.
 Medical - Systems that diagnose or heal or that contribute to medical research.
 Military - Systems for consultation, communications, command, control, and
intelligence (C4I) as well as offensive and defensive weapons.

 Operating systems - Systems that sit just above hardware to provide basic
software services.
 Platforms - Systems that sit just above operating systems to provide
advanced services.
 Scientific - Systems that are used for scientific research and applications.
 Tools -Systems that are used to develop other systems.
 Transportation - Systems that control water, ground, air, or space vehicles.
 Utilities - Systems that interact with other software to provide some point
service.

36
Architecture Patterns

37 Layered Architecture

38

39 Event-driven architecture

40 Client-server (Master-slave)
architecture

41 Web Application Architecture

Component-Level
Design
42

43 Component design
 Component design is a type of

software design and
architecture. The component-
based architecture focuses on
breaking the software design
into small individual modules.
The component design
describes communication,
interfaces, algorithms, and the
functionalities of each
component regarding the
whole software design.

44 Benefits of component design design
 The major benefit of using the Component design is that it makes every
module reusable.
 It also reduces the cost as every module is reusable.
 It is more reliable as the client gets its interaction with the system with
each module, so it increases the reliability of the entire system.
 The component design makes the system easy to maintain as we don't
need to make changes in the entire system.
 The component design describes each component's functionality more
clearly.

45 Component design views
 Object-Oriented view: the modules consist of a set of classes or objects

with some common properties and functionalities and how classes in
each module are connected.
 Traditional view: the module acts like a functional part of the software
which means it is responsible for processing all logical and internal
operations according to their designated task. The traditional view
module also plays a vital role in calling and coordinating the request of
other modules.
 Process-related view: uses pre-existed modules for the creation of new
modules. Databases and libraries are used to store pre-existed modules.
The process-related view majorly focuses on the reusability feature of the
component design.

46 Object-Oriented View

47 Structure chart for a traditional system

48 Design elaboration
 The ComputePageCost
module is elaborated to
provide algorithm detail
and interface detail

49 Basic Design Principles
 The Open-Closed Principle (OCP). “A module [component] should be open

for extension but closed for modification”.
 The Liskov Substitution Principle (LSP). “Subclasses should be substitutable for
their base classes”.
 Dependency Inversion Principle (DIP). “Depend on abstractions. Do not
depend on concretions.”

50 Basic Design Principles
 The Interface Segregation Principle (ISP). “Many client-specific interfaces

are better than one general purpose interface”.
 The Release Reuse Equivalency Principle (REP). “The granule of reuse is the
granule of release.”
 The Common Closure Principle (CCP). “Classes that change together
belong together.”
 The Common Reuse Principle (CRP). “Classes that arenʼt reused together
should not be grouped together.”

51 Open-Closed Principle
 The sensor interface presents a consistent view of sensors to the detector

component. If a new type of sensor is added no change is required for the
Detector class (component)

52 Liskov Substitution Principle Violation
Example
 Cannot implement the
method
get100MileFuelRequireme
nts

53 Dependency Inversion Principle

54 The Interface Segregation Principle

55 The Release Reuse Equivalency
Principle

56 The Common Closure Principle
 Classes should be packaged cohesively. That is, when classes are

packaged as part of a design, they should address the same functional or
behavioral area. When some characteristic of that area must change, it is
likely that only those classes within the package will require modification.
This leads to more effective change control and release management.

57 The Common Reuse Principle
 When one or more classes within a package changes, the release number
of the package changes. All other classes or packages that rely on the
package that has been changed must now update to the most recent
release of the package and be tested to ensure that the new release
operates without incident. If classes are not grouped cohesively, it is
possible that a class with no relationship to other classes within a package
is changed. This will precipitate unnecessary integration and testing. For
this reason, only classes that are reused together should be included
within a package.

58 Cohesion

59 Cohesion
 Functional: Exhibited primarily by operations, this level of cohesion occurs

when a component performs a targeted computation and then returns a
result.
 Layer: Exhibited by packages, components, and classes, this type of
cohesion occurs when a higher layer accesses the services of a lower layer,
but lower layers do not access higher layers.
 Communicational: All operations that access the same data are defined
within one class.

60 Functional Cohesion

61 Layer Cohesion

62 Low vs. High Cohesion

63 Advantages of High Cohesion
 It is easier to make code changes since all the related code is within the
module.
 It is easier to test the code. Since such modules do not depend on other
modules for their purpose, they are easy to unit test.
 Overall, highly cohesive modules reflect better quality of software design.
Hence, look for elements in a module, that are not directly related to the
main purpose. Move them to some other module that better fits the
purpose or create a new module.

64 Coupling

65 Types of Coupling

 Content coupling. Occurs when one component “surreptitiously modifies

data that is internal to another component” [Let01]. This violates
information hiding - a basic design concept.
 Common coupling. Occurs when a number of components all make use of
a global variable. Although this is sometimes necessary (e.g., for
establishing default values that are applicable throughout an application),
common coupling can lead to uncontrolled error propagation and
unforeseen side effects when changes are made.
 Control coupling. Occurs when operation A() invokes operation B() and
passes a control flag to B. The control flag then “directs” logical flow within
B. The problem with this form of coupling is that an unrelated change in B
can result in the necessity to change the meaning of the control flag that A
passes. If this is overlooked, an error will result.

 Stamp coupling. Occurs when ClassB is declared as a type for an argument

of an operation of ClassA. Because ClassB is now a part of the definition of
ClassA, modifying the system becomes more complex.
 Data coupling. Occurs when operations pass long strings of data
arguments. The “bandwidth” of communication between classes and
components grows and the complexity of the interface increases. Testing
and maintenance are more difficult.
 Routine call coupling. Occurs when one operation invokes another. This
level of coupling is common and is often quite necessary. However, it does
increase the connectedness of a system.

 Type use coupling. Occurs when component A uses a data type defined in
component B (e.g., this occurs whenever “a class declares an instance
variable or a local variable as having another class for its type” [Let01]). If
the type definition changes, every component that uses the definition must
also change.
 Inclusion or import coupling. Occurs when component A imports or
includes a package or the content of component B.
 External coupling. Occurs when a component communicates or
collaborates with infrastructure components (e.g., operating system
functions, database capability, telecommunication functions). Although
this type of coupling is necessary, it should be limited to a small number of
components or classes within a system.

69 Tight vs. Loose Coupling

70 Advantages of Low Coupling
 Tightly coupled modules are difficult to change. The developer needs to

understand multiple modules and how they relate to each other. They
need to be careful in making changes to all the modules consistently. This
makes it more error-prone. Also, we need to build, test and deploy each
changed module, further increasing the development effort.
 Tightly coupled modules are also difficult to test. Unit testing a single
module is difficult since it heavily depends on other modules. Significant
effort has to be spent in mocking the calls to other modules so that the
module can be independently unit tested.

71 Component-level design for an object-
oriented system.
 Step 1. Identify all design classes that correspond to the problem domain.
 Step 2. Identify all design classes that correspond to the infrastructure
domain: GUI components (often available as reusable components),
operating system components, and object and data management
components.
 Step 3. Elaborate all design classes that are not acquired as reusable
components.
 Step 3a. Specify message details when classes or components collaborate:
can use “Collaboration diagram with messaging”
 Step 3b. Identify appropriate interfaces for each component.

72 Component-level design for an object-
oriented system.
 Step 3c. Elaborate attributes and define data types and data structures
required to implement them.
 Step 3d. Describe processing flow within each operation in detail: using a
programming language-based pseudocode or with a UML activity diagram.
 Step 4. Describe persistent data sources (databases and files) and identify the
classes required to manage them.
 Step 5. Develop and elaborate behavioral representations for a class or
component: using a UML state chart
 Step 6. Elaborate deployment diagrams to provide additional implementation
detail.
 Step 7. Refactor every component-level design representation and always
consider alternatives

73 Collaboration diagram with messaging

74 Refactoring interfaces and class
definitions for PrintJob

75
 UML activity diagram for

computePaperCost()

76

77 UML state chart

78

Chapter 05

Uploaded by

Copyright:

Available Formats

You might also like

Chapter 05

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chapter 05

Uploaded by

Copyright:

Available Formats

1

Software Engineering - Le Vu Hao 8/2/2023

Software Engineering - Le Vu Hao 8/2/2023

Software Engineering - Le Vu Hao 8/2/2023

 Software design is a process to transform user requirements into some

Software Engineering - Le Vu Hao 8/2/2023

Software Engineering - Le Vu Hao 8/2/2023

Software Engineering - Le Vu Hao 8/2/2023

 Abstraction is one of the fundamental ways that we as humans cope with

Software Engineering - Le Vu Hao 8/2/2023

Software Engineering - Le Vu Hao 8/2/2023

Software Engineering - Le Vu Hao 8/2/2023

Software Engineering - Le Vu Hao 8/2/2023

 Representation defines the

Software Engineering - Le Vu Hao 8/2/2023

 Address how the design architecture achieves requirements for

Software Engineering - Le Vu Hao 8/2/2023

 Upon repeatable patterns

Software Engineering - Le Vu Hao 8/2/2023

 Each pattern describes a problem which

Software Engineering - Le Vu Hao 8/2/2023

 Any complex problem can be more easily handled if it is subdivided into

Software Engineering - Le Vu Hao 8/2/2023

 Software is divided into

Software Engineering - Le Vu Hao 8/2/2023

 The intent of information hiding is

Software Engineering - Le Vu Hao 8/2/2023

 reduces the likelihood of “side effects”

Software Engineering - Le Vu Hao 8/2/2023

 Each module addresses a specific subset of requirements and has a simple

Software Engineering - Le Vu Hao 8/2/2023

 Cohesion is a qualitative indication of the degree to which a module

Software Engineering - Le Vu Hao 8/2/2023

 Coupling is a qualitative indication of the degree to which a module is

Software Engineering - Le Vu Hao 8/2/2023

 Both coupling and cohesion are important factors in determining the

Software Engineering - Le Vu Hao 8/2/2023

 Stepwise refinement is a top-down design

Software Engineering - Le Vu Hao 8/2/2023

Software Engineering - Le Vu Hao 8/2/2023

 Refactoring is the process of reorganizing code without affecting its original

Software Engineering - Le Vu Hao 8/2/2023

 Inheritance: A subclass Y inherits all of the attributes and operations

Software Engineering - Le Vu Hao 8/2/2023

Software Engineering - Le Vu Hao 8/2/2023

 Complete and sufficient: complete encapsulation of all attributes and

Software Engineering - Le Vu Hao 8/2/2023

Software Engineering - Le Vu Hao 8/2/2023

Software Engineering - Le Vu Hao 8/2/2023

Software Engineering - Le Vu Hao 8/2/2023

Software Engineering - Le Vu Hao 8/2/2023

 Artificial intelligence - Systems that simulate or augment human cognition,

Software Engineering - Le Vu Hao 8/2/2023

Software Engineering - Le Vu Hao 8/2/2023

Software Engineering - Le Vu Hao 8/2/2023

Software Engineering - Le Vu Hao 8/2/2023

Software Engineering - Le Vu Hao 8/2/2023

Software Engineering - Le Vu Hao 8/2/2023