5/21/24
SOICT
School of Information and Communication Technology
1
5/21/24
IT3180 – Introduction to Software
Engineering
12 – System Architecture
Pha thiết kế
Đối với một tập hợp các yêu cầu nhất định, nhóm phát triển phần mềm
phải thiết kế một hệ thống đáp ứng các yêu cầu đó
Việc thiết kế một hệ thống bao gồm:
• Kiến trúc hệ thống
• Thiết kế chương trình
• Bảo mật
• Hiệu năng
• Trong thực tế, các yêu cầu và thiết kế có mối quan hệ với nhau, làm việc
trên thiết kế thường cho phép làm rõ các yêu cầu.
4
2
5/21/24
Creativity and Design
Creativity
• System and program design are a particular part of creativity in the
software development, as user interfaces
Software development as a craft
• Software developers have a variety of tools that can be used in design
• We have to select the appropriate tool for a given implementation
System architecture
System architecture is the overall design of a system:
• Computers and networks (e.g., LAN, Internet, cloud services)
• Interfaces and protocols (e.g., HTTP, IMAP, ODBC)
• Databases (e.g., relational, distributed)
• Security
• Operations (e.g., backup, archiving, audit trails)
At this stage of the development process, we should select:
• Software environment (e.g., language, database system, framework)
• Testing framework
3
5/21/24
Models for System Architecture
Our models for system architecture are based on UML
• For every system, there is a choice of models
• The goal is to choose models that best model the system, which are
also clear to everybody
In UML, every model must have both a diagram and a supporting
specification
• The lectures provide diagrams that give an outline of the system,
without supporting specifications
• The diagrams show the relationship among parts of the system, but
much more details are needed to specify the system
Subsystems
Subsystem is a group of elements that form part of a system
• Coupling is a measure of the dependencies between two subsystems
• If two systems are strongly coupled, it is hard to modify one without modifying
the other
• Cohesion is a measure of dependencies within a subsystem
• If a subsystem contains many closely related functions, its cohesion is high
• An ideal division of a complex system into subsystems has low
coupling between subsystems and high cohesion within subsystems
4
5/21/24
Example: Low cohesion (blue), High coupling (red)
Example: High cohesion (blue), Low coupling (red)
BETTER!
10
10
5
5/21/24
11
11
12
12
6
5/21/24
Component
• A component is a replaceable part of a system that conforms to and
provides the realization of a set of interfaces
• A component can be thought of as an implementation of a subsystem
• UML definition of a component
• A distributable piece of implementation of a system, including software code
(source, binary, executable) but also including business documents
13
13
Components as Replaceable Elements
Components allow systems to be
assembled from binary replaceable
elements
• A component can be replaced by
any other component(s) that
conforms to the interfaces
• A component is part of a system
• A component provides the
realization of a set of interfaces
14
14
7
5/21/24
Components and Classes
• Classes represent logical abstractions
• They have attributes (data) and operations (methods)
• Classes can be combined to form programs
• Components represent physical things that live in the world of bits
• Components may be at different levels of abstraction
• Components have operations that are reachable only through
interfaces
• Components can be combined to form systems
15
15
Kinds of Components
• Three kinds of components may be distinguished
• Deployment components
• Components are necessary and sufficient to form an executable system
• Dynamic libraries (.dll) or executable files (.exe) are two examples of
deployment components
• Work product components
• These components are generally the residue of the development process
• Source code files, data files are examples of work product components from
which deployment components are created
• Execution components
• These components are created as a consequence of an executing system, such
as .obj, .class files
16
16
8
5/21/24
Package
A package is a general purpose mechanism for organizing elements into
groups
17
17
Node
• A node is a physical element that exists at a run time and provides a
computational resource, e.g., a computer, a smartphone, a router etc.
• Components may live on nodes
18
18
9
5/21/24
Example: Simple Web System
• Static pages from server
• All interactions require communication with the server
19
19
Deployment Diagram
• One of the two kinds of diagrams used in modeling the physical aspects
of an object-oriented system
• Show the configuration of run time processing nodes and the
components that live on them
• We use deployment diagrams to model the static deployment view of a
system
• A deployment diagram commonly contains
• Nodes
• Dependency and association relationships
20
20
10
5/21/24
Deployment Diagram (2)
21
21
Deployment Diagram (3) – Common Uses
When modeling the static deployment view of a system, we’ll typically
use deployment diagrams in one of the three ways
• To model embedded systems
• To model client/server systems
• To model fully distributed systems
22
22
11
5/21/24
Model embedded system
• Identify the devices and nodes
that are unique to your system
• Model the relationships
among these processors and
devices
23
23
Model client/server system
• Identify the nodes that represent your system’s client and server
processors
• Highlight those devices that are relevant to the behavior of the system
• Model the topology of these nodes in a deployment diagram
24
24
12
5/21/24
Model a fully distributed system
25
25
Component Diagram
• Component diagrams are one
of the two kinds of diagrams
for modeling the physical
aspects of object-oriented
software system
• Show the organization and
dependencies among a set of
components
• We use component diagrams
to model the static
implementation view of a
software system
26
26
13
5/21/24
Component diagram - content
Component diagram commonly contains:
• Components
• Interfaces
• Dependency, generalization, association and realization relationships
27
27
Component Diagram: Interfaces
An interface is a collection of
operations that are used to
specify a service of a class or a
component
• Relationship between a
component and its interface
can be in two ways
• Iconic form of realization
• Expanded form (reveal
operations) of realization
• The component that accesses
the services of the other
component through the
interfaces using dependency
28
28
14
5/21/24
Application Programming Interface (API)
An API is an interface that is realized by one or more components
29
29
Component diagaram to Model an API
30
30
15
5/21/24
Component Diagram to Model Source Code
31
31
Component Diagram to Model an executable release
32
32
16
5/21/24
Component Diagram to Model Tables, Files, Documents
33
33
Component Diagram to Model a physical database
34
34
17
5/21/24
Architectural Styles
• An architectural style is system architecture that recurs in many
different applications
• See:
• Mary Shaw and David Garlan, Software architecture: perspective on an emerging
discipline. Prentice Hall, 1996.
35
35
Architecture Style: Pipe
• Example: A three-pass compiler
36
36
18
5/21/24
Architectural Style: Client/Server
• Example: A mail system
• The control flows in the client and the server are independent
• Communication between client and server follows a protocol
• Because components are binary replaceable elements, either the client
or the server can be replaced by another component that implements
the protocol
• In a peer-to-peer architecture, the same components act as both client
and server
37
37
Architectural Style: Repository
38
38
19
5/21/24
Architectural Style: Repository with Storage Access Layer
39
39
Exercise (Old Exam Question)
• A company that makes sport equipments decides to create a system
for selling online. The company already has a product database with
description, marketing information, and prices of the equipment that it
manufactures
• To sell equipment online the company will need to create: a customer
database and an ordering system for online customers
• The plan is to develop the system in two phases. During phase 1,
simple versions of the customer database and ordering system will be
brought into production. In Phase 2, major enhancements will be made
to these components
40
40
20
5/21/24
12. System Architecture
(end of lecture)
46
46
21
