Bài giảng Kiến trúc phần mềm - Bài 8: Quy trình kiến trúc phần mềm - Trần Minh Triết

CTT526 - Kiến trúc phần mềm
Quy trình 
kiến trúc phần mềm
PGS.TS. Trần Minh Triết
tmtriet@fit.hcmus.edu.vn 
Trường Đại học Khoa Học Tự Nhiên
Khoa Công Nghệ Thông Tin
Bộ môn Công Nghệ Phần Mềm
Version 1.0 CuuDuongThanCong.com https://fb.com/tailieudientucntt
 Nội dung của bài giảng sử dụng:
Session 5:
A Software Architecture Process
trong bộ slide Software Architecture Essential
của GS. Ian Gorton 
Software Engineering Institute
Carnegie Mellon University
2
CuuDuongThanCong.com https://fb.com/tailieudientucntt
A Software Architecture Process
 Architects must be versatile:
 Work with the requirements team: The architect plays 
an important role in requirements gathering by 
understanding the overall systems needs and ensuring 
that the appropriate quality attributes are explicit and 
understood.
 Work with various application stakeholders: Architects 
play a pivotal liaison role by making sure all the 
application‟s stakeholder needs are understood and 
incorporated into the design. 
 Lead the technical design team: Defining the 
application architecture is a design activity. 
 Work with the project management: Planning, 
estimates, budgets, schedules
3
CuuDuongThanCong.com https://fb.com/tailieudientucntt
An Architecture Process
 Highly iterative
 Can scale to small/large projects
4
D e te rm in e 
A rc h ite c tu ra l 
R e q u ire m e n ts 
A rc h ite c tu re
D e s ig n
V a lid a t io n
CuuDuongThanCong.com https://fb.com/tailieudientucntt
Determine Architectural 
Requirements
 Sometime called:
 architecturally significant 
requirements 
 architecture use cases
 essentially the quality 
and non-functional 
requirements for a 
system. 
5
Functional
Requirements
Stakeholder
Requirements
Architecture 
Requirements
Determine
Architecture 
Requirements
CuuDuongThanCong.com https://fb.com/tailieudientucntt
Examples
 A typical architecture requirement :
 “Communications between components must be 
guaranteed to succeed with no message loss”
 Some architecture requirements are constraints:
 “The system must use the existing IIS-based web server 
and use Active Server Page to process web requests”
 Constraints impose restrictions on the architecture 
and are (almost always) non-negotiable. 
 They limit the range of design choices an architect 
can make. 
6
CuuDuongThanCong.com https://fb.com/tailieudientucntt
Quality Attribute Requirements
Quality
Attribute
Architecture Requirement
Performance Application performance must provide sub-four second response times for 90% of 
requests.
Security All communications must be authenticated and encrypted using certificates.
Resource
Management
The server component must run on a low end office-based server with 512MB memory.
Usability The user interface component must run in an Internet browser to support remote users.
Availability The system must run 24x7x365, with overall availability of 0.99.
Reliability No message loss is allowed, and all message delivery outcomes must be known with 30 
seconds
Scalability The application must be able to handle a peak load of 500 concurrent users during the 
enrollment period.
Modifiability The architecture must support a phased migration from the current Forth Generation 
Language (4GL) version to a .NET systems technology solution.
7
CuuDuongThanCong.com https://fb.com/tailieudientucntt
Constraints
Constraint Architecture Requirement
Business The technology must run as a plug-in for MS BizTalk, as we want to sell this to 
Microsoft.
Development The system must be written in Java so that we can use existing development staff.
Schedule The first version of this product must be delivered within six months.
Business We want to work closely with and get more development funding from MegaHugeTech 
Corp, so we need to use their technology in our application.
8
CuuDuongThanCong.com https://fb.com/tailieudientucntt
Priorities
 All requirements are not equal
 High: the application must support this requirement. 
 Medium: this requirement will need to be supported at some 
stage
 Low: this is part of the requirements wish list. 
 Tricky in face of conflicts, eg:
 Reusability of components in the solution versus rapid 
time-to-market. Making components generalized and 
reusable always takes more time and effort.
 Minimal expenditure on COTS products versus reduced 
development effort/cost. COTS products mean you have 
to develop less code, but they cost money.
 It‟s design – not meant to be easy!
9
CuuDuongThanCong.com https://fb.com/tailieudientucntt
Architecture Design
 Design steps are iterative
 Risk identification is a 
crucial output of the 
design
10
Architecture
Requirements
Architecture 
Views
Choose 
Architecture 
Framework
Allocate
Components
Architecture 
Document
CuuDuongThanCong.com https://fb.com/tailieudientucntt
Choosing the Architecture 
Framework
 Choose a architecture pattern/patterns that suit 
requirements
 No magic formula
 Analyze requirements and quality attributed 
supported by each pattern
 Complex architectures require creative blending of 
multiple patterns.
11
CuuDuongThanCong.com https://fb.com/tailieudientucntt
N-Tier Client Server Pattern
 Separation of concerns:
Presentation, business and 
data handling logic are clearly 
partitioned in different tiers. 
 Synchronous 
communications:
Communications between tiers 
is synchronous request-reply. 
Each tier waits for a response 
from the other tier before 
proceeding.
 Flexible deployment: There 
are no restrictions on how a 
multi-tier application is 
deployed. All tiers could run on 
the same machine, or each tier 
may be deployed on its own 
machine. 
12
Databases
Application Server
Web Server
Web 
Client
Web 
Client
Web 
Client
Client 
Tier
Web Server
Tier
Business 
Logic Tier
Data 
Management 
Tier
CuuDuongThanCong.com https://fb.com/tailieudientucntt
N-Tier Client Server – Quality 
Attribute Analysis
Quality
Attribute
Issues
Availability Servers in each tier can be replicated, so that if one fails, others remain available. 
Overall the application will provide a lower quality of service until the failed 
server is restored.
Failure handling If a client is communicating with a server that fails, most web and application 
servers implement transparent failover. This means a client request is, without 
its knowledge, redirected to a live replica server that can satisfy the request.
Modifiability Separation of concerns enhances modifiability, as the presentation, business and 
data management logic are all clearly encapsulated. Each can have its internal 
logic modified in many cases without changes rippling into other tiers.
Performance This architecture has proven high performance. Key issues to consider are the 
amount of concurrent threads supported in each server, the speed of 
connections between tiers and the amount of data that is transferred. As 
always with distributed systems, it makes sense to minimize the calls needed 
between tiers to fulfill each request.
Scalability As servers in each tier can be replicated, and multiple server instances run on the 
same or different servers, the architecture scales out and up well. In practice, 
the data management tier often becomes a bottleneck on the capacity of a 
system. 13
CuuDuongThanCong.com https://fb.com/tailieudientucntt
Messaging Pattern
 Asynchronous 
communications: Clients 
send requests to the queue, 
where the message is 
stored until an application 
removes it. Configurable 
QoS: The queue can be 
configured for high-speed, 
non-reliable or slower, 
reliable delivery. Queue 
operations can be 
coordinated with database 
transactions. 
 Loose coupling: There is 
no direct binding between 
clients and servers. 
14
Server
Server
Client
Client
Client
Que
ue Server
CuuDuongThanCong.com https://fb.com/tailieudientucntt
Messaging – Quality Attribute 
Analysis
Quality
Attribute
Issues
Availability Physical queues with the same logical name can be replicated across different 
messaging server instances. When one fails, clients can send messages to 
replica queues.
Failure handling If a client is communicating with a queue that fails, it can find a replica queue and 
post the message there. 
Modifiability Messaging is inherently loosely coupled, and this promotes high modifiability as 
clients and servers are not directly bound through an interface. Changes to 
the format of messages sent by clients may cause changes to the server 
implementations. Self-describing, discoverable message formats can help 
reduce this dependency on message formats.
Performance Message queuing technology can deliver thousands of messages per second. Non-
reliable messaging is faster than reliable, with the difference dependent of 
the quality of the messaging technology used.
Scalability Queues can be hosted on the communicating endpoints, or be replicated across 
clusters of messaging servers hosted on a single or multiple server machines. 
This makes messaging a highly scalable solution.
15
CuuDuongThanCong.com https://fb.com/tailieudientucntt
Publish-Subscribe Pattern
 Many-to-Many messaging:
Published messages are 
sent to all subscribers who 
are registered with the topic. 
 Configurable QoS: In 
addition to non-reliable and 
reliable messaging, the 
underlying communication 
mechanism may be point-to-
point or broadcast/multicast. 
 Loose Coupling: As with 
messaging, there is no 
direct binding between 
publishers and subscribers. 
16
Subscriber
Publisher Subscriber
Subscriber
Topic
CuuDuongThanCong.com https://fb.com/tailieudientucntt
Publish-Subscribe – Quality Attribute 
Analysis
Quality
Attribute
Issues
Availability Topics with the same logical name can be replicated across different server 
instances managed as a cluster. When one fails, publishers send messages to 
replica queues.
Failure handling If a publisher is communicating with a topic hosted by a server that fails, it can 
find a live replica server and send the message there. 
Modifiability Publish-subscribe is inherently loosely coupled, and this promotes high 
modifiability. New publishers and subscribers can be added to the system 
without change to the architecture or configuration. Changes to the format of 
messages published may cause changes to the subscriber implementations.
Performance Publish-subscribe can deliver thousands of messages per second, with non-
reliable messaging faster than reliable. If a publish-subscribe broker supports 
multicast/broadcast, it will deliver multiple messages in a more uniform time 
to each subscriber.
Scalability Topics can be replicated across clusters of servers hosted on a single or multiple 
server machines. Clusters of server can scale to provide very high message 
volume throughput. Also, multicast/broadcast solutions scale better than their 
point-to-point counterparts.
17
CuuDuongThanCong.com https://fb.com/tailieudientucntt
Broker Pattern
 Hub-and-spoke architecture:
The broker acts as a 
messaging hub, and senders 
and receivers connect as 
spokes. 
 Performs message routing:
The broker embeds processing 
logic to deliver a message 
received on an input port to an 
output port. 
 Performs message 
transformation: The broker 
logic transforms the source 
message type received on the 
input port to the destination 
message type required on the 
output port.
18
Receiver-2
Sender-1 Receiver-1
Broker
Sender-2
inPort1
inPort2
OutPort1
OutPort2
CuuDuongThanCong.com https://fb.com/tailieudientucntt
Broker Pattern - Quality Attribute 
Analysis
Quality
Attribute
Issues
Availability To build high availability architectures, brokers must be replicated. This 
is typically supported using similar mechanisms to messaging and 
publish-subscribe server clustering.
Failure handling As brokers have typed input ports, they validate and discard any 
messages that are sent in the wrong format. With replicated brokers, 
senders can fail over to a live broker should one of the replicas fail.
Modifiability Brokers separate the transformation and message routing logic from the 
senders and receivers. This enhances modifiability, as changes to 
transformation and routing logic can be made without affecting 
senders or receivers.
Performance Brokers can potentially become a bottleneck, especially if they must 
service high message volumes and execute complex transformation 
logic. Their throughput is typically lower than simple messaging 
with reliable delivery.
Scalability Clustering broker instances makes it possible to construct systems scale 
to handle high request loads.
19
CuuDuongThanCong.com https://fb.com/tailieudientucntt
Process Coordinator Pattern
 Process encapsulation: The 
process coordinator 
encapsulates the sequence of 
steps needed to fulfill the 
business process. The 
sequence can be arbitrarily 
complex. 
 Loose coupling: The server 
components are unaware of 
their role in the overall business 
process, and of the order of the 
steps in the process. 
 Flexible communications:
Communications between the 
coordinator and servers can be 
synchronous or asynchronous. 
20
Server-3Server-2 Server-4
Process
Coordinator
Server-1
step1
step2 step3 step4
Start
process
request
Process
results
CuuDuongThanCong.com https://fb.com/tailieudientucntt
Process Coordinator – Quality 
Attribute Analysis
Quality
Attribute
Issues
Availability The coordinator is a single point of failure. Hence it needs to be replicated to 
create a high availability solution.
Failure handling Failure handling is complex, as it can occur at any stage in the business process 
coordination. Failure of a later step in the process may require earlier steps 
to be undone using compensating transactions. Handling failures needs 
careful design to ensure the data maintained by the servers remains 
consistent.
Modifiability Process modifiability is enhanced because the process definition is 
encapsulated in the coordinator process. Servers can change their 
implementation without affecting the coordinator or other servers, as long 
as their external service definition doesn’t change.
Performance To achieve high performance, the coordinator must be able to handle multiple 
concurrent requests and manage the state of each as they progress through 
the process. Also, the performance of any process will be limited by the 
slowest step, namely the slowest server in the process.
Scalability The coordinator can be replicated to scale the application both up and out. 
21
CuuDuongThanCong.com https://fb.com/tailieudientucntt
Allocate Components
 Need to:
 Identify the major application components, and how they 
plug into the framework.
 Identify the interface or services that each component 
supports.
 Identify the responsibilities of the component, stating what 
it can be relied upon to do when it receives a request.
 Identify dependencies between components.
 Identify partitions in the architecture that are candidates 
for distribution over servers in a network
 And independent development
22
CuuDuongThanCong.com https://fb.com/tailieudientucntt
Some Design Guidelines
 Minimize dependencies between components. Strive for a 
loosely coupled solution in which changes to one component do 
not ripple through the architecture, propagating across many 
components. 
 Remember, every time you change something, you have to re-
test it.
 Design components that encapsulate a highly “cohesive” set of 
responsibilities. Cohesion is a measure of how well the parts of 
a component fit together. 
 Isolate dependencies on middleware and any COTS 
infrastructure technologies. 
 Use decomposition to structure components hierarchically. 
 Minimize calls between components, as these can prove costly 
if the components are distributed. 
23
CuuDuongThanCong.com https://fb.com/tailieudientucntt
A Simple Design Example
24
Validate
OrderInput
read
New
Orders
O
rd
erQ
Store
Customer
System
Order
System
SendEmail
Email
Server
Write
Order
Check
Order
Write
Order
Get
Order
Figure Key
Existing 
Component
New 
Component
Dependency
Database
Persistent 
Queue
Error
Log
CuuDuongThanCong.com https://fb.com/tailieudientucntt
Example Design
 Based on messaging
 Application components are:
 OrderInput: responsible for accessing the new orders 
database, encapsulating the order processing logic, and writing 
to the queue.
 Validate: encapsulates the responsibility of interacting with the 
customer system to carry out validation, and writing to the error 
logs if an order is invalid.
 Store: responsibility of interacting with the order system to 
store the order data.
 SendEmail: removes a message from the queue, formats an 
email message and sends it via an email server. It encapsulates 
all knowledge of the email format and email server access.
 Clear responsibilities and dependencies
25
CuuDuongThanCong.com https://fb.com/tailieudientucntt
Architecture Validation
 Aim of the validation phase is to increase confidence of the 
design team that the architecture is fit for purpose. 
 The validation has to be achieved within the project constraints 
of time and budget
 The trick is to be as rigorous and efficient as possible.
 Validating an architecture design poses tough challenges.
 „coz it‟s a design that can‟t be executed or tested 
 consists of new and COTS components that have to be 
integrated
 Two main techniques:
1. manual testing of the architecture using test scenarios. 
2. construction of a prototype that creates a simple archetype of the 
desired application
 aim of both is to identify potential flaws in the design so that they 
can be improved before implementation commences. 
 Cheaper to fix before built
26
CuuDuongThanCong.com https://fb.com/tailieudientucntt
Scenarios
 Part of SEI‟s ATAM work 
 Involves defining: 
 some kind of stimulus that will have an impact on the 
architecture. 
 working out how the architecture responds to this 
stimulus. 
 If the response is desirable, then a scenario is 
deemed to be satisfied by the architecture. 
 If the response is undesirable, or hard to quantify, 
then a flaw or at least an area of risk in the 
architecture may have been uncovered.
27
CuuDuongThanCong.com https://fb.com/tailieudientucntt
Scenario Examples
Quality
Attribute
Stimulus Response
Availability The network connection to the 
message consumers fails. 
Messages are stored on the MOM server until the 
connection is restored. Messages will only be 
lost if the server fails before the connection 
comes back up.
Modifiability A new set of data analysis 
components must be made 
available in the application.
The application needs to be rebuilt with the new 
libraries, and the all configuration files must be 
updated on every desktop to make the new 
components visible in the GUI toolbox.
Security No requests are received on a user 
session for ten minutes. 
The system treats this session as potentially insecure 
and invalidates the security credentials 
associated with the session. The user must 
logon again to connect to the application.
Modifiability The supplier of the transformation 
engine goes out of business.
A new transformation engine must be purchased. 
The abstract service layer that wraps the 
transformation engine component must be re-
implemented to support the new engine. Client 
components are unaffected as they only use the 
abstract service layer.
Scalability The concurrent user request load 
doubles during the 3 week 
enrollment period.
The application server is scaled out on a two 
machine cluster to handle the increased request 
load. 28
CuuDuongThanCong.com https://fb.com/tailieudientucntt
Scenarios for Order Processing 
Example
Quality
Attribute
Stimulus Response
Modifiability The Customer System packaged 
application is updated to an Oracle 
database.
The Validate component must be rewritten to 
interface to the Oracle system.
Availability The email server fails. Messages build up in the OrderQ until the 
email server restarts. Messages are then 
sent by the SendEmail component to 
remove the backlog. Order processing is 
not affected.
Reliability The Customer or Order systems are 
unavailable.
If either fails, order processing halts and alerts 
are sent to system administrators so that 
the problem can be fixed.
29
Needs fixing .
CuuDuongThanCong.com https://fb.com/tailieudientucntt
Prototyping
 Scenarios can‟t address everything:
 “On Friday afternoon, orders must be processed before close-
of-business to ensure delivery by Monday. Five thousand 
orders arrive through various channels (Web/Call 
centre/business partners) five minutes before close-of-
business.”
 Only one way – build something!
 Proof-of-concept prototype: Can the architecture as 
designed be built in a way that can satisfy the 
requirements?
 Proof-of-technology prototype : Does the technology 
(middleware, integrated applications, libraries, etc) 
selected to implement the application behave as 
expected?
30
CuuDuongThanCong.com https://fb.com/tailieudientucntt
Prototyping Strategy
 Build minimal system required to validate 
architecture, eg:
 An existing application shows that the queue and 
email systems are capable of supporting five 
thousand messages in five minutes
 So:
 Write a test program that calls the Customer System
validation APIs five thousand times, and time how long 
this takes.
 Write a test program that calls the Order System store 
APIs five thousand times, and time how long this takes.
31
CuuDuongThanCong.com https://fb.com/tailieudientucntt
Prototyping Thoughts
 Prototypes should be used judiciously to help 
reduce the risks inherent in a design. 
 Only way to address: 
 Performance
 Scalability
 Ease of integration
 Capabilities of off-the-shelf components 
 Need to be carefully scoped and managed. 
 Ideally take a day or two, a week or two at most. 
 Usually thrown-away so keep them cheap
 Don‟t let them acquire a life of their own
32
CuuDuongThanCong.com https://fb.com/tailieudientucntt
Summary
 3 step, iterative architecture design process
 Can be customized to small/meduim/large projects
 Agnostic to overall process framework (ie RUP, agile, 
waterfall, etc)
33
CuuDuongThanCong.com https://fb.com/tailieudientucntt