Bài giảng Kiến trúc phần mềm - Chương: Quy trình kiến trúc phần mềm - Trần Minh Triết
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
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
Version 1.0
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
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 y.
Work with the project management: Planning,
estimates, budgets, schedules
3
An Architecture Process
Highly iterative
Can scale to small/large projects
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
V a lid a tio n
4
Determine Architectural
Requirements
Sometime called:
Functional
Requirements
Stakeholder
Requirements
architecturally significant
requirements
Determine
Architecture
quirements
architecture use cases
essentially the quality
and non-functional
requirements for a
system.
Architecture
Requirements
5
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
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
The sserver with 512MB memory.
Management
Usability
The user interface component must run in an Internet browser to support remote users.
The system must run 24x7x365, with overall availability of 0.99.
Availability
Reliability
No message loss is allowed, and all message delivery outcomes must be known with 30
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
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
Schedule
The ting development staff.
The first version of this product must be delivered within six months.
Business
We wunding from MegaHugeTech
Corp, so we need to use their technology in our application.
8
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 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
Architecture Design
Design steps are iterative
Architecture
Requirements
Risk identification is a
crucial output of the
design
Choose
Architecture
Framework
Allocate
Components
Architecture
Views
Architecture
Document
10
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
N-Tier Client Server Pattern
Separation of concerns:
Presentation, business and
data handling logic are clearly
partitioned in different tiers.
Client
Tier
Web
Client
Web
Client
Web
Client
Synchronous
communications:
Web Server
Web Server
Application Server
Databases
Communication
is synchronous request-reply.
Each tier waits for a response
from the other tier before
proceeding.
Business
Logic Tier
Flexible deployment: There
are no restrictions on how a
multi-tier application is
Data
Management
deployed. All tiers could run on
the same machine, or each tier
may be deployed on its own
machine.
12
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
Modifiability
Performance
If a client is communicating with a server that fails, most web and application
ns a client request is, without
its knowledge, redirected to a live replica server that can satisfy the request.
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.
This architecture has proven high performance. Key issues to consider are the
amount of concurrent threads supported in each server, the speed of
a 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
Messaging Pattern
Asynchronous
communications: Clients
send requests to the queue,
where the message is
stored until an application
removes it. Co
QoS: The queue can be
configured for high-speed,
non-reliable or slower,
reliable delivery. Queue
operations can be
Client
Client
Server
Server
Server
Que
ue
coordinated w
transactions.
Loose coupling: There is
no direct binding between
clients and servers.
14
Messaging – Quality Attribute
Analysis
Quality
Issues
Attribute
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
Modifiability
If a client is communicating with a queue that fails, it can find a replica queue and
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
Scalability
Message queuing technology can deliver thousands of messages per second. Non-
he difference dependent of
the quality of the messaging technology used.
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
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 messaging, the
Subscriber
Publisher
Topic
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
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
Modifiability
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.
Publis-subscribe is inherently losely couled, 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
Scalability
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
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
Broker Pattern
Hub-and-spoke architecture:
The broker acts as a
messaging hub, and senders
and receivers connect as
spokes.
inPort1
OutPort1
Sender-1
Sender-2
Receiver-1
Receiver-2
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 transform
message type received on the
input port to the destination
message type required on the
output port.
Broker
inPort2
OutPort2
18
Broker Pattern - Quality Attribute
Analysis
Quality
Issues
Attribute
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
Modifiability
Performance
Scalability
As brokers have typed input ports, they validate and discard any
mat. With replicated brokers,
senders can fail over to a live broker should one of the replicas fail.
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.
k, especially if they must
service high message volumes and execute complex transformation
logic. Their throughput is typically lower than simple messaging
with reliable delivery.
Clustering broker instances makes it possible to construct systems scale
to handle high request loads.
19
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.
Start
process
request
Process
results
Process
Coordinator
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 com
Communications between the
coordinator and servers can be
synchronous or asynchronous.
step1
step2
step3
step4
2
Server-3
Server-4
20
Tải về để xem bản đầy đủ
33 trang
21200
Free
Bạn đang xem 20 trang mẫu của tài liệu "Bài giảng Kiến trúc phần mềm - Chương: Quy trình kiến trúc phần mềm - Trần Minh Triết", để tải tài liệu gốc về máy hãy click vào nút Download ở trên
File đính kèm:
- bai_giang_kien_truc_phan_mem_chuong_quy_trinh_kien_truc_phan.pdf
