CHGCJHCRT 1

Chapter 6 – Architectural Design
Lecture 1
Chapter 6 Architectural
1
design
Architecting and Designing Software
The Process of Design

Finish Process + Software Architecture
Architectural Patterns
Where are we? Where are we going?
• Know some about Business Modeling, business object models,

and domain modeling
• Know about the UP – its definition = a use-case driven,
architecture-centric, iterative development process…
• Know about gathering and capturing functional user requirements
using Use Cases and the contribution of a user interface prototype
• Know about documenting non-functional requirements and their
essentials
• Know about several of the basic models and views as well as class
diagrams, activity diagrams, use case diagrams, domain modeling, a
little bit about interaction diagrams and more…
• Now it is time to get serious about design.
• We have started with looking more seriously as the User Interface

Design. Now, let’s address the architectural design – likely the
second iteration in the Elaboration Phase – or thereabouts…
© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 2
The Process of Design
•Definition:
• Design is a problem-solving process whose objective is to
find and describe a way:
—To implement the system’s functional requirements...
—while respecting the constraints imposed by
non-functional requirements...
- Such as performance, maintainability, security, persistence,
cost, reliability, portability, etc…..(long list)
- including also the budget, technologies, environment, legal
issues, deadlines, ...
—and while adhering to general principles of good quality
• Consider this perspective:

Object-Oriented Analysis
•An investigation of the problem (rather than how a

solution is defined)
•During OO analysis, there is an emphasis on

finding and describing the objects (or concepts) in
the problem domain.
• For example, concepts in a Library Information

System include Book, and Library.
4
Object-Oriented Design
•Emphasizes a conceptual solution that fulfills the

requirements.
•Need to define software objects and how they collaborate to

fulfill the requirements.
•For example, in the Library Information System, a Book

software object may have a title attribute and a getChapter
method.
•Designs are implemented in a programming language.

•In the example, we will have a Book class in Java.
•These we refer to as ‘software classes’ or POJC (Plain Old
Java Class)
5
From Design to Implementation
Analysis
Design Construction
investigation
logical solution code
of the problem
Book public class Book {

Book
public void print();
(concept) title
print()
private String title;
}
Domain concept Representation in Representation in an
analysis of concepts
object-oriented
programming language.
6
Process of Design
•Design is all about decisions.

•Approaches:
• Top down – start with the architecture
• Bottom up – start with utilities
• Are a number of very serious design principles that
lead to maintainable software that may persist for years
• Will look at satisfying functional requirements while
accommodating portability, reuse potential, performance
• There are always TRADEOFFS! There is no free lunch!!!--

• Will look at several of the tradeoffs
• Will look at (and you will develop) a software
architecture to support your high-level design
Design as a Series of Decisions
•A designer is faced with a series of design issues

• These are sub-problems of the overall design problem.
• Are always several alternative solutions: design options.
• Designer makes design decisions to resolve each issue.
—This process involves choosing the best option from
among the alternatives.
• Recognize that there may be a number of solutions – in

fact, there may be a number of good solutions for the
problem to be solved.
• We would like the ‘best’ one.

Making decisions
•To make each design decision, the software engineer uses:

• Knowledge of
—the requirements (use cases, UI prototype,
supplementary specification document, class diagrams,
interaction diagrams …)
—the design as created ‘so far’
—Available technologies (RMI, RPC, xml, jsp, servlets,
html, jdbc, etc. etc.) given a development environment
—software design principles and ‘best practices’
—what has worked well in the past
• Sometimes there is no single, best solution.
• Sometimes they conflict – each presenting pros and cons

‘Design space’ – example Consider choice of thin
client vs fat client options:
•The space of possible designs that could be
achieved by choosing different sets of alternatives is
often called the design space
fat-client (more efficient use of CPU and of network
• For example: separate resources) Why???
user interface
layer for programmmed in Java
client-server client
programmed in .Net
thin-client
no programmed in C++; C#?

separate
monolithic user interface
layer for client
(simpler
Advantages of fat client: software)
bandwidth, networking services, reduced need for powerful server…
Advantages of thin client: simpler client devices; maintaining services; central bus logic…
Disadvantages? Know! Cost, reliability, maintenance, security, bandwidth, network

traffic; Never a single answer for all cases! è Design!
Criticality of Certain Design Decisions
• Some design decisions are critical; others not so.
• Example: architectural design decision to separate the user

interface module from rest of system.
• Yes: easier to develop and maintain, internationalize, employ

reuse.
• No: Likely not as efficient; (disadvantage. why?)
• Recommend iterating User Interface as a part of iteration

planning!
• As increments of value are produced, so too should the

interface evolve.
Features of Top-down and Bottom-up design
•Top-down design
• First design the very high level structure of system.
• Then gradually work down to detailed decisions about
low-level constructs.
• Finally arrive at detailed decisions such as:
—the format of particular data items;
—the individual algorithms that will be used.
• Start with the software architecture and the type of

database that will be used (not ‘which’ database).
• Ultimately arrive at specific data items and detailed
algorithms.
Top-down and Bottom-Up design
•Bottom-up design
• Make decisions about reusable low-level utilities.
• Then decide how these will be put together to create high-
level constructs.
• Mix of top-down and bottom-up approaches normally used:

• Top-down design is almost always needed to give the
system a good structure (architecture).
• Bottom-up design is normally useful so that reusable
components can be created.

Different aspects of Design – Very important!!
• All kinds of ‘design’ This is where the decisions are made!!!!

• èArchitecture design:
—The division into subsystems and components,
- How these will be connected.
- How they will interact.
- Their interfaces.
• Class design:
—The various features of classes.
• User interface design
• Algorithm design:
—The design of computational mechanisms.
• Protocol design:
—The design of communications protocol.
•For a while, now, we will emphasize Architectural Design – after we discuss

class design.
Principles Leading to Good Design
•Overall goals of Good Design:

• Increase profit by reducing cost and increasing revenue
• Ensure design accommodates requirements
• Speed up development for use / competing in
marketplace
• Increase qualities such as
—Usability – learnability; ease of use; on-line help…
—Efficiency
—Reliability
—Maintainability
—Reusability to reduce cost and increase revenues

Design Principle 1: Divide and Conquer
•Trying to deal with something big all at once is normally

much more difficult than dealing with a series of smaller,
manageable, understandable things
•(hence the iterative approach to software development)
• A software engineer/software developer can specialize.
—Specialize in network, distribution, database,
algorithms, searching / sorting techniques…
• Individual components smaller, easier to understand.
• Parts can be replaced or changed without having to

replace or extensively change other parts.
Ways of dividing a software system
• A distributed system is divided up into clients and servers
• A system is divided up into subsystems
• A subsystem can be divided up into one or more

packages
• A package is divided up into classes
• A class is divided up into methods

Design Principle 2:
Increase (High) Cohesion where possible
•Divide and Conquer says split things up. Smaller parts,

easier to grasp.
•A subsystem or module has high cohesion if it keeps

together things that are related to each other, and keeps
other things out!
• Makes system as a whole easier to understand / change
• Type of cohesion:
—Functional, Layer, Communicational, Sequential,
Procedural, Temporal, Utility

Functional Cohesion
• Achieved when all the code that computes a particular result is

kept together - and everything else is kept out
• i.e. when a module only performs a single computation, and returns a result,
without having side-effects.
—No changes to anything but the computation
—Normally implemented via parameters
—Can call other methods, if cohesion is preserved.

- (Recall: Call by Value; Call by Reference… as examples)
- Avoid things like common, global data, more
• Benefits to the system:

—Easier to understand
—More reusable
—Easier to replace
—Example: pass an array of integers; sort the array and return sorted array.
Can change algorithms if interface remains unchanged…

Layer cohesion
• All facilities for providing or accessing a set of related services are kept together,
and everything else is kept out
• The layers should form a hierarchy
—(Layers – presentation (interface); business (domain) logic; application
logic; technical services…)
—Higher layers can access services of lower layers,
—Lower layers do not access higher layers
• Will talk about architectural layers a great deal very soon…
• The set of procedures through which a layer provides its services is the
application programming interface (API)
• Specification of API says how to use it.
• è You can replace a layer without having any impact on the other layers
because you know that it does not access upper layers.

Example of the use of layers
Application programs
Sometimes we have a business services
and then a domain (more general) layer Screen display
facilities Dealing with
Will have a middleware layer often! application protocols
User account
User management Dealing with
interface connections
File
Application system Dealing with
logic packets
Kernel
Operating system Database Network (handling processes Transmitting
access access communication and swapping) and receiving
a) Typical layers in an b) Typical layers in an c) Simplified view of layers

application program operating system in a communication system
Examples: services for computations; transmissions of messages; storage of data; managing security,
interacting with users; accessing the operating system; interacting with hardware, and more

Communicational cohesion
•All the modules that access or “manipulate certain data”

are kept together (e.g. in the same class) - and everything
else is kept out
• A class would have good communicational cohesion
—if all the system’s facilities for storing and
manipulating its data are contained in this class.
—if the class does not do anything other than manage
its data.
• Main advantage: When you need to make changes to
the data, you find all the code in one place
• Keeps methods where the data is, if possible.
• Talk about this extensively in Data Structures course!!

Other measures of Cohesion
• Sequential Cohesion
•Procedures, in which one procedure provides input to the next, are kept together – and
everything else is kept out
•You should achieve sequential cohesion, only once you have already achieved the preceding
types of cohesion.
•Procedural Cohesion
•Keep together several procedures that are used one after another
•Even if one does not necessarily provide input to the next. Weaker than sequential.
•Temporal Cohesion
•Operations that are performed during the same phase of the execution of the program are kept
together, and everything else is kept out
•For example, placing together the code used during system start-up or initialization.
•Weaker than procedural cohesion.
•Utility Cohesion
•When related utilities which cannot be logically placed in other cohesive units are kept together
•A utility is a procedure or class that has wide applicability to many different subsystems and
is designed to be reusable.
•For example, the java.lang.Math class. ç
•

Design Principle 3:
Reduce (Low) Coupling where possible
•Coupling occurs when there are interdependencies

between one module and another
• When interdependencies exist, changes in one place
will require changes somewhere else.
• A network of interdependencies makes it difficult to
see at a glance how some component works.
• Type of coupling: (in decreasing order of avoidance!)
—Content, Common, Control, Stamp, Data, Routine
Call, Type use, Inclusion/Import, External

Content Coupling: The Worst of the Bad!
•Occurs when one component surreptitiously modifies data (or

instructions!) that is/are internal to another component
•To reduce content coupling you should therefore encapsulate
all instance variables
—declare them private
—and provide get and set methods
•A worse form of content coupling occurs when you directly
modify an instance variable from outside the object.
•Discuss: how easy it is to do this and how/why it has been

done in the past! (especially in non-object-oriented systems)
—Assembler; ‘Alter’ verb in Cobol

Common Coupling – also Avoid where possible
and practical!!!
•Occurs whenever you use a global variable

•All the components using global variables
become coupled to each other
•Can be acceptable for creating global variables

that represent system-wide default values
•Clearly, when a value is changed, it may be very

difficult to trace the source of the change!

Control Coupling – not as bad, but still is pretty
strong coupling! Avoid if you are able to.
•Occurs when one procedure calls another using a ‘flag’

or ‘command’ that explicitly controls what the second
procedure does (passing a switch….)
• To make a change you have to change both the calling
and called method; that is, to avoid the flags…
• The use of polymorphic operations is normally the best
way to avoid control coupling
• One way to reduce the control coupling could be to
have a look-up table
—commands are then mapped to a method that
should be called when that command is issued

Example of control coupling
public routineX(String command)

{
if (command.equals("drawCircle")
{
drawCircle();
}
else
{
drawRectangle();
}
}
See? Flag is passed (command) whose value

is used to control flow!
Can be handled better through polymorphism…

Other Forms of Coupling:
• Stamp Coupling
• Data Coupling
• Routine-call Coupling
• Type Use Coupling
• Inclusion or import Coupling
• External Coupling

Design Principle 4:
Keep level of Abstraction as high as possible
•Ensure that your designs allow you to hide or defer

consideration of details, thus reducing complexity
• A good abstraction is said to provide information hiding
• Abstractions allow you to understand the essence of a
subsystem without having to know unnecessary details
• Allows us to grasp the essential!
—Defer the less important grunt-level items until later
• Allows us to deal with complexity!
• You will be doing this when you create your

subsystems and when they are contained in layers, etc.

Remaining Slides
on your own
Architectural Abstraction
 Architecture in the small is concerned with the architecture of

individual programs.
 At this level, we are concerned with the way that an individual
program is decomposed into components.
 Structure charts; UML diagrams showing
 organization…
 Architecture in the large is concerned with the architecture of

complex enterprise systems that include other systems,
programs, and program components. These enterprise
systems are distributed over different computers, which may
be owned and managed by different companies.
36
design
Architectural Representations
 ==> Simple, informal block diagrams showing entities

and relationships are the most frequently used method
for documenting software architectures.
 But these have been criticized because they lack
semantics, do not show the types of relationships
between entities nor the visible properties of entities in
the architecture.
 Depends on the use of architectural models.The
requirements for model semantics depends on how the
models are used.
37
design
Architectural Design Decisions
 Is there a generic application architecture that can be

used?
 How will the system be distributed?
 What architectural styles are appropriate?
 What approach will be used to structure the system?
 How will the system be decomposed into modules?
 What control strategy should be used?
 How will the architectural design be evaluated?
 How should the architecture be documented?
40
design
Architecture Reuse
 Systems in the same domain often have similar

architectures that reflect domain concepts.
 Application product lines are built around a core architecture

with variants that satisfy particular customer requirements.
 The architecture of a system may be designed around one

of more architectural patterns or ‘styles’.
These capture the essence of an architecture and can be instantiated
in different ways.
Discussed later in this lecture.
41
design
Architectural Views
 What views or perspectives are useful when designing

and documenting a system’s architecture?
 What notations should be used for describing
architectural models?
 Each architectural model only shows one view or
perspective of the system.
It might show how a system is decomposed into modules, how the
run-time processes interact or the different ways in which system
components are distributed across a network. For both design
and documentation, you usually need to present multiple views of
the software architecture.
43
design
4 + 1 view model of software architecture
 A logical view, which shows the key abstractions in the

system as objects or object classes.
 A process view, which shows how, at run-time, the
system is composed of interacting processes.
 A development view, which shows how the software is
decomposed for development.
 A physical view, which shows the system hardware and
how software components are distributed across the
processors in the system.
 Related using use cases or scenarios (+1)
44
design
Representing Architecture: The 4+1 View Model
Logical View
Functional Logical Implementation
Requirements –
View View
Deals with design, Functional requirements
packages, sub- Analysts/
systems, and Designers End-user Programmers
classes, layers, … Structure Functionality Software management
Use-Case
Implementation
View
View – deals mostly Process
with programming
Deployment
and organization of View View
System Integrators System Engineering
the static software
Performance System topology
modules & unit test
Scalability, Concurrency, Delivery, installation
Throughput, Parallelism… Communication
A View is a complete description (an abstraction) of a system from a particular view-

point or perspective – covering particular concerns and omitting others not
relevant to this perspective.
Different ‘views’ from different ‘stakeholders; different concerns.
A Model is a complete representation.

CHGCJHCRT 1

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

CHGCJHCRT 1

Uploaded by

Copyright:

Available Formats

Chapter 6 – Architectural Design

The Process of Design

• Know some about Business Modeling, business object models,

• Now it is time to get serious about design.

• We have started with looking more seriously as the User Interface

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 3

•An investigation of the problem (rather than how a

•During OO analysis, there is an emphasis on

• For example, concepts in a Library Information

•Emphasizes a conceptual solution that fulfills the

•Need to define software objects and how they collaborate to

•For example, in the Library Information System, a Book

•Designs are implemented in a programming language.

Book public class Book {

•Design is all about decisions.

• There are always TRADEOFFS! There is no free lunch!!!--

•A designer is faced with a series of design issues

• Recognize that there may be a number of solutions – in

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 8

•To make each design decision, the software engineer uses:

• Sometimes there is no single, best solution.

• Sometimes they conflict – each presenting pros and cons

no programmed in C++; C#?

Disadvantages? Know! Cost, reliability, maintenance, security, bandwidth, network

• Some design decisions are critical; others not so.

• Example: architectural design decision to separate the user

• Yes: easier to develop and maintain, internationalize, employ

• No: Likely not as efficient; (disadvantage. why?)

• Recommend iterating User Interface as a part of iteration

• As increments of value are produced, so too should the

• Start with the software architecture and the type of

• Mix of top-down and bottom-up approaches normally used:

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 14

• All kinds of ‘design’ This is where the decisions are made!!!!

•For a while, now, we will emphasize Architectural Design – after we discuss

•Overall goals of Good Design:

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 16

•Trying to deal with something big all at once is normally

• Individual components smaller, easier to understand.

• Parts can be replaced or changed without having to

• A distributed system is divided up into clients and servers

• A system is divided up into subsystems

• A subsystem can be divided up into one or more

• A package is divided up into classes

• A class is divided up into methods

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 18

•Divide and Conquer says split things up. Smaller parts,

•A subsystem or module has high cohesion if it keeps

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 19

• Achieved when all the code that computes a particular result is

—Normally implemented via parameters

—Can call other methods, if cohesion is preserved.

• Benefits to the system:

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 20

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 21

a) Typical layers in an b) Typical layers in an c) Simplified view of layers

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 22

•All the modules that access or “manipulate certain data”

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 23

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 24

•Coupling occurs when there are interdependencies

© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 25

•Occurs when one component surreptitiously modifies data (or