1. Highlights of data design and
Chapter 10
Architectural Design
Highlights of data design and
architectural styles

2. Mapping OO Analysis to Design
Design Patterns
(domain Objects)
Responsibilities
Design
Subsystem Design
Class/Object Design
Message
Use
Cases
Object
Behavior Model
Class Model
Object Relatio-
nships
Attributes
Operations
Collaborators

3. Business/Domain level
Data Design - 1
Data design is defining data structures and their relationships.
Business/Domain level
Data Modeling (SRS)
Data Warehouses
Data Structures
Databases
Component level
Application level
Data warehouse: Large and independent database that has access to data stored in databases that serve a set of applications required by a specific business domain (Data Mining area).

4. Data Design - 2 Data design steps (at component level):
- Refine data objects (from ERD or Analysis Classes of SRS) and develop a set of data abstractions (user’s view of data objects).
(e.g., attributes of student data object)
- Implement data object attributes as one or more data structures
(this influenced by attributes, their relationships, and their use in the program).
(e.g., student_record: name, ID, Address, Phone#)
- Review data structures to ensure that appropriate relationships have been established.
(e.g., student_record and class_list)
- Simplify data structures as needed.

5. Software Architecture
- Data Design: Represents the data component of the architecture
- Architectural Design: Represents the structure of software components and their interactions (i.e., high-level organization of components and how they work together).
- The architecture is not the operational! It is a representation that enables a software engineer to:
1) analyze the design effectiveness for meeting system requirements
2) consider architectural alternatives early on so that design changes
can be made at low cost
3) reduce the risks associated with building the operational software.
4) facilitates ease of implementation
5) facilitates future updates
6) promote communications between all stakeholders

6. Architectural Styles (1)
The architecture is a representation of the structure of components and their interactions. That is, how components (processing elements or modules) are organized (arranged) and how they interact with each other.
An architecture (architectural style) has four elements:
- Components: processing elements that transform inputs to outputs, and data components.
- Connectors: the “glue” or interfaces that hold the processing elements together.
- Constraints: rules of how components interact with each other.
- Semantic models: information for understanding the system.
(Think of house architecture regardless of it style)

7. Architectural Styles (2)
An architectural style is a pattern of structural organization of components in the architecture.
Each style requires different design details.
Examples:
Data-Centered
Data-Flow
Call-and-Return
Layered OO

8. Data-Centered Architecture
Promotes independent components (integrateability)
Example:
Airline reservation system

9. Data Flow Architecture
Data transformation (pipe and filter) model.
Input/output
formats are
required.
Example:
Engineering or Scientific applications

10. Call and Return Architecture
Promotes modular design (easy to modify and scale)
Can be:
- Main/Sub
architecture
- RPC
- OO
Example:
Any I-P-O application (survey processing)

11. Layered Architecture
Layer of components are defined for specific tasks
Example:
Client/Server applications

12. Architectural Patterns
An architectural pattern represents a repeated aspect of the style.
The architectural style may include a number of patterns.
Examples:
Concurrency: Applications must handle multiple tasks in a manner that simulates parallelism (e.g.,OS process management pattern and task scheduler pattern)
Persistence: Data persists if it survives past the execution of the process that created it. (e.g., DBMS storage and retrieval capability pattern and application level persistence pattern that builds persistence features into the application architecture)
Distribution: Communicates among systems (or components of a system) in a distributed environment (e.g., a broker that acts as a “middle-man” between the client and a server)

13. Architectural Design - 1
1. The software
must be placed
into context.
That is, the design
should define
external entities
(other systems,
devices, people)
that the software
interacts with and
the nature of
the interaction.
See page 267 for roles (figure 10.6, page 268)
target system:
Security Function
uses
peers
homeowner
Safehome
Product
Internet-based
system
surveillance
function
sensors
control
panel

14. Architectural Design - 2
2. Define architectural
“archetypes”
- An archetype is an abstraction
(abstract class) that represents
one element of system behavior.
- They are derived from the
analysis model.
- They require further refinement.
(figure 10.7, page 269) C o n t r l e N d D c I i a
Communicates with

15. Architectural Design - 3
3. Define and refine software components that implement each archetype. (figure 10.8, page 270) S a f e H o m E x c u t i v r n l C M g G U I F s y p d

16. Architectural Design - 4
More refinement
(Instantiation of
Components)
(Refinement of
SafeHome
Example)
(figure 10.9,
page 271) s e n o r E x t a l C m u i c M g G U I f S y p d K P h H v

17. Analyzing Architectural Designs - 1
Methods for evaluating alternative architectural design:
- Architecture Trade-off Analysis Method (ATAM):
It is six steps approach developed by SEI
It is qualitative approach.
It is elimination process. A set of steps is applied to alternative architectures to assess design trade-offs, and identify “sensitive points” to quality attributes. See page 272 for analysis steps.
- Quantitative Guidance for Architectural Design: (not in the book)
Evolving research area that focus on defining quantitative techniques for assessing quality attributes of an architecture (design dimensions: such as performance, reliability, security, maintainability, flexibility, testability, portability, interoperability, reusability, etc…).

18. Analyzing Architectural Designs - 2
- Architectural Complexity:
It is the degree of coupling (dependency) among architecture elements (sharing, flow, constrained (control flow) dependencies)
Architectural Description Language (ADL):
ADLs provide syntax and semantic description of the design (diagrammatic and textual)
Example ADL tools: Rapide, UniCon, ACME, Aesop, UML, …
Please see Software Tools Box, page 275.

19. 10.6: Structured Design (self-reading)
Issue: There is no one particular approach for mapping requirements to design. Common approaches are Structured Design and OO Design.
Structured (data-flow) design is a method for deriving
Call-and-Return architecture from data flow diagrams. (i.e., using information flow for mapping requirements to design).
Objective: to derive a top-down architecture that is partitioned and modular.
Approach:
- the DFD is mapped into a program architecture (modules)
- the PSPEC and STD are used to indicate the content of each
module (component level design, Ch-12)

20. Structured Design (self-reading)
Derivation methods:
- Transform Mapping: It is based on flow of data items between
processes on the DFD.
- Transaction Mapping: It is based on transaction flow between
processes. A transaction is a data item that triggers data flow
along different paths (think of a menu system).
Notation:
Structure chart

21. Mapping Method (self-reading)
Program
Architecture
DFD
Transformation Or
Transaction Mapping

22. * Source: Software Engineering, 2nd ed., by David Budgen
Design and Quality issues*
The quality of the design determines the success and quality of the system to be built.
A quality system is that performs required tasks within specified constraints.
Unlike physical products, software design does not have physical properties that can be assessed against established measures (length, weight, height, thickness, etc…)
A software design is assessed based on quality factors (called “ilities”) including reliability, efficiency, maintainability, usability.
* Source: Software Engineering, 2nd ed., by David Budgen

23. Reliability Factor
Reliability is related to the behaviour of the system.
The designer tries to ensure that the system is
- complete: does it handle all combinations of events and states?
- consistent: is the system behavior as expected and is it repeatable?
- robust: a failure in one component should not “hung” the entire system (ensure graceful termination in case of a failure)
In safety-critical systems, this factors is Dominant. Multiple versions of the system (designed by different teams) may be used (auto-pilot system)

24. Efficiency Factor
Efficiency is related to resource allocation (CPU time, memory, disk space, network access, etc…)
The designer tries to predict the system needs of each identified resource.
Some resources are more important than others for a particular system.
Efficiency is difficult to deal with since it is based the designer's projection of resource needs from the design.

25. Maintainability Factor
Maintainability is related to the life time of the system, which relates to its cost.
The designer tries to structure the system such that future modifications are easy to conduct.
Other elements that affect maintainability include names (variables and procedures), documentation standards, presentation forms, etc…
Implementation (coding) also affects maintainability (Inline comments, documentation, headers, coding style, etc…)

26. Usability Factor Usability is related to user interface design.
The designer tries to ensure that interfaces
- are easy to use and navigate
- provide the user with control
- reduce “user memory load”
- are consistent
A “bad” interface makes a “good” system look “bad” from user perspective.
Other factors such as testability, portability, and reusability have special purposes in specific systems.

27. Quality Attributes of Design
Other quality factors are assessed by identifying quality attributes in the design, such as simplicity, modularity, coupling, cohesion, information hiding, accuracy, consistency, completeness, etc…
For a given system and for a specific purpose (operations, update, transfer, etc…), quality attributes must be identified for each quality factors. (see examples next slides).

28. Example - 1
Quality factors and attributes for a real-time control system.
Accuracy
Completeness
Consistency …
Storage Organization
CPU Utilization, …
Modularity
Structuredness …
. . .
Operation
Revision
Reliability
Efficiency
Maintainability
Testability
Purpose
Quality Factor
Quality Attributes

29. Example - 2 Quality factors and attributes for a compiler software.
Purpose
Quality Factor
Quality Attributes
Accuracy
Completeness
Consistency
Accessibility
Legibility
Modularity
Structuredness
Machine Independence
. . .
Operation
Revision
Transfer
Reliability
Usability
Maintainability
Testability
Portability
Reusability

30. Suggested Problems 10.1, 10.3, 10.4, 10.5, and 10.6.
Consider working the following problems from chapter 10, textbook, page 290:
10.1, 10.3, 10.4, 10.5, and 10.6.
NO submission is required. Work them for yourself!

31. Last Slide
End of Chapter 10