Lecture-5
Software Design & Architecture
(SDA)
Muhammad Jamil
Software Developer
jamil.57@[Link]
Types of Design Classes
• User interface classes – define all abstractions necessary for human-
computer interaction (usually via metaphors of real-world objects)
• Business domain classes – refined from analysis classes; identify
attributes and services (methods) that are required to implement some
element of the business domain
• Process classes – implement 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 the outside world
2
Characteristics of a Well-Formed
Design Class
• Complete and sufficient
• Contains the complete encapsulation of all attributes and methods that exist for
the class
• Contains only those methods that are sufficient to achieve the intent of the class
• Primitiveness
• Each method of a class focuses on accomplishing one service for the class
• High cohesion
• The class has a small, focused set of responsibilities and single-mindedly applies
attributes and methods to implement those responsibilities
• Low coupling
• Collaboration of the class with other classes is kept to an acceptable minimum
• Each class should have limited knowledge of other classes in other subsystems
3
The Design Model
Component-level Design
Interface Design
Architectural Design
Data/Class Design
Introduction
• The design model can be viewed in two different dimensions
• (Horizontally) The process dimension indicates the evolution of the parts
of the design model as each design task is executed
• (Vertically) The abstraction dimension represents the level of detail as
each element of the analysis model is transformed into the design model
and then iteratively refined
• Elements of the design model use many of the same UML diagrams
used in the analysis model
• The diagrams are refined and elaborated as part of the design
• More implementation-specific detail is provided
• Emphasis is placed on
• Architectural structure and style
• Interfaces between components and the outside world
• Components that reside within the architecture
5
Introduction (continued)
• Design model elements are not always developed in a sequential
fashion
• Preliminary architectural design sets the stage
• It is followed by interface design and component-level design, which
often occur in parallel
• The design model has the following layered elements
• Data/class design
• Architectural design Component-level Design
• Interface design
Interface Design
• Component-level design
•
Architectural Design
A fifth element that follows all of
Data/Class Design
the others is deployment-level design
6
Design Elements
• Data/class design
• Creates a model of data and objects that is represented at a high level of
abstraction
• Architectural design
• Depicts the overall layout of the software
• Interface design
• Tells how information flows into and out of the system and how it is
communicated among the components defined as part of the architecture
• Includes the user interface, external interfaces, and internal interfaces
• Component-level design elements
• Describes the internal detail of each software component by way of data
structure definitions, algorithms, and interface specifications
• Deployment-level design elements
• Indicates how software functionality and subsystems will be allocated within
the physical computing environment that will support the software
7
Pattern-based Software Design
• Mature engineering disciplines make use of thousands of design patterns for such
things as buildings, highways, electrical circuits, factories, weapon systems,
vehicles, and computers
• Design patterns also serve a purpose in software engineering
• Architectural patterns
• Define the overall structure of software
• Indicate the relationships among subsystems and software components
• Define the rules for specifying relationships among software elements
• Design patterns
• Address a specific element of the design such as an aggregation of components or solve
some design problem, relationships among components, or the mechanisms for
effecting inter-component communication
• Consist of creational, structural, and behavioral patterns
• Coding patterns
• Describe language-specific patterns that implement an algorithmic or data structure
element of a component, a specific interface protocol, or a mechanism for
communication among components
8
J
From Analysis Model to
Design Model
• Each element of the analysis model provides information that is
necessary to create the four design models
• The data/class design transforms analysis classes into design classes
along with the data structures required to implement the software
• The architectural design defines the relationship between major
structural elements of the software; architectural styles and design
patterns help achieve the requirements defined for the system
• The interface design describes how the software communicates with
systems that interoperate with it and with humans that use it
• The component-level design transforms structural elements of the
software architecture into a procedural description of software
components
9
From Analysis Model to
Design Model (continued)
Component-level Design
(Class-based model, Flow-oriented model
Behavioral model)
Interface Design
(Scenario-based model, Flow-oriented model
Behavioral model)
Architectural Design
(Class-based model, Flow-oriented model)
Data/Class Design
(Class-based model, Behavioral model) 10
Why this programmer’s approach?
• Design is a waste of time
• We need to show something to the customer real quick
• We are judged by the amount of LOC/month
• We expect or know that the schedule is too tight
11
However, ...
The longer you postpone coding, the sooner you’ll be finished
12
Design principles
• Abstraction
• Modularity, coupling and cohesion
• Information hiding
• Limit complexity
13
Abstraction
• procedural abstraction: natural consequence of stepwise
refinement: name of procedure denotes sequence of
actions
abstraction subproblems
time
14
Modularity
• structural criteria which tell us something about
individual modules and their interconnections
• cohesion and coupling
• cohesion: the glue that keeps a module together
• coupling: the strength of the connection between
modules
15
Types of cohesion
• coincidental cohesion
• logical cohesion
• temporal cohesion
• procedural cohesion
• communicational cohesion
• sequential cohesion
• functional cohesion
16
How to determine the cohesion
type?
• describe the purpose of the module in one sentence
• if the sentence is compound, contains a comma or more than one
verb Þ it probably has more than one function: logical or
communicational cohesion
• if the sentence contains time-related words like “first”, “then”,
“after” Þ temporal cohesion
• if the verb is not followed by a specific object Þ probably logical
cohesion (example: edit all data)
• words like “startup”, “initialize” imply temporal cohesion
17
Types of coupling
• content coupling
• common coupling
• external coupling
• control coupling
• stamp coupling
• data coupling
18
Information hiding
• each module has a secret
• design involves a series of decision: for each such
decision, wonder who needs to know and who can be
kept in the dark
• information hiding is strongly related to
• abstraction: if you hide something, the user may abstract from
that fact
• coupling: the secret decreases coupling between a module and
its environment
• cohesion: the secret is what binds the parts of the module
together
19
Complexity
• measure certain aspects of the software (lines of code, #
of if-statements, depth of nesting, …)
• use these numbers as a criterion to assess a design, or to
guide the design
• interpretation: higher value Þ higher complexity Þ
more effort required (= worse design)
• two kinds:
• intra-modular: inside one module
• inter-modular: between modules
20
Design methods
• Functional decomposition
• Data Flow Design (SA/SD)
• Design based on Data Structures (JSD/JSP)
• OO is good, isn’t it
21
Sample of design methods
• Decision tables
• OOD
• E-R
• Flowcharts
• PDL
• FSM • Petri Nets
• JSD • SA/SD
• JSP • SA/WM
• LCP • SADT
• Meta IV
• SSADM
• NoteCards
• OBJ
• Statecharts
22
Functional decomposition
bottom-up top-down
23
Functional decomposition (cnt’d)
• Extremes: bottom-up and top-down
• Not used as such; design is not purely rational:
• clients do not know what they want
• changes influence earlier decisions
• people make errors
• projects do not start from scratch
• Rather, design has a yo-yo character
• We can only fake a rational design process
24
Data flow design
• Yourdon and Constantine (early 70s)
• nowadays version: two-step process:
• Structured Analysis (SA), resulting in a logical design, drawn as a
set of data flow diagrams
• Structured Design (SD) transforming the logical design into a
program structure drawn as a set of structure charts
25
Entities in a data flow diagram
• external entities
• processes
• data flows
• data stores
26
Top-level DFD: context diagram
direction request
library
management client
system
report ack’ment
27
Design based on data structures
(JSP & JSD)
• JSP = Jackson Structured Programming (for
programming-in-the-small)
• JSD = Jackson Structured Design (for programming-in-
the-large)
28
OOAD methods
• three major steps:
1 identify the objects
2 determine their attributes and services
3 determine the relationships between objects
29
(Part of) problem statement
Design the software to support the operation of a public
library. The system has a number of stations for customer
transactions. These stations are operated by library
employees. When a book is borrowed, the identification
card of the client is read. Next, the station’s bar code
reader reads the book’s code. When a book is returned,
the identification card isnot needed and only the book’s
code needs to be read.
30
Candidate objects
• software
• library
• system
• station
• customer
• transaction
• book
• library employee
• identification card
• client
• bar code reader
31
• book’s code
Relationships
• From the problem statement:
• employee operates station
• station has bar code reader
• bar code reader reads book copy
• bar code reader reads identification card
• Tacit knowledge:
• library owns computer
• library owns stations
• computer communicates with station
• library employs employee
• client
32
is member of library
• client has identification card
OO design methods
• Booch: early, new and rich set of notations
• Fusion: more emphasis on process
• RUP: full life cycle model associated with UML
33
Object-oriented Design
Objectives
• To explain how a software design may be represented as
a set of interacting objects that manage their own state
and operations
• To describe the activities in the object-oriented design
process
• To introduce various models that can be used to describe
an object-oriented design
• To show how the UML may be used to represent these
models
Object-oriented development
• Object-oriented analysis, design and programming are
related but distinct.
• OOA is concerned with developing an object model of the
application domain.
• OOD is concerned with developing an object-oriented
system model to implement requirements.
• OOP is concerned with realising an OOD using an OO
programming language such as Java or C++.
Characteristics of OOD
• Objects are abstractions of real-world or system entities
and manage themselves.
• Objects are independent and encapsulate state and
representation information.
• System functionality is expressed in terms of object
services.
• Shared data areas are eliminated. Objects
communicate by message passing.
• Objects may be distributed and may execute
sequentially or in parallel.
Advantages of OOD
• Easier maintenance. Objects may be
understood as stand-alone entities.
• Objects are potentially reusable components.
• For some systems, there may be an obvious
mapping from real world entities to system
objects.
Objects and object classes
• Objects are entities in a software system which represent
instances of real-world and system entities.
• Object classes are templates for objects. They may be
used to create objects.
• Object classes may inherit attributes and services from
other object classes.
Objects and object classes
An object is an entity that has a state and a defined set of operations
which operate on that state. The state is represented as a set of object
attributes. The operations associated with the object provide services to
other objects (clients) which request these services when some
computation is required.
Objects are created according to some object class definition. An object
class definition serves as a template for objects. It includes declarations of
all the attributes and services which should be associated with an object of
that class.
The Unified Modeling Language
• Several different notations for describing object-oriented
designs were proposed in the 1980s and 1990s.
• The Unified Modeling Language is an integration of these
notations.
• It describes notations for a number of different models
that may be produced during OO analysis and design.
• It is now a de facto standard for OO modelling.
Employee object class (UML)
Emplo yee
name: string
address: string
dateOfBir th: Date
employeeNo: int eger
socialSecurityNo: string
depar tm ent: Dept
manager: Employee
salar y: integer
status: {current, left, retired}
taxCode: integer
. ..
joi n ()
leave ()
retire ()
changeDetails ()
UML associations
• Objects and object classes participate in relationships
with other objects and object classes.
• In the UML, a generalised relationship is indicated by an
association.
• Associations may be annotated with information that
describes the association.
• Associations are general but may indicate that an
attribute of an object is an associated object or that a
method relies on an associated object.
