Programming Techniques Lecture 8 Architectural Design Based on: Software Engineering, A Practitioner’s Approach, 6/e, R.S. Pressman Software Engineering

Programming Techniques

Lecture 8 Architectural Design

Based on: Software Engineering, A Practitioner’s Approach, 6/e, R.S. Pressman

Software Engineering

Fall 2005


Overview

• Architectural design represents the structure of the data and program components required to build a computer-based system.

• A number of architectural "styles" exist. • Architectural design begins with data design and

proceeds to the derivation of one or more representations of the architectural structure of the system. The resulting architectural model encompasses both the data architecture and the program structure.

• The architectural model is subjected to software quality review like all other design work products.


Architectural Design

• Represents the structure of data and program components that are required to build a computer-based system.

• It considers the architectural style that the system will take, the structure and properties of the components that constitute the system, and the interrelationships that occur among all architectural components of a system.


Who Does It?

• The job is often allocated to specialists when large, complex systems are built. Otherwise, a software engineer can design both data and architecture.

• The ‘system architect’ selects an appropriate architectural style for the requirements derived during system engineering and software requirements analysis.


What are the steps?

• Architectural design begins with data design and then proceeds to the derivation of one or more representations of the architectural structure of the system.

• Alternative architectural styles or patterns are analysed to derive structure that is best suited to customer requirements and quality attributes.

• Once an alternative has been selected, the architecture is elaborated using an architectural design method.


What is the work product

• An architecture model encompassing data architecture and program structure is created during architectural design.

• In addition, component properties and relationships (interactions) are described.


1. Software Architecture?

• The architecture is not the operational software. The architecture is not the operational software. Rather, it is a representation that enables a Rather, it is a representation that enables a software engineer to: software engineer to:

• (1) analyze the effectiveness of the design in (1) analyze the effectiveness of the design in meeting its stated requirements, meeting its stated requirements,

• (2) consider architectural alternatives at a stage (2) consider architectural alternatives at a stage when making design changes is still relatively when making design changes is still relatively easy, and easy, and

• (3) reduce the risks associated with the (3) reduce the risks associated with the construction of the software.construction of the software.


Importance of Architecture

• Architecture highlights early design decisions that will have a profound impact on the ultimate success of the system as an operational entity

• The architecture itself constitutes an intellectually manageable model of how the system is structured and how its components work together


Software Architecture

• The design of software architecture considers two levels of the design pyramid:- Data design- Architectural design

• Data design enables us to represent the data component of the architecture in conventional systems and class definitions in object-oriented systems.

• Architectural design focuses on the representation of the structure of software components, their properties and interactions.


2. Data Design

• Translates data objects defined as part of the analysis model into data structures at the software component level and, when necessary, a database architecture at the application level

• Existing databases can be used or a database is designed and built specifically for a new system.


2.1. Data Design at the Architectural Level

• Design of one or more databases to support the application architecture

• Design of methods for ‘mining’ (also called knowledge discovery in databases (KDD) ) the content of multiple databases

» navigate through existing databases in an attempt to extract appropriate business-level information

» design of a 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


Data Warehouse

• A data warehouse is a separate data environment that is not directly integrated with day-to-day applications, but encompasses all data used by a business.

• It is 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.


Data Warehouse Challenges for Data Architects

• Subject orientation - data warehouse organized by business subjects rather than business processes or functions

• Integration - data in the warehouse must exhibit consistent naming conventions, encoding structures, and physical attributes even when inconsistencies exist among application-oriented databases

• Time variancy - unlike transaction-oriented databases where data may only be accurate for short time periods, the time horizon for a data warehouse may be several years

• Nonvolatility - data remains in the data warehouse once added and old data may only be purged every few years, if at all


Data Mining/Warehousing Software Tools

• They assist in the identification of significant relationships among attributes that describe a specific data object or set of data objects.

• Mining tools accept large data sets as input and allow the user to query the data in an effort to better understand relationships among various data items.

• Warehousing tools that are used for design provide entity relationship or other modeling capabilities.


2.2. Data Design at the Component Level

• Focus is on the representation of data structures that are directly accessed by one or more software components.

• In reality, the design of data begins during the creation of the analysis model.

• Steps:– refine data objects and develop a set of data abstractions

– implement data object attributes as one or more data structures

– review data structures to ensure that appropriate relationships have been established

– simplify data structures as required


Data Specification Principles I

• 1. Systematic analysis principles applied to function and behavior should also be applied to data - Representation of data flow and content should also developed and reviewed, data objects should be identified, alternative data organisations should be considered, and the impact of data modeling on software design should be evaluated.

• 2. All data structures and the operations to be performed on each should be identified. – The design of an efficient data structure must take the operations to be performed on the data structure into account (encapsulation)


Data Specification Principles II

• 3. Data dictionary should be established and used to define both data and program design. – Class diagrams define the data items (attributes) contained within a class and the processing (operations) that are applied to these data items.

• 4. Low level design processes should be deferred until late in the design process. – Overall data organisation may be defined during requirements analysis, refined during data design work, and specified in detail during component-level design.


Data Specification Principles III

• 5. Representations of data structure should be known only to those modules that must make direct use of the data contained within in the data structure. – Information hiding and coupling provide insight into the quality of a software design.

• 6. A library of useful data structures and operations should be developed. – A class library achieves this.

• 7. A software design and its implementation language should support the specification and realization of abstract data types.


3. Architectural Styles and Patterns

• An architectural style is a transformation that is imposed on the design of an entire system. The intent is to establish a structure for all components of the system.

• An architectural pattern, like an architectural style, imposes a transformation on the design of an architecture.


Comparing Architectural Styles and Patterns

• Both impose transformations on the design of an entire system

• Scope of architectural pattern is less broad

• Patterns impose rules on the architecture describing how the software will deliver some aspect of its functionality at the infrastructure level


3.1. Architectural Style Elements

• Set of components – that perform a function required by a system (e.g. database, computational modules)

• Set of connections - that enable communication, coordination, and cooperation among components

• Constraints - defining how components can be integrated to form the system

• Semantic models - that enable designers to understand the overall system properties by analyzing properties of its constituent parts


Architectural Styles

• Data-centered - data store (e.g., file or database) lies at the center of this architecture and is accessed frequently by other components that modify data

• Data-flow - input data is transformed by a series of computational or manipulative components into output data

• Call and return - program structure decomposes function into control hierarchy with main program invokes several subprograms

• Object-oriented - components of system encapsulate data and operations, communication between components is by message passing

• Layered - several layers are defined, each accomplishing operations that progressively become closer to the machine instruction set


Data-centered Architecture

• A data store (e.g. a file or database) resides at the centre of this architecture and is accessed frequently by other components that update, add, delete or otherwise modify data within the store.

• Promotes integrability – existing components can be changed and new client components added to the architecture without concern about other clients (clients operate independently). Also, data can be passed among clients using the blackboard mechanism (i.e.. The blackboard component serves to coordinate the transfer of information between clients).


Data-centered Architecture

Next figure:

• Client software accesses a central repository. In some cases the data repository is passive. That is, client software accesses the data independent on any changes to the data or the actions of other client software.

• A variation of this approach transforms the repository into a ‘blackboard’ that sends notifications to client software when data of interest to the client changes.


Data-Centered Architecture


Data-flow architecture

• This architecture is applied when input data are to be transformed through a series of computational or manipulative components into output data.

• A pipe and filter structure has a set of components, called filters, connected by pipes that transmits data from one component to the next.

• Each filter works independently of those components upstream and downstream; is designed to expect data input of a certain form; and produces data output (to the next filter) of a specified form.

• The filter does not require knowledge of the workings of its neighbouring filters.

• Batch sequential - if the data flow degenerate into a single line of transform. This structure accepts a batch of data and then applies a series of sequential components (filters) to transform it.


Data Flow Architecture


Call and Return Architecture

• It enables a software designer to achieve a program structure that is relatively easy to modify and scale

Two substyles:

• Main program/subprogram architecture – decomposes function into a control hierarchy where a ‘main’ program invokes a number of program components, which in turn may invoke still other components.

• Remote procedure call architecture – the components of main program/subprogram architecture are distributed across multiple computers on a network.


Call and Return Architecture


Object-oriented architecture

• The components of a system encapsulate data and the operations that must be applied to manipulate the data

• Communication and coordination between components is accomplished by message passing


Layered Architecture

• A number of different layers are defined, each accomplishing operations that progressively become closer to the machine instruction set.

• At the outer layer, components service user interface operations.

• At the inner layer, components perform operating system interfacing.

• Intermediate layers provide utility services and application software functions.


Layered Architecture


Choosing an Architectural Style

• More than one style might be appropriate

• Alternatives might be designed and evaluated

• For example, a layered style (appropriate for most systems) can be combined with a data-centred architecture in many database applications.


3.2. Architectural Patterns

• Architectural patterns for software define a specific approach for handling some behavioral characteristic of the system.

• A software architecture may have a number of architectural patterns that address issues such as concurrency, persistence, and distribution.


Concurrency

• Many applications must handle multiple tasks in a manner that simulates parallelism

• The way in which an application can handle concurrency can be presented by a different architectural pattern:

– operating system process management pattern – that provides built-in OS features that allow components to execute concurrently. Also incorporates OS functionality that manages communication between processes, scheduling and other capabilities required to achieve concurrency.

– task scheduler pattern – contains a set of active objects that each contain a tick() operation. The scheduler periodically invokes tick() for each object, which then performs the functions it must perform before returning control back to the scheduler, which then invokes the tick() operation for the next concurrent object.


Persistence

• Data persists if it survives past the execution of the process that created it.

• Persistent data are stored in a database or file and may be read or modified by other processes at a later time.

Two patterns are common: – a database management system pattern that applies the

storage and retrieval capability of a DBMS to the application architecture

– an application level persistence pattern that builds persistence features into the application architecture


Distribution

• The distribution problem addresses the manner in which systems or components within systems communicate with one another in a distributed environment

• Two elements to this problem:

- the way in which entities connect to one another;

- the nature of the communication that occurs• A broker acts as a ‘middle-man’ between the client component

and a server component. The client sends a message to the broker, and the broker completes the connection. CORBA is an example of a broker architecture.


4. Architectural Design

• Software to be developed must be put into context (i.e., model external entities and define interfaces)

• Identify architectural archetypes (collection of abstractions that must be modeled if the system is to be constructed)

• Specify structure of the system by defining and refining the software components needed to implement each archetype

• Continue the process iteratively until a complete architectural structure has been derived


4.1. Representing the System in Context

• Use the architectural context diagram (ACD) to model the manner in which the system interacts with external entities


Representing the System in Context

• Systems that interoperate with the target system (the system for which an architectural design is to be developed) are represented as

– Superordinate systems - using the target system as part of some higher level processing scheme

– Subordinate systems - used by the target system to provide data or processing needed to complete the target system

– Peer level systems - producing or consuming information needed by peers of the target system

– Actors - people or devices that interact with the system to produce or consume information needed for requisite processing


ACD for the SafeHome Security Function

Figure on the next slide:

• The SafeHome product controller and the Internet-based system – superordinate to the security function

• The surveillance function - peer system

• The homeowner and control panels – actors

• Sensors, used by the security software – subordinate system


Architectural Context

target system: Security Function

uses

uses peershomeowner

Safehome Product

Internet-based system

surveillance function

sensors

control panel

sensors

uses


Architectural Context Diagram

• As part of architectural design:

- Interfaces must be defined

- All the data that flow into or out of the target system must be identified


4.2. Defining Archetypes

• An archetype is a class or pattern that represents a core abstraction that is critical to the design of an architecture for the target system.

• May be defined by examining the analysis classes defined in the analysis model

• Determine the stable elements of the architecture that will need to be implemented when the system is built


Archetypes

SafeHome security function archetypes:

• Node – a cohesive collection of input and output elements (E.g. various sensors, alarm (output) indicators)

• Detector – an abstraction that encompasses all sensing equipment that feeds information into the target system.

• Indicator – all mechanisms (e.g. alarm siren, flashing lights, bell) for indicating that an alarm condition is occurring

• Controller – the mechanism that allows the arming or disarming of a node. If they reside on a network, they have the ability to communicate with one another.


Archetypes

Figure 10.7 UML relationships for SafeHome security function archetypes (adapted from [BOS00])

Controller

Node

communicates with

Detector Indicator


4.3. Refining Architecture into Components

• Process begins with an examination of the analysis classes for entities from the business domain that must be addressed in the software architecture. Hence, the application domain is one source for the derivation and refinement of components.

• Another source is the infrastructure domain. – The architecture must accommodate many infrastructure components that enable application components, but have no business connection to the application domain. (E.g. – memory management components, communication components, database components and task management components)

• The interfaces depicted in the architecture context diagram may imply specialized components needed to process data that crosses the interfaces

• Look for archetypes that are reoccur in several components and create new components that service each repeating design pattern


Refining Architecture into Components

SafeHome...We might define the set of top-level components that address the following functionality:

• External communication management – coordinates communication of the security function with external entities

• Control panel processing – manages all control panel functionality

• Detector management – coordinates access to all detectors attached to the system

• Alarm processing – verifies and acts on all alarm conditions


Refining Architecture into Components

• Each of the top-level components would have to be elaborated iteratively and then positioned within the overall architecture.

• Design classes would be defined for each

• The design details of all attributes and operations would not be specified until component-level design.


Component Structure

SafeHome Executive

External Communication Management

GUI Internet Interface

Function selection

Security Surveillance Home management

Control panel

processing

detector management

alarm processing


4.4.Instantiation of the System

• Instantiation of the system – the architecture is applied to a specific problem with the intent of demonstrating that the structure of components is appropriate.

• Components of the SafeHome architecture for the security system are further refined to show additional details (the figure on the next slide). For example: The detector management component interact with a scheduler infrastructure component that implements ‘concurrent’ polling of each sensor object used by the security system.


Refined Component Structure

sensorsensorsensorsensor

sensorsensorsensor

sensor

External Communication Management

GUI Internet Interface

Security

Control

panelprocessing

detector

managementalarm

processing

Keypad processing

CP display functions

scheduler

sensorsensorsensorsensor

phone communication

alarm

SafeHome Executive


Software Tools

• Architectural design tools model the overall software structure by representing component interfaces, dependencies and relationships and interactions

• Adalon (www.synthis.com) – web-based component architecture

• ObjectIF (www.microtool.com) – UML-based design tool

• Rational Rose (www.rational.com) – UML-based design tool


5. Assessing Alternative Architectural Design

• Ideally, design results in a number of architectural alternatives that are each assessed to determine which is the most appropriate for the problem to be solved.


5.1. Architecture Trade-off Analysis Method I

Architecture trade-off analysis method (ATAM) - establishes aniterative evaluation process for software architecture:• 1. Collect scenarios • 2. Elicit requirements, constraints, and environmental description - to

be sure that all stakeholder concerns have been addressed.• 3. Describe architectural styles/patterns chosen to address scenarios

and requirements (module view, process view, data flow view) • 4. Evaluate quality attributes independently - reliability, performance,

security, maintainability, flexibility, testability, portability, reusability and interoperability.


Architecture Trade-off Analysis Method II

• 5. Identify sensitivity points for architecture (any attributes significantly affected by variation – small changes - in the architecture)

• 6. Critique candidate architectures (from step 3) using the sensitivity analysis (conducted in step 5)After finding sensitivity points – identify architectural elements to which multiple attributes are sensitive. For example, the performance of a client-server architecture might be highly sensitive to the number of servers (performance increases). The number of servers, then , is the trade-off point with respect to this architecture.

• Based on the results of steps 5 and 6:- some architecture alternatives may be eliminated,- one or more of the remaining architectures may be modified and represented in more detail,- and, then the ATAM steps are reapplied.


5.2. Architectural Complexity

• Similar to coupling

• Three types of dependencies between components:

- Sharing dependencies - represent dependence relationships among consumers who use the same resource or producers who produce for the same consumers

- Flow dependencies - represent dependence relationships between producers and consumers of resources

- Constrained dependencies - represent constraints on the relative flow among a set of components


5.3. Architectural Description Language (ADL)

• Provides syntax and semantics for describing software architecture

• Provides designers with ability to decompose components, combine components, and define interfaces


Architectural Description Languages

• Rapide (poset.standford.edu/rapide) – builds on the notion of partial ordered sets.

• UniCon (www.cs.cmu.edu) – defines software architecture in terms of abstractions that designers find useful.

• UML (www.uml.org) – includes many of the artifacts needed for architectural descriptions, but is not as complete as other ADLs.


6. Mapping Data Flow into a Software Architecture

• To illustrate one approach to architectural mapping, a mapping technique for the call and return is discussed.

• This mapping technique – structured design – enables a designer to derive fairly complex call and return architectures from data flow diagrams.

• Structured design is often characterised as a data-flow oriented design method because it provides a convenient transition from a data flow diagram to software architecture.


Structured Design

• Objective: to derive a program architecture that is partitioned

• Approach: – the DFD is mapped into a program architecture

– the PSPEC and STD are used to indicate the content of each module

• Notation: structure chart


Mapping Requirements to Software Architecture in Structured Design

• Establish type of information flow (transform or transaction)

• Flow boundaries indicated

• DFD is mapped into program structure

• Control hierarchy defined

• Resultant structure refined using design measures and heuristics

• Architectural description refined and elaborated


General Mapping Approach

isolate incoming and outgoing flow isolate incoming and outgoing flow boundaries; for transaction flows, isolate boundaries; for transaction flows, isolate the transaction centerthe transaction center

working from the boundary outward, mapworking from the boundary outward, mapDFD transforms into corresponding modulesDFD transforms into corresponding modules

add control modules as requiredadd control modules as required

refine the resultant program structurerefine the resultant program structureusing effective modularity conceptsusing effective modularity concepts


Transform Flow

• Information must enter and exit software in an ‘external world’ form

• Information enters the system along paths (incoming flow ) that transforms external data into an internal form.

• At the kernel of the software, a transition occurs. Incoming data are passed through a transform centre and begin to move along paths that now lead ‘out’ out of the software. Data moving along these paths are called outgoing flow.

• Overall data flow is sequential and flows along one or a small number of straight line paths


Transaction Flow

• A single data item - transaction - triggers information flow along one of many paths

• Characterised by data moving along an incoming path that converts external world information into a transaction.

• The transaction is evaluated and, based on its value, flow along one of many action paths is initiated.

• The hub of information flow from which many action paths emanate is called a transaction centre.


Transaction Flow

T

incoming flow

action path


Flow Characteristics

• Both transform and transaction flows may occur in the same DFD (Data Flow Diagram).

• Each subflow should be classified and mapped using the appropriate technique (transform or transaction).

• The difference between transform flow and transaction flow:

Transform flow is largely sequential and has very little divergence along the action path. Transaction flow can follow many action paths and the processing of a single data item often triggers path selection.


Flow Characteristics

Transform flow

Transaction

flow


Transform Mapping Steps I

Transform Mapping - set of design steps that allows a DFD withtransform flow characteristics to be mapped into a specific architecturalstyle.• 1. Review fundamental system model - Level 0 model

• 2. Review and refine data flow diagrams for the software - Information obtained from the analysis model is refined to produce greater detail.

• 3. Determine whether the DFD has transform or transaction characteristics - In general, information flow within a system can always be represented as transform. When an obvious transaction characteristic is encountered, a different design mapping is recommended. In this step, the designer selects global flow characteristics based on the prevailing nature of the DFD. In addition, local regions of transform or transaction flow are isolated. These subflows can be used to refine program architecture derived from a global characteristic described previously.

• 4. Isolate the transform center by specifying incoming and outgoing flow boundaries. – Different designers may select slightly different points in the flow as boundary locations. In fact, alternative design solutions can be derived by varying the placement of flow boundaries, but a variance of one bubble along a flow path will generally have little impact on the final program structure.


Transform Mapping

data flow model

"Transform" mapping

ab

c

d e fg h

ij

x1

x2 x3 x4

b c

a

d e f g i

h j


Transform Mapping Steps II

• 5. Perform ‘first-level factoring’ – The program architecture derived using this mapping results in a top-down distribution of control.

Factoring results in a program structure in which top-level components perform decision-making, low-level components perform most input, computation and output work, middle-level components perform some control and do moderate amounts of work.

When transform flow is encountered, a DFD is mapped to a specific structure (a call and return architecture) that provides control for incoming, transform, and outgoing information processing.


Factoring

typical "worker" modules

typical "decision making" modules

direction of increasing decision making


First Level Factoring

main programcontroller

inputcontroller

processingcontroller

outputcontroller


Transform Mapping Steps III

• 6. Perform ‘second-level factoring’ - Second level factoring is accomplished by mapping individual transforms (bubbles) of a DFD into appropriate modules within the architecture. Beginning at the transform centre boundary and moving outward along incoming and then outgoing paths, transforms are mapped into subordinate levels of the software structure.

Two or even three bubbles can be combined and represented as one component, or a single bubble may be expanded to two or more components.

Second-level factoring for incoming flow is also accomplished by moving outward from the transform centre boundary on the incoming flow side.

A brief processing narrative (adapted from the PSPEC created during analysis modeling) should be written for each mapped component.


Second Level Mapping

D

C

B A

A

C

B

Dmapping from the flow boundary outward

main

control


Transform Mapping Steps IV

• 7. Refine the first iteration architecture using design heuristics for improved software quality – A first-iteration architecture can always be refined by applying concepts of functional independence.

Components are exploded or imploded to produce sensible factoring, good cohesion, minimal coupling, and a structure that can be implemented without difficulty, tested without confusion and maintained without grief.

Software requirements coupled with human judgement is a final arbiter for refinements.


Transform vs Transaction Mapping

• Transaction mapping – design steps used to map transaction flow into a software architecture.

• The process of performing transaction mapping is similar to transform mapping, but focusing on transaction (not transform) centers. A major difference lies in the mapping of DFD to software structure.

• In transaction mapping, the first level factoring results in the derivation of the control hierarchy. The second level factoring distributes the low-level modules among the appropriate controller.


Transaction Mapping Steps I

• 1. Review fundamental system model

• 2. Review and refine data flow diagrams for the software

• 3. Determine whether the DFD has transform or transaction characteristics

• 4. Identify the transaction center and flow characteristics along each action path – The location of the transaction centre can be immediately discerned from the DFD. The transaction centre lies at the origin of a number of action paths that flow radially from it. The incoming path (i.e. the flow path along which a transaction is received) and all action paths must also be isolated. Each action path must be evaluated for its individual characteristic.


Transaction Mapping

data flow model

ab

t

de f

gh

i

j

kl

mn Mapping

b

a

x1

t

x2

d e f

x3

g h x3.1

i j

k

x4

l m n


Transaction Mapping Steps II

• 5. Map the DFD to a program structure amenable to transaction processing – Transaction flow is mapped into an architecture that contains an incoming branch and a dispatch branch. The structure of the incoming branch is developed in the same way as transform mapping. Starting at the transaction centre, bubbles along the incoming path are mapped into modules. The structure of the dispatch branch contains a dispatcher module that controls all subordinate action modules.Each action flow path of the DFD is mapped to a structure that corresponds to its specific flow characteristics.


Transaction Mapping Steps III

• 6. Factor and refine the transaction structure and the structure of each action path

• 7. Refine the first iteration architecture using design heuristics for improved software quality


Refining Architectural Design

• Processing narrative developed for each module

• Interface description provided for each module

• Local and global data structures are defined

• Design restrictions/limitations noted

• Design reviews conducted

• Refinement considered if required and justified


Summary I

• Software architecture provides a holistic view of the system to be built. It depicts the structure and organisation of software components, their properties and the connections between them.

• Software components include program modules and the various data representations that are manipulated by the program


Summary II

• Architectural design is generally accomplished using four distinct steps:

– 1. The system must be represented in context – i.e. the designer should define external entities that the software interacts with, and the nature of the interaction.

– 2. Once context has been specified, the designer should identify a set of top-level abstractions, called archetypes, that represent pivotal elements of the system’s behavior or function.

– 3. After abstractions have been defined, the design begins to move closer to the implementation domain. Components are identified and represented within the context of an architecture that supports them.

– 4. Finally, specific instantiations of the architecture are developed to ‘prove’ the design in ‘real’ world context.


2005F

Instructor

John D Lin - [email protected]

Lectures

Tues & Thurs 10:00-11:30 RM. 100, Lower Block

Documents

Programming Techniques Lecture 8 Architectural Design Based on: Software Engineering, A Practitioner’s Approach, 6/e, R.S. Pressman Software Engineering