2. 2
Lecture Objectives
What is software architecture?
What are popular architecture styles?
Quality attributes of a system?
Architecture Design Guidelines?
4. 4
Overview
Goal of SW Design - is to build a model that meets all
customer requirements and leads to successful
implementation
Software systems grow in
Scale
Complexity
Distribution
How to deal with complexity?
Software engineering!
5. 5
What is architectural design?
Any software, regardless of application domain, should have an
architectural design that guides its construction and development.
What is architectural design?
» It defines the relationship between major structural elements
» It also define the styles and design patterns used to achieve requirements.
» Also the constraints that affects the way architecture can be implemented.
6. 6
What is architecture design?
Who is responsible for developing architecture design?
» Software architect and designer.
» They map the SW system requirements into architecture design.
» They apply various design strategies to divide and conquer the
complexities.
The architecture of a system is its 'skeleton'. It's the highest level of
abstraction of a system.
Software architecture is more about the design of the entire system, while
software design emphasizes on module/component/class level.
7. 7
Why is SW architecture Design is important?
There are several reasons:
» Poor design
May result in deficient product (does not meet system requirements)
Is not adaptive to future requirement changes
Not reusable
Exhibits unpredictable behaviour or perform badly
» Good design!!
» reduces the risks associated with software production
» helps development team works together in an orderly fashion
» makes the system traceable for implementation and testing,
and leads to software products that have higher quality
attributes.
10. 10
Software Requirements Specification
Serves as contract between
Developer and Customer
Specifies
Functional requirements
Non-functional requirements
Speed
Reliability
Security
Program size ...
System constraints and pre-condition
11. 11
Software Design Description (SDD)
What Is Outcome Of Software Architecture Design?
Software Design Description (SDD): an overall representation of
the software to be build.
Describes high and low level design
Components of the system
Modules of each components
Detailed information of each module
Data attributes
Operations
Developer
DB oriented application - data dictionary
Tables, columns and definition of terms.
12. 12
Software Design Description (SDD)
A sample outline of SDD (IEEE 1016)
Design overview, purpose and scope
Decomposition description (module, data, and process)
Dependency and connection
Attributes
User interfaces
Detailed design
13. 13
Design
In summary, SDLC consists of
Specification Analysis
Design
Implementation
Testing, Maintenance
We are interested in Design
14. 14
Two Steps in Software Design
Further split into two steps
Architectural Design
Detailed Design/Tactical design
Architecture design is front strategy for the detailed
design
Arch. Design: describe user accessible components and
the interconnections among them that are visible to
stakeholders.
Detailed Design: specify the internal details of each
component and might introduce new invisible
components – to the stakeholder, into the design.
15. 15
Example
Architecture Decision:
A priority queue for all customers
Detailed Design Decision:
The priority queue implemented using
Array?
Linked List?
Double Linked List?
...
16. Motivation of Architecture Design
• Question: can we directly start with detailed design?
• Most likely NO! for large scaled systems
• Example: build a house, many styles available:
– Victorian, Colonial, Cap Cod, California Ranch
– Depending on the system spec., a style has to be chosen
16
19. 19
Introduction to Software Architecture
Software Arch: very important in software development
Highlights early design decisions
Shows how system is structured
Covers functional and non-functional requirements
Blueprint guideline for development
21. 21
Software Architect
Who does the architectural design?
System Analyst or Software Architect
Jobs of Software Architect:
System static partition and decomposition
Establishing dynamic control between subsystems
Considering and evaluating all alternative architectural styles
Analysis of trade-off on quality attributes
22. 22
Formal Definition of SW Architecture
By IEEE 1471
“the fundamental organization of a system embodied in its
components, their relationships to each other, and to the
environment, and the principle guiding its design and evolution”
24. 24
Architecture Style
What is architecture style?
An architecture style (also known as an "architecture
pattern") abstracts the common properties of a family of
similar designs.
It contains a set of rules, constraints, and patterns of how to
structure a system into a set of elements and connectors
It governs runtime interaction of flow control and data transfer.
25. 25
Architecture Style
Key components are:
Elements that perform functions required by a system
Connectors that enable communication, coordination, and cooperation
among elements
Constraints that define how elements are integrated to form the system
Attributes that describe the advantages and disadvantages of the chosen
structure
26. 26
Why Architecture Style?
Saves cost and time on design!
Think about house example
Architecture style represents
Layout topology of elements
Once overall structure determined, rest are easy
27. 27
Example
Data Flow
Batch sequence, Pipe & Filter, Process Control
Data Centered
Repository and Blackboard
Object Oriented
Hierarchy
Layered, Virtual Machine Main/Subroutine
Asynchronous Communication
Event-Based, Buffered Messaging
Interaction Oriented
MVC, PAC
28. 28
How to decide architecture style?
Depends on how quality attributes are satisfied.
Each architecture style has its advantages,
disadvantages, and potential risks. Choosing the right
style to satisfy required functions and quality
attributes is very important.
Quality attributes are identified in the requirement
analysis process.
Three categories
Implementation attributes
Runtime attributes
Business attributes
30. 30
Implementation Attributes
Interoperability
Universal accessibility and ability to exchange data among
internal components and the outside world
Requires loose dependency of infrastructure
31. Implementation Attributes (cont..)
Maintainability & Extensibility
The ability to modify the system and conveniently extend it
Testability
Whether the system allows easy debugging
Portability
Can the system be deployed on different platforms
Scalability
Can system adapt to increase of requests
Flexibility
Ease of modification of system to cater to a different environment
32. 32
Run-Time Attributes
Availability
If system is available 24/7
Can be enhanced by replication
Security
The ability to defend against attacks
Performance
Time efficiency and resource efficiency
Usability
Completeness, correctness, compatibility and user friendliness
33. 33
Business Attributes
Time to market:
The time it takes from requirement analysis to the product is
released
Cost:
Expense of the building, maintaining, and operating the system,
Lifetime:
The period of time that the product is alive before retirement.
34. 34
Quality Attribute Trade-Off
Many quality attributes conflicts with each other!
Example:
Space vs. Time:
For example, to increase the time efficiency of a hash table or algorithm
means to decrease its space efficiency.
Reliability vs. performance
Java Program – array boundary check => performance down
C/C++ has no such checking and fast
Scalability vs. performance
Sacrifice performance for consistency
36. 36
Guideline 1
Think of What to Do before How to Do It.
System requirements (functional and non-functional
requirements) must be nailed down before design starts
Notice, different stakeholders have different opinions,
e.g.,.
Investor: system release date, budget
Developer: system performance, easy to maintain
User: user friendly
Clarify priority of all requirements before design
37. 37
Guideline 2: Think about abstract design
before thinking about concrete design.
Always starts with abstraction
Use multiple level of abstraction if necessary
Nail down the interface but leave room of change for
implementation
Using an abstract architectural design of a system to
communicate with stakeholders helps avoid overhauling
the system design in later stages of the software
development cycle.
Make all implementation decisions depend on the
abstract interfaces instead of concrete ones because those
are more stable
38. 38
Guideline 3: Think of non-functional
requirements early in design process
Speed, Reliability, Security have to be considered first
Otherwise, very hard to change your design to reflect
these requirements
The earlier, the better.
It is not possible to find a design that meets all quality
attributes.
Balance the quality attributes, and consider
heterogeneous architecture styles when necessary.
39. 39
Guideline 4: Think of reusability and
extensibility!
User requirements can change frequently
Extensibility is very important
Leave room for expansion
we need to consider how to reuse existing software
components to increase the reliability and cost-
effectiveness of new systems.
Always try hard to make software extensible in the
future.
40. 40
Guideline 5: High Cohesion and Loose
Coupling
Try to promote high cohesion within each element and
loose-coupling between elements.
One component (module) should be assigned ONE
functionality only
Design should be logically clear!
The less correlation between modules, the better!
Easy debugging and maintenance
Also allows great extensibility
41. Guideline 6: Tolerate refinement of
design.
• Never expect to have software design completely
perfect within one step.
• We may need to use prototyping and iteration to
refine the software design.
1. Wilki: Interoperability is a property referring to the ability of diverse systems and organizations to work together (inter-operate).
Tính tương hợp: khả năng các hệ thống khác nhau có thể trao đổi thông tin và sử dụng các thông tin trao đổi đó. Việc thiếu tính tương hợp ngụ ý rằng sản phẩm và các sản phẩm được mô tả không được thiết kế với sự tiêu chuẩn hoá ngay từ đầu. Đối với phần mềm, khái niệm tính tương hợp được sử dụng để mô tả khả năng các chương trình khác nhau trao đổi dữ liệu thông qua một tập các thủ tục nghiệp vụ chung, và để đọc và viết cùng các định dạng tệp và sử dụng cùng các giao thức.