1. Design Model Like a Pyramid Component Level Design i n t e r f a c d sh u l
Component Level Design

2. software architecture
The software architecture of a program or computing system is the structure or structures of the system which comprise
The software components
The externally visible properties of those components
The relationships among the components
Software architectural design represents the structure of the data and program components that are required to build a computer-based system
An architectural design model is transferable
It can be applied to the design of other systems
It represents a set of abstractions that enable software engineers to describe architecture in predictable ways

3. Architectural Design Process
Basic Steps
Creation of the data design
Derivation of one or more representations of the architectural structure of the system
Analysis of alternative architectural styles to choose the one best suited to customer requirements and quality attributes
Elaboration of the architecture based on the selected architectural style
A database designer creates the data architecture for a system to represent the data components
A system architect selects an appropriate architectural style derived during system engineering and software requirements analysis

4. A software architecture enables a software engineer to
Analyze the effectiveness of the design in meeting its stated requirements
Consider architectural alternatives at a stage when making design changes is still relatively easy
Reduce the risks associated with the construction of the software
Focus is placed on the software component
A program module
An object-oriented class
A database
Middleware

5. Architectural Design 5

6. Why is Architecture Important?
Representations of software architecture are an enabler for communication between all parties (stakeholders) interested in the development of a computer-based system.
The architecture highlights early design decisions that will have a profound impact on all software engineering work that follows and, as important, on the ultimate success of the system as an operational entity.
Architecture “constitutes a relatively small, intellectually graspable model of how the system is structured and how its components work together” .

7. Data Design At the architectural level
Design of one or more databases to support the application architecture
Data Mining - Navigate through existing databases in an attempt to extract appropriate business-level information
Data warehouse — a large, independent database that has access to the data that are stored in databases that serve the set of applications required by a business

8. Data Design—Component Level
1. The systematic analysis principles applied to function and behavior should also be applied to data.
2. All data structures and the operations to be performed on each should be identified.
3. A data dictionary should be established and used to define both data and program design.
4. Low level data design decisions should be deferred until late in the design process.
5. The representation of data structure should be known only to those modules that must make direct use of the data contained within the structure – Concept of information hiding
6. A library of useful data structures and the operations that may be applied to them should be developed.
7. A software design and programming language should support the specification and realization of abstract data types.

9. Architectural Design
Architectural Styles
Architectural Patterns

10. Architectural Styles Each style has
a set of components (e.g., a database, computational modules) that perform a function required by a system,
a set of connectors that enable “communication, coordination and cooperation” among components,
constraints that define how components can be integrated to form the system, and
semantic models that enable a designer to understand the overall properties of a system by analyzing the known properties of its constituent parts.

11. Types of Architectural Styles
Data-centered architectures
Data flow architectures
Call and return architectures
Object-oriented architectures
Layered architectures

12. Data-Centered Architecture

13. Data Flow Architecture

14. Call and Return Architecture

15. Layered Architecture

16. Architectural Patterns
Concurrency — applications must handle multiple tasks in a manner that simulates parallelism
Operating system process management pattern
Task scheduler pattern
Persistence — Persistent data are stored in a database and may be read or modified by other processes at a later time.
Data Base Management System pattern
Application level persistence pattern
Distribution — the manner in which systems or components within systems communicate with one another in a distributed environment
Broker pattern

17. An Architectural Design Method
customer requirements
"four bedrooms, three baths,
lots of glass ..."
architectural design

18. Deriving Program Architecture

19. Partitioning the Architecture
“horizontal” and “vertical” partitioning are required

20. Horizontal Partitioning
function 1
function 3
function 2

21. Vertical Partitioning: Factoring
workers
decision-makers

22. Benefits of Partitioned Architecture
results in software that is easier to test
leads to software that is easier to maintain
results in propagation of fewer side effects
results in software that is easier to extend

23. DFD to Program structure
Mapping requirements into a software architecture or
DFD to Program structure
Steps:
The type of information flow is established.
Flow boundaries are indicated.
The DFD is mapped into program structure.
Control hierarchy is defined.
Resultant structure is refined using design measures and heuristics.
The architectural description is refined and elaborated.

24. Types of information flow
Transform flow
Transaction
flow 24

25. Transform Mapping

26. Transform Mapping Design Steps: Step1: Review the fundamental model.
Level 0 DFD

27. Transform Mapping
Step2: Review and refine data flow diagrams for the software
Level 1 DFD

28. Level 2 DFD for monitor sensor process

29. Step3: Determine whether the DFD has transform or transaction flow characteristics.
Step4: Isolate the transform center by specifying incoming and outgoing flow boundaries.
Level 3 DFD

30. Step5: Perform “First level factoring”.
First level factoring for monitor sensors

31. Step6: Perform “second level factoring”.

32. Step7: Refine the first iteration architecture using design heuristics for improved software quality.

33. Refined Program structure

34. Transaction Flow
incoming flow
action path T

35. Transaction Mapping Data flow model mapping program structure f a e bx1 g i
program structure l h k t j b m a x2 x3 x4 n d e f g h
x3.1 l m n i j k