Slide

1. Introduction to Software Architecture

2. 2
Lecture Objectives
 What is software architecture?
 What are popular architecture styles?
 Quality attributes of a system?
 Architecture Design Guidelines?

3. 1.1 Overview

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.

8. 8
Software Development Life Cycle (SDLC)

9. 9
Software Requirements Specification

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

17. 1.2 Software architecture: Bridging
requirements and implementation

18. 18
Introduction to Software Architecture

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

20. 20
Box-Line Diagram

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”

23. 1.3 Architectural Styles

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

29. 1.4 Quality 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

35. 1.5 Software architecture design
guidelines

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.

42. Guideline 7: Avoid ambiguous design and
over-detailed design.
• Ambiguous design lacks constraints
• Over-detailed design restricts implementation.

43. 43
Thanks!