CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. Chapter 10 Architectural Design Highlights of data design and architectural styles

CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept.

Chapter 10Architectural Design

Highlights of data design and architectural styles


Mapping OO Analysis to Design

Design Patterns(domain Objects)

ResponsibilitiesDesign

Subsystem Design

Class/Object Design

MessageDesign

UseCases

Object Behavior

Model

Class Model

Object Relatio-nships

AttributesOperations

Collaborators


Data Design - 1

Data design is defining data structures and their relationships.

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).

Business/Domain level

Data Modeling (SRS)

Data Warehouses

Data Structures

Databases

Component level

Application level


Data Design - 2Data 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.


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 implementation5) facilitates future updates6) promote communications between all stakeholders


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)


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


Data-Centered Architecture

Promotes independent components (integrateability)

Example:Airline reservation system


Data Flow Architecture

Data transformation (pipe and filter) model. Input/output formats are required.

Example:Engineering or Scientific applications


Call and Return Architecture

Promotes modular design (easy to modify and scale)

Can be:- Main/Sub architecture- RPC architecture- OO architecture

Example:Any I-P-O application (survey processing)


Layered Architecture

Layer of components are defined for specific tasks

Example:Client/Server applications


Architectural PatternsAn 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)


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 softwareinteracts with and the nature of the interaction.See page 267 for roles. (figure 10.6, page 268)

target system: Security Function

uses

uses peershomeowner

Safehome Product

Internet-based system

surveillance function

sensors

control panel

sensors

uses



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 ontroller

Node

Detector Indicator

Communicateswith



3. Define and refine software components that implement each archetype. (figure 10.8, page 270)

SafeHome Execut ive

External Communicat ion Management

GUI Int ernet Int erface

Funct ion select ion

Securit y Surveillance Home management

Control panel

processing

detector management

alarm processing



More refinement(Instantiation of Components)

(Refinement of SafeHome Example)

(figure 10.9, page 271)

sensorsensorsensorsensorsensorsensorsensorsensor

External Communicat ion Management

GUI Internet Interface

Security

Control panel

processing

detector management

alarm processing

Keypad processing

CP display functions

scheduler

sensorsensorsensorsensor

phone communication

alarm

SafeHome Execut ive


Analyzing Architectural Designs - 1Methods 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…).


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.


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)


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


Mapping Method (self-reading)

ProgramArchitecture

DFD

TransformationOr

Transaction Mapping


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


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)


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.


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…)


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.


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).


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 FactorQuality Attributes


Example - 2

Quality factors and attributes for a compiler software.

Purpose Quality FactorQuality Attributes

Accuracy

Completeness

Consistency

Accessibility

Legibility

Modularity

Structuredness

Machine Independence

. . .

Operation

Revision

Transfer

Reliability

Usability

Maintainability

Testability

Portability

Reusability


Suggested Problems

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!


Last Slide

End of Chapter 10

Documents

CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. Chapter 10 Architectural Design Highlights of data design and architectural styles