Systems Analysis and

Design II

System Decomposition and Design

Criteria
Design Topics
■>>Introduction to Design
■Design Criteria
■Design Goals
■Architecture Styles
■Physical Architecture
■From Design to Implementation

2
Design
“There are two ways of
constructing a software design:
One way is to make it so
simple that there are obviously
no deficiencies, and the other
way is to make it so
complicated that there are no
obvious deficiencies.”
3
 What Is Design?
■ Requirements specification was about the WHAT
the system will do
■ Design is about the HOW the system will perform
its functions
■ provides the overall decomposition of the system
■ allows to split the work among a team of developers
■ also lays down the groundwork for achieving non-
functional requirements (performance, maintainability,
reusability, etc.)
■ takes target technology into account (e.g., kind of
middleware, database design, web server, UI design,
etc.)
■ The steps in both analysis and design phases are
highly interrelated and may require much “going
back and forth”
4
EVOLVING THE ANALYSIS
MODELS INTO DESIGN
MODELS
 System Design
System Design

1. Design
Goals
Definition
8.
Trade-offs
Conditions
Boundary
Initialization
Termination
Failure
2.
Decomposition
System
Layers/Partitions 7. Software
Cohesion/Coupling
Control
Monolithic
Event-Driven
3. Concurrency Threads
Identification of 4. Hardware/ 6. Global Conc. Processes
Threads Software 5. Data Resource Handling
Mapping Management
Access control
Special purpose Persistent Objects Security
Buy or Build Trade-off Files
Databases
Allocation
Connectivity Data structure
6
How to use the results from the
Requirements Analysis for System
Design
■ Nonfunctional requirements =>
■ Activity 1: Design Goals Definition
■ Functional model =>
■ Activity 2: System decomposition (Selection of subsystems
based on functional requirements, cohesion, and coupling)
■ Object model =>
■ Activity 4: Hardware/software mapping
■ Activity 5: Persistent data management
■ Dynamic model =>
■ Activity 3: Concurrency
■ Activity 6: Global resource handling
■ Activity 7: Software control
■ Subsystem Decomposition
■ Activity 8: Boundary conditions
7
 System Decomposition
■ Subsystem (UML: Package)
■ Collection of classes, associations, operations, events
and constraints that are interrelated
■ Seed for subsystems: UML Objects and Classes.
■ (Subsystem) Service:
■ Group of operations provided by the subsystem
■ Seed for services: Subsystem use cases
■ Service is specified by Subsystem interface:
■ Specifies interaction and information flow from/to
subsystem boundaries, but not inside the subsystem.
■ Should be well-defined and small.
■ Often called API: Application programmer’s interface, but
this term should used during implementation, not
during System Design

8
Choosing Subsystems
■ Criteria for subsystem selection: Most of the interaction
should be within subsystems, rather than across
subsystem boundaries (High cohesion).
■ Does one subsystem always call the other for the service?
■ Which of the subsystems call each other for service?
■ Primary Question:
■ What kind of service is provided by the subsystems
(subsystem interface)?
■ Secondary Question:
■ Can the subsystems be hierarchically ordered (layers)?
■ What kind of model is good for describing layers and
partitions?

9
 Subsystem Decomposition
Example
Is this the right Authoring
decomposition or Augmented
is this too much Reality
ravioli?

Modeling Workflow

Inspection

Workorder Repair

10
Definition: Subsystem
Interface Object
■A Subsystem Interface Object
provides a service
■This is the set of public methods
provided by the subsystem
■The Subsystem interface describes all
the methods of the subsystem
interface object
■Use a Facade pattern for the
subsystem interface object
11
 System as a set of subsystems
communicating via a software bus
Authoring
Modeling

Workflow

Augmente
Inspection d
Reality

Repair Workorder

A Subsystem Interface Object publishes the service (= Set of

public methods)
provided by the subsystem 12
© E. Gamma, R. Helm, R. Johnson, J. Vlissides and Addison-Wesley

Façade Pattern

13
Façad
Façade

14
 A 3-layered Architecture
Repair Inspection Authoring

Augmented
Reality

Workflow
Modeling

What is the relationship between Modeling and Authoring?

Are other subsystems needed?
15
 Coupling and Cohesion
■ Goal: Reduction of complexity while change
occurs
■ Cohesion measures the dependence among
classes
■ High cohesion: The classes in the subsystem perform
similar tasks and are related to each other (via
associations)
■ Low cohesion: Lots of miscellaneous and auxiliary
classes, no associations
■ Coupling measures dependencies between
subsystems
■ High coupling: Changes to one subsystem will have
high impact on the other subsystem (change of model,
massive recompilation, etc.)
■ Low coupling: A change in one subsystem does not
affect any other subsystem
■ Subsystems should have as maximum 16
cohesion
Partitions and Layers
■ Partitioning and layering are techniques to
achieve low coupling.
■ A large system is usually decomposed into
subsystems using both, layers and partitions.
■ Partitions vertically divide a system into
several independent (or weakly-coupled)
subsystems that provide services on the same
level of abstraction.
■ A layer is a subsystem that provides
subsystem services to a higher layers (level of
abstraction)
■ A layer can only depend on lower layers
■ A layer has no knowledge of higher layers
17
 Subsystem Decomposition
into Layers
Layer 1

Layer 2

Layer 3

■Subsystem Decomposition Heuristics:

■No more than 7+/-2 subsystems
■More subsystems increase cohesion but also
complexity (more services)
■No more than 4+/-2 layers, use 3 layers
(good)
18
Relationships between
Subsystems
■Layer relationship
■Layer A “Calls” Layer B (runtime)
■Layer A “Depends on” Layer B
(“make” dependency, compile time)
■Partition relationship
■The subsystem have mutual but not
deep knowledge about each other
■Partition A “Calls” partition B and
partition B “Calls” partition A
19
PACKAGES AND PACKAGE
DIAGRAMS
 Packages
■Logical grouping of UML elements
■Simplifies UML diagrams
■Groups related elements into a single
higher-level element
■Dependency relationships
■Shows a dependency between packages

21
Syntax for Package
Diagram

A PACKAGE
Package

A DEPENDENCY RELATIONSHIP

22
Modification Dependency
■ Indicates that a change in one package could
cause a change to be required in another
package.
■ Example:
■A change in one method will cause the
interface for all objects of this class to
change. Therefore, all classes that have
objects that send messages to the instances
of the modified class have to be modified.

23
Dependencies
Acyclic Cyclic graph
graph (UNDESIREBLE)
( DESIREBL
E)

24
Package Diagram of
Appointment System

25
Importing and Accessing
Packages
With <<import>>, the elements of imported
package
are accessible without qualification
With <<access>> only the importing package
can
access the elements of the accessed package

26
Steps for Identifying Packages
and Building Package Diagrams
■ Set the context
■ Cluster classes together based on shared
relationships
■ Model clustered classes as a package
■ Identify dependency relationships among
packages
■ Place dependency relationships between
packages

27
Your Turn
■What is the difference between an
analysis modes and a design
model?
■What is a layer? What are the
layers for your project?
■What UML artifact are you going to
use to depict layers and
subsystems?
■What is the difference between a
layer and a partition?
28
Summary so far
■ When evolving analysis into design models, it
is important to review the analysis models
then add system environment information.
■ Packages and package diagrams help provide
structure and less complex views of the new
system.

29
Design Topics
■Introduction to Design
■>>Design Criteria
■Design Goals
■Architecture Styles
■Physical Architecture
■Reuse and Design Patterns
■From Design to Implementation

30
DESIGN CRITERIA
Coupling
■Indicates the interdependence or
interrelationships of the modules
■Interaction coupling
■Relationships with methods and
objects through message passage

32
Interaction Coupling

33
Content Coupling
■ One module directly refers to the content of the other
■ module 1 modifies a statement of module 2
■ assembly languages typically supported this, but not high-level
languages
■ COBOL, at one time, had a verb called alter which could also
create self-modifying code (it could directly change an
instruction of some module).
■ module 1 refers to local data of module 2 in terms of some
kind of offset into the start of module 2.
■ This is not a case of knowing the offset of an array entry - this
is a direct offset from the start of module 2's data or code
section.
■ module 1 branches to a local label contained in module 2.
■ This is not the same as calling a function inside module 2 - this
is a goto to a label contained somewhere inside module 2.

34
Common Coupling
■ Common coupling exists when two or more modules
have read and write access to the same global data.
■ Common coupling is problematic in several areas of
design/maintenance.
■ Code becomes hard to understand - need to know all
places in all modules where a global variable gets modified
■ Hampered reusability because of hidden dependencies
through global variables
■ Possible security breaches (an unauthorized access to a
global variable with sensitive information)
■ It’s ok if just one module is writing the global data and
all other modules have read-only access to it.

35
Common Coupling
■Consider the following code fragment:
while( global_variable > 0 )
{ switch( global_variable )
{ case 1: function_a(); break;
case 2: function_b(); break;
...
case n: ...
}
global_variable++;
}
36
Common Coupling
■ If function_a(), function_b(), etc can modify the value of global
variable, then it can be extremely difficult to track the
execution of this loop.

■ If they are located in two or more different modules, it

becomes even more difficult
■ potentially all modules of the program have to be searched for
references to global variable, if a change or correction is to take
place.

■ Another scenario is if all modules in a program have access to

a common database in both read and write mode, even if
write mode is not required in all cases.

■ Sometimes necessary, if a lot of data has to be supplied to

each module
37
Control Coupling
■ Two modules are control-coupled if module 1
can directly affect the execution of module 2,
e.g.,
■ module 1 passes a “control parameter” to module 2
with logical cohesion, or
■ the return code from a module 2 indicates NOT ONLY
success or failure, but also implies some action to be
taken on the part of the calling module 1 (such as
writing an error message in the case of failure).

■ The biggest problem is in the area of code re-

use: the two modules are not independent if
they are control coupled.
38
Stamp Coupling
■ It is a case of passing more than the required data
values into a module, e.g.,
■ passing an entire employee record into a function that
prints a mailing label for that employee. (The data fields
required to print the mailing label are name and address.
There is no need for the salary, SIN number, etc.)
■ Making the module depend on the names of data fields
in the employee record hinders portability.
■ If instead, the four or five values needed are passed in as
parameters, this module can probably become quite
reusable for other projects.
■ As with common coupling, leaving too much information
exposed can be dangerous.

39
Data Coupling
■Data coupling exhibits the
properties that all parameters to a
module are either simple data
types, or in the case of a record
being passed as a parameter, all
data members of that record are
used/required by the module. That
is, no extra information is passed
to a module at any time.
40
The Law of Demeter
■An object should only send
messages to one of the following:
■Itself
■An object that is contained in an
attribute of the object or its
supercalss
■An object that is passed as a
parameter to the method
■An object that is created by the
method
■An object that is stored in a global
variable 41
Types of Method Cohesion

42
Coincidental cohesion
■The result of randomly breaking the
project into modules to gain the
benefits of having multiple smaller
files/modules to work on
■Inflexible enforcement of rules such as:
“every function/module shall be between 40
and 80 lines in length” can result in
coincidental coherence

■Usually worse than no modularization

■Confuses the reader that may infer
dependencies that are not there 43
Logical cohesion
■ A “template” implementation of a number of
quite different operations that share some
basic course of action
■ variation is achieved through parameters
■ “logic” - here: the internal workings of a module

■ Problems:
■ Results in hard to understand modules with
complicated logic
■ Undesirable coupling between operations

■ Usually should be refactored to separate the

different operations
44
Example of Logical
Cohesion
void function(param1, param2, param3, ..., paramN)
{
variable declarations....
code common to all cases... [A]
if ( param1 == 1 ) [B]
...
else if ( param1 == 2 )
...
else if ( param1 == n )
...
end if
code common to all cases... [C]
if ( param == 1) [D]
...
else if ( param1 == 5 )
...
end if
code common to all cases... [E]
if ( param1 == 7 )
...
}

45
Temporal Cohesion
■ Temporal cohesion concerns a module organized to contain all
those operations which occur at a similar point in time.

■ Consider a product performing the following major steps:

■ initialization, get user input, run calculations, perform appropriate
output, cleanup.

■ Temporal cohesion would lead to five modules named

initialize, input, calculate, output and cleanup.

■ This division will most probably lead to code duplication across

the modules, e.g.,
■ Each module may have code that manipulates one of the major
data structures used in the program.

46
Procedural Cohesion
■ A module has procedural cohesion if all the operations it
performs are related to a sequence of steps performed in the
program.

■ For example, if one of the sequence of operations in the

program was “read input from the keyboard, validate it, and
store the answers in global variables”, that would be
procedural cohesion.

■ Procedural cohesion is essentially temporal cohesion with the

added restriction that all the parts of the module correspond
to a related action sequence in the program.

■ It also leads to code duplication in a similar way.

47
 Procedural Cohesion
Module A Module B
operationA() operationB()
{ readData(data,filename1); { readData(data,filename1);
processAData(data); processBData(data);

storeData(data,filename2); storeData(data,filename2);
} }
readData(data,filename) readData(data,filename)
{ f := { f :=
openfile(filename); openfile(filename);
readrecords(f, data); readrecords(f, data);
closefile(f); closefile(f);
} }
storeData(data,filename) storeData(data,filename)
{...} {...}
processAData(data) processBData(data)
{...} {...}
48
Communicational
Cohesion
■Communicational cohesion occurs when
a module performs operations related to
a sequence of steps performed in the
program (see procedural cohesion) AND
all the actions performed by the module
are performed on the same data.

■Communicational cohesion is an
improvement on procedural cohesion
because all the operations are
performed on the same data.
49
Functional Cohesion
■ Module with functional cohesion focuses on exactly one
goal or “function”
■ (in the sense of purpose, not a programming language
“function”).

■ Module performing a well-defined operation is more

reusable, e.g.,
■ modules such as: read_file, or draw_graph are more likely
to be applicable to another project than one called
initialize_data.

■ Another advantage of is fault isolation, e.g.,

■ If the data is not being read from the file correctly, there is
a good chance the error lies in the read_file
module/function.
50
Ideal Class Cohesion
■Contain multiple methods that are
visible outside the class
■Have methods that refer to
attributes or other methods
defined with the class or its
superclass
■Not have any control-flow coupling
between its methods

51
Types of Class Cohesion

52
Your Turn
■In the diagram below, what
“name” attribute does Robot-
Employee inherit?

53
Summary
■ Cohesion measures the dependence among classes
■ High cohesion: The classes in the subsystem perform
similar tasks and are related to each other (via
associations) GOOD!
■ Low cohesion: Lots of miscellaneous and auxiliary classes,
no associations BAD!!
■ Coupling measures dependencies between subsystems
■ High coupling: Changes to one subsystem will have high
impact on the other subsystem (change of model, massive
recompilation, etc.) BAD!!
■ Low coupling: A change in one subsystem does not affect
any other subsystem GOOD!!

54
DESIGN STRATEGIES
Custom Development
■Develop the system “from scratch”
■Allows for meeting highly specialized
requirements
■Allows flexibility and creativity in solving
problems
■Easier to change components
■Builds personnel skills
■May tax firm’s resources
■May add significant risk

56
Packaged Software
■ Software already written
■ May be more efficient
■ May be more thoroughly tested and proven
■ May range from components to tools to whole
enterprise systems
■ ActiveX, MsWord, SAP,PeopleSoft, Oracle,Ban
■ Must accept functionality provided
■ May require change in how the firm does
business
■ May require significant “customization” or
“workarounds”

57
System Integration
■The process of combining
packages, legacy systems, and
new software
■Key challenge is integrating data
■Write data in the same format
■Revise existing data formats
■Develop “object wrappers”

58
Outsourcing
■Hire external firm to create system
■May have more skills
■May extend existing resources
■Never outsource what you don’t
understand
■Carefully choose vendor
■Prepare contract and payment style
carefully

59
 Outsourcing Guidelines
■Keep lines of communication open with
outsourcer
■Define and stabilize requirements
before signing a contract
■View outsourcing relationship as
partnership
■Select outsource vender carefully
■Assign person to manage relationship
■Don’t outsource what you don’t
understand
■Emphasize flexible requirements, long-
term relationships, and short-term
60
contracts
Selecting a Design
Strategy
■Business need
■In-house experience
■Project skills
■Project management
■Time frame

61
Your Turn
■Suppose that your university is
interested in creating a new course
registration system that can support
Web-based registration?
■What should the university consider
when determining whether to invest in a
custom, packaged, or outsourcing
system solution?

62