Chapter 10: Architectural Design Presented By: Andy Carroll

Software Architecture: What is it? Structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them Two Levels Data Design Architectural Design

Software Architecture The architecture is not the operational software. Rather, it is a representation that 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, and Reduce the risks associated with the construction of the software.

Importance? Representations of software architecture are enablers for communication The architecture highlights early design decisions Architecture “constitutes a relatively small, intellectually graspable model of how the system is structured and how its components work together” Most important?

Data Design: Architectural Level Multiple Databases Data mining: Knowledge Discovery in Databases (KDD) Data Warehousing

Data Design: Component Level Focuses on representation of data structures that are directly accessed by software components Best practices: Develop data abstractions Ensure relationships established Simplify where possible Examples?

Principles of Data Design The systematic analysis principles applied to function and behavior should also be applied to data. All data structures and the operations to be performed on each should be identified A mechanism for defining the content of each data object should be established and used to define both data and the operations applied to it. Low-level design decisions should be deferred until late in the design process. The representation of a data structure should be known only to those modules that must make direct use of the data contained within the structure. A library of useful data structures and the operations that may be applied to them should be developed. A software design and programming language should support the specification and realization of abstract data types.

Architectural Styles Styles describe a category defined by: A set of components that perform a function Set of connectors that enable communication Constraints on integration of components Semantic models that help the understanding of overall properties of a system Types of Architectures Data-centered Data flow Call and Return ( Main Program/Subprogram and Remote Procedure Call) Object Oriented Layered

Data-Centered Example?

Data Flow Examples?

Call and Return

Layered

Architectural Patterns Concurrency: applications must handle multiple tasks in a manner that simulates parallelism Persistence: Data persists if it survives past the execution of the process that created it. Two patterns are common: DBMS Pattern Application Level Persistence Pattern Distribution: the manner in which systems or components within systems communicate with one another in a distributed environment

Organization and Refinement Assessing architectural style: Control How is control managed? Does a hierarchy exist? How is control transferred? Data How is data communicated? Is flow continuous? Sporadic? Component interaction with data? When might data flow be continuous? Sporadic?

Architectural Design Representing in context: interaction with target system Superordinate Systems Subordinate Systems Peer-Level Systems Actors Archetypes: one element of the system Nodes, Detectors, Indicators, Controllers Refining: implementation of previously defined archetypes

Architectural Context Example

Archetype Example

Components Example

Refined Components Example

Analyzing the Design Collect scenarios Elicit requirements, constraints, environment description Describe architectural designs or patterns that have been chosen Evaluate quality attributes in isolation Identify the sensitivity of quality attributes to various attributes for a specific style Critique candidate architectures

Architectural Complexity Sharing dependencies Flow dependencies Constrained dependencies Could these be related or causal?

Mapping Data Flow to Architecture Transform Mapping Review the fundamental system model. Review and refine data flow diagrams for the software Determine whether the DFD has transform or transaction flow characteristics. Isolate the transform center by specifying incoming and outgoing flow boundaries. Perform “first-level factoring” Perform “second-level factoring” Refine the first-iteration architecture using design heuristics for improved software quality.

Flow Characteristics Transform flow Transaction flow

Transform Mapping

Factoring

First Level Factoring main program controller output input processing

Second Level Factoring

Mapping Data Flow to Architecture Transaction Mapping Review the fundamental system model. Review and refine data flow diagrams for the software Determine whether the DFD has transform or transaction flow characteristics. Isolate the transaction center and the flow characteristics along each of the action paths. Map the DFD in a program structure amenable to transaction processing. Factor and refine the transaction structure and the structure of each action path. Refine the first-iteration architecture using design heuristics for improved software quality.

Transaction Mapping Data flow model mapping program structure f a e b x1 t 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

Isolate Flow Paths error msg command produce error msg read command format setting fixture setting status determine setting validate command invalid command read fixture status command raw setting combined status determine type valid command read record robot control record calculate output values send control value values format report assembly record report start/stop

Map the Flow Model

Refining