Lecture 8: Architectural
Design
Addendum
Introduction to Software Engineering
Concepts of Sub-systems Design Models
(I) Architectural design, system and (III a) Questions on architectural design (22)
subsystems (III b) Architectures from different perspectives
(I a) Architectural design in software (23)
development life cycle (3-5) (IV) System Organization (24-37)
(I b) System and subsystems (6-7) (IV a) Repository model (25-30)
(I c) Purposes of architectural design (IV b) Client server model (31-33)
(8-11) (IV c) Layer model (34-37)
Design Principles (V) Component Control (38-40)
(II) Design Fundamentals (12-21) Centralized control (39)
(II a) Abstraction (13) Event-based control (40)
(II b) Pattern (14)
(II c) Modularity (15)
(II d) Information hiding (16)
(II e) Independence (17)
(II e1) Cohesion (18)
(II e2) Coupling (19)
(II f) Refinement (20)
(II g) Refactoring (21)
• Assignment 4 (from Lecture 7) will be released Friday.
• Due Fri 21 March 2025
(I)Architectural design, system and subsystems
Slides 3-5 (I a) Architectural design in software development life cycle
• Previous lectures discussed SRS and models
• This lecture discuss Design
Slides 6-7 (I b) Systems and subsystems
• E.g. Java has packages for IO, graphics, arrays, etc.
• Each of them is a subsystem of the Java system
• Slide 7:
• The big circle represents the whole system
• The rounded rectangles represent subsystems
• The lines represent the relationships between subsystems
(I) Architectural design, system and subsystems
Slide 8-11 (I c) Purposes of architectural design
Slide 9
• A poorly designed system is like a house of cards
• A feather (i.e. a little change) can break the system
(II) Design Fundamentals
Reference: Pressmen, 7th Ed, Section 8.3 Design Concepts
Slides 12
• Independence includes coupling and cohesion
Slide 14 (IIb) Pattern
• Will learn more on design patters in the lecture Software Reuse
• Example of design pattern
• Entity/boundary/controller (and Model/view/controller) in Lecture 7
addendum.
(II) Design Fundamentals
Slide 15 (II c) Modularity
• Break a complicated system into smaller units
Slide 16 (II d) Info Hiding - Encapsulation
Slide 17 (II e) Independence
Reference Pressmen, 7th Ed., 10.2.3 to 10.2.4
• Coupling and cohesion are this lecture’s two most important new
ideas
• You’ve learned other important ideas already (abstraction, encapsulation)
• Others are too difficult (patterns, refactoring); can only scratch the surface
(II) Design Fundamentals
Slide 18 (IIe1) Cohesion (higher is better)
• Measures how components are grouped together
• A cohesive team works well together
• Highest cohesion is at bottom of the slide!
• Functional cohesion is the best cohesion (bottom of slide)
• Components work together to perform one well defined function task
• Informational cohesion is next best
• Components use the same data structure (i.e. use same info)
• Sequential cohesion is next
• In the output, group components that produced sequential part of output
• Commonly used in trying to understand a code you’re not familiar
(II) Design Fundamentals
Slide 19 Coupling (looser is better)
• Looser coupling allows components to be more independent
• Components can work without worrying about side effects on other components
• Data coupling (parameter passing) is best coupling (bottom of slide)
• Only the most relevant info are passed as parameters
• “Use get() and set()”.
• (Part of) Data-structure coupling is next best
• More info than necessary are passed, but changes are restricted to that data
structure
• Global-data coupling is next
• Two modules communicate by global data; not easy to tell which global data or
component got used or changed
(II) Design Fundamentals
Slide 20 (II f) Refinement
• Filling in details, when the process go from abstract to concrete
Slide 21 (II g) Refactoring
• Reorganizing the components
• Visual Studio has a tool for refactoring
• Classic book: Refactoring by Martin Fowler
• A code that “smells” bad needs refactoring
Slide 23
(IIIb) Architecture from different perspectives
Similar ideas to the models in Lectures 6 and 7, but applied to architecture
design.
• Static model
• Similar to structural diagrams (e.g. class diagram).
• Dynamic model
• Similar to behavioral diagrams (e.g. activity, use case, state machine transition
diagram, sequence diagrams)
• Interface model
• E.g.: one subsystem is a plotting package; concern with the interface in calling the
plotting functions.
• Relationship model
• Similar to associations in class diagram
(IV) System Organizations
Slide 25-30 (IV a) Repository model
• Reference – Sommerville 6.3.2 Repository architecture
Slide 26: All the subsystems share the same repository (in middle)
Slide 31-33 (IV b) Client-server model
• Reference – Sommerville 6.3.3 Client-server architecture
• E.g. iSpace is the server, you access it with a browser as a client
• Email server is another server In UIC.
(IV) System Organizations
Slides 34-37 (IV c) Layered model
• Reference: Sommerville, 6.3.1 Layered architecture
Slide 35 Example
General rule:
• Objects in one layer can only call other objects in the same layer or one
layer below.
• Lower layer cannot access any layer above it
• Objects in operating system (OS) layer can only access other objects in OS layer.
• Objects in DB layer can only access other objects in DB layer and OS layer.
(IV) System Organizations
Slide 35
• From basics of IT class
• Software / hardware are layered:
Slide 36
• Examples in next lecture on how to “structure into layers”.
Slide 37
• E.g. Easy to add a new DB into system.
• Another e.g. Virtual machine, add another layer between OS layer
and hardware.
• Performance suffers.
(V) Component Control
Two types of component’s service
https://iansommerville.com/software-engineering-book/web/archpatterns/
1. Centralized control (Slide 38-39)
• One component tells other components what to do
• E.g. call-return model: higher module calls the lower module to do something
• Similar to function calls represented as a tree diagram
2. Event-based control (Slide 38, 40)
• Broadcast model: e.g. delegates; fire-alarm system, any component can raise
the alarm and call to action.
• Interrupt-driven model: e.g. in-coming phone call
