Architecture DesignPreeti MishraCourse Instructor

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.

Definitions The software architecture of a program or computing system is the structure or structures of the system which compriseThe software componentsThe externally visible properties of those componentsThe relationships among the componentsSoftware architectural design represents the structure of the data and program components that are required to build a computer-based systemAn architectural design model is transferableIt can be applied to the design of other systemsIt represents a set of abstractions that enable software engineers to describe architecture in predictable ways

Why Architecture?The architecture is not the operational software. Rather, it is a representation that enables a software engineer to: (1) analyze the effectiveness of the design in meeting its stated requirements, (2) consider architectural alternatives at a stage when making design changes is still relatively easy, and (3) reduce the risks associated with the construction of the software.

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 mode of how the system is structured and how its components work together

Architectural DescriptionsThe IEEE Computer Society has proposed IEEE-Std-1471-2000, Recommended Practice for Architectural Description of Software-Intensive System, [IEE00]to establish a conceptual framework and vocabulary for use during the design of software architecture, to provide detailed guidelines for representing an architectural description, and to encourage sound architectural design practices.The IEEE Standard defines an architectural description (AD) as a a collection of products to document an architecture. The description itself is represented using multiple views, where each view is a representation of a whole system from the perspective of a related set of [stakeholder] concerns.

Architectural Design ProcessBasic StepsCreation of the data designDerivation of one or more representations of the architectural structure of the systemAnalysis of alternative architectural styles to choose the one best suited to customer requirements and quality attributesElaboration of the architecture based on the selected architectural style A database designer creates the data architecture for a system to represent the data componentsA system architect selects an appropriate architectural style derived during system engineering and software requirements analysis

Emphasis on Software ComponentsA software architecture enables a software engineer toAnalyze the effectiveness of the design in meeting its stated requirementsConsider architectural alternatives at a stage when making design changes is still relatively easyReduce the risks associated with the construction of the softwareFocus is placed on the software componentA program moduleAn object-oriented classA databaseMiddleware

Data Design

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.

Purpose of Data DesignData design translates data objects defined as part of the analysis model intoData structures at the software component levelA possible database architecture at the application levelIt focuses on the representation of data structures that are directly accessed by one or more software componentsThe challenge is to store and retrieve the data in such way that useful information can be extracted from the data environment"Data quality is the difference between a data warehouse and a data garbage dump"

Data Design PrinciplesThe systematic analysis principles that are applied to function and behavior should also be applied to dataAll data structures and the operations to be performed on each one should be identifiedA mechanism for defining the content of each data object should be established and used to define both data and the operations applied to itLow-level data design decisions should be deferred until late in the design processThe representation of a data structure should be known only to those modules that must make direct use of the data contained within the structureA library of useful data structures and the operations that may be applied to them should be developedA software programming language should support the specification and realization of abstract data types

Software Architectural Styles

These slides are designed to accompany Software Engineering: A Practitioners Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.

*Common Architectural Stylesof American Homes

Architectural StylesData-centered architecturesData flow architecturesCall and return architecturesObject-oriented architecturesLayered architecturesEach style describes a system category that encompasses: (1) a set of components (e.g., a database, computational modules) that perform a function required by a system, (2) a set of connectors that enable communication, coordination and cooperation among components, (3) constraints that define how components can be integrated to form the system, (4) semantic models that enable a designer to understand the overall properties of a system by analyzing the known properties of its constituent parts.

Software Architectural StyleThe software that is built for computer-based systems exhibit one of many architectural stylesEach style describes a system category that encompassesA set of component types that perform a function required by the systemA set of connectors (subroutine call, remote procedure call, data stream, socket) that enable communication, coordination, and cooperation among componentsSemantic constraints that define how components can be integrated to form the systemA topological layout of the components indicating their runtime interrelationships

*A Taxonomy of Architectural Styles

Data-Centered Architecture

Data Flow StyleValidateSortUpdateReport

Data Flow StyleHas the goal of modifiabilityCharacterized by viewing the system as a series of transformations on successive pieces of input dataData enters the system and then flows through the components one at a time until they are assigned to output or a data storeBatch sequential styleThe processing steps are independent componentsEach step runs to completion before the next step beginsPipe-and-filter styleEmphasizes the incremental transformation of data by successive componentsThe filters incrementally transform the data (entering and exiting via streams)The filters use little contextual information and retain no state between instantiationsThe pipes are stateless and simply exist to move data between filters

Data Flow Style (continued)AdvantagesHas a simplistic design in the limited ways in which the components interact with the environmentConsists of no more and no less than the construction of its partsSimplifies reuse and maintenanceIs easily made into a parallel or distributed execution in order to enhance system performanceDisadvantagesImplicitly encourages a batch mentality so interactive applications are difficult to create in this styleOrdering of filters can be difficult to maintain so the filters cannot cooperatively interact to solve a problemExhibits poor performanceFilters typically force the least common denominator of data representation (usually ASCII stream)Filter may need unlimited buffers if they cannot start producing output until they receive all of the inputEach filter operates as a separate process or procedure call, thus incurring overhead in set-up and take-down time

Data Flow Style (continued)Use this style when it makes sense to view your system as one that produces a well-defined easily identified outputThe output should be a direct result of sequentially transforming a well-defined easily identified input in a time-independent fashion

Data Flow Architecture

Call-and-Return StyleHas the goal of modifiability and scalabilityHas been the dominant architecture since the start of software developmentMain program and subroutine styleDecomposes a program hierarchically into small pieces (i.e., modules)Typically has a single thread of control that travels through various components in the hierarchyRemote procedure call styleConsists of main program and subroutine style of system that is decomposed into parts that are resident on computers connected via a networkStrives to increase performance by distributing the computations and taking advantage of multiple processorsIncurs a finite communication time between subroutine call and response

Call-and-Return Style (continued)Object-oriented or abstract data type systemEmphasizes the bundling of data and how to manipulate and access dataKeeps the internal data representation hidden and allows access to the object only through provided operationsPermits inheritance and polymorphismLayered systemAssigns components to layers in order to control inter-component interactionOnly allows a layer to communicate with its immediate neighborAssigns core functionality such as hardware interfacing or system kernel operations to the lowest layerBuilds each successive layer on its predecessor, hiding the lower layer and providing services for the upper layerIs compromised by layer bridging that skips one or more layers to improve runtime performanceUse this style when the order of computation is fixed, when interfaces are specific, and when components can make no useful progress while awaiting the results of request to other components

*Call-and-Return StyleMain moduleSubroutine ASubroutine B Subroutine A-1 Subroutine A-2 Physical layer Data layer Network layer Transport layer Application layer Class W Class V Class X Class Z Class Y

Call and Return Architecture

Layered Architecture

Architectural PatternsConcurrencyapplications must handle multiple tasks in a manner that simulates parallelism operating system process management patterntask scheduler patternPersistenceData persists if it survives past the execution of the process that created it. Two patterns are common: a database management system pattern that applies the storage and retrieval capability of a DBMS to the application architecturean application level persistence pattern that builds persistence features into the application architectureDistribution the manner in which systems or components within systems communicate with one another in a distributed environmentA broker acts as a middle-man between the client component and a server component.

Architectural DesignThe software must be placed into contextthe design should define the external entities (other systems, devices, people) that the software interacts with and the nature of the interactionA set of architectural archetypes should be identifiedAn archetype is an abstraction (similar to a class) that represents one element of system behaviorThe designer specifies the structure of the system by defining and refining software components that implement each archetype

Architectural Context

Archetypes

Component Structure

Refined Component Structure

Analyzing Architectural Design1. Collect scenarios. 2. Elicit requirements, constraints, and environment description. 3. Describe the architectural styles/patterns that have been chosen to address the scenarios and requirements: module view process view data flow view4. Evaluate quality attributes by considered each attribute in isolation. 5. Identify the sensitivity of quality attributes to various architectural attributes for a specific architectural style. 6. Critique candidate architectures (developed in step 3) using the sensitivity analysis conducted in step 5.

Architectural Complexitythe overall complexity of a proposed architecture is assessed by considering the dependencies between components within the architecture [Zha98]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 of control among a set of activities.

ADLArchitectural description language (ADL) provides a semantics and syntax for describing a software architectureProvide the designer with the ability to: decompose architectural componentscompose individual components into larger architectural blocks and represent interfaces (connection mechanisms) between components.

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

Deriving Program ArchitectureProgramArchitecture

Partitioning the Architecturehorizontal and vertical partitioning are required

Horizontal Partitioningdefine separate branches of the module hierarchy for each major functionuse control modules to coordinate communication between functionsfunction 1function 3function 2

Vertical Partitioning: Factoringdesign so that decision making and work are stratifieddecision making modules should reside at the top of the architectureworkersdecision-makers

Why Partitioned Architecture?results in software that is easier to testleads to software that is easier to maintainresults in propagation of fewer side effectsresults in software that is easier to extend

Structured Designobjective: to derive a program architecture that is partitionedapproach: a DFD is mapped into a program architecturethe PSPEC and STD are used to indicate the content of each modulenotation: structure chart

Flow CharacteristicsTransform flowTransactionflowThis edition of SEPA does not cover transaction mapping. For a detailed discussion see the SEPA website

General Mapping Approachisolate incoming and outgoing flow boundaries; for transaction flows, isolate the transaction centerworking from the boundary outward, mapDFD transforms into corresponding modulesadd control modules as requiredrefine the resultant program structureusing effective modularity concepts

General Mapping ApproachIsolate the transform center by specifying incoming and outgoing flow boundariesPerform "first-level factoring.The program architecture derived using this mapping results in a top-down distribution of control. Factoring leads to a program structure in which top-level components perform decision-making and low-level components perform most input, computation, and output work. Middle-level components perform some control and do moderate amounts of work.Perform "second-level factoring."

Transform Mapping

Factoring

First Level Factoringmain programcontrollerinputcontrollerprocessingcontrolleroutputcontroller

Second Level Mapping