Architectural Design Software Architecture What is it Structure

Architectural Design

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”

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

Architectural 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 Archetypes: one element of the system Superordinate Systems Subordinate Systems Peer-Level Systems Actors 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

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

Flow Characteristics Transform flow Transaction flow

Transform Mapping

Factoring

First Level Factoring main program controller input controller processing controller output controller First level factoring is. Top-Down distribution of control.

Second Level Factoring Second level factoring is begins at the transform center boundary and moving outward along incoming and then outgoing paths.

Transaction Mapping Data flow model f e a d b mapping t x 1 program structure i g h l k j m t b a n d x 2 e x 4 x 3 f g l x 3. 1 h j i k m n

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

Map the Flow Model

Refining