Software Engineering (8SR2)

Unit V
Software architecture: Data Design, Architectural styles, Requirement mapping. Transform & Transaction mappings. Userinterface design : Golden Rule. UTD, Task analysis & modeling, ID activities, Tools, design evaluation. Component level design : Structure programming, Comparison of design notation.
Book Recommended

Software Engineering, A Practitioners Approach - Pressman Roger. S. TMH. (Strictly 5th Ed)U1-1,2,3
Reference Books R1 Software Engineering Somerville R2 Software Engineering Fairly R R3 Principles of Software Development R4 Software Engineering Shooman, M.L
U2-4,5,6 U3-7,8,9 Addison-Wesley (5/e) McGraw Hill U4-10,11,13 Davis A McGraw Hill U5-14,15,16 McGraw Hill U6-17,18,19

Chapter 14 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 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.

Data Design
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 DesignComponent Level

1. The systematic analysis principles applied to function and behavior should also be applied to data. 2. All data structures and the operations to be performed on each should be identified. 3. A data dictionary should be established and used to define both data and program design. 4. Low level data design decisions should be deferred until late in the design process. 5. The representation of data structure should be known only to those modules that must make direct use of the data contained within the structure. 6. A library of useful data structures and the operations that may be applied to them should be developed. 7. A software design and programming language should support the specification and realization of abstract data types.

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 architectures Data flow architectures Call and return architectures Object-oriented architectures Layered architectures

Data-Centered Architecture

Data Flow Architecture

Call and Return Architecture

Layered Architecture

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.

An Architectural Design Method

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

architectural design

Deriving Program Architecture

Program Architecture

Partitioning the Architecture

horizontal and vertical partitioning are required

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

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

Why Partitioned Architecture?

results in software that is easier to test leads to software that is easier to maintain results in propagation of fewer side effects results in software that is easier to extend

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

Flow Characteristics

Transform flow

Transaction flow

General Mapping Approach

isolate incoming and outgoing flow boundaries; for transaction flows, isolate the transaction center working from the boundary outward, map DFD transforms into corresponding modules

add control modules as required

refine the resultant program structure using effective modularity concepts

Transform Mapping
a b d c data flow model x1 x2 b a c d x3 e f g h x4 i j e f g i h

"Transform" mapping

Factoring
direction of increasing decision making typical "decision making" modules

typical "worker" modules

First Level Factoring

main program controller

input controller

processing controller

output controller

Second Level Mapping

D C
control main

A A B C

mapping from the flow boundary outward

Transaction Flow
incoming flow
action path T

Transaction Example
fixture setting commands operator
process operator commands

fixture servos

report

display screen

robot control

robot control software

assembly record in reality, other commands would also be shown

Refining the Analysis Model

1. write an English language processing narrative for the level 01 flow model
2. apply noun/verb parse to isolate processes, data items, store and entities

3. develop level 02 and 03 flow models 4. create corresponding data dictionary entries 5. refine flow models as appropriate
... now, we're ready to begin design!

Deriving Level 1
Processing narrative for " process operator commands" Process operator command software reads operator commands from the cell operator. An error message is displayed for invalid commands. The command type is determined for valid commands and appropriate action is taken. When fixture commands are encountered, fixture status is analyzed and a fixture setting is output to the fixture servos. When a report is selected, the assembly record file is read and a report is generated and displayed on the operator display screen. When robot control switches are selected, control values are sent to the robot control system. Process operator command software reads operator commands from the cell operator. An error message is displayed for invalid commands. The command type is determined for valid commands and appropriate action is taken. When fixture commands are encountered, fixture status is analyzed and a fixture setting is output to the fixture servos. When a report is selected, the assembly record file is read and a report is generated and displayed on the operator display screen. When robot control switches are selected, control values are sent to the robot control system.

noun-verb parse

Level 1 Data Flow Diagram

operator commands read operator commands valid command f ix ture determine command type analyze f ix ture status Error msg status f ix ture servos

f ix ture setting

select report report display sc reen

control robot

generate report

send control value

as sembly record

robot control sy stem

robot control

Level 2 Data Flow Diagram

co mmand prod uce error msg read co mmand i nva li d co mmand co mmand va li da te co mmand de te rmi ne type error msg sta tus de te rmi ne setti ng read fixtu re sta tus co mbi ned sta tus format setti ng raw se tti ng fixtu re setti ng

robo t co ntro l

read reco rd

reco rd ca lcul ate ou tp ut va lu es va lu es

send co ntro l va lu e asse mbl y reco rd sta rt /sto p

format repo rt

repo rt

Transaction Mapping Principles

isolate the incoming flow path

define each of the action paths by looking for the "spokes of the wheel" assess the flow on each action path
define the dispatch and control structure

map each action path flow individually

Transaction Mapping
a b t g h j m x1 b a d x2 e f g t x3 h i k x3.1 j l x4 m n n l e d i k f

data flow model

Mapping

Isolate Flow Paths

co mmand prod uce error msg read co mmand i nva li d co mmand co mmand va li da te co mmand de te rmi ne type error msg sta tus de te rmi ne setti ng read fixtu re sta tus co mbi ned sta tus format setti ng raw se tti ng fixtu re settin g

robo t co ntro l

read reco rd

reco rd ca lcul ate ou tp ut va lu es va lu es

send co ntro l va lu e asse mbl y reco rd sta rt /sto p

format repo rt

repo rt

Map the Flow Model

process operator commands

command input controller read command validate command produce error message fixture status controller

determine type

report generation controller

send control value

each of the action paths must be expanded further

Refining the Structure Chart

process operator commands command input controller read command validate command produce error message fixture status controller determine type

report generation controller

send control value

read fixture status

determine setting

format setting

read record

calculate output values

format report

Interface Are Designed

intermodular interface design
driven by data flow between modules

external interface design

driven by interface between applications driven by interface between software and non-human producers and/or consumers of information

human-computer interface design

driven by the communication between human and machine

Chapter 15 User Interface Design

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

Interface Design
Typical Design Errors lack of consistency too much memorization no guidance / help no context sensitivity poor response Arcane/unfriendly

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

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.

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.

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.

User Interface Design Models

System perception the users mental image of what the interface is User model a profile of all end users of the system System image the presentation of the system projected by the complete interface Design model data, architectural, interface and procedural representations of the software

User Interface Design Process

Task Analysis and Modeling

All human tasks required to do the job (of the interface) are defined and classified Objects (to be manipulated) and actions (functions applied to objects) are identified for each task Tasks are refined iteratively until the job is completely defined

Interface Design Activities

1. Establish the goals and intentions for each task. 2. Map each goal/intention to a sequence of specific actions. 3. Specify the action sequence of tasks and subtasks, also called a user scenario, as it will be executed at the interface level. 4. Indicate the state of the system, i.e., what does the interface look like at the time that a user scenario is performed? 5. Define control mechanisms, i.e., the objects and actions available to the user to alter the system state. 6. Show how control mechanisms affect the state of the system. 7. Indicate how the user interprets the state of the system from information provided through the interface.

Design Evaluation Cycle

Chapter 16 Component-Level Design

Component-Level 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

Stepwise Refinement
open
walk to door; reach for knob; open door; walk through; close door.

repeat until door opens turn knob clockwise; if knob doesn't turn, then take key out; find correct key; insert in lock; endif pull/push door move out of way; end repeat

The Component-Level 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 conduct walkthrough to assess quality

Structured Programming for Procedural Design

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

important for achieving high quality, but not enough

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

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

Why Design Language?

can be a derivative of the HOL of choice e.g., Ada PDL machine readable and processable can be embedded with source code, therefore easier to maintain can be represented in great detail, if designer and coder are different easy to review