Chapter 9

Architectural Design

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 to meet 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.

Architectural Styles
Each 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, and (4) semantic models that enable a designer to understand the overall properties of a system by analyzing the known properties of its constituent parts.

Data-Centered Architecture

Data Flow Architecture

Call and Return Architecture

Layered Architecture

Architectural Design

The software must be placed into context

the design should define the external entities (other systems, devices, people) that the software interacts with and the nature of the interaction

A set of architectural archetypes should be identified

An archetype is an abstraction (similar to a class) that represents one element of system behavior

The designer specifies the structure of the system by defining and refining software components that implement each archetype
8

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

Architectural Context
Safehome Product Internet-based system

control panel

target system: Security Function uses

uses

surveillance function peers

homeowner

uses

sensors

sensors
9

Archetypes
Cont roller communicat es wit h

Node

Det ect or

Indicat or

Figure 10.7 UML relat ionships f or Saf eHome securit y f unct ion archet ypes (adapt ed f rom [ BOS00] )

10

Component Structure
SafeHome Execut ive Funct ion select ion

Ext ernal Communicat ion Management

Securit y

Surveillance

Home management

GUI

Int ernet Int erface

Cont rol panel processing det ect or management alarm processing

11

Refined Component Structure

SafeHome Executive

Ext ernal Communicat ion Management

Security GUI Internet Interface

Cont rol panel pro cessing det ect or m anagem ent alarm processing

Key pad processing

scheduler

phone com m u nicat ion

CP display funct ions

alarm sensor sensor sensor sensor sensor sensor sensor sensor sensor

12

Analyzing Architectural Design

1. 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 view 4. 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.

13

An Architectural Design Method

customer requirements
"four bedrooms, three baths, lots of glass ..."

architectural design

14

Deriving Program Architecture

Program Architecture

15

Partitioning the Architecture

horizontal and vertical partitioning are required

16

Horizontal Partitioning

define separate branches of the module hierarchy for each major function use control modules to coordinate communication between functions
function 1 function 3

function 2
17

Vertical Partitioning: Factoring

design so that decision making and work are stratified decision making modules should reside at the top of the architecture
decision-makers

workers

18

Structured Design

objective: to derive a program architecture that is partitioned approach:

a DFD is mapped into a program architecture the PSPEC and STD are used to indicate the content of each module

notation: structure chart

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

19

Chapter 10

What is a Component?
UML Unified Modeling Language Specification defines a component as OO Object Oriented Component: a component contains a set of collaborating classes Conventional Component: a component contains processing logic, the internal data structures that are required to implement the processing logic, and an interface that enables the component to be invoked and data to be passed to it.

20

OO Component
a n a l y si s c l a ss Pri n t Jo b n u m b e rOf Pa g e s n u m b e rOf Si d e s p a p e rTy p e m agnif ic at ion p ro d u c t i o n Fe a t u re s d e si g n c o m p o n e n t c o m p u t e Jo b Co st( ) p a ssJo b t o Pri n t e r( ) c o m p u t e Jo b

Pri n t Jo b

i n i t i a t e Jo b

< < in t er f ace> > co m p u t eJo b comput ePageCost ( ) comput ePaper Cost ( ) comput ePr odCost ( ) comput eTot alJobCost ( )

elaborat ed des ign c las s Print J ob

number Of Pages number Of Sides paper Type paper Weight paper Size paper Color magnif icat ion color R equir ement s pr oduct ionFeat ur es collat ionOpt ions bindingOpt ions cover St ock bleed pr ior it y t ot alJobCost WOnumber comput eP ageCost ( ) comput eP aper Cost ( ) comput eP odCost ( ) r comput eTot alJobCost ( ) buildWor kOr der ( ) checkP ior it y ( ) r passJobt o P oduct ion( ) r

< < in t er f ace> > in it iat eJo b buildWor kOr der ( ) checkP ior it y ( ) r passJobt o P oduct ion( ) r

21

Conventional Component
design component getJobData ComputePageCost accessCostsDB

elaborated module PageCost

in: numberPages in: numberDocs in: sides= 1, 2 in: color=1, 2, 3, 4 in: page size = A, B, C, B out : page cost in: j ob size in: color=1, 2, 3, 4 in: pageSize = A, B, C, B out : BPC out : SF get JobDat a ( num berPages, num berDocs, sides, color, pageSize , pageCost ) accessCost sDB (jobSize, color, pageSize, BPC, SF) com put ePageCost( )

job size ( JS) = num berPages * num berDocs; lookup base page cost ( BPC) --> accessCost sDB ( JS, color) ; lookup size fact or ( SF) --> accessCost DB ( JS, color, size) j ob com plexit y fact or ( JCF) = 1 + [ ( sides-1) * sideCost + SF] page cost = BPC * JCF

22

Design Guidelines

Components Naming should be established for components that are specified as part of the architectural model and then refined and elaborated as part of the component-level model Interfaces Interfaces provide important information about communication and collaboration Dependencies and Inheritance it is a good idea to model dependencies from left to right and inheritance from bottom (derived classes) to top (base classes).

23

Component Level Design-I

Step 1. Identify all design classes that correspond to the problem domain. Step 2. Identify all design classes that correspond to the infrastructure domain. Step 3. Elaborate all design classes that are not acquired as reusable components. Step 3a. Specify message details when classes or component collaborate. Step 3b. Identify appropriate interfaces for each component.

24

Component-Level Design-II

Step 3c. Elaborate attributes and define data types and data structures required to implement them. Step 3d. Describe processing flow within each operation in detail. Step 4. Describe persistent data sources (databases and files) and identify the classes required to manage them. Step 5. Develop and elaborate behavioral representations for a class or component. Step 6. Elaborate deployment diagrams to provide additional implementation detail. Step 7. Factor every component-level design representation and always consider alternatives.

25

Collaboration Diagram
:ProductionJob

1: buildJob (WOnumber)

2: submitJob (WOnumber)

:WorkOrder :JobQueue

26

Refactoring
computeJob PrintJob initiateJob

WorkOrder
appropriat e at t ribut e s

getJobDescriiption

buildWorkOrder ()

buildJob

<<interface>> initiateJob
passJobToProduct ion( )

ProductionJob

submitJob JobQueue
appropriat e at t ribut e s

checkPriority ()

27

Activity Diagram

validat e at t ribut es input

accessPaperDB (weight )

ret urns baseCost perPage paperCost perPage = baseCost perPage

size = B

paperCost perPage = paperCost perPage * 1 . 2

size = C

paperCost perPage = paperCost perPage * 1 . 4

size = D

paperCost perPage = paperCost perPage * 1 . 6

color is cust om

paperCost perPage = paperCost perPage * 1 . 1 4

color is st andard

ret urns ( paperCost perPage )

28

Statechart

b ehavior w it hin t he st at e b uildingJobDat a d at aInpu t Incomplet e

buildingJobDat a ent ry/ readJobDat a () exit / displayJobDat a () do/ checkConsist ency() include/ dat aInput

d at aInpu t Co mplet ed [ all dat a it ems consist ent ] / disp layUserOp t ion s

comput ingJobCost ent ry/ comput eJob exit / save t ot alJobCost

jo bCo st Accep t ed [ cust omer is au t ho rized] / get Elect ro nicSig nat ure

f ormingJob ent ry/ buildJob exit / save WOnumber do/

submit t ingJob ent ry/ submit Job exit / init iat eJob do/ place on JobQueue

j ob Submit t ed[ all aut horizat ion s acquired] / p rint WorkOrder

29

Designing Conventional Components

The design of processing logic is governed by the basic principles of algorithm design and structured programming The design of data structures is defined by the data model developed for the system The design of interfaces is governed by the collaborations that a component must effect

30

Algorithm Design

the closest design activity to coding the approach:

review the design description for the component use stepwise refinement to develop algorithm use structured programming to implement procedural logic use formal methods to prove logic

31

Algorithm Design Model

represents the algorithm at a level of detail that can be reviewed for quality options:

graphical (e.g. flowchart, box diagram) pseudocode (e.g., PDL) ... choice of many programming language decision table

32

Structured Programming
uses a limited set of logical constructs: sequence conditional if-then-else, select-case loops do-while, repeat until leads to more readable, testable code can be used in conjunction with proof of correctness important for achieving high quality, but not enough
33

A Structured Procedural Design

a x1 b x3 f x2 d e x4 g x5 c add a condition Z, if true, exit the program

34

Decision Table
Rule s Condit ions regular cust omer silver cust omer gold cust omer special discount Rule s no discount apply 8 percent discount apply 15 percent discount apply addit ional x percent discount

T T T T T F T F T F T T

35

Program Design Language (PDL)

if condition x then process a; else process b; endif

if-then-else

PDL

easy to combine with source code machine readable, no need for graphics input graphics can be generated from PDL enables declaration of data as well as procedure easier to maintain

36

Chapter 11

Interface Design
Easy to learn? Easy to use? Easy to understand?

37

Golden Rules

Place the user in control Reduce the users memory load Make the interface consistent

38

Place the User in Control

Define interaction modes in a way that does not force a user into unnecessary or undesired actions. Provide for flexible interaction. Allow user interaction to be interruptible and undoable. Streamline interaction as skill levels advance and allow the interaction to be customized. Hide technical internals from the casual user.

Design for direct interaction with objects that appear on the screen.

39

Reduce the Users Memory Load

Reduce demand on short-term memory.
Establish meaningful defaults. Define shortcuts that are intuitive. The visual layout of the interface should be based on a real world metaphor. Disclose information in a progressive fashion.

40

Make the Interface Consistent

Allow the user to put the current task into a meaningful context. Maintain consistency across a family of applications. If past interactive models have created user expectations, do not make changes unless there is a compelling reason to do so.

41

User Interface Design Models

User model a profile of all end users of the system Design model a design realization of the user model Mental model (system perception) the users mental image of what the interface is Implementation model the interface look and feel coupled with supporting information that describe interface syntax and semantics

42

User Interface Design Process

43

Interface Analysis

Interface analysis means understanding

(1) the people (end-users) who will interact with the system through the interface; (2) the tasks that end-users must perform to do their work, (3) the content that is presented as part of the interface (4) the environment in which these tasks will be conducted.

44

Interface Design Steps

Using information developed during interface analysis, define interface objects and actions (operations). Define events (user actions) that will cause the state of the user interface to change. Model this behavior. Depict each interface state as it will actually look to the end-user. Indicate how the user interprets the state of the system from information provided through the interface.
45

Design Evaluation Cycle

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

46