Part 2

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 1

Supplementary Slides forSupplementary Slides for

Software Engineering:Software Engineering:A Practitioner's A Practitioner's Approach, 6/eApproach, 6/e

Part 2Part 2copyright © 1996, 2001, 2005

R.S. Pressman & Associates, Inc.

For University Use OnlyMay be reproduced ONLY for student use at the university level

when used in conjunction with Software Engineering: A Practitioner's Approach.Any other reproduction or use is expressly prohibited.

This presentation, slides, or hardcopy may NOT be used forshort courses, industry seminars, or consulting purposes.


Software Engineering: A Practitioner’s Software Engineering: A Practitioner’s Approach, 6/eApproach, 6/e

Chapter 5Chapter 5Practice: A Generic ViewPractice: A Generic View

copyright © 1996, 2001, 2005





What is “Practice”?What is “Practice”?

Practice is a broad array of concepts, principles, Practice is a broad array of concepts, principles, methods, and toolsmethods, and tools that you must consider as that you must consider as software is planned and developed.software is planned and developed.

It represents the detailsIt represents the details—the technical —the technical considerations and how to’s—that are below the considerations and how to’s—that are below the surface of the software process—the things that surface of the software process—the things that you’ll need to actually build high-quality you’ll need to actually build high-quality computer software.computer software.


The Essence of PracticeThe Essence of Practice

George Polya, in a book written in 1945 (!), George Polya, in a book written in 1945 (!), describes the essence of software engineering describes the essence of software engineering practice …practice …

Understand the problemUnderstand the problem (communication and analysis). (communication and analysis). Plan a solutionPlan a solution (modeling and software design). (modeling and software design). Carry out the planCarry out the plan (code generation). (code generation). Examine the result for accuracyExamine the result for accuracy (testing and quality (testing and quality

assurance).assurance).

At its core, good practice is At its core, good practice is common-sense common-sense problem solvingproblem solving


Core Software Engineering Core Software Engineering PrinciplesPrinciples

Provide value to the customer and the Provide value to the customer and the useruser

KIS—keep it simple!KIS—keep it simple! Maintain the product and project Maintain the product and project

“vision”“vision” What you produce, others will consumeWhat you produce, others will consume Be open to the futureBe open to the future Plan ahead for reusePlan ahead for reuse Think!Think!


Software Engineering Software Engineering PracticesPractices

Consider the generic process Consider the generic process frameworkframework CommunicationCommunication PlanningPlanning ModelingModeling ConstructionConstruction DeploymentDeployment

Here, we’ll identifyHere, we’ll identify Underlying principlesUnderlying principles How to initiate the practiceHow to initiate the practice An abbreviated task setAn abbreviated task set


Communication PracticesCommunication Practices PrinciplesPrinciples

ListenListen Prepare before you communicatePrepare before you communicate Facilitate the communicationFacilitate the communication Face-to-face is bestFace-to-face is best Take notes and document decisionsTake notes and document decisions Collaborate with the customerCollaborate with the customer Stay focusedStay focused Draw pictures when things are unclearDraw pictures when things are unclear Move on …Move on … Negotiation works best when both parties Negotiation works best when both parties

win.win.


Communication PracticesCommunication Practices InitiationInitiation

The parties should be physically close to one anotherThe parties should be physically close to one another Make sure communication is interactiveMake sure communication is interactive Create solid team “ecosystems”Create solid team “ecosystems” Use the right team structureUse the right team structure

An abbreviated task setAn abbreviated task set Identify who it is you need to speak withIdentify who it is you need to speak with Define the best mechanism for communicationDefine the best mechanism for communication Establish overall goals and objectives and define the Establish overall goals and objectives and define the

scopescope Get more detailedGet more detailed

Have stakeholders define scenarios for usageHave stakeholders define scenarios for usage Extract major functions/featuresExtract major functions/features

Review the results with all stakeholdersReview the results with all stakeholders


Planning PracticesPlanning Practices PrinciplesPrinciples

Understand the project scopeUnderstand the project scope Involve the customer (and other stakeholders)Involve the customer (and other stakeholders) Recognize that planning is iterativeRecognize that planning is iterative Estimate based on what you knowEstimate based on what you know Consider riskConsider risk Be realisticBe realistic Adjust granularity as you planAdjust granularity as you plan Define how quality will be achievedDefine how quality will be achieved Define how you’ll accommodate changesDefine how you’ll accommodate changes Track what you’ve plannedTrack what you’ve planned


Planning PracticesPlanning Practices

InitiationInitiation Ask Boehm’s questionsAsk Boehm’s questions

Why is the system begin developed?Why is the system begin developed? What will be done?What will be done? When will it be accomplished?When will it be accomplished? Who is responsible?Who is responsible? Where are they located (organizationally)?Where are they located (organizationally)? How will the job be done technically and managerially?How will the job be done technically and managerially? How much of each resource is needed?How much of each resource is needed?


Planning PracticesPlanning Practices An abbreviated task setAn abbreviated task set

Re-assess project scopeRe-assess project scope Assess risksAssess risks Evaluate functions/featuresEvaluate functions/features Consider infrastructure functions/featuresConsider infrastructure functions/features Create a coarse granularity planCreate a coarse granularity plan

Number of software incrementsNumber of software increments Overall scheduleOverall schedule Delivery dates for incrementsDelivery dates for increments

Create fine granularity plan for first Create fine granularity plan for first incrementincrement

Track progressTrack progress


Modeling PracticesModeling Practices

We create models to gain a better understanding We create models to gain a better understanding of the actual entity to be builtof the actual entity to be built

Analysis modelsAnalysis models represent the customer represent the customer requirements by depicting the software in three requirements by depicting the software in three different domains: the information domain, the different domains: the information domain, the functional domain, and the behavioral domain. functional domain, and the behavioral domain.

Design modelsDesign models represent characteristics of the represent characteristics of the software that help practitioners to construct it software that help practitioners to construct it effectively: the architecture, the user interface, effectively: the architecture, the user interface, and component-level detail.and component-level detail.


Analysis Modeling PracticesAnalysis Modeling Practices Analysis modeling principlesAnalysis modeling principles

Represent the information domainRepresent the information domain Represent software functionsRepresent software functions Represent software behaviorRepresent software behavior Partition these representationsPartition these representations Move from essence toward implementationMove from essence toward implementation

Elements of the analysis model (Chapter 8)Elements of the analysis model (Chapter 8) Data modelData model Flow modelFlow model Class modelClass model Behavior modelBehavior model


Design Modeling PracticesDesign Modeling Practices PrinciplesPrinciples

Design must be traceable to the analysis modelDesign must be traceable to the analysis model Always consider architectureAlways consider architecture Focus on the design of dataFocus on the design of data Interfaces (both user and internal) must be designedInterfaces (both user and internal) must be designed Components should exhibit functional independenceComponents should exhibit functional independence Components should be loosely coupledComponents should be loosely coupled Design representation should be easily understoodDesign representation should be easily understood The design model should be developed iterativelyThe design model should be developed iteratively

Elements of the design modelElements of the design model Data designData design Architectural designArchitectural design Component designComponent design Interface designInterface design


Construction PracticesConstruction Practices

Preparation principles:Preparation principles: Before you write one line Before you write one line of code, be sure you:of code, be sure you:

Understand of the problem you’re trying to solve (see Understand of the problem you’re trying to solve (see communicationcommunication and and modelingmodeling))

Understand basic design principles and concepts.Understand basic design principles and concepts. Pick a programming language that meets the needs of the Pick a programming language that meets the needs of the

software to be built and the environment in which it will software to be built and the environment in which it will operate.operate.

Select a programming environment that provides tools Select a programming environment that provides tools that will make your work easier.that will make your work easier.

Create a set of unit tests that will be applied once the Create a set of unit tests that will be applied once the component you code is completedcomponent you code is completed.



Coding principles: Coding principles: As you begin writing code, be sure you:As you begin writing code, be sure you: Constrain your algorithms by following structured programming Constrain your algorithms by following structured programming

[BOH00] practice.[BOH00] practice. Select data structures that will meet the needs of the design.Select data structures that will meet the needs of the design. Understand the software architecture and create interfaces that Understand the software architecture and create interfaces that

are consistent with it.are consistent with it. Keep conditional logic as simple as possible.Keep conditional logic as simple as possible. Create nested loops in a way that makes them easily testable.Create nested loops in a way that makes them easily testable. Select meaningful variable names and follow other local coding Select meaningful variable names and follow other local coding

standards.standards. Write code that is self-documenting.Write code that is self-documenting. Create a visual layout (e.g., indentation and blank lines) that aids Create a visual layout (e.g., indentation and blank lines) that aids

understanding.understanding.



Validation Principles: Validation Principles: After you’ve completed After you’ve completed your first coding pass, be sure you:your first coding pass, be sure you:

Conduct a code walkthrough when appropriate.Conduct a code walkthrough when appropriate. Perform unit tests and correct errors you’ve uncovered.Perform unit tests and correct errors you’ve uncovered. Refactor the code. Refactor the code.



Testing PrinciplesTesting Principles All tests should be traceable to requirementsAll tests should be traceable to requirements Tests should be plannedTests should be planned The Pareto Principle applies to testingThe Pareto Principle applies to testing Testing begins “in the small” and moves toward “in the Testing begins “in the small” and moves toward “in the

large”large” Exhaustive testing is not possibleExhaustive testing is not possible


Deployment PracticesDeployment Practices

PrinciplesPrinciples Manage customer expectations for each incrementManage customer expectations for each increment A complete delivery package should be assembled and A complete delivery package should be assembled and

testedtested A support regime should be establishedA support regime should be established Instructional materials must be provided to end-usersInstructional materials must be provided to end-users Buggy software should be fixed first, delivered laterBuggy software should be fixed first, delivered later



Chapter 6Chapter 6System EngineeringSystem Engineering

copyright © 1996, 2001, 2005





System EngineeringSystem Engineering

Elements of a computer-based Elements of a computer-based systemsystem SoftwareSoftware HardwareHardware PeoplePeople DatabaseDatabase DocumentationDocumentation ProceduresProcedures

SystemsSystems A hierarchy of macro-elementsA hierarchy of macro-elements


The The HierarchyHierarchy

World view

Business orProduct Domain

Domain of interest

Domain view

System element

Element view

Detailed view


System ModelingSystem Modeling

define the processes that serve the needs of the view define the processes that serve the needs of the view under consideration.under consideration.

represent the behavior of the processes and the represent the behavior of the processes and the assumptions on which the behavior is based.assumptions on which the behavior is based.

explicitly define both exogenous and endogenous input to explicitly define both exogenous and endogenous input to the model.the model. exogenous inputs link one constituent of a given view with exogenous inputs link one constituent of a given view with

other constituents at the same level of other levels; other constituents at the same level of other levels; endogenous input links individual components of a constituent endogenous input links individual components of a constituent at a particular view.at a particular view.

represent all linkages (including output) that will enable represent all linkages (including output) that will enable the engineer to better understand the view.the engineer to better understand the view.


Business Process Business Process EngineeringEngineering uses an integrated set of procedures, uses an integrated set of procedures,

methods, and tools to identify how methods, and tools to identify how information systems can best meet the information systems can best meet the strategic goals of an enterprisestrategic goals of an enterprise

focuses first on the enterprise and then focuses first on the enterprise and then on the business areaon the business area

creates enterprise models, data models creates enterprise models, data models and process modelsand process models

creates a framework for better creates a framework for better information management distribution, information management distribution, and controland control


System ArchitecturesSystem Architectures

Three different architectures must be analyzed and Three different architectures must be analyzed and designed within the context of business objectives and designed within the context of business objectives and goals:goals:

data architecturedata architecture applications architectureapplications architecture technology infrastructuretechnology infrastructure

data architecturedata architecture provides a framework for the information provides a framework for the information needs of a business or business functionneeds of a business or business function

application architectureapplication architecture encompasses those elements of a encompasses those elements of a system that transform objects within the data architecture system that transform objects within the data architecture for some business purposefor some business purpose

technology infrastructuretechnology infrastructure provides the foundation for the provides the foundation for the data and application architecturesdata and application architectures


The BPE The BPE HierarchyHierarchy Information strategy planning (ISP)Information strategy planning (ISP)

strategic goals definedstrategic goals defined success factors/business rules success factors/business rules

identifiedidentified enterprise model createdenterprise model created

Business area analysis (BAA)Business area analysis (BAA) processes/services modeledprocesses/services modeled interrelationships of processes and datainterrelationships of processes and data

Application EngineeringApplication Engineering a.k.a ... software engineeringa.k.a ... software engineering modeling applications/procedures that modeling applications/procedures that

address (BAA) and constraints of ISPaddress (BAA) and constraints of ISP Construction and deliveryConstruction and delivery

using CASE and 4GTs, testingusing CASE and 4GTs, testing


Information Strategy Information Strategy PlanningPlanning Management issuesManagement issues

define strategic business define strategic business goals/objectivesgoals/objectives

isolate critical success factorsisolate critical success factors conduct analysis of technology conduct analysis of technology

impactimpact perform analysis of strategic systemsperform analysis of strategic systems

Technical issuesTechnical issues create a top-level data modelcreate a top-level data model cluster by business/organizational cluster by business/organizational

areaarea refine model and clusteringrefine model and clustering


Defining Objectives and Defining Objectives and GoalsGoals

ObjectiveObjective—general statement of direction—general statement of direction GoalGoal—defines measurable objective: —defines measurable objective:

“reduce manufactured cost of our “reduce manufactured cost of our product”product” SubgoalsSubgoals::

decrease reject rate by 20% in first 6 monthsdecrease reject rate by 20% in first 6 months gain 10% price concessions from suppliersgain 10% price concessions from suppliers re-engineer 30% of components for ease of re-engineer 30% of components for ease of

manufacture during first yearmanufacture during first year Objectives tend to be strategic while goals Objectives tend to be strategic while goals

tend to be tacticaltend to be tactical


Business Area Business Area AnalysisAnalysis define “naturally cohesive groupings of define “naturally cohesive groupings of

business functions and data” (Martin)business functions and data” (Martin) perform many of the same activities as ISP, perform many of the same activities as ISP,

but narrow scope to individual business areabut narrow scope to individual business area identify existing (old) information systems / identify existing (old) information systems /

determine compatibility with new ISP modeldetermine compatibility with new ISP model define systems that are problematic define systems that are problematic defining systems that are incompatible with new defining systems that are incompatible with new

information modelinformation model begin to establish re-engineering prioritiesbegin to establish re-engineering priorities


The BAA The BAA ProcessProcess

salesacct

manufacturing

QC

eng’ring

distribution

admin.

DataModel

ProcessDecomposition

DiagramMatrices

e.g.,entity/process

matrix

Process Flow

Models


Product Product EngineeringEngineeringSystem analysis

(World view)

The completeproduct

capabilities

Componentengineering

(Domain view)

Processing requirement

Analysis & DesignModeling

(Element view)

Construction&

Integration(Detailed view)

software

function

SoftwareEngineering

programcomponent

hardware

data behavior


Product Architecture Product Architecture TemplateTemplate

user interface processing

inputprocessing

outputprocessing

maintenance and self-test

process and controlfunctions


Architecture Flow Architecture Flow DiagramDiagram

bar codereader

subsystem

bar codedecoding

subsystem

data baseaccess

subsystem

shuntcontrol

subsystem

reportformating

subsystem

diagnosticssubsystem

operatorinterface

subsystem

shuntcontroller

mainframecommunications

driver

operator requests CLSS queries, reports, displays

shunt control statusbar code acquisition request

bar code

pulse tach input

linespeed

bar codereader status

sensor status

raw barcode data

partnumber

reportrequests

binlocation

key

sort records

formatedreporting data

sorting reports

shunt commands

CLSS reports

BCR statusshunt status

communications status

timing/location data

operatorinterface

data acquisitioninterface diagnostic interface output interface

CLSS processing & control

sensor dataacquisitionsubsystem


System Modeling with UMLSystem Modeling with UML

Deployment diagramsDeployment diagrams Each 3-D box depicts a hardware element that is Each 3-D box depicts a hardware element that is

part of the physical architecture of the systempart of the physical architecture of the system Activity diagramsActivity diagrams

Represent procedural aspects of a system Represent procedural aspects of a system elementelement

Class diagramsClass diagrams Represent system level elements in terms of the Represent system level elements in terms of the

data that describe the element and the operations data that describe the element and the operations that manipulate the datathat manipulate the data

These and other UML models will be discussed laterThese and other UML models will be discussed later


Deployment DiagramDeployment Diagram

CLSS processor

Sorting subsystem

Sensor dataacquisition subsystem

Operator display

shunt controller

ConveyorPulse tach

Bar code reader Shunt actuator


Activity DiagramActivity Diagram

get conveyor speed

send shuntcontrol data

get shunt status read bar code

start conveyor line

determine bin location

valid bar code

set for reject bin

conveyor in motion

read bar code

get conveyor status

produce report entry

conveyor stopped

invalid bar code


Class DiagramClass Diagram

Box

barcodeforwardSpeedconveyorLocationheightwidthdepthweightcontents

readBarcode()updateSpeed()readSpeed()updateLocation()readLocation()getDimensions()getWeight()checkContents()

class name

attributesnote use of capitalletter for multi-wordattribute names

operations(parentheses at endof name indicate thelist of attributes that theoperation requires)



Chapter 7Chapter 7Requirements EngineeringRequirements Engineering

copyright © 1996, 2001, 2005





Requirements Engineering-IRequirements Engineering-I InceptionInception—ask a set of questions that establish …—ask a set of questions that establish …

basic understanding of the problembasic understanding of the problem the people who want a solutionthe people who want a solution the nature of the solution that is desired, and the nature of the solution that is desired, and the effectiveness of preliminary communication and the effectiveness of preliminary communication and

collaboration between the customer and the developercollaboration between the customer and the developer ElicitationElicitation—elicit requirements from all stakeholders—elicit requirements from all stakeholders ElaborationElaboration—create an analysis model that identifies —create an analysis model that identifies

data, function and behavioral requirementsdata, function and behavioral requirements NegotiationNegotiation—agree on a deliverable system that is —agree on a deliverable system that is

realistic for developers and customersrealistic for developers and customers


Requirements Engineering-IIRequirements Engineering-II SpecificationSpecification—can be any one (or more) of the following:—can be any one (or more) of the following:

A written documentA written document A set of modelsA set of models A formal mathematicalA formal mathematical A collection of user scenarios (use-cases)A collection of user scenarios (use-cases) A prototypeA prototype

ValidationValidation—a review mechanism that looks for—a review mechanism that looks for errors in content or interpretationerrors in content or interpretation areas where clarification may be requiredareas where clarification may be required missing informationmissing information inconsistencies (a major problem when large products or inconsistencies (a major problem when large products or

systems are engineered)systems are engineered) conflicting or unrealistic (unachievable) requirements. conflicting or unrealistic (unachievable) requirements.

Requirements managementRequirements management


InceptionInception Identify stakeholdersIdentify stakeholders

““who else do you think I should talk to?”who else do you think I should talk to?” Recognize multiple points of viewRecognize multiple points of view Work toward collaborationWork toward collaboration The first questionsThe first questions

Who is behind the request for this work?Who is behind the request for this work? Who will use the solution?Who will use the solution? What will be the economic benefit of a successful What will be the economic benefit of a successful

solutionsolution Is there another source for the solution that you Is there another source for the solution that you

need?need?


Eliciting RequirementsEliciting Requirements meetings are conducted and attended by both software meetings are conducted and attended by both software

engineers and customersengineers and customers rules for preparation and participation are establishedrules for preparation and participation are established an agenda is suggested an agenda is suggested a "facilitator" (can be a customer, a developer, or an a "facilitator" (can be a customer, a developer, or an

outsider) controls the meetingoutsider) controls the meeting a "definition mechanism" (can be work sheets, flip charts, or a "definition mechanism" (can be work sheets, flip charts, or

wall stickers or an electronic bulletin board, chat room or wall stickers or an electronic bulletin board, chat room or virtual forum) is usedvirtual forum) is used

the goal is the goal is to identify the problemto identify the problem propose elements of the solutionpropose elements of the solution negotiate different approaches, andnegotiate different approaches, and specify a preliminary set of solution requirementsspecify a preliminary set of solution requirements


Eliciting RequirementsEliciting Requirements

Use QFD toprioritize

requirementsinformallyprioritize

requirements

formal prioritization?

Create Use-cases

yes noElicit requirements

write scenario

define actors

complete template

draw use-casediagram

Conduct FASTmeetings

Make lists offunctions, classes

Make lists ofconstraints, etc.


Quality Function Quality Function DeploymentDeployment

Function deploymentFunction deployment determines the “value” (as determines the “value” (as perceived by the customer) of each function perceived by the customer) of each function required of the systemrequired of the system

Information deploymentInformation deployment identifies data objects identifies data objects and eventsand events

Task deploymentTask deployment examines the behavior of the examines the behavior of the systemsystem

Value analysisValue analysis determines the relative priority of determines the relative priority of requirementsrequirements


Elicitation Work ProductsElicitation Work Products a statement of need and feasibility.a statement of need and feasibility. a bounded statement of scope for the system or product.a bounded statement of scope for the system or product. a list of customers, users, and other stakeholders who a list of customers, users, and other stakeholders who

participated in requirements elicitation participated in requirements elicitation a description of the system’s technical environment.a description of the system’s technical environment. a list of requirements (preferably organized by function) a list of requirements (preferably organized by function)

and the domain constraints that apply to each.and the domain constraints that apply to each. a set of usage scenarios that provide insight into the use a set of usage scenarios that provide insight into the use

of the system or product under different operating of the system or product under different operating conditions.conditions.

any prototypesany prototypes developed to better define requirementsdeveloped to better define requirements.


Use-CasesUse-Cases A collection of user scenarios that describe the thread of usage A collection of user scenarios that describe the thread of usage

of a systemof a system Each scenario is described from the point-of-view of an “actor”—Each scenario is described from the point-of-view of an “actor”—

a person or device that interacts with the software in some waya person or device that interacts with the software in some way Each scenario answers the following questions:Each scenario answers the following questions:

Who is the primary actor, the secondary actor (s)?Who is the primary actor, the secondary actor (s)? What are the actor’s goals?What are the actor’s goals? What preconditions should exist before the story begins?What preconditions should exist before the story begins? What main tasks or functions are performed by the actor?What main tasks or functions are performed by the actor? What extensions might be considered as the story is described?What extensions might be considered as the story is described? What variations in the actor’s interaction are possible?What variations in the actor’s interaction are possible? What system information will the actor acquire, produce, or change?What system information will the actor acquire, produce, or change? Will the actor have to inform the system about changes in the Will the actor have to inform the system about changes in the

external environment?external environment? What information does the actor desire from the system?What information does the actor desire from the system? Does the actor wish to be informed about unexpected changes?Does the actor wish to be informed about unexpected changes?


Use-Case DiagramUse-Case Diagram

homeowner

Arms/disarmssystem

Accesses systemvia Internet

Reconfigures sensorsand related

system features

Responds toalarm event

Encounters anerror condition

systemadministrator

sensors


Building the Analysis ModelBuilding the Analysis Model

Elements of the analysis modelElements of the analysis model Scenario-based elementsScenario-based elements

Functional—processing narratives for software Functional—processing narratives for software functionsfunctions

Use-case—descriptions of the interaction between Use-case—descriptions of the interaction between an “actor” and the systeman “actor” and the system

Class-based elementsClass-based elements Implied by scenariosImplied by scenarios

Behavioral elementsBehavioral elements State diagramState diagram

Flow-oriented elementsFlow-oriented elements Data flow diagramData flow diagram


Class DiagramClass Diagram

Sensor

name/idtypelocationareacharacteristics

identify()enable()disable()reconfigure()

From the From the SafeHomeSafeHome system … system …


State DiagramState Diagram

Figure 7.6 Preliminary UML state diagram for a photocopier

Initialization

system status=“not ready”display msg = “please wait”display status = blinking

entry/ switch machine ondo: run diagnosticsdo: initiate all subsystems

turn copier“on“

subsystemsready system status=“Ready”

display msg = “enter cmd”display status = steady

entry/ subsystems readydo: poll user input paneldo: read user inputdo: interpret user input

Readingcommands

system status=“Copying”display msg= “copy count =”display message=#copiesdisplay status= steady

entry/ start copiesdo: manage copyingdo: monitor paper traydo: monitor paper flow

Making copies

start copies

system status=“Jammed”display msg= “paper jam”display message=locationdisplay status= blinking

entry/ paper jammeddo: determine locationdo: provide corrective msg.do: interrupt making copies

problem diagnosis

paper jammed

system status=“load paper”display msg= “load paper”display status= blinking

entry/ paper emptydo: lower paper traydo: monitor fill switchdo: raise paper tray

load paper

paper tray empty

not jammed

paper full

turn copier “off”

not jammed

copies complete


Analysis PatternsAnalysis PatternsPattern name:Pattern name: A descriptor that captures the essence of the pattern. A descriptor that captures the essence of the pattern.

Intent:Intent: Describes what the pattern accomplishes or represents Describes what the pattern accomplishes or represents

Motivation:Motivation: A scenario that illustrates how the pattern can be used to A scenario that illustrates how the pattern can be used to address the problem.address the problem.

Forces and context:Forces and context: A description of external issues (forces) that can A description of external issues (forces) that can affect how the pattern is used and also the external issues that will be affect how the pattern is used and also the external issues that will be resolved when the pattern is applied. resolved when the pattern is applied.

Solution:Solution: A description of how the pattern is applied to solve the A description of how the pattern is applied to solve the problem with an emphasis on structural and behavioral issues.problem with an emphasis on structural and behavioral issues.

ConsequencesConsequences: Addresses what happens when the pattern is applied : Addresses what happens when the pattern is applied and what trade-offs exist during its application.and what trade-offs exist during its application.

DesignDesign: Discusses how the analysis pattern can be achieved through : Discusses how the analysis pattern can be achieved through the use of known design patterns.the use of known design patterns.

Known usesKnown uses: Examples of uses within actual systems.: Examples of uses within actual systems.

Related patternsRelated patterns: On e or more analysis patterns that are related to : On e or more analysis patterns that are related to the named pattern because (1) it is commonly used with the named the named pattern because (1) it is commonly used with the named pattern; (2) it is structurally similar to the named pattern; (3) it is a pattern; (2) it is structurally similar to the named pattern; (3) it is a variation of the named pattern.variation of the named pattern.


Negotiating RequirementsNegotiating Requirements

Identify the key stakeholdersIdentify the key stakeholders These are the people who will be involved in the These are the people who will be involved in the

negotiationnegotiation Determine each of the stakeholders “win Determine each of the stakeholders “win

conditions”conditions” Win conditions are not always obviousWin conditions are not always obvious

NegotiateNegotiate Work toward a set of requirements that lead to “win-Work toward a set of requirements that lead to “win-

win”win”


Validating Requirements-IValidating Requirements-I Is each requirement consistent with the overall objective Is each requirement consistent with the overall objective

for the system/product?for the system/product? Have all requirements been specified at the proper level Have all requirements been specified at the proper level

of abstraction? That is, do some requirements provide a of abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this stage?level of technical detail that is inappropriate at this stage?

Is the requirement really necessary or does it represent Is the requirement really necessary or does it represent an add-on feature that may not be essential to the an add-on feature that may not be essential to the objective of the system?objective of the system?

Is each requirement bounded and unambiguous?Is each requirement bounded and unambiguous? Does each requirement have attribution? That is, is a Does each requirement have attribution? That is, is a

source (generally, a specific individual) noted for each source (generally, a specific individual) noted for each requirement? requirement?

Do any requirements conflict with other requirements?Do any requirements conflict with other requirements?


Validating Requirements-IIValidating Requirements-II

Is each requirement achievable in the technical Is each requirement achievable in the technical environment that will house the system or product?environment that will house the system or product?

Is each requirement testable, once implemented?Is each requirement testable, once implemented? Does the requirements model properly reflect the Does the requirements model properly reflect the

information, function and behavior of the system to be built.information, function and behavior of the system to be built. Has the requirements model been “partitioned” in a way Has the requirements model been “partitioned” in a way

that exposes progressively more detailed information about that exposes progressively more detailed information about the system.the system.

Have requirements patterns been used to simplify the Have requirements patterns been used to simplify the requirements model. Have all patterns been properly requirements model. Have all patterns been properly validated? Are all patterns consistent with customer validated? Are all patterns consistent with customer requirements?requirements?



Chapter 8Chapter 8Analysis ModelingAnalysis Modeling

copyright © 1996, 2001, 2005





Requirements AnalysisRequirements Analysis

Requirements analysis Requirements analysis specifies software’s operational characteristicsspecifies software’s operational characteristics indicates software's interface with other system elements indicates software's interface with other system elements establishes constraints that software must meetestablishes constraints that software must meet

Requirements analysis allows the software engineer Requirements analysis allows the software engineer (called an (called an analystanalyst or or modelermodeler in this role) to: in this role) to: elaborate on basic requirements established during earlier elaborate on basic requirements established during earlier

requirement engineering tasksrequirement engineering tasks build models that depict user scenarios, functional activities, build models that depict user scenarios, functional activities,

problem classes and their relationships, system and class problem classes and their relationships, system and class behavior, and the flow of data as it is transformed. behavior, and the flow of data as it is transformed.


A BridgeA Bridge

systemdescription

analysismodel

designmodel


Rules of ThumbRules of Thumb The model should focus on requirements that are The model should focus on requirements that are

visible within the problem or business domain. The visible within the problem or business domain. The level of abstraction should be relatively high. level of abstraction should be relatively high.

Each element of the analysis model should add to an Each element of the analysis model should add to an overall understanding of software requirements and overall understanding of software requirements and provide insight into the information domain, provide insight into the information domain, function and behavior of the system.function and behavior of the system.

Delay consideration of infrastructure and other non-Delay consideration of infrastructure and other non-functional models until design. functional models until design.

Minimize coupling throughout the system. Minimize coupling throughout the system. Be certain that the analysis model provides value to Be certain that the analysis model provides value to

all stakeholders. all stakeholders. Keep the model as simple as it can be. Keep the model as simple as it can be.


Domain AnalysisDomain Analysis

Software domain analysis is the identification, Software domain analysis is the identification, analysis, and specification of common analysis, and specification of common requirements from a specific application requirements from a specific application domain, typically for reuse on multiple projects domain, typically for reuse on multiple projects within that application domain . . . [Object-within that application domain . . . [Object-oriented domain analysis is] the identification, oriented domain analysis is] the identification, analysis, and specification of common, reusable analysis, and specification of common, reusable capabilities within a specific application domain, capabilities within a specific application domain, in terms of common objects, classes, in terms of common objects, classes, subassemblies, and frameworks . . .subassemblies, and frameworks . . .Donald Firesmith


Domain AnalysisDomain Analysis Define the domain to be investigated.Define the domain to be investigated. Collect a representative sample of Collect a representative sample of

applications in the domain.applications in the domain. Analyze each application in the sample.Analyze each application in the sample. Develop an analysis model for the objects. Develop an analysis model for the objects.


Data ModelingData Modeling

examines data objects examines data objects independently of processingindependently of processing

focuses attention on the data focuses attention on the data domaindomain

creates a model at the customer’s creates a model at the customer’s level of abstractionlevel of abstraction

indicates how data objects relate to indicates how data objects relate to one anotherone another


What is a Data Object?What is a Data Object?

ObjectObject——something that is described by a setsomething that is described by a setof attributes (data items) and that will be of attributes (data items) and that will be manipulated within the software (system)manipulated within the software (system)

each each instanceinstanceof an object (e.g., a book) of an object (e.g., a book) can be identified uniquely (e.g., ISBN #) can be identified uniquely (e.g., ISBN #)

each plays a necessary role in the systemeach plays a necessary role in the systemi.e., the system could not function without i.e., the system could not function without access to instances of the objectaccess to instances of the objecteach is described by attributes that are each is described by attributes that are

themselves data itemsthemselves data items


Typical ObjectsTypical Objects

external entitiesexternal entities (printer, user, sensor)(printer, user, sensor)thingsthings (e.g, reports, displays, signals) (e.g, reports, displays, signals)

occurrences or eventsoccurrences or events (e.g., interrupt, alarm)(e.g., interrupt, alarm)rolesroles (e.g., manager, engineer, salesperson)(e.g., manager, engineer, salesperson)

organizational unitsorganizational units (e.g., division, team)(e.g., division, team)placesplaces (e.g., manufacturing floor) (e.g., manufacturing floor)

structuresstructures (e.g., employee record)(e.g., employee record)


Data Objects and Data Objects and AttributesAttributes

A data object contains a set of A data object contains a set of attributes that act as an aspect, attributes that act as an aspect, quality, characteristic, or descriptor of quality, characteristic, or descriptor of the objectthe objectobject: automobileobject: automobile

attributes:attributes: makemake modelmodel body typebody type priceprice options codeoptions code


What is a Relationship?What is a Relationship?

relationshiprelationship——indicates “connectedness”; indicates “connectedness”; a "fact" that must be "remembered" a "fact" that must be "remembered" by the system and cannot or is not computed by the system and cannot or is not computed or derived mechanicallyor derived mechanically

several instances of a relationship several instances of a relationship can existcan exist

objects can be related in many objects can be related in many different waysdifferent ways


ERD NotationERD Notation

(0, m) (1, 1)

objectobject objectobjectrelationshiprelationship11 22

One common form:One common form:

(0, m)(0, m)

(1, 1)(1, 1)

objectobject11 objectobject22relationshiprelationship

Another common form:Another common form:attributeattribute


Building an ERDBuilding an ERD

Level 1—model all data objects (entities) and Level 1—model all data objects (entities) and their “connections” to one anothertheir “connections” to one another

Level 2—model all entities and relationshipsLevel 2—model all entities and relationships Level 3—model all entities, relationships, Level 3—model all entities, relationships,

and the attributes that provide further depthand the attributes that provide further depth


The ERD: An ExampleThe ERD: An Example

(1,1)(1,1) (1,m)(1,m)placesplacesCustomerCustomer

requestrequestfor servicefor service

generatesgenerates (1,n)(1,n)

(1,1)(1,1)

workworkorderorder

workworktaskstasks

materialsmaterials

consistsconsistsofof

listslists

(1,1)(1,1)(1,w)(1,w)

(1,1)

(1,i)(1,i)

selectedselectedfromfrom

standardstandardtask tabletask table

(1,w)(1,w)

(1,1)(1,1)


Object-Oriented ConceptsObject-Oriented Concepts

Must be understood to apply class-based Must be understood to apply class-based elements of the analysis modelelements of the analysis model

Key concepts:Key concepts: Classes and objectsClasses and objects Attributes and operationsAttributes and operations Encapsulation and instantiationEncapsulation and instantiation InheritanceInheritance


ClassClasseses• object-oriented thinking begins with object-oriented thinking begins with

the definition of a the definition of a class,class, often often defined as:defined as:– templatetemplate– generalized descriptiongeneralized description– “ “blueprint” ... describing a collection of blueprint” ... describing a collection of

similar itemssimilar items• a a metaclassmetaclass (also called a (also called a superclasssuperclass) )

establishes a hierarchy of classesestablishes a hierarchy of classes• once a class of items is defined, a once a class of items is defined, a

specific instance of the class can be specific instance of the class can be identified identified


Building a Building a ClassClass

class name

attributes:

operations:

attributes:

operations


What is a What is a Class?Class?

external entities

things

occurrences roles

organizational units

places

structures

class name

attributes:

operations:


Encapsulation/Encapsulation/HidingHidingThe object encapsulates

both data and the logicalprocedures required tomanipulate the data

Achieves “information hiding”

method # 1

data

method # 2

method # 4

method # 5

method # 6

method # 3


Class Class HierarchyHierarchy

ChairTable Desk ”Chable"

instances of Chair

PieceOfFurniture (superclass)

subclasses of the


MethodsMethods(a.k.a. Operations, (a.k.a. Operations,

Services)Services)An executable procedure that is encapsulated in a class and is designed to operate on one or more data attributes that are defined as part of the class.A method is invoked via message passing.


Scenario-Based ModelingScenario-Based Modeling

““[Use-cases] are simply an aid to defining what [Use-cases] are simply an aid to defining what exists outside the system (actors) and what exists outside the system (actors) and what should be performed by the system (use-cases).” should be performed by the system (use-cases).” Ivar JacobsonIvar Jacobson

(1) What should we write about?(1) What should we write about?

(2) How much should we write about it?(2) How much should we write about it?

(3) How detailed should we make our description? (3) How detailed should we make our description?

(4) How should we organize the description?(4) How should we organize the description?


Use-Use-CasesCases

a scenario that describes a “thread of a scenario that describes a “thread of usage” for a systemusage” for a system

actorsactors represent roles people or devices represent roles people or devices play as the system functionsplay as the system functions

usersusers can play a number of different roles can play a number of different roles for a given scenariofor a given scenario


Developing a Use-Developing a Use-CaseCase What are the main tasks or functions that are What are the main tasks or functions that are

performed by the actor?performed by the actor? What system information will the the actor What system information will the the actor

acquire, produce or change?acquire, produce or change? Will the actor have to inform the system about Will the actor have to inform the system about

changes in the external environment?changes in the external environment? What information does the actor desire from the What information does the actor desire from the

system?system? Does the actor wish to be informed about Does the actor wish to be informed about

unexpected changes?unexpected changes?


Use-Case DiagramUse-Case Diagram

homeowner

Access camerasurveillance via the

Internet

Configure SafeHomesystem parameters

Set alarm

cameras

SafeHome


Activity DiagramActivity DiagramSupplements the use-case by providing a diagrammatic Supplements the use-case by providing a diagrammatic representation of procedural flowrepresentation of procedural flow

enter passwordand user ID

select major function

valid passwords/ID

prompt for reentry

invalid passwords/ID

input tries remainno inputtries remain

select surveillance

other functionsmay also beselected

thumbnail views select a specific camera

select camera icon

prompt foranother view

select specificcamera - thumbnails

exit this function see another camera

view camera outputin labelled window


Swimlane DiagramsSwimlane DiagramsAllows the modeler to represent the flow of activities described by the use-case Allows the modeler to represent the flow of activities described by the use-case and at the same time indicate which actor (if there are multiple actors involved and at the same time indicate which actor (if there are multiple actors involved in a specific use-case) or analysis class has responsibility for the action in a specific use-case) or analysis class has responsibility for the action described by an activity rectangledescribed by an activity rectangle

enter passwordand user ID

select major functionvalid passwords/ID

prompt for reentry

invalidpasswords/ID

input triesremain

no inputtries remain

select surveillance

other functionsmay also beselected

thumbnail views select a specific camera

select camera icon

generate videooutput

select specificcamera - thumbnails

exit thisfunctionsee

anothercamera

homeowner camera interface

prompt foranother viewview camera output

in labelled window


Flow-Oriented Flow-Oriented ModelingModeling

Represents how data objects are transformed at Represents how data objects are transformed at they move through the systemthey move through the system

A A data flow diagram (DFD)data flow diagram (DFD) is the diagrammatic is the diagrammatic form that is usedform that is used

Considered by many to be an ‘old school’ Considered by many to be an ‘old school’ approach, flow-oriented modeling continues to approach, flow-oriented modeling continues to provide a view of the system that is unique—it provide a view of the system that is unique—it should be used to supplement other analysis should be used to supplement other analysis model elementsmodel elements


The Flow ModelThe Flow ModelEvery computer-based system is an Every computer-based system is an information transform ....information transform ....

computercomputerbasedbased

systemsysteminputinput outputoutput


Flow Modeling NotationFlow Modeling Notation

external entityexternal entity

processprocess

data flowdata flow

data storedata store


External EntityExternal Entity

A producer or consumer of dataA producer or consumer of data

Examples: a person, a device, a sensorExamples: a person, a device, a sensor

Another example: computer-basedAnother example: computer-basedsystemsystem

Data must always originate somewhereData must always originate somewhereand must always be sent to somethingand must always be sent to something


ProcessProcess

A data transformer (changes inputA data transformer (changes inputto output)to output)

Examples: compute taxes, determine area,Examples: compute taxes, determine area,format report, display graph format report, display graph

Data must always be processed in some Data must always be processed in some way to achieve system functionway to achieve system function


Data FlowData Flow

Data flows through a system, beginningData flows through a system, beginningas input and be transformed into output.as input and be transformed into output.

computecomputetriangle triangle

areaarea

basebase

heightheight

areaarea


Data StoresData Stores

DataData is often stored for later use.is often stored for later use.

look-uplook-upsensorsensor

datadata

sensor #sensor #

report requiredreport required

sensor #, type, sensor #, type, location, agelocation, age

sensor datasensor data

sensor numbersensor number

type, type, location, agelocation, age


Data Flow Diagramming:Data Flow Diagramming:GuidelinesGuidelines

all icons must be labeled with all icons must be labeled with meaningful namesmeaningful names

the DFD evolves through a number of the DFD evolves through a number of levels of detaillevels of detail

always begin with a context level always begin with a context level diagram (also called level 0)diagram (also called level 0)

always show external entities at level always show external entities at level 00

always label data flow arrowsalways label data flow arrows do not represent procedural logicdo not represent procedural logic


Constructing a DFD—IConstructing a DFD—I

review the data model to isolate data review the data model to isolate data objects and use a grammatical parse to objects and use a grammatical parse to determine “operations”determine “operations”

determine external entities (producers determine external entities (producers and consumers of data)and consumers of data)

create a level 0 DFDcreate a level 0 DFD


Level 0 DFD ExampleLevel 0 DFD Example

useruserprocessing processing

requestrequest

videovideosourcesource NTSCNTSC

video signalvideo signal

digitaldigitalvideovideo

processorprocessor

requestedrequestedvideovideosignalsignal

monitormonitor


Constructing a DFD—IIConstructing a DFD—II

write a narrative describing the write a narrative describing the transformtransform

parse to determine next level parse to determine next level transformstransforms

““balance” the flow to maintain data balance” the flow to maintain data flow continuityflow continuity

develop a level 1 DFDdevelop a level 1 DFD use a 1:5 (approx.) expansion ratiouse a 1:5 (approx.) expansion ratio


The Data Flow HierarchyThe Data Flow Hierarchy

PPaa bbxx yy

p1p1p2p2

p3p3p4p4 55

aa

bb

cc

ddee

ff

gg

level 0level 0

level 1level 1


Flow Modeling NotesFlow Modeling Notes

each bubble is refined until it does each bubble is refined until it does just one thingjust one thing

the expansion ratio decreases as the the expansion ratio decreases as the number of levels increasenumber of levels increase

most systems require between 3 and most systems require between 3 and 7 levels for an adequate flow model7 levels for an adequate flow model

a single data flow item (arrow) may a single data flow item (arrow) may be expanded as levels increase (data be expanded as levels increase (data dictionary provides information)dictionary provides information)


Process Specification Process Specification (PSPEC)(PSPEC)

PSPECPSPEC

narrativenarrativepseudocode (PDL)pseudocode (PDL)

equationsequationstablestables

diagrams and/or chartsdiagrams and/or charts

bubblebubble


Maps intoMaps into

DFDs: A Look AheadDFDs: A Look Ahead

analysis modelanalysis model

design modeldesign model


Control Flow DiagramsControl Flow Diagrams

Represents “Represents “eventsevents” and the processes that ” and the processes that manage eventsmanage events

An “event” is a Boolean condition that can be An “event” is a Boolean condition that can be ascertained by:ascertained by:

listing all sensors that are "read" by the software.listing all sensors that are "read" by the software. listing all interrupt conditions.listing all interrupt conditions. listing all "switches" that are actuated by an operator.listing all "switches" that are actuated by an operator. listing all data conditions.listing all data conditions. recalling the noun/verb parse that was applied to the recalling the noun/verb parse that was applied to the

processing narrative, review all "control items" as possible processing narrative, review all "control items" as possible CSPEC inputs/outputs.CSPEC inputs/outputs.


The Control The Control ModelModelthe control flow diagram is "superimposed" on the DFD the control flow diagram is "superimposed" on the DFD

and shows events that control the processes noted in and shows events that control the processes noted in the DFDthe DFD

control flows—events and control items—are noted by control flows—events and control items—are noted by dashed arrowsdashed arrows

a vertical bar implies an input to or output from a control a vertical bar implies an input to or output from a control spec (CSPEC) — a separate specification that spec (CSPEC) — a separate specification that describes how control is handleddescribes how control is handled

a dashed arrow entering a vertical bar is an input to the a dashed arrow entering a vertical bar is an input to the CSPECCSPEC

a dashed arrow leaving a process implies a data a dashed arrow leaving a process implies a data conditioncondition

a dashed arrow entering a process implies a control a dashed arrow entering a process implies a control input read directly by the processinput read directly by the process

control flows do not physically activate/deactivate the control flows do not physically activate/deactivate the processes—this is done via the CSPECprocesses—this is done via the CSPEC


Control Flow Control Flow DiagramDiagram

readoperator

input managecopying

reloadprocess

performproblemdiagnosis

createuser

displays

empty

jammed

full

display panel enabled

beeper on/off

start

problemlight

copies done


Control Specification Control Specification (CSPEC)(CSPEC)

The CSPEC can be:The CSPEC can be:

state diagram state diagram (sequential spec)(sequential spec)

state transition tablestate transition table

decision tables decision tables

activation tablesactivation tables

combinatorial speccombinatorial spec


Guidelines for Building a Guidelines for Building a CSPECCSPEClist all sensors that are "read" by the softwarelist all sensors that are "read" by the software

list all interrupt conditionslist all interrupt conditions

list all "switches" that are actuated by the operatorlist all "switches" that are actuated by the operator

list all data conditionslist all data conditions

recalling the noun-verb parse that was applied to therecalling the noun-verb parse that was applied to thesoftware statement of scope, review all "control items"software statement of scope, review all "control items"

as possible CSPEC inputs/outputsas possible CSPEC inputs/outputs

describe the behavior of a system by identifying its describe the behavior of a system by identifying its states; identify how each state is reach and defines states; identify how each state is reach and defines

the transitions between statesthe transitions between states

focus on possible omissions ... a very common error in focus on possible omissions ... a very common error in specifying control, e.g., ask: "Is there any other way I specifying control, e.g., ask: "Is there any other way I can get to this state or exit from it?"can get to this state or exit from it?"


Class-Based ModelingClass-Based Modeling Identify analysis classes by examining the Identify analysis classes by examining the

problem statementproblem statement Use a “grammatical parse” to isolate Use a “grammatical parse” to isolate

potential classespotential classes Identify the attributes of each classIdentify the attributes of each class Identify operations that manipulate the Identify operations that manipulate the

attributesattributes


Analysis ClassesAnalysis Classes External entitiesExternal entities (e.g., other systems, devices, people) that produce or (e.g., other systems, devices, people) that produce or

consume information to be used by a computer-based system.consume information to be used by a computer-based system. ThingsThings (e.g, reports, displays, letters, signals) that are part of the (e.g, reports, displays, letters, signals) that are part of the

information domain for the problem.information domain for the problem. Occurrences or eventsOccurrences or events (e.g., a property transfer or the completion of a (e.g., a property transfer or the completion of a

series of robot movements) that occur within the context of system series of robot movements) that occur within the context of system operation.operation.

RolesRoles (e.g., manager, engineer, salesperson) played by people who (e.g., manager, engineer, salesperson) played by people who interact with the system.interact with the system.

Organizational unitsOrganizational units (e.g., division, group, team) that are relevant to an (e.g., division, group, team) that are relevant to an application.application.

PlacesPlaces (e.g., manufacturing floor or loading dock) that establish the (e.g., manufacturing floor or loading dock) that establish the context of the problem and the overall function of the system.context of the problem and the overall function of the system.

StructuresStructures (e.g., sensors, four-wheeled vehicles, or computers) that (e.g., sensors, four-wheeled vehicles, or computers) that define a class of objects or related classes of objects.define a class of objects or related classes of objects.


Selecting Classes—Selecting Classes—CriteriaCriteria

needed servicesneeded services

multiple attributesmultiple attributes

common attributescommon attributes

common operationscommon operations

essential requirementsessential requirements

retained informationretained information


Class DiagramClass DiagramSystem

program()display()reset()query()modify()call()

systemIDverificationPhoneNumbersystemStatusdelayTimetelephoneNumbermasterPasswordtemporaryPasswordnumberTries

Class name

attributes

operations


Class DiagramClass DiagramFloorPlan

determineType()positionFloorplanscale()change color()

typenameoutsideDimensions

Camera

determineType()translateLocation()displayID()displayView()displayZoom()

typeIDlocationfieldViewpanAngleZoomSetting

WallSegmenttypestartCoordinatesstopCoordinatesnextWallSement

determineType()draw()

WindowtypestartCoordinatesstopCoordinatesnextWindow


is placed within

WalltypewallDimensions

determineType()computeDimensions ()

DoortypestartCoordinatesstopCoordinatesnextDoor


is part of

is used to buildis used to build

is used to build


CRC ModelingCRC Modeling

Analysis classes have “responsibilities”Analysis classes have “responsibilities” ResponsibilitiesResponsibilities are the attributes and operations are the attributes and operations

encapsulated by the classencapsulated by the class Analysis classes collaborate with one anotherAnalysis classes collaborate with one another

CollaboratorsCollaborators are those classes that are required to are those classes that are required to provide a class with the information needed to complete provide a class with the information needed to complete a responsibility. a responsibility.

In general, a collaboration implies either a request for In general, a collaboration implies either a request for information or a request for some action.information or a request for some action.


CRC CRC ModelingModeling

Class:

Description:

Responsibility: Collaborator:

Class:

Description:


Class:

Description:


Class: FloorPlan

Description:


incorporates walls, doors and windows

shows position of video cameras

defines floor plan name/type

manages floor plan positioning

scales floor plan for display

scales floor plan for display

Wall

Camera


Class TypesClass Types Entity classesEntity classes, also called, also called model model or or businessbusiness classes, are classes, are

extracted directly from the statement of the problem (e.g., extracted directly from the statement of the problem (e.g., FloorPlan and Sensor). FloorPlan and Sensor).

Boundary classesBoundary classes are used to create the interface (e.g., are used to create the interface (e.g., interactive screen or printed reports) that the user sees and interactive screen or printed reports) that the user sees and interacts with as the software is used. interacts with as the software is used.

Controller classesController classes manage a “unit of work” [UML03] from start manage a “unit of work” [UML03] from start to finish. That is, controller classes can be designed to manage to finish. That is, controller classes can be designed to manage the creation or update of entity objects; the creation or update of entity objects; the instantiation of boundary objects as they obtain information the instantiation of boundary objects as they obtain information

from entity objects; from entity objects; complex communication between sets of objects; complex communication between sets of objects; validation of data communicated between objects or between the validation of data communicated between objects or between the

user and the application. user and the application.


ResponsibilitiesResponsibilities

System intelligence should be distributed across System intelligence should be distributed across classes to best address the needs of the problemclasses to best address the needs of the problem

Each responsibility should be stated as generally Each responsibility should be stated as generally as possibleas possible

Information and the behavior related to it should Information and the behavior related to it should reside within the same classreside within the same class

Information about one thing should be localized Information about one thing should be localized with a single class, not distributed across with a single class, not distributed across multiple classes.multiple classes.

Responsibilities should be shared among related Responsibilities should be shared among related classes, when appropriate. classes, when appropriate.


CollaborationsCollaborations

Classes fulfill their responsibilities in one of two ways:Classes fulfill their responsibilities in one of two ways: A class can use its own operations to manipulate its own A class can use its own operations to manipulate its own

attributes, thereby fulfilling a particular responsibility, or attributes, thereby fulfilling a particular responsibility, or a class can collaborate with other classes.a class can collaborate with other classes.

Collaborations identify relationships between classesCollaborations identify relationships between classes Collaborations are identified by determining whether a Collaborations are identified by determining whether a

class can fulfill each responsibility itselfclass can fulfill each responsibility itself three different generic relationships between classes three different generic relationships between classes

[WIR90]: [WIR90]: the the is-part-ofis-part-of relationshiprelationship the the has-knowledge-ofhas-knowledge-of relationship relationship the the depends-upondepends-upon relationshiprelationship


Composite Aggregate Composite Aggregate ClassClass

Player

PlayerHead PlayerArms PlayerLegsPlayerBody


Reviewing the CRC ModelReviewing the CRC Model All participants in the review (of the CRC model) are given a subset of the CRC All participants in the review (of the CRC model) are given a subset of the CRC

model index cards.model index cards. Cards that collaborate should be separated (i.e., no reviewer should have two cards that Cards that collaborate should be separated (i.e., no reviewer should have two cards that

collaborate).collaborate). All use-case scenarios (and corresponding use-case diagrams) should be All use-case scenarios (and corresponding use-case diagrams) should be

organized into categoriesorganized into categories.. The review leader reads the use-case deliberatelyThe review leader reads the use-case deliberately..

As the review leader comes to a named object, she passes a token to the person holding As the review leader comes to a named object, she passes a token to the person holding the corresponding class index card.the corresponding class index card.

When the token is passed, the holder of the class card is asked to describe the When the token is passed, the holder of the class card is asked to describe the responsibilities noted on the cardresponsibilities noted on the card.. The group determines whether one (or more) of the responsibilities satisfies the use-The group determines whether one (or more) of the responsibilities satisfies the use-

case requirement.case requirement. If the responsibilities and collaborations noted on the index cards cannot If the responsibilities and collaborations noted on the index cards cannot

accommodate the use-case, modifications are made to the cardsaccommodate the use-case, modifications are made to the cards.. This may include the definition of new classes (and corresponding CRC index cards) or This may include the definition of new classes (and corresponding CRC index cards) or

the specification of new or revised responsibilities or collaborations on existing cards.the specification of new or revised responsibilities or collaborations on existing cards.


Associations and Associations and DependenciesDependencies

Two analysis classes are often related to one Two analysis classes are often related to one another in some fashionanother in some fashion In UML these relationships are called In UML these relationships are called associationsassociations Associations can be refined by indicatingAssociations can be refined by indicating multiplicitymultiplicity

(the term (the term cardinalitycardinality is used in data modelingis used in data modeling In many instances, a client-server relationship In many instances, a client-server relationship

exists between two analysis classes. exists between two analysis classes. In such cases, a client-class depends on the server-class In such cases, a client-class depends on the server-class

in some way and a in some way and a dependency relationshipdependency relationship is is establishedestablished


MultiplicityMultiplicity

WallSegment Window Door

Wall

is used to buildis used to build

is used to build1..*

1 1 1

0..* 0..*


DependenciesDependencies

CameraDisplayWindow

{password}

<<access>>


Analysis PackagesAnalysis Packages

Various elements of the analysis model (e.g., use-Various elements of the analysis model (e.g., use-cases, analysis classes) are categorized in a cases, analysis classes) are categorized in a manner that packages them as a groupingmanner that packages them as a grouping

The plus sign preceding the analysis class name The plus sign preceding the analysis class name in each package indicates that the classes have in each package indicates that the classes have public visibility and are therefore accessible from public visibility and are therefore accessible from other packages.other packages.

Other symbols can precede an element within a Other symbols can precede an element within a package. A minus sign indicates that an element package. A minus sign indicates that an element is hidden from all other packages and a # symbol is hidden from all other packages and a # symbol indicates that an element is accessible only to indicates that an element is accessible only to packages contained within a given package.packages contained within a given package.


Analysis PackagesAnalysis PackagesEnvironment

+Tree+Landscape+Road+Wall+Bridge+Building+VisualEffect+Scene

Characters

+Player+Protagonist+Antagonist+SupportingRole

RulesOfTheGame

+RulesOfMovement+ConstraintsOnAction

package name


Behavioral ModelingBehavioral Modeling

The behavioral model indicates how software will respond The behavioral model indicates how software will respond to external events or stimuli. To create the model, the to external events or stimuli. To create the model, the analyst must perform the following steps:analyst must perform the following steps:

Evaluate all use-cases to fully understand the sequence of Evaluate all use-cases to fully understand the sequence of interaction within the system.interaction within the system.

Identify events that drive the interaction sequence and understand Identify events that drive the interaction sequence and understand how these events relate to specific objects.how these events relate to specific objects.

Create a sequence for each use-case.Create a sequence for each use-case. Build a state diagram for the system.Build a state diagram for the system. Review the behavioral model to verify accuracy and consistency.Review the behavioral model to verify accuracy and consistency.


State RepresentationsState Representations

In the context of behavioral modeling, two different In the context of behavioral modeling, two different characterizations of states must be considered: characterizations of states must be considered: the state of each class as the system performs its function the state of each class as the system performs its function

andand the state of the system as observed from the outside as the the state of the system as observed from the outside as the

system performs its functionsystem performs its function The state of a class takes on both passive and active The state of a class takes on both passive and active

characteristics [CHA93]. characteristics [CHA93]. A A passive statepassive state is simply the current status of all of an is simply the current status of all of an

object’s attributes.object’s attributes. The The active stateactive state of an object indicates the current status of of an object indicates the current status of

the object as it undergoes a continuing transformation or the object as it undergoes a continuing transformation or processing. processing.


State Diagram for the ControlPanel State Diagram for the ControlPanel ClassClass

reading

locked

selecting

passwordentered

comparing

password = incorrect& numberOfTries < maxTries

password = correct

activation successful

key hit

do: validatePassword

numberOfTries > maxTries

timer < lockedTime

timer > lockedTime


The States of a SystemThe States of a System statestate—a set of observable circum-—a set of observable circum-

stances that characterizes the stances that characterizes the behavior of a system at a given timebehavior of a system at a given time

state transitionstate transition—the movement —the movement from one state to anotherfrom one state to another

eventevent—an occurrence that causes —an occurrence that causes the system to exhibit some the system to exhibit some predictable form of behaviorpredictable form of behavior

actionaction—process that occurs as a —process that occurs as a consequence of making a transitionconsequence of making a transition


Behavioral ModelingBehavioral Modeling

make a list of the different states of a make a list of the different states of a system (How does the system system (How does the system behave?)behave?)

indicate how the system makes a indicate how the system makes a transition from one state to another transition from one state to another (How does the system change state?)(How does the system change state?) indicate eventindicate event indicate actionindicate action

draw a draw a state diagram or a sequence state diagram or a sequence diagramdiagram


Sequence DiagramSequence Diagram

homeowner control panel sensorssystem sensors

systemready

reading

request lookupcomparing

result

password entered

password = correctrequest activation


lockednumberOfTries > maxTries

selecting

timer > lockedTimeA

A

Figure 8.27 Sequence diagram (partial) for SafeHome security function



Writing the Software Writing the Software SpecificationSpecification

Everyone knew exactly what had to be done until someone wrote it down!


Specification Specification GuidelinesGuidelinesuse a layered format that provides increasing detail

as the "layers" deepen

use consistent graphical notation and apply textual terms consistently (stay away from aliases)

be sure to define all acronyms

be sure to include a table of contents; ideally, include an index and/or a glossary

write in a simple, unambiguous style (see "editing suggestions" on the following pages)

always put yourself in the reader's position, "Would I be able to understand this if I wasn't intimately familiar with the system?"


Specification Specification GuidelinesGuidelinesBe on the lookout for persuasive connectors, ask why?

keys: certainly, therefore, clearly, obviously, it follows that ...

Watch out for vague terms keys: some, sometimes, often, usually,ordinarily, most, mostly ...

When lists are given, but not completed, be sure all items are understood keys: etc., and so forth, and so on, such as

Be sure stated ranges don't contain unstated assumptions e.g., Valid codes range from 10 to 100. Integer? Real? Hex?

Beware of vague verbs such as handled, rejected, processed, ...

Beware "passive voice" statements e.g., The parameters are initialized. By what?

Beware "dangling" pronouns e.g., The I/O module communicated with the data validation module and its contol flag is set. Whose control flag?


Specification Specification GuidelinesGuidelines

When a term is explicitly defined in one place, try substituting the definition forother occurrences of the term

When a structure is described in words, draw a picture

When a structure is described with a picture, try to redraw the picture to emphasize different elements of the structure

When symbolic equations are used, try expressing their meaning in words

When a calculation is specified, work at least two examples

Look for statements that imply certainty, then ask for proof keys; always, every, all, none, never

Search behind certainty statements—be sure restrictions or limitations are realistic



Chapter 9Chapter 9Design EngineeringDesign Engineering

copyright © 1996, 2001, 2005





Analysis Model -> Design Analysis Model -> Design ModelModel

Analysis Model

use-cases - textuse-case diagramsactivity diagramsswim lane diagrams

data flow diagramscontrol-flow diagramsprocessing narratives

flow-orientedelements

behavioralelements

class-basedelements

scenario-basedelements

class diagramsanalysis packagesCRC modelscollaboration diagrams

state diagramssequence diagrams

Data/Class Design

Architectural Design

Interface Design

Component-Level Design

Design Model


Design and QualityDesign and Quality

the design must implement all of the explicit the design must implement all of the explicit requirementsrequirements contained in the analysis model, and contained in the analysis model, and it must accommodate all of the implicit it must accommodate all of the implicit requirements desired by the customer.requirements desired by the customer.

the design must be a readable, understandable the design must be a readable, understandable guideguide for those who generate code and for those for those who generate code and for those who test and subsequently support the software.who test and subsequently support the software.

the design should provide a complete picture of the design should provide a complete picture of the softwarethe software, addressing the data, functional, and , addressing the data, functional, and behavioral domains from an implementation behavioral domains from an implementation perspective.perspective.


Quality GuidelinesQuality Guidelines A design should exhibit an architectureA design should exhibit an architecture that (1) has been created using recognizable that (1) has been created using recognizable

architectural styles or patterns, (2) is composed of components that exhibit good architectural styles or patterns, (2) is composed of components that exhibit good design characteristics and (3) can be implemented in an evolutionary fashiondesign characteristics and (3) can be implemented in an evolutionary fashion For smaller systems, design can sometimes be developed linearly.For smaller systems, design can sometimes be developed linearly.

A design should be modularA design should be modular; that is, the software should be logically partitioned into ; that is, the software should be logically partitioned into elements or subsystemselements or subsystems

A design should contain distinct representationsA design should contain distinct representations of data, architecture, interfaces, and of data, architecture, interfaces, and components.components.

A design should lead to data structures that are appropriateA design should lead to data structures that are appropriate for the classes to be for the classes to be implemented and are drawn from recognizable data patterns.implemented and are drawn from recognizable data patterns.

A design should lead to components that exhibit independent functional characteristicsA design should lead to components that exhibit independent functional characteristics.. A design should lead to interfaces that reduce the complexityA design should lead to interfaces that reduce the complexity of connections between of connections between

components and with the external environment.components and with the external environment. A design should be derived using a repeatable methodA design should be derived using a repeatable method that is driven by information that is driven by information

obtained during software requirements analysis.obtained during software requirements analysis. A design should be represented using a notation that effectively communicates its A design should be represented using a notation that effectively communicates its

meaningmeaning..


Design Design PrinciplesPrinciples The design process should not suffer from ‘tunnel vision.’ The design process should not suffer from ‘tunnel vision.’

The design should be traceable to the analysis model. The design should be traceable to the analysis model. The design should not reinvent the wheel. The design should not reinvent the wheel. The design should “minimize the intellectual distance” [DAV95] The design should “minimize the intellectual distance” [DAV95]

between the software and the problem as it exists in the real between the software and the problem as it exists in the real world. world.

The design should exhibit uniformity and integration. The design should exhibit uniformity and integration. The design should be structured to accommodate change. The design should be structured to accommodate change. The design should be structured to degrade gently, even when The design should be structured to degrade gently, even when

aberrant data, events, or operating conditions are encountered. aberrant data, events, or operating conditions are encountered. Design is not coding, coding is not design. Design is not coding, coding is not design. The design should be assessed for quality as it is being created, The design should be assessed for quality as it is being created,

not after the fact. not after the fact. The design should be reviewed to minimize conceptual The design should be reviewed to minimize conceptual

(semantic) errors.(semantic) errors.From Davis [DAV95]


Fundamental Fundamental ConceptsConcepts

abstractionabstraction—data, procedure, control—data, procedure, control architecturearchitecture—the overall structure of the software—the overall structure of the software patternspatterns—”conveys the essence” of a proven design solution—”conveys the essence” of a proven design solution modularitymodularity—compartmentalization of data and function—compartmentalization of data and function hidinghiding—controlled interfaces—controlled interfaces Functional independenceFunctional independence—single-minded function and low —single-minded function and low

couplingcoupling refinementrefinement—elaboration of detail for all abstractions—elaboration of detail for all abstractions RefactoringRefactoring—a reorganization technique that simplifies the —a reorganization technique that simplifies the

designdesign


Data Data AbstractionAbstraction

doordoor

implemented as a data structure

manufacturermanufacturermodel numbermodel numbertypetypeswing directionswing directioninsertsinsertslightslights typetype numbernumberweightweightopening mechanismopening mechanism


Procedural Procedural AbstractionAbstraction

openopen

implemented with a "knowledge" of the object that is associated with enter

details of enter details of enter algorithmalgorithm


ArchitectureArchitecture““The overall structure of the software and the The overall structure of the software and the ways in which that structure provides ways in which that structure provides conceptual integrity for a system.” [SHA95a]conceptual integrity for a system.” [SHA95a]

Structural properties.Structural properties. This aspect of the architectural design This aspect of the architectural design representation defines the components of a system (e.g., modules, representation defines the components of a system (e.g., modules, objects, filters) and the manner in which those components are objects, filters) and the manner in which those components are packaged and interact with one another. For example, objects are packaged and interact with one another. For example, objects are packaged to encapsulate both data and the processing that packaged to encapsulate both data and the processing that manipulates the data and interact via the invocation of methods manipulates the data and interact via the invocation of methods Extra-functional properties.Extra-functional properties. The architectural design description The architectural design description should address how the design architecture achieves requirements should address how the design architecture achieves requirements for performance, capacity, reliability, security, adaptability, and for performance, capacity, reliability, security, adaptability, and other system characteristics.other system characteristics.Families of related systems.Families of related systems. The architectural design should draw The architectural design should draw upon repeatable patterns that are commonly encountered in the upon repeatable patterns that are commonly encountered in the design of families of similar systems. In essence, the design should design of families of similar systems. In essence, the design should

have the ability to reuse architectural building blocks.have the ability to reuse architectural building blocks.


PatternsPatternsDesign Pattern TemplateDesign Pattern TemplatePattern namePattern name—describes the essence of the pattern in a short but —describes the essence of the pattern in a short but expressive name expressive name

IntentIntent—describes the pattern and what it does—describes the pattern and what it does

Also-known-asAlso-known-as—lists any synonyms for the pattern—lists any synonyms for the pattern

MotivationMotivation—provides an example of the problem —provides an example of the problem

ApplicabilityApplicability—notes specific design situations in which the pattern is —notes specific design situations in which the pattern is applicableapplicable

StructureStructure—describes the classes that are required to implement the —describes the classes that are required to implement the patternpattern

ParticipantsParticipants—describes the responsibilities of the classes that are —describes the responsibilities of the classes that are required to implement the patternrequired to implement the pattern

CollaborationsCollaborations—describes how the participants collaborate to carry out —describes how the participants collaborate to carry out their responsibilitiestheir responsibilities

ConsequencesConsequences—describes the “design forces” that affect the pattern and —describes the “design forces” that affect the pattern and the potential trade-offs that must be considered when the pattern is the potential trade-offs that must be considered when the pattern is implementedimplemented

Related patternsRelated patterns—cross-references related design patterns—cross-references related design patterns


Modular Modular DesignDesigneasier to build, easier to change, easier to fix ...


Modularity: Trade-Modularity: Trade-offsoffsWhat is the "right" number of modules What is the "right" number of modules

for a specific software design?for a specific software design?

optimal numberoptimal number of modulesof modules

cost ofcost of softwaresoftware

number of modulesnumber of modules

modulemoduleintegrationintegration

costcost

module development cost module development cost


Information HidingInformation Hiding

modulemodulecontrolledcontrolledinterfaceinterface

"secret""secret"

• • algorithmalgorithm

• • data structuredata structure

• • details of external interfacedetails of external interface

• • resource allocation policyresource allocation policy

clientsclients

a specific design decisiona specific design decision


Why Information Why Information Hiding?Hiding?

reduces the likelihood of “side reduces the likelihood of “side effects”effects”

limits the global impact of local limits the global impact of local design decisionsdesign decisions

emphasizes communication through emphasizes communication through controlled interfacescontrolled interfaces

discourages the use of global datadiscourages the use of global data leads to encapsulation—an attribute leads to encapsulation—an attribute

of high quality designof high quality design results in higher quality softwareresults in higher quality software


Stepwise Stepwise RefinementRefinementopen

walk to door;reach for knob;

open door;

walk through;close door.

repeat until door opensturn knob clockwise;if knob doesn't turn, then take key out; find correct key; insert in lock;endifpull/push doormove out of way;end repeat


Functional Functional IndependenceIndependence

COHESION - the degree to which amodule performs one and only onefunction.

COUPLING - the degree to which amodule is "connected" to othermodules in the system.


Sizing Modules: Two Sizing Modules: Two ViewsViews

MODULE

What'sinside??

How bigis it??


RefactoringRefactoring Fowler [FOW99] defines refactoring in the following

manner: "Refactoring is the process of changing a software

system in such a way that it does not alter the external behavior of the code [design] yet improves its internal structure.”

When software is refactored, the existing design is examined for redundancy unused design elements inefficient or unnecessary algorithms poorly constructed or inappropriate data structures or any other design failure that can be corrected to

yield a better design.


OO Design ConceptsOO Design Concepts Design classesDesign classes

Entity classesEntity classes Boundary classesBoundary classes Controller classesController classes

InheritanceInheritance—all responsibilities of a superclass —all responsibilities of a superclass is immediately inherited by all subclassesis immediately inherited by all subclasses

MessagesMessages—stimulate some behavior to occur in —stimulate some behavior to occur in the receiving objectthe receiving object

PolymorphismPolymorphism—a characteristic that greatly —a characteristic that greatly reduces the effort required to extend the reduces the effort required to extend the designdesign


Design ClassesDesign Classes Analysis classes are refined during design to become Analysis classes are refined during design to become entity entity

classesclasses Boundary classesBoundary classes are developed during design to create the are developed during design to create the

interface (e.g., interactive screen or printed reports) that interface (e.g., interactive screen or printed reports) that the user sees and interacts with as the software is used. the user sees and interacts with as the software is used. Boundary classes are designed with the responsibility of Boundary classes are designed with the responsibility of

managing the way entity objects are represented to users. managing the way entity objects are represented to users. Controller classeController classess are designed to manage are designed to manage

the creation or update of entity objects; the creation or update of entity objects; the instantiation of boundary objects as they obtain the instantiation of boundary objects as they obtain

information from entity objects; information from entity objects; complex communication between sets of objects; complex communication between sets of objects; validation of data communicated between objects or between validation of data communicated between objects or between

the user and the application.the user and the application.


InheritanceInheritance

Design options:Design options: The class can be designed and built from scratch. That is, The class can be designed and built from scratch. That is,

inheritance is not used.inheritance is not used. The class hierarchy can be searched to determine if a The class hierarchy can be searched to determine if a

class higher in the hierarchy (a superclass)contains most class higher in the hierarchy (a superclass)contains most of the required attributes and operations. The new class of the required attributes and operations. The new class inherits from the superclass and additions may then be inherits from the superclass and additions may then be added, as required.added, as required.

The class hierarchy can be restructured so that the The class hierarchy can be restructured so that the required attributes and operations can be inherited by required attributes and operations can be inherited by the new class.the new class.

Characteristics of an existing class can be overridden and Characteristics of an existing class can be overridden and different versions of attributes or operations are different versions of attributes or operations are implemented for the new class.implemented for the new class.


MessageMessagess

:SenderObject

:ReceiverObject

message (<parameters>)


PolymorphismPolymorphism

case of graphtype:case of graphtype:

if graphtype = linegraph then DrawLineGraph (data);if graphtype = linegraph then DrawLineGraph (data);

if graphtype = piechart then DrawPieChart (data);if graphtype = piechart then DrawPieChart (data);

if graphtype = histogram then DrawHisto (data);if graphtype = histogram then DrawHisto (data);

if graphtype = kiviat then DrawKiviat (data);if graphtype = kiviat then DrawKiviat (data);

end case;end case;

All of the graphs become subclasses of a general class All of the graphs become subclasses of a general class called graph. Using a concept called overloading [TAY90], called graph. Using a concept called overloading [TAY90], each subclass defines an operation called each subclass defines an operation called drawdraw. An object . An object can send a can send a drawdraw message to any one of the objects message to any one of the objects instantiated from any one of the subclasses. The object instantiated from any one of the subclasses. The object receiving the message will invoke its own receiving the message will invoke its own drawdraw operation operation to create the appropriate graph. to create the appropriate graph.

graphtype drawgraphtype draw

ConventionalConventional approach …approach …


The Design ModelThe Design Model

process dimension

architectureelements

interfaceelements

component-levelelements

deployment-levelelements

low

high


use-cases - textuse-case diagramsactivity diagramsswim lane diagramscollaboration diagrams data flow diagrams

control-flow diagramsprocessing narratives

data flow diagramscontrol-flow diagramsprocessing narratives



design class realizationssubsystemscollaboration diagrams

design class realizationssubsystemscollaboration diagrams

refinements to:

deployment diagrams


component diagramsdesign classesactivity diagramssequence diagrams

refinements to:component diagramsdesign classesactivity diagramssequence diagrams

design class realizationssubsystemscollaboration diagramscomponent diagramsdesign classesactivity diagramssequence diagrams

analysis model

design model

Requirements: constraints interoperability targets and configuration

technical interface designNavigation designGUI design


Design Model ElementsDesign Model Elements Data elementsData elements

Data model --> data structuresData model --> data structures Data model --> database architectureData model --> database architecture

Architectural elementsArchitectural elements Application domainApplication domain Analysis classes, their relationships, collaborations and behaviors Analysis classes, their relationships, collaborations and behaviors

are transformed into design realizationsare transformed into design realizations Patterns and “styles” (Chapter 10)Patterns and “styles” (Chapter 10)

Interface elementsInterface elements the user interface (UI) the user interface (UI) external interfaces to other systems, devices, networks or other external interfaces to other systems, devices, networks or other

producers or consumers of informationproducers or consumers of information internal interfaces between various design componentsinternal interfaces between various design components.

Component elementsComponent elements Deployment elementsDeployment elements


Interface ElementsInterface Elements

ControlPanel

LCDdisplayLEDindicatorskeyPadCharacteristicsspeakerwirelessInterface

readKeyStroke()decodeKey()displayStatus()lightLEDs()sendControlMsg()

Figure 9.6 UML interface representation for ControlPanel

KeyPad

readKeystroke()decodeKey()

<<interface>>

WirelessPDA

KeyPad

MobilePhone


Component ElementsComponent Elements

SensorManagementSensor


Deployment ElementsDeployment Elements

Figure 9.8 UML deployment diagram for SafeHome

Personal computer

Security

homeManagement

Surveillance

communication

Control Panel CPI server

Security homeownerAccess

externalAccess


Design PatternsDesign Patterns

The best designers in any field have an uncanny ability to The best designers in any field have an uncanny ability to see patterns that characterize a problem and see patterns that characterize a problem and corresponding patterns that can be combined to create a corresponding patterns that can be combined to create a solutionsolution

A description of a design pattern may also consider a set of A description of a design pattern may also consider a set of design forces. design forces. Design forcesDesign forces describe non-functional requirements (e.g., describe non-functional requirements (e.g.,

ease of maintainability, portability) associated the software for ease of maintainability, portability) associated the software for which the pattern is to be applied. which the pattern is to be applied.

The The pattern characteristicspattern characteristics (classes, responsibilities, and (classes, responsibilities, and collaborations) indicate the attributes of the design that collaborations) indicate the attributes of the design that may be adjusted to enable the pattern to accommodate a may be adjusted to enable the pattern to accommodate a variety of problems.variety of problems.


FrameworksFrameworks

A A framework framework is not an architectural pattern, but is not an architectural pattern, but rather a skeleton with a collection of “plug rather a skeleton with a collection of “plug points” (also called points” (also called hookshooks and and slotsslots) that enable ) that enable it to be adapted to a specific problem domain. it to be adapted to a specific problem domain.

Gamma et al note that:Gamma et al note that: Design patterns are more abstract than frameworks.Design patterns are more abstract than frameworks. Design patterns are smaller architectural elements than Design patterns are smaller architectural elements than

frameworksframeworks Design patterns are less specialized than frameworksDesign patterns are less specialized than frameworks



Chapter 10Chapter 10Architectural DesignArchitectural Design

copyright © 1996, 2001, 2005





Why Architecture?Why 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 easy, when making design changes is still relatively easy, and and

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


Why is Architecture Why is Architecture Important?Important?

Representations of software architecture are an enablerRepresentations of software architecture are an enabler for communication between all parties (stakeholders) for communication between all parties (stakeholders) interested in the development of a computer-based system.interested in the development of a computer-based system.

The architecture highlights early design decisionsThe architecture highlights early design decisions that will that will have a profound impact on all software engineering work have a profound impact on all software engineering work that follows and, as important, on the ultimate success of that follows and, as important, on the ultimate success of the system as an operational entity.the system as an operational entity.

Architecture “constitutes a relatively small, intellectually Architecture “constitutes a relatively small, intellectually graspable modelgraspable model of how the system is structured and how of how the system is structured and how its components work together” [BAS03].its components work together” [BAS03].


Data DesignData Design

At the architectural level …At the architectural level … Design of one or more databases to support the Design of one or more databases to support the

application architectureapplication architecture Design of methods for ‘Design of methods for ‘miningmining’ the content of multiple ’ the content of multiple

databasesdatabases navigate through existing databases in an attempt to navigate through existing databases in an attempt to

extract appropriate business-level informationextract appropriate business-level information Design of a Design of a data warehousedata warehouse—a large, independent —a large, independent

database that has access to the data that are stored in database that has access to the data that are stored in databases that serve the set of applications required by a databases that serve the set of applications required by a businessbusiness


Data Data DesignDesign At the component level …At the component level …

refine data objects and develop a set of data refine data objects and develop a set of data abstractionsabstractions

implement data object attributes as one or implement data object attributes as one or more data structuresmore data structures

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

simplify data structures as requiredsimplify data structures as required


Data Design—Component Data Design—Component LevelLevel

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


Architectural StylesArchitectural Styles

Data-centered architecturesData-centered architectures Data flow architecturesData flow architectures Call and return architecturesCall and return architectures Object-oriented architecturesObject-oriented architectures Layered architecturesLayered architectures

Each style describes a system category that encompasses: (1) a Each style describes a system category that encompasses: (1) a set of componentsset of components (e.g., a database, computational modules) (e.g., a database, computational modules) that perform a function required by a system, (2) a that perform a function required by a system, (2) a set of set of connectorsconnectors that enable “communication, coordination and that enable “communication, coordination and cooperation” among components, (3) cooperation” among components, (3) constraintsconstraints that define that define how components can be integrated to form the system, and (4) how components can be integrated to form the system, and (4) semantic modelssemantic models that enable a designer to understand the that enable a designer to understand the overall properties of a system by analyzing the known overall properties of a system by analyzing the known properties of its constituent parts. properties of its constituent parts.


Data-Centered ArchitectureData-Centered Architecture


Data Flow ArchitectureData Flow Architecture


Call and Return ArchitectureCall and Return Architecture


Layered ArchitectureLayered Architecture


Architectural PatternsArchitectural Patterns ConcurrencyConcurrency—applications must handle multiple tasks in a —applications must handle multiple tasks in a

manner that simulates parallelism manner that simulates parallelism operating system process managementoperating system process management patternpattern task schedulertask scheduler pattern pattern

PersistencePersistence—Data persists if it survives past the execution of —Data persists if it survives past the execution of the process that created it. Two patterns are common: the process that created it. Two patterns are common: a a database management systemdatabase management system pattern that applies the storage pattern that applies the storage

and retrieval capability of a DBMS to the application architectureand retrieval capability of a DBMS to the application architecture an an application levelapplication level persistencepersistence pattern that builds persistence pattern that builds persistence

features into the application architecturefeatures into the application architecture DistributionDistribution— the manner in which systems or components — the manner in which systems or components

within systems communicate with one another in a distributed within systems communicate with one another in a distributed environmentenvironment AA brokerbroker acts as a ‘middle-man’ between the client component and acts as a ‘middle-man’ between the client component and

a server component.a server component.


Architectural DesignArchitectural Design

The software must be placed into contextThe software must be placed into context the design should define the external entities (other the design should define the external entities (other

systems, devices, people) that the software interacts systems, devices, people) that the software interacts with and the nature of the interactionwith and the nature of the interaction

A set of architectural archetypes should be A set of architectural archetypes should be identifiedidentified AnAn archetypearchetype is an abstraction (similar to a class) that is an abstraction (similar to a class) that

represents one element of system behaviorrepresents one element of system behavior The designer specifies the structure of the The designer specifies the structure of the

system by defining and refining software system by defining and refining software components that implement each archetypecomponents that implement each archetype


Architectural ContextArchitectural Context

target system:Security Function

uses

uses peershomeowner

SafehomeProduct

Internet-basedsystem

surveillancefunction

sensors

controlpanel

sensors

uses


ArchetypesArchetypes

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

Controller

Node

communicates with

Detector Indicator


Component StructureComponent StructureSafeHomeExecutive

ExternalCommunicationManagement

GUI InternetInterface

Functionselection

Security Surveillance Homemanagement

Controlpanel

processing

detectormanagement

alarmprocessing


Refined Component Refined Component StructureStructure

sensorsensorsensorsensorsensorsensorsensorsensor

ExternalCommunicationManagement

GUI InternetInterface

Security

Controlpanel

processing

detectormanagement

alarmprocessing

Keypadprocessing

CP displayfunctions

scheduler

sensorsensorsensorsensor

phonecommunication

alarm

SafeHomeExecutive


Analyzing Architectural Analyzing Architectural DesignDesign

1. Collect scenarios. 1. Collect scenarios. 2. Elicit requirements, constraints, and environment 2. Elicit requirements, constraints, and environment description. description. 3. Describe the architectural styles/patterns that have 3. Describe the architectural styles/patterns that have been chosen to address the scenarios and requirements:been chosen to address the scenarios and requirements:

• • module viewmodule view• • process viewprocess view• • data flow viewdata flow view

4. Evaluate quality attributes by considered each 4. Evaluate quality attributes by considered each attribute in isolation. attribute in isolation. 5. Identify the sensitivity of quality attributes to various 5. Identify the sensitivity of quality attributes to various architectural attributes for a specific architectural style. architectural attributes for a specific architectural style. 6. Critique candidate architectures (developed in step 3) 6. Critique candidate architectures (developed in step 3) using the sensitivity analysis conducted in step 5.using the sensitivity analysis conducted in step 5.


An Architectural Design An Architectural Design MethodMethod

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

customer requirements

architectural design


Deriving Program Deriving Program ArchitectureArchitecture

ProgramProgramArchitectureArchitecture


Partitioning the Partitioning the ArchitectureArchitecture

““horizontal” and “vertical” horizontal” and “vertical” partitioning are requiredpartitioning are required


Horizontal PartitioningHorizontal Partitioning

define separate branches of the module define separate branches of the module hierarchy for each major functionhierarchy for each major function

use control modules to coordinate use control modules to coordinate communication between functionscommunication between functions

function 1function 1 function 3function 3

function 2function 2


Vertical Partitioning:Vertical Partitioning:FactoringFactoring

design so that decision making and work design so that decision making and work are stratifiedare stratified

decision making modules should reside at decision making modules should reside at the top of the architecturethe top of the architecture

workersworkers

decision-makersdecision-makers


Why Partitioned Why Partitioned Architecture?Architecture?

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


Structured DesignStructured Design

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

approach:approach: the DFD is mapped into a program the DFD is mapped into a program

architecturearchitecture the PSPEC and STD are used to the PSPEC and STD are used to

indicate the content of each moduleindicate the content of each module notation:notation: structure chart structure chart


Flow Flow CharacteristicsCharacteristics

Transform flow

Transactionflow


General Mapping General Mapping ApproachApproach

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 Transform MappingMapping

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


FactoriFactoringng

typical "worker" modules

typical "decision making" modules

direction of increasingdecision making


First Level First Level FactoringFactoring

main programcontroller

inputcontroller

processingcontroller

outputcontroller


Second Level Second Level MappingMapping

DC

B A

A

CB

Dmapping from theflow boundary outward

main

control


Transaction Transaction FlowFlow

T

incoming flow

action path


Transaction Transaction ExampleExample

operatorcommands

processoperator commands

fixture setting

report

robot control

fixtureservos

displayscreen

robotcontrolsoftware

in reality, other commandswould also be shown

assemblyrecord


Refining the Analysis Refining the Analysis ModelModelwrite an English language processing narrative write an English language processing narrative

for the level 01 flow modelfor the level 01 flow model

apply noun/verb parse to isolate processes, data apply noun/verb parse to isolate processes, data items, store and entitiesitems, store and entities

develop level 02 and 03 flow modelsdevelop level 02 and 03 flow models

create corresponding data dictionary entriescreate corresponding data dictionary entries

refine flow models as appropriaterefine flow models as appropriate

... now, we're ready to begin design!... now, we're ready to begin design!

1.1.

2.2.

3.3.

4.4.

5.5.


Deriving Deriving Level 1Level 1Processing narrative for " process operator commands"Processing narrative for " process operator commands"

Process operator command software reads operator commands from Process operator command software reads operator commands from the cell operator. An error message is displayed for invalid commands. the cell operator. An error message is displayed for invalid commands. The command type is determined for valid commands and appropriate The command type is determined for valid commands and appropriate action is taken. When fixture commands are encountered, fixture action is taken. When fixture commands are encountered, fixture status is analyzed and a fixture setting is output to the fixture servos. 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 When a report is selected, the assembly record file is read and a report is generated and displayed on the operator display screen. report is generated and displayed on the operator display screen. When robot control switches are selected, control values are sent to When robot control switches are selected, control values are sent to

the robot control system. the robot control system.

Processing narrative for " process operator commands"Processing narrative for " process operator commands"

Process operator command software Process operator command software readsreads operator operator commandscommands from from the cell the cell operatoroperator. An . An error messageerror message is is displayeddisplayed for for invalid commandsinvalid commands. . The The command typecommand type is is determineddetermined for for valid commandsvalid commands and appropriate and appropriate action is action is takentaken. When . When fixture commandsfixture commands are are encounteredencountered, , fixture fixture statusstatus is is analyzedanalyzed and a and a fixture settingfixture setting is is outputoutput to the to the fixture servosfixture servos. . When a When a reportreport is is selectedselected,, the the assembly record fileassembly record file is is readread and a and a report is report is generatedgenerated and and displayeddisplayed on the operator on the operator display screendisplay screen. . When When robot control switchesrobot control switches are are selectedselected, , control valuecontrol values s are are sentsent to to the the robot control system. robot control system.

noun-verbnoun-verbparseparse


Level 1 Data Flow Level 1 Data Flow DiagramDiagram

operator commands

readoperator

commands

determinecommand

type

analyzefixturestatus

generatereport

send controlvalue

fixtureservos

displayscreen

robotcontrol system

assemblyrecord

valid command

Error msg

fixture setting

report

robot control

fixture

select report

controlrobot

status


Level 2 Data Flow Level 2 Data Flow DiagramDiagram

read command

produce errormsg

validatecommand

determinetype

read fixturestatus

determinesetting

format setting

readrecord

calculateoutputvalues

formatreport

reportvalues

record

assemblyrecord

command

command invalid command

status

error msg

robot control

send controlvalue

start /stop

combined status

raw setting

fixture setting


Transaction Mapping Transaction Mapping PrinciplesPrinciplesisolate the incoming flow pathisolate the incoming flow path

define each of the action paths by looking for define each of the action paths by looking for the "spokes of the wheel"the "spokes of the wheel"

assess the flow on each action pathassess the flow on each action path

define the dispatch and control structuredefine the dispatch and control structure

map each action path flow individuallymap each action path flow individually


Transaction Transaction MappingMapping

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


Isolate Flow Isolate Flow PathsPaths

read command

produce errormsg

validatecommand

determinetype

read fixturestatus

determinesetting

format setting

readrecord


formatreport

reportvalues

record

assemblyrecord

command

command invalid command

status

error msg

robot control

send controlvalue

start /stop

combined status

raw setting

fixture setting


Map the Flow Map the Flow ModelModelprocess

operatorcommands

commandinput

controller

read command

validatecommand

produce error

message

determinetype

fixturestatus

controller

reportgenerationcontroller

sendcontrolvalue

each of the action paths must be expanded further


Refining the Structure Refining the Structure ChartChartprocessoperator

commands

commandinput

controller

read command

validatecommand

produce error

message

determinetype

sendcontrolvalue

read fixturestatus

determinesetting

formatsetting

read record


formatreport

fixturestatus

controller

reportgenerationcontroller



Chapter 11Chapter 11Component-Level DesignComponent-Level Design

copyright © 1996, 2001, 2005





What is a Component?What is a Component?

OMG Unified Modeling Language SpecificationOMG Unified Modeling Language Specification [OMG01] defines a component as [OMG01] defines a component as “… “… a modular, deployable, and replaceable part of a a modular, deployable, and replaceable part of a

system that encapsulates implementation and exposes a system that encapsulates implementation and exposes a set of interfaces.”set of interfaces.”

OO view: a component contains a set of OO view: a component contains a set of collaborating classescollaborating classes

Conventional view: logic, the internal data Conventional view: logic, the internal data structures that are required to implement the structures that are required to implement the processing logic, and an interface that enables processing logic, and an interface that enables the component to be invoked and data to be the component to be invoked and data to be passed to it.passed to it.


OO ComponentOO Component

PrintJob

computeJob

initiateJob

numberOfPagesnumberOfSidespaperType paperWeight paperSize paperColormagnificationcolorRequirementsproductionFeatures collationOptions bindingOptions coverStock bleed prioritytotalJobCostWOnumber

PrintJob

computePageCost ()computePaperCost()computeProdCost()computeTotalJobCost ()buildWorkOrder()checkPriority()passJobto Production()

elaborated design class<<interface>>computeJobcomputePageCost()computePaperCost()computeProdCost()computeTotalJobCost()

<<interface>>initiateJob

buildWorkOrder()checkPriority()passJobto Production()

design component

numberOfPagesnumberOfSidespaperTypemagnificationproductionFeatures

PrintJob

computeJobCost()passJobtoPrinter()

analysis class


Conventional ComponentConventional Component

ComputePageCost

design component

accessCostsDB

getJobData

elaborated module

PageCost

in: job sizein: color=1, 2, 3, 4in: pageSize = A, B, C, Bout: BPCout: SF

in: numberPagesin: numberDocsin: sides= 1, 2in: color=1, 2, 3, 4in: page size = A, B, C, Bout: page cost

job size (JS) = numberPages * numberDocs;lookup base page cost (BPC) --> accessCostsDB (JS, color);lookup size factor ( SF) --> accessCostDB (JS, color, size)job complexity factor (JCF) = 1 + [(sides-1)*sideCost + SF]pagecost = BPC * JCF

getJobData (numberPages, numberDocs,sides, color, pageSize, pageCost)accessCostsDB(jobSize, color, pageSize,BPC, SF)computePageCost()


Basic Design PrinciplesBasic Design Principles The Open-Closed Principle (OCP).The Open-Closed Principle (OCP). “A module [component] should “A module [component] should

be open for extension but closed for modification.be open for extension but closed for modification. The Liskov Substitution Principle (LSP).The Liskov Substitution Principle (LSP). “Subclasses should be “Subclasses should be

substitutable for their base classes.substitutable for their base classes. Dependency Inversion Principle (DIP).Dependency Inversion Principle (DIP). “Depend on abstractions. “Depend on abstractions.

Do not depend on concretions.”Do not depend on concretions.” The Interface Segregation Principle (ISP).The Interface Segregation Principle (ISP). “Many client-specific “Many client-specific

interfaces are better than one general purpose interface.interfaces are better than one general purpose interface. The Release Reuse Equivalency Principle (REP).The Release Reuse Equivalency Principle (REP). “The granule of “The granule of

reuse is the granule of release.”reuse is the granule of release.” The Common Closure Principle (CCP).The Common Closure Principle (CCP). “Classes that change “Classes that change

together belong together.” together belong together.” The Common Reuse Principle (CRP).The Common Reuse Principle (CRP). “Classes that aren’t reused “Classes that aren’t reused

together should not be grouped together.”together should not be grouped together.”

Source: Martin, R., “Design Principles and Design Patterns,” downloaded from Source: Martin, R., “Design Principles and Design Patterns,” downloaded from http:www.objectmentor.com, 2000.http:www.objectmentor.com, 2000.


Design GuidelinesDesign Guidelines

ComponentsComponents Naming conventions should be established for Naming conventions should be established for

components that are specified as part of the components that are specified as part of the architectural model and then refined and elaborated as architectural model and then refined and elaborated as part of the component-level modelpart of the component-level model

InterfacesInterfaces Interfaces provide important information about Interfaces provide important information about

communication and collaboration (as well as helping communication and collaboration (as well as helping us to achieve the OPC)us to achieve the OPC)

Dependencies and InheritanceDependencies and Inheritance it is a good idea to model dependencies from left to it is a good idea to model dependencies from left to

right and inheritance from bottom (derived classes) to right and inheritance from bottom (derived classes) to top (base classes).top (base classes).


CohesionCohesion Conventional view: Conventional view:

the “single-mindedness” of a modulethe “single-mindedness” of a module OO view: OO view:

cohesioncohesion implies that a component or class implies that a component or class encapsulates only attributes and operations that are encapsulates only attributes and operations that are closely related to one another and to the class or closely related to one another and to the class or component itselfcomponent itself

Levels of cohesionLevels of cohesion FunctionalFunctional LayerLayer CommunicationalCommunicational SequentialSequential ProceduralProcedural TemporalTemporal utilityutility


CouplingCoupling Conventional view: Conventional view:

The degree to which a component is connected to other The degree to which a component is connected to other components and to the external worldcomponents and to the external world

OO view:OO view: a qualitative measure of the degree to which classes are a qualitative measure of the degree to which classes are

connected to one anotherconnected to one another Level of couplingLevel of coupling

ContentContent CommonCommon ControlControl StampStamp DataData Routine callRoutine call Type useType use Inclusion or importInclusion or import ExternalExternal


Component Level Design-IComponent Level Design-I

Step 1. Identify all design classes that correspond Step 1. Identify all design classes that correspond to the problem domain. to the problem domain.

Step 2. Identify all design classes that correspond Step 2. Identify all design classes that correspond to the infrastructure domain.to the infrastructure domain.

Step 3. Elaborate all design classes that are not Step 3. Elaborate all design classes that are not acquired as reusable components.acquired as reusable components.

Step 3a. Specify message details when classes or Step 3a. Specify message details when classes or component collaborate. component collaborate.

Step 3b. Identify appropriate interfaces for each Step 3b. Identify appropriate interfaces for each component. component.


Component-Level Design-IIComponent-Level Design-II Step 3c. Elaborate attributes and define data types Step 3c. Elaborate attributes and define data types

and data structures required to implement them. and data structures required to implement them. Step 3d.Step 3d. Describe processing flow within each Describe processing flow within each

operation in detail.operation in detail. Step 4. Describe persistent data sources (databases Step 4. Describe persistent data sources (databases

and files) and identify the classes required to and files) and identify the classes required to manage them. manage them.

Step 5. Develop and elaborate behavioral Step 5. Develop and elaborate behavioral representations for a class or component. representations for a class or component.

Step 6. Elaborate deployment diagrams to provide Step 6. Elaborate deployment diagrams to provide additional implementation detail. additional implementation detail.

Step 7. Factor every component-level design Step 7. Factor every component-level design representation and always consider alternatives.representation and always consider alternatives.


Collaboration DiagramCollaboration Diagram

:ProductionJob

:WorkOrder

:JobQueue

1: buildJob (WOnumber)2: submitJob (WOnumber)


RefactoringRefactoring

PrintJob

computeJob

initiateJob

ProductionJob

buildJob

submitJob

WorkOrderappropriate attributes

buildWorkOrder ()getJobDescriiption

JobQueueappropriate attributes

checkPriority ()

<<interface>>initiateJob

passJobToProduction()


Activity DiagramActivity Diagram

validate attributesinput

accessPaperDB(weight)

returns baseCostperPage

size = B paperCostperPage =paperCostperPage*1.2

size = C paperCostperPage =paperCostperPage*1.4

size = D paperCostperPage =paperCostperPage*1.6

color is custom paperCostperPage = paperCostperPage*1.14

color is standard

paperCostperPage = baseCostperPage

returns(paperCostperPage)


StatechartStatechart

buildingJobDataentry/readJobData()exit/displayJobData()do/checkConsistency()include/dataInput

entry/computeJobexit/save totalJobCost

formingJobentry/buildJobexit/save WOnumberdo/

computingJobCost

submittingJobentry/submitJobexit/initiateJobdo/place on JobQueue

behavior within thestate buildingJobData

dataInputCompleted [all dataitems consistent]/displayUserOptions

dataInputIncomplete

jobCostAccepted [customer is authorized]/getElectronicSignature

jobSubmitted [all authorizations acquired]/printWorkOrder


Object Constraint Language Object Constraint Language (OCL)(OCL)

complements UML by allowing a software engineer to complements UML by allowing a software engineer to use a formal grammar and syntax to construct use a formal grammar and syntax to construct unambiguous statements about various design model unambiguous statements about various design model elementselements

simplest OCL language statements are constructed in simplest OCL language statements are constructed in four parts:four parts: (1) a (1) a contextcontext that defines the limited situation in which the that defines the limited situation in which the

statement is valid; statement is valid; (2) a (2) a propertyproperty that represents some characteristics of the that represents some characteristics of the

context (e.g., if the context is a class, a property might be context (e.g., if the context is a class, a property might be an attribute)an attribute)

(3) an (3) an operationoperation (e.g., arithmetic, set-oriented) that (e.g., arithmetic, set-oriented) that manipulates or qualifies a property, and manipulates or qualifies a property, and

(4)(4) keywords keywords (e.g., if, then, else, and, or, not, implies) that (e.g., if, then, else, and, or, not, implies) that are used to specify conditional expressions.are used to specify conditional expressions.


OCL ExampleOCL Example

contextcontext PrintJob::validate(upperCostBound PrintJob::validate(upperCostBound : Integer, custDeliveryReq :: Integer, custDeliveryReq : Integer)Integer) pre:pre: upperCostBound > 0 upperCostBound > 0 and custDeliveryReq > 0and custDeliveryReq > 0 and self.jobAuthorization = 'no'and self.jobAuthorization = 'no' post: ifpost: if self.totalJobCost <= self.totalJobCost <= upperCostBoundupperCostBound and self.deliveryDate <= and self.deliveryDate <= custDeliveryReqcustDeliveryReq thenthen self.jobAuthorization = 'yes'self.jobAuthorization = 'yes' endifendif


Algorithm DesignAlgorithm Design

the closest design activity to codingthe closest design activity to coding the approach:the approach:

review the design description for the review the design description for the componentcomponent

use stepwise refinement to develop use stepwise refinement to develop algorithmalgorithm

use structured programming to use structured programming to implement procedural logicimplement procedural logic

use ‘formal methods’ to prove logicuse ‘formal methods’ to prove logic


Stepwise RefinementStepwise Refinement

openopen

walk to door;walk to door;reach for knob;reach for knob;

open door;open door;

walk through;walk through;close door.close door.

repeat until door opensrepeat until door opensturn knob clockwise;turn knob clockwise;if knob doesn't turn, thenif knob doesn't turn, then take key out;take key out; find correct key;find correct key; insert in lock;insert in lock;endifendifpull/push doorpull/push doormove out of way;move out of way;end repeatend repeat


Algorithm Design ModelAlgorithm Design Model

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

options:options: graphical (e.g. flowchart, box diagram)graphical (e.g. flowchart, box diagram) pseudocode (e.g., PDL)pseudocode (e.g., PDL) ... choice of many ... choice of many

programming languageprogramming language decision tabledecision table conduct walkthrough to assess qualityconduct walkthrough to assess quality


Structured ProgrammingStructured Programmingfor Procedural Designfor Procedural Design

uses a limited set of logical constructs:uses a limited set of logical constructs: sequencesequence conditionalconditional — — if-then-else, select-caseif-then-else, select-case loopsloops — — do-while, repeat untildo-while, repeat until

leads to more readable, testable codeleads to more readable, testable code

important for achieving high quality, important for achieving high quality, but not enoughbut not enough

can be used in conjunction with ‘proof can be used in conjunction with ‘proof of correctness’of correctness’


A Structured Procedural A Structured Procedural DesignDesign

a

x1

x2b

3x

4

5

c

d

ef

g

x

x

add a condition Z,if true, exit the program


Decision TableDecision Table

Conditions

regular customer

silver customer

gold customer

special discount

Rules

no discount

apply 8 percent discount

apply 15 percent discount

apply additional x percent discount

T

F

T

T

T

T

T

F

1 3 5 64

F

T T

T

2

Rules


Program Design Language Program Design Language (PDL)(PDL)

if-then-else

if condition xthen process a;else process b;endif

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 Why Design Language?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



Chapter 12Chapter 12User Interface DesignUser Interface Design

copyright © 1996, 2001, 2005





Interface DesignInterface Design

Easy to use?Easy to use?

Easy to understand?Easy to understand?

Easy to learn?Easy to learn?


Interface DesignInterface Design

lack of consistencylack of consistencytoo much memorizationtoo much memorizationno guidance / helpno guidance / helpno context sensitivityno context sensitivitypoor responsepoor responseArcane/unfriendlyArcane/unfriendly

Typical Design ErrorsTypical Design Errors


Golden RulesGolden Rules

Place the user in controlPlace the user in control Reduce the user’s memory loadReduce the user’s memory load Make the interface consistentMake the interface consistent


Place the User in ControlPlace the User in ControlDefine interaction modes in a way that does not force Define interaction modes in a way that does not force a user into unnecessary or undesired actions. a user into unnecessary or undesired actions.

Provide for flexible interaction. Provide for flexible interaction.

Allow user interaction to be interruptible and Allow user interaction to be interruptible and undoable. undoable.

Streamline interaction as skill levels advance and Streamline interaction as skill levels advance and allow the interaction to be customized. allow the interaction to be customized.

Hide technical internals from the casual user. Hide technical internals from the casual user.

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


Reduce the User’s Memory LoadReduce the User’s Memory Load

Reduce demand on short-term memory. Reduce demand on short-term memory.

Establish meaningful defaults. Establish meaningful defaults.

Define shortcuts that are intuitive. Define shortcuts that are intuitive.

The visual layout of the interface should be based on The visual layout of the interface should be based on a real world metaphor. a real world metaphor.

Disclose information in a progressive fashion.Disclose information in a progressive fashion.


Make the Interface Make the Interface ConsistentConsistent

Allow the user to put the current task into a Allow the user to put the current task into a meaningful context. meaningful context.

Maintain consistency across a family of Maintain consistency across a family of applications. applications.

If past interactive models have created user If past interactive models have created user expectations, do not make changes unless there is expectations, do not make changes unless there is a compelling reason to do so. a compelling reason to do so.


User Interface Design ModelsUser Interface Design Models

User modelUser model — a profile of all end users of — a profile of all end users of the systemthe system

Design modelDesign model — a design realization of the — a design realization of the user modeluser model

Mental model (system perception)Mental model (system perception) — the — the user’s mental image of what the interface isuser’s mental image of what the interface is

Implementation modelImplementation model — the interface — the interface “look and feel” coupled with supporting “look and feel” coupled with supporting information that describe interface syntax information that describe interface syntax and semanticsand semantics


User Interface Design ProcessUser Interface Design Process


Interface AnalysisInterface Analysis

Interface analysis means understanding Interface analysis means understanding (1) the people (end-users) who will interact with the (1) the people (end-users) who will interact with the

system through the interface;system through the interface; (2) the tasks that end-users must perform to do their (2) the tasks that end-users must perform to do their

work, work, (3) the content that is presented as part of the interface(3) the content that is presented as part of the interface (4) the environment in which these tasks will be (4) the environment in which these tasks will be

conductedconducted.


User AnalysisUser Analysis Are users trained professionals, technician, clerical, or manufacturing workers?Are users trained professionals, technician, clerical, or manufacturing workers? What level of formal education does the average user have?What level of formal education does the average user have? Are the users capable of learning from written materials or have they expressed a Are the users capable of learning from written materials or have they expressed a

desire for classroom training?desire for classroom training? Are users expert typists or keyboard phobic?Are users expert typists or keyboard phobic? What is the age range of the user community?What is the age range of the user community? Will the users be represented predominately by one gender?Will the users be represented predominately by one gender? How are users compensated for the work they perform? How are users compensated for the work they perform? Do users work normal office hours or do they work until the job is done?Do users work normal office hours or do they work until the job is done? Is the software to be an integral part of the work users do or will it be used only Is the software to be an integral part of the work users do or will it be used only

occasionally?occasionally? What is the primary spoken language among users?What is the primary spoken language among users? What are the consequences if a user makes a mistake using the system?What are the consequences if a user makes a mistake using the system? Are users experts in the subject matter that is addressed by the system?Are users experts in the subject matter that is addressed by the system? Do users want to know about the technology the sits behind the interface?Do users want to know about the technology the sits behind the interface?


Task Analysis and ModelingTask Analysis and Modeling Answers the following questions …Answers the following questions …

What work will the user perform in specific circumstances?What work will the user perform in specific circumstances? What tasks and subtasks will be performed as the user What tasks and subtasks will be performed as the user

does the work?does the work? What specific problem domain objects will the user What specific problem domain objects will the user

manipulate as work is performed?manipulate as work is performed? What is the sequence of work tasks—the workflow?What is the sequence of work tasks—the workflow? What is the hierarchy of tasks?What is the hierarchy of tasks?

Use-casesUse-cases define basic interaction define basic interaction Task elaborationTask elaboration refines interactive tasks refines interactive tasks Object elaborationObject elaboration identifies interface objects (classes) identifies interface objects (classes) Workflow analysisWorkflow analysis defines how a work process is defines how a work process is

completed when several people (and roles) are involvedcompleted when several people (and roles) are involved


Swimlane DiagramSwimlane Diagrampatient pharmacist physician

requests that aprescription be refilled

no refillsremaining

checks patientrecords

determines status ofprescription

refillsremaining

refill notallowed

approves refill

evaluates alternativemedication

none

receives request tocontact physician

alternativeavailable

checks inventory forrefill or alternative

out of stockreceives out of stocknotification

receives time/dateto pick up

in stock

picks upprescription fillsprescription

Figure 12.2 Swimlane diagram for prescription refill function


Analysis of Display ContentAnalysis of Display Content Are different types of data assigned to consistent geographic Are different types of data assigned to consistent geographic

locations on the screen (e.g., photos always appear in the upper locations on the screen (e.g., photos always appear in the upper right hand corner)?right hand corner)?

Can the user customize the screen location for content?Can the user customize the screen location for content? Is proper on-screen identification assigned to all content? Is proper on-screen identification assigned to all content? If a large report is to be presented, how should it be partitioned If a large report is to be presented, how should it be partitioned

for ease of understanding?for ease of understanding? Will mechanisms be available for moving directly to summary Will mechanisms be available for moving directly to summary

information for large collections of data.information for large collections of data. Will graphical output be scaled to fit within the bounds of the Will graphical output be scaled to fit within the bounds of the

display device that is used?display device that is used? How will color to be used to enhance understanding?How will color to be used to enhance understanding? How will error messages and warning be presented to the user?How will error messages and warning be presented to the user?


Interface Design StepsInterface Design Steps

Using information developed during interface Using information developed during interface analysis (SEPA, Section 12.3), analysis (SEPA, Section 12.3), define interface define interface objects and actions (operations).objects and actions (operations).

Define events (user actions)Define events (user actions) that will cause the state that will cause the state of the user interface to change. Model this behavior.of the user interface to change. Model this behavior.

Depict each interface stateDepict each interface state as it will actually look to as it will actually look to the end-user.the end-user.

Indicate how the user interprets the state of the Indicate how the user interprets the state of the systemsystem from information provided through the from information provided through the interface.interface.


Interface Design PatternsInterface Design Patterns

Patterns are available forPatterns are available for The complete UIThe complete UI Page layoutPage layout Forms and inputForms and input TablesTables Direct data manipulationDirect data manipulation NavigationNavigation SearchingSearching Page elementsPage elements e-Commercee-Commerce


Design IssuesDesign Issues

Response timeResponse time Help facilitiesHelp facilities Error handlingError handling Menu and command labelingMenu and command labeling Application accessibilityApplication accessibility InternationalizationInternationalization


Design Evaluation Design Evaluation CycleCyclepreliminary

design

buildprototype #1

interface

evaluationis studied by

designer

designmodifications

are made

buildprototype # n

interface

userevaluate'sinterface

Interface designis complete



Chapter 13Chapter 13Software Testing StrategiesSoftware Testing Strategies

copyright © 1996, 2001, 2005





Software Software TestingTesting

Testing is the process of exercising aTesting is the process of exercising aprogram with the specific intent of findingprogram with the specific intent of findingerrors prior to delivery to the end user.errors prior to delivery to the end user.


What Testing ShowsWhat Testing Shows

errorserrors

requirements conformancerequirements conformance

performanceperformance

an indicationan indicationof qualityof quality


Who Tests the Who Tests the Software?Software?

developerdeveloper independent testerindependent tester

Understands the system Understands the system

but, will test "gently"but, will test "gently"

and, is driven by "delivery"and, is driven by "delivery"

Must learn about the system,Must learn about the system,but, will attempt to break itbut, will attempt to break itand, is driven by qualityand, is driven by quality


Testing StrategyTesting Strategy

unit testunit test integrationintegrationtesttest

validationvalidationtesttest

systemsystemtesttest


Testing StrategyTesting Strategy

We begin by ‘We begin by ‘testing-in-the-small’testing-in-the-small’ and move and move toward ‘toward ‘testing-in-the-large’testing-in-the-large’

For conventional softwareFor conventional software The module (component) is our initial focusThe module (component) is our initial focus Integration of modules followsIntegration of modules follows

For OO softwareFor OO software our focus when “testing in the small” changes from an our focus when “testing in the small” changes from an

individual module (the conventional view) to an OO individual module (the conventional view) to an OO class that encompasses attributes and operations and class that encompasses attributes and operations and implies communication and collaborationimplies communication and collaboration


Strategic IssuesStrategic Issues

State testing objectives explicitly. State testing objectives explicitly. Understand the users of the software and develop a profile Understand the users of the software and develop a profile

for each user category.for each user category. Develop a testing plan that emphasizes “rapid cycle Develop a testing plan that emphasizes “rapid cycle

testing.”testing.” Build “robust” software that is designed to test itselfBuild “robust” software that is designed to test itself Use effective formal technical reviews as a filter prior to Use effective formal technical reviews as a filter prior to

testingtesting Conduct formal technical reviews to assess the test Conduct formal technical reviews to assess the test

strategy and test cases themselves. strategy and test cases themselves. Develop a continuous improvement approach for the Develop a continuous improvement approach for the

testing process. testing process.


Unit TestingUnit Testing

modulemoduleto beto betestedtested

test casestest cases

resultsresults

softwaresoftwareengineerengineer


Unit TestingUnit Testing

interface interface local data structureslocal data structures

boundary conditionsboundary conditionsindependent pathsindependent pathserror handling pathserror handling paths

modulemoduleto beto betestedtested



Unit Test Unit Test EnvironmentEnvironment

ModuleModule

stubstub stubstub

driverdriver

RESULTSRESULTS

interface interface

local data structureslocal data structures

boundary conditionsboundary conditions

independent pathsindependent paths

error handling pathserror handling paths



Integration Testing StrategiesIntegration Testing StrategiesOptions:Options:

•• the “big bang” approachthe “big bang” approach•• an incremental construction strategyan incremental construction strategy


Top Down IntegrationTop Down Integration

top module is tested with top module is tested with stubsstubs

stubs are replaced one at stubs are replaced one at a time, "depth first"a time, "depth first"

as new modules are integrated, as new modules are integrated, some subset of tests is re-runsome subset of tests is re-run

AA

BB

CC

DD EE

FF GG


Bottom-Up IntegrationBottom-Up Integration

drivers are replaced one at a drivers are replaced one at a time, "depth first"time, "depth first"

worker modules are grouped into worker modules are grouped into builds and integratedbuilds and integrated

AA

BB

CC

DD EE

FF GG

clustercluster


Sandwich TestingSandwich Testing

Top modules areTop modules aretested with stubstested with stubs

Worker modules are grouped into Worker modules are grouped into builds and integratedbuilds and integrated

AA

BB

CC

DD EE

FF GG

clustercluster


Object-Oriented Object-Oriented TestingTesting

begins by evaluating the correctness and begins by evaluating the correctness and consistency of the OOA and OOD modelsconsistency of the OOA and OOD models

testing strategy changestesting strategy changes the concept of the ‘unit’ broadens due to encapsulationthe concept of the ‘unit’ broadens due to encapsulation integration focuses on classes and their execution integration focuses on classes and their execution

across a ‘thread’ or in the context of a usage scenarioacross a ‘thread’ or in the context of a usage scenario validation uses conventional black box methodsvalidation uses conventional black box methods

test case design draws on conventional methods, test case design draws on conventional methods, but also encompasses special featuresbut also encompasses special features


Broadening the View of Broadening the View of “Testing”“Testing”

It can be argued that the review of OO analysis and It can be argued that the review of OO analysis and design models is especially useful because the design models is especially useful because the same semantic constructs (e.g., classes, attributes, same semantic constructs (e.g., classes, attributes, operations, messages) appear at the analysis, operations, messages) appear at the analysis, design, and code level. Therefore, a problem in the design, and code level. Therefore, a problem in the definition of class attributes that is uncovered definition of class attributes that is uncovered during analysis will circumvent side effects that during analysis will circumvent side effects that might occur if the problem were not discovered might occur if the problem were not discovered until design or code (or even the next iteration of until design or code (or even the next iteration of analysis). analysis).


Testing the CRC ModelTesting the CRC Model

1. Revisit the CRC model and the object-relationship 1. Revisit the CRC model and the object-relationship model.model.

2. Inspect the description of each CRC index card to 2. Inspect the description of each CRC index card to determine if a delegated responsibility is part of the determine if a delegated responsibility is part of the collaborator’s definition.collaborator’s definition.

3. Invert the connection to ensure that each collaborator 3. Invert the connection to ensure that each collaborator that is asked for service is receiving requests from a that is asked for service is receiving requests from a reasonable source.reasonable source.

4. Using the inverted connections examined in step 3, 4. Using the inverted connections examined in step 3, determine whether other classes might be required or determine whether other classes might be required or whether responsibilities are properly grouped among the whether responsibilities are properly grouped among the classes.classes.

5. Determine whether widely requested responsibilities 5. Determine whether widely requested responsibilities might be combined into a single responsibility.might be combined into a single responsibility.

6. Steps 1 to 5 are applied iteratively to each class and 6. Steps 1 to 5 are applied iteratively to each class and through each evolution of the OOA model.through each evolution of the OOA model.


OOT OOT StrategyStrategy

class testing is the equivalent of unit testingclass testing is the equivalent of unit testing operations within the class are testedoperations within the class are tested the state behavior of the class is examinedthe state behavior of the class is examined

integration applied three different strategiesintegration applied three different strategies thread-based testing—integrates the set of classes thread-based testing—integrates the set of classes

required to respond to one input or eventrequired to respond to one input or event use-based testing—integrates the set of classes use-based testing—integrates the set of classes

required to respond to one use caserequired to respond to one use case cluster testing—integrates the set of classes cluster testing—integrates the set of classes

required to demonstrate one collaborationrequired to demonstrate one collaboration


Smoke TestingSmoke Testing A common approach for creating “daily builds” for product A common approach for creating “daily builds” for product

softwaresoftware Smoke testing steps:Smoke testing steps:

Software components that have been translated into code are Software components that have been translated into code are integrated into a “build.” integrated into a “build.”

A build includes all data files, libraries, reusable modules, and A build includes all data files, libraries, reusable modules, and engineered components that are required to implement one or engineered components that are required to implement one or more product functions.more product functions.

A series of tests is designed to expose errors that will keep A series of tests is designed to expose errors that will keep the build from properly performing its function. the build from properly performing its function.

The intent should be to uncover “show stopper” errors that have The intent should be to uncover “show stopper” errors that have the highest likelihood of throwing the software project behind the highest likelihood of throwing the software project behind schedule.schedule.

The build is integrated with other builds and the entire The build is integrated with other builds and the entire product (in its current form) is smoke tested daily. product (in its current form) is smoke tested daily.

The integration approach may be top down or bottom up.The integration approach may be top down or bottom up.


High Order TestingHigh Order Testing Validation testingValidation testing

Focus is on software requirementsFocus is on software requirements System testingSystem testing

Focus is on system integrationFocus is on system integration Alpha/Beta testingAlpha/Beta testing

Focus is on customer usageFocus is on customer usage Recovery testingRecovery testing

forces the software to fail in a variety of ways and verifies that forces the software to fail in a variety of ways and verifies that recovery is properly performedrecovery is properly performed

Security testingSecurity testing verifies that protection mechanisms built into a system will, in fact, verifies that protection mechanisms built into a system will, in fact,

protect it from improper penetrationprotect it from improper penetration Stress testingStress testing

executes a system in a manner that demands resources in abnormal executes a system in a manner that demands resources in abnormal quantity, frequency, or volumequantity, frequency, or volume

Performance TestingPerformance Testing test the run-time performance of software within the context of an test the run-time performance of software within the context of an

integrated systemintegrated system


Debugging: Debugging: A Diagnostic ProcessA Diagnostic Process


The Debugging ProcessThe Debugging Processtest casestest cases

resultsresults

DebuggingDebugging

suspectedsuspectedcausescauses

identifiedidentifiedcausescauses

correctionscorrections

regressionregressionteststests

new testnew testcasescases


Debugging EffortDebugging Effort

time requiredtime requiredto diagnose theto diagnose thesymptom andsymptom anddetermine thedetermine thecausecause

time requiredtime requiredto correct the errorto correct the errorand conductand conductregression testsregression tests


Symptoms & CausesSymptoms & Causes

symptomsymptomcausecause

symptom and cause may be symptom and cause may be geographically separated geographically separated

symptom may disappear when symptom may disappear when another problem is fixedanother problem is fixed

cause may be due to a cause may be due to a combination of non-errors combination of non-errors

cause may be due to a system cause may be due to a system or compiler erroror compiler error

cause may be due to cause may be due to assumptions that everyone assumptions that everyone believesbelieves

symptom may be intermittentsymptom may be intermittent


Consequences of BugsConsequences of Bugs

damagedamage

mildmild annoyingannoying

disturbingdisturbingseriousserious

extremeextremecatastrophiccatastrophic

infectiousinfectious

Bug TypeBug Type

Bug Categories:Bug Categories: function-related bugs, function-related bugs, system-related bugs, data bugs, coding bugs, system-related bugs, data bugs, coding bugs, design bugs, documentation bugs, standards design bugs, documentation bugs, standards violations, etc.violations, etc.


Debugging TechniquesDebugging Techniques

brute force / testingbrute force / testing

backtrackingbacktracking

inductioninduction

deductiondeduction


Debugging: Final Debugging: Final ThoughtsThoughts

Don't run off half-cocked, Don't run off half-cocked, thinkthink about the about the symptom you're seeing.symptom you're seeing.

Use toolsUse tools (e.g., dynamic debugger) to gain (e.g., dynamic debugger) to gain more insight.more insight.

If at an impasse, If at an impasse, get helpget help from someone else.from someone else.

Be absolutely sure to Be absolutely sure to conduct regression testsconduct regression tests when you do "fix" the bug.when you do "fix" the bug.

1.1.

2.2.

3.3.

4.4.



Chapter 14Chapter 14Software Testing Software Testing

TechniquesTechniques

copyright © 1996, 2001, 2005





TestabiliTestabilityty OperabilityOperability—it operates cleanly—it operates cleanly

ObservabilityObservability—the results of each test case are —the results of each test case are readily observedreadily observed

ControllabilityControllability—the degree to which testing can —the degree to which testing can be automated and optimizedbe automated and optimized

DecomposabilityDecomposability—testing can be targeted—testing can be targeted SimplicitySimplicity—reduce complex architecture and —reduce complex architecture and

logic to simplify testslogic to simplify tests StabilityStability—few changes are requested during —few changes are requested during

testingtesting UnderstandabilityUnderstandability—of the design—of the design


What is a “Good” Test?What is a “Good” Test?

A good test has a high probability of A good test has a high probability of finding an errorfinding an error

A good test is not redundant.A good test is not redundant. A good test should be “best of breed” A good test should be “best of breed” A good test should be neither too A good test should be neither too

simple nor too complexsimple nor too complex


Test Case Test Case DesignDesign

"Bugs lurk in corners "Bugs lurk in corners and congregate at and congregate at boundaries ..."boundaries ..."

Boris BeizerBoris Beizer

OBJECTIVEOBJECTIVE

CRITERIACRITERIA

CONSTRAINTCONSTRAINT

to uncover errorsto uncover errors

in a complete mannerin a complete manner

with a minimum of effort and timewith a minimum of effort and time


Exhaustive TestingExhaustive Testing

loop < 20 Xloop < 20 X

There are 10 possible paths! If we execute oneThere are 10 possible paths! If we execute onetest per millisecond, it would take 3,170 years totest per millisecond, it would take 3,170 years totest this program!!test this program!!

1414


Selective TestingSelective Testing

loop < 20 Xloop < 20 X

Selected pathSelected path


Software TestingSoftware Testing

Methods

Strategies

white-boxmethods

black-box methods


White-Box White-Box TestingTesting

... our goal is to ensure that all ... our goal is to ensure that all statements and conditions have statements and conditions have been executed at least once ...been executed at least once ...


Why Why Cover?Cover?

logic errors and incorrect assumptions logic errors and incorrect assumptions are inversely proportional to a path's are inversely proportional to a path's execution probabilityexecution probability

we often we often believebelieve that a path is not that a path is not likely to be executed; in fact, reality is likely to be executed; in fact, reality is often counter intuitiveoften counter intuitive

typographical errors are random; it's typographical errors are random; it's likely that untested paths will contain likely that untested paths will contain some some


Basis Path Basis Path TestingTesting

First, we compute the cyclomatic complexity:

number of simple decisions + 1

or

number of enclosed areas + 1

In this case, V(G) = 4


Cyclomatic Cyclomatic ComplexityComplexityA number of industry studies have indicated A number of industry studies have indicated

that the higher V(G), the higher the probability that the higher V(G), the higher the probability or errors.or errors.

V(G)V(G)

modulesmodules

modules in this range are modules in this range are more error pronemore error prone


Basis Path Basis Path TestingTestingNext, we derive the Next, we derive the

independent paths:independent paths:

Since V(G) = 4,Since V(G) = 4,there are four pathsthere are four paths

Path 1: 1,2,3,6,7,8Path 1: 1,2,3,6,7,8Path 2: 1,2,3,5,7,8Path 2: 1,2,3,5,7,8Path 3: 1,2,4,7,8Path 3: 1,2,4,7,8Path 4: 1,2,4,7,2,4,...7,8Path 4: 1,2,4,7,2,4,...7,8

Finally, we derive testFinally, we derive testcases to exercise these cases to exercise these paths.paths.

11

22

3344

55 66

77

88


Basis Path Testing Basis Path Testing NotesNotesyou don't need a flow chart, you don't need a flow chart, but the picture will help when but the picture will help when you trace program pathsyou trace program paths

count each simple logical test, count each simple logical test, compound tests count as 2 or compound tests count as 2 or moremore

basis path testing should be basis path testing should be applied to critical modulesapplied to critical modules


Graph MatricesGraph Matrices A graph matrix is a square matrix whose size A graph matrix is a square matrix whose size

(i.e., number of rows and columns) is equal (i.e., number of rows and columns) is equal to the number of nodes on a flow graphto the number of nodes on a flow graph

Each row and column corresponds to an Each row and column corresponds to an identified node, and matrix entries identified node, and matrix entries correspond to connections (an edge) correspond to connections (an edge) between nodes. between nodes.

By adding a By adding a link weightlink weight to each matrix entry, to each matrix entry, the graph matrix can become a powerful tool the graph matrix can become a powerful tool for evaluating program control structure for evaluating program control structure during testingduring testing


Control Structure TestingControl Structure Testing

Condition testingCondition testing — a test case design method — a test case design method that exercises the logical conditions contained in that exercises the logical conditions contained in a program modulea program module

Data flow testingData flow testing — selects test paths of a — selects test paths of a program according to the locations of definitions program according to the locations of definitions and uses of variables in the programand uses of variables in the program


Loop TestingLoop Testing

Nested Nested LoopsLoops

ConcatenatedConcatenated Loops Loops Unstructured Unstructured

LoopsLoops

Simple Simple looploop


Loop Testing: Simple Loop Testing: Simple LoopsLoops

Minimum conditions—Simple LoopsMinimum conditions—Simple Loops

1. skip the loop entirely1. skip the loop entirely

2. only one pass through the loop2. only one pass through the loop3. two passes through the loop3. two passes through the loop4. m passes through the loop m < n4. m passes through the loop m < n5. (n-1), n, and (n+1) passes through 5. (n-1), n, and (n+1) passes through the loopthe loop

where n is the maximum number where n is the maximum number of allowable passesof allowable passes


Loop Testing: Nested Loop Testing: Nested LoopsLoops

Start at the innermost loop. Set all outer loops to their Start at the innermost loop. Set all outer loops to their minimum iteration parameter values.minimum iteration parameter values.

Test the min+1, typical, max-1 and max for the Test the min+1, typical, max-1 and max for the innermost loop, while holding the outer loops at their innermost loop, while holding the outer loops at their minimum values.minimum values.Move out one loop and set it up as in step 2, holding all Move out one loop and set it up as in step 2, holding all other loops at typical values. Continue this step until other loops at typical values. Continue this step until the outermost loop has been tested.the outermost loop has been tested.

If the loops are independent of one another If the loops are independent of one another then treat each as a simple loopthen treat each as a simple loop else* treat as nested loopselse* treat as nested loopsendif* endif*

for example, the final loop counter value of loop 1 is for example, the final loop counter value of loop 1 is used to initialize loop 2.used to initialize loop 2.

Nested LoopsNested Loops

Concatenated LoopsConcatenated Loops


Black-Box TestingBlack-Box Testing

requirementsrequirements

eventseventsinputinput

outputoutput


Black-Box TestingBlack-Box Testing How is functional validity tested?How is functional validity tested? How is system behavior and performance tested?How is system behavior and performance tested? What classes of input will make good test cases?What classes of input will make good test cases? Is the system particularly sensitive to certain Is the system particularly sensitive to certain

input values?input values? How are the boundaries of a data class isolated?How are the boundaries of a data class isolated? What data rates and data volume can the system What data rates and data volume can the system

tolerate?tolerate? What effect will specific combinations of data What effect will specific combinations of data

have on system operation?have on system operation?


Graph-Based MethodsGraph-Based Methods

newfile

menu select generates(generation time < 1.0 sec)

documentwindow

documenttext

is represented ascontains

Attributes:

background color: whitetext color: default color

or preferences

(b)

object#1

Directed link(link weight)

object#2

object#3

Undirected link

Parallel links

Node weight(value)

(a)

allows editingof

To understand To understand the objects that the objects that are modeled in are modeled in software and software and the the relationships relationships that connect that connect these objectsthese objects

In this context, we In this context, we consider the term consider the term “objects” in the “objects” in the broadest possible broadest possible context. It context. It encompasses data encompasses data objects, traditional objects, traditional components components (modules), and (modules), and object-oriented object-oriented elements of elements of computer software.computer software.


Equivalence PartitioningEquivalence Partitioning

useruserqueriesqueries

mousemousepickspicks

outputoutputformatsformats

promptsprompts

FKFKinputinput

datadata


Sample Equivalence Sample Equivalence ClassesClasses

user supplied commandsuser supplied commandsresponses to system promptsresponses to system promptsfile namesfile namescomputational datacomputational data physical parameters physical parameters bounding valuesbounding values initiation valuesinitiation valuesoutput data formattingoutput data formattingresponses to error messagesresponses to error messagesgraphical data (e.g., mouse picks)graphical data (e.g., mouse picks)

data outside bounds of the program data outside bounds of the program physically impossible dataphysically impossible dataproper value supplied in wrong placeproper value supplied in wrong place

Valid dataValid data

Invalid dataInvalid data


Boundary Value Boundary Value AnalysisAnalysis

useruserqueriesqueries

mousemousepickspicks

outputoutputformatsformats

promptsprompts

FKFKinputinput

datadata

outputoutputdomaindomaininput domaininput domain


Comparison TestingComparison Testing

Used only in situations in which the reliability of Used only in situations in which the reliability of software is absolutely critical (e.g., human-rated software is absolutely critical (e.g., human-rated systems)systems) Separate software engineering teams develop Separate software engineering teams develop

independent versions of an application using the same independent versions of an application using the same specificationspecification

Each version can be tested with the same test data to Each version can be tested with the same test data to ensure that all provide identical output ensure that all provide identical output

Then all versions are executed in parallel with real-time Then all versions are executed in parallel with real-time comparison of results to ensure consistencycomparison of results to ensure consistency


Orthogonal Array TestingOrthogonal Array Testing Used when the number of input parameters is

small and the values that each of the parameters may take are clearly bounded

One input item at a time L9 orthogonal array

XY

Z

XY

Z


OOT—Test Case OOT—Test Case DesignDesignBerard [BER93] proposes the following approach:Berard [BER93] proposes the following approach:

1.1. Each test case should be uniquely identified and should be explicitly Each test case should be uniquely identified and should be explicitly associated with the class to be tested,associated with the class to be tested,

2.2. The purpose of the test should be stated,The purpose of the test should be stated,

3.3. A list of testing steps should be developed for each test and should A list of testing steps should be developed for each test and should contain [BER94]:contain [BER94]:

a.a. a list of specified states for the object that is to be testeda list of specified states for the object that is to be tested

b.b. a list of messages and operations that will be exercised as a list of messages and operations that will be exercised as a consequence of the testa consequence of the test

c.c. a list of exceptions that may occur as the object is testeda list of exceptions that may occur as the object is tested

d.d. a list of external conditions (i.e., changes in the environment external a list of external conditions (i.e., changes in the environment external to the software that must exist in order to properly conduct the test)to the software that must exist in order to properly conduct the test)

e.e. supplementary information that will aid in understanding or supplementary information that will aid in understanding or implementing the test.implementing the test.


Testing MethodsTesting Methods

Fault-based testingFault-based testing The tester looks for plausible faults (i.e., aspects of the The tester looks for plausible faults (i.e., aspects of the

implementation of the system that may result in defects). To implementation of the system that may result in defects). To determine whether these faults exist, test cases are designed to determine whether these faults exist, test cases are designed to exercise the design or code. exercise the design or code.

Class Testing and the Class HierarchyClass Testing and the Class Hierarchy Inheritance does not obviate the need for thorough testing of all Inheritance does not obviate the need for thorough testing of all

derived classes. In fact, it can actually complicate the testing derived classes. In fact, it can actually complicate the testing process.process.

Scenario-Based Test DesignScenario-Based Test Design Scenario-based testing concentrates on what the user does, not Scenario-based testing concentrates on what the user does, not

what the product does. This means capturing the tasks (via use-what the product does. This means capturing the tasks (via use-cases) that the user has to perform, then applying them and their cases) that the user has to perform, then applying them and their variants as tests.variants as tests.


OOT Methods: Random OOT Methods: Random TestingTesting

Random testingRandom testing identify operations applicable to a classidentify operations applicable to a class define constraints on their usedefine constraints on their use identify a miminum test sequenceidentify a miminum test sequence

an operation sequence that defines the minimum an operation sequence that defines the minimum life history of the class (object)life history of the class (object)

generate a variety of random (but valid) test generate a variety of random (but valid) test sequencessequences exercise other (more complex) class instance life exercise other (more complex) class instance life

historieshistories


OOT Methods: Partition OOT Methods: Partition TestingTesting Partition TestingPartition Testing

reduces the number of test cases required to test a reduces the number of test cases required to test a class in much the same way as equivalence class in much the same way as equivalence partitioning for conventional softwarepartitioning for conventional software

state-based partitioningstate-based partitioning categorize and test operations based on their ability to categorize and test operations based on their ability to

change the state of a classchange the state of a class attribute-based partitioningattribute-based partitioning

categorize and test operations based on the attributes categorize and test operations based on the attributes that they usethat they use

category-based partitioningcategory-based partitioning categorize and test operations based on the generic categorize and test operations based on the generic

function each performsfunction each performs


OOT Methods: Inter-Class OOT Methods: Inter-Class TestingTesting Inter-class testingInter-class testing

For each client class, use the list of class operators For each client class, use the list of class operators to generate a series of random test sequences. The to generate a series of random test sequences. The operators will send messages to other server classes.operators will send messages to other server classes.

For each message that is generated, determine the For each message that is generated, determine the collaborator class and the corresponding operator in collaborator class and the corresponding operator in the server object.the server object.

For each operator in the server object (that has been For each operator in the server object (that has been invoked by messages sent from the client object), invoked by messages sent from the client object), determine the messages that it transmits.determine the messages that it transmits.

For each of the messages, determine the next level For each of the messages, determine the next level of operators that are invoked and incorporate these of operators that are invoked and incorporate these into the test sequenceinto the test sequence


OOT Methods: Behavior TestingOOT Methods: Behavior Testing

emptyacctopen setup Accnt

set upacct

deposit(initial)

workingacct

withdrawal(final)

deadacct close

nonworkingacct

deposit

withdrawbalance

creditaccntInfo

Figure 14.3 State diagram for Account class (adapted from [ KIR94])

The tests to be The tests to be designed designed should achieve should achieve all state all state coverage coverage [KIR94]. That [KIR94]. That is, the is, the operation operation sequences sequences should cause should cause the Account the Account class to make class to make transition transition through all through all allowable allowable statesstates


Testing PatternsTesting Patterns

Pattern name:Pattern name: pair testing pair testingAbstract: Abstract: A process-oriented pattern, pair testing describes a A process-oriented pattern, pair testing describes a technique that is analogous to pair programming (Chapter 4) in technique that is analogous to pair programming (Chapter 4) in which two testers work together to design and execute a series of which two testers work together to design and execute a series of tests that can be applied to unit, integration or validation testing tests that can be applied to unit, integration or validation testing activities.activities.

Pattern name: Pattern name: separate test interface separate test interfaceAbstract: Abstract: There is a need to test every class in an object-oriented There is a need to test every class in an object-oriented system, including “internal classes” (i.e., classes that do not system, including “internal classes” (i.e., classes that do not expose any interface outside of the component that used them). expose any interface outside of the component that used them). The separate test interface pattern describes how to create “a The separate test interface pattern describes how to create “a test interface that can be used to describe specific tests on test interface that can be used to describe specific tests on classes that are visible only internally to a component.” [LAN01]classes that are visible only internally to a component.” [LAN01]

Pattern name: Pattern name: scenario testing scenario testingAbstract: Abstract: Once unit and integration tests have been conducted, Once unit and integration tests have been conducted, there is a need to determine whether the software will perform in there is a need to determine whether the software will perform in a manner that satisfies users. The scenario testing pattern a manner that satisfies users. The scenario testing pattern describes a technique for exercising the software from the user’s describes a technique for exercising the software from the user’s point of view. A failure at this level indicates that the software point of view. A failure at this level indicates that the software has failed to meet a user visible requirement. [KAN01]has failed to meet a user visible requirement. [KAN01]



Chapter 15Chapter 15Product Metrics for Product Metrics for

SoftwareSoftware

copyright © 1996, 2001, 2005





McCall’s Triangle of McCall’s Triangle of QualityQuality

MaintainabilityMaintainability

FlexibilityFlexibility

TestabilityTestability

PortabilityPortability

ReusabilityReusability

InteroperabilityInteroperability

CorrectnessCorrectness

ReliabilityReliabilityEfficiencyEfficiency

IntegrityIntegrityUsabilityUsability

PRODUCT TRANSITIONPRODUCT TRANSITIONPRODUCT REVISIONPRODUCT REVISION

PRODUCT OPERATIONPRODUCT OPERATION


A A CommentComment

McCall’s quality factors were proposed in theMcCall’s quality factors were proposed in theearly 1970s. They are as valid today as they wereearly 1970s. They are as valid today as they werein that time. It’s likely that software built to conform in that time. It’s likely that software built to conform to these factors will exhibit high quality well intoto these factors will exhibit high quality well intothe 21st century, even if there are dramatic changesthe 21st century, even if there are dramatic changesin technology.in technology.


Measures, Metrics and Measures, Metrics and IndicatorsIndicators

A A measuremeasure provides a quantitative indication of provides a quantitative indication of the extent, amount, dimension, capacity, or size the extent, amount, dimension, capacity, or size of some attribute of a product or processof some attribute of a product or process

The IEEE glossary defines aThe IEEE glossary defines a metricmetric as “a as “a quantitative measure of the degree to which a quantitative measure of the degree to which a system, component, or process possesses a given system, component, or process possesses a given attribute.”attribute.”

An An indicatorindicator is a metric or combination of is a metric or combination of metrics that provide insight into the software metrics that provide insight into the software process, a software project, or the product itself process, a software project, or the product itself


Measurement Measurement PrinciplesPrinciples

The objectives of measurement should be established The objectives of measurement should be established before data collection begins;before data collection begins;

Each technical metric should be defined in an Each technical metric should be defined in an unambiguous manner;unambiguous manner;

Metrics should be derived based on a theory that is valid Metrics should be derived based on a theory that is valid for the domain of application (e.g., metrics for design for the domain of application (e.g., metrics for design should draw upon basic design concepts and principles should draw upon basic design concepts and principles and attempt to provide an indication of the presence of and attempt to provide an indication of the presence of an attribute that is deemed desirable);an attribute that is deemed desirable);

Metrics should be tailored to best accommodate specific Metrics should be tailored to best accommodate specific products and processes [BAS84]products and processes [BAS84]


Measurement ProcessMeasurement Process

FormulationFormulation.. The derivation of software measures and The derivation of software measures and metrics appropriate for the representation of the software metrics appropriate for the representation of the software that is being considered.that is being considered.

Collection.Collection. The mechanism used to accumulate data The mechanism used to accumulate data required to derive the formulated metrics.required to derive the formulated metrics.

AnalysisAnalysis.. The computation of metrics and the application of The computation of metrics and the application of mathematical tools.mathematical tools.

InterpretationInterpretation.. The evaluation of metrics results in an The evaluation of metrics results in an effort to gain insight into the quality of the representation.effort to gain insight into the quality of the representation.

Feedback.Feedback. Recommendations derived from the Recommendations derived from the interpretation of productinterpretation of product metrics transmitted to the metrics transmitted to the software team.software team.


Goal-Oriented Software Goal-Oriented Software MeasurementMeasurement

The Goal/Question/Metric ParadigmThe Goal/Question/Metric Paradigm (1) establish an explicit measurement (1) establish an explicit measurement goalgoal that is specific to the that is specific to the

process activity or product characteristic that is to be assessedprocess activity or product characteristic that is to be assessed (2) define a set of (2) define a set of questionsquestions that must be answered in order to that must be answered in order to

achieve the goal, and achieve the goal, and (3) identify well-formulated(3) identify well-formulated metricmetricss that help to answer these that help to answer these

questions.questions. Goal definition templateGoal definition template

AnalyzeAnalyze {the name of activity or attribute to be measured} {the name of activity or attribute to be measured} for the purpose offor the purpose of {the overall objective of the analysis} {the overall objective of the analysis} with respect towith respect to {the aspect of the activity or attribute that is {the aspect of the activity or attribute that is

considered} considered} from the viewpoint offrom the viewpoint of {the people who have an interest in the {the people who have an interest in the

measurement} measurement} in the context ofin the context of {the environment in which the measurement {the environment in which the measurement

takes place}.takes place}.


Metrics Metrics AttributesAttributes simple and computable.simple and computable. It should be relatively easy to learn how to derive It should be relatively easy to learn how to derive

the metric, and its computation should not demand inordinate effort or the metric, and its computation should not demand inordinate effort or timetime

empirically and intuitively persuasiveempirically and intuitively persuasive.. The metric should satisfy the The metric should satisfy the engineer’s intuitive notions about the product attribute under engineer’s intuitive notions about the product attribute under considerationconsideration

consistent and objectiveconsistent and objective.. The metric should always yield results that are The metric should always yield results that are unambiguous. unambiguous.

consistent in its use of units and dimensionsconsistent in its use of units and dimensions.. The mathematical The mathematical computation of the metric should use measures that do not lead to computation of the metric should use measures that do not lead to bizarre combinations of unit. bizarre combinations of unit.

programming language independentprogramming language independent.. Metrics should be based on the Metrics should be based on the analysis model, the design model, or the structure of the program itself. analysis model, the design model, or the structure of the program itself.

an effective mechanism for quality feedbackan effective mechanism for quality feedback.. That is, the metric should That is, the metric should provide a software engineer with information that can lead to a higher provide a software engineer with information that can lead to a higher quality end productquality end product


Collection and Analysis Collection and Analysis PrinciplesPrinciples

Whenever possible, data collection and analysis Whenever possible, data collection and analysis should be automated;should be automated;

Valid statistical techniques should be applied to Valid statistical techniques should be applied to establish relationship between internal product establish relationship between internal product attributes and external quality characteristics attributes and external quality characteristics

Interpretative guidelines and recommendations Interpretative guidelines and recommendations should be established for each metricshould be established for each metric


Analysis MetricsAnalysis Metrics

Function-based metricsFunction-based metrics:: use the function point as use the function point as a normalizing factor or as a measure of the “size” a normalizing factor or as a measure of the “size” of the specificationof the specification

Specification metricsSpecification metrics:: used as an indication of used as an indication of quality by measuring number of requirements by quality by measuring number of requirements by typetype


Function-Based MetricsFunction-Based Metrics

The The function point metricfunction point metric (FP), (FP), first proposed by Albrecht first proposed by Albrecht [ALB79], can be used effectively as a means for measuring the [ALB79], can be used effectively as a means for measuring the functionality delivered by a system.functionality delivered by a system.

Function points are derived using an empirical relationship Function points are derived using an empirical relationship based on countable (direct) measures of software's based on countable (direct) measures of software's information domain and assessments of software complexityinformation domain and assessments of software complexity

Information domain values are defined in the following Information domain values are defined in the following manner:manner: number of external inputs (EIs)number of external inputs (EIs) number of external outputs (EOs)number of external outputs (EOs) number of external inquiries (EQs)number of external inquiries (EQs) number of internal logical files (ILFs)number of internal logical files (ILFs) Number of external interface files (EIFs)Number of external interface files (EIFs)


Function PointsFunction Points

InformationDomain Value Count simple average complex

Weighting factor

External Inputs (EIs)

External Outputs (EOs)

External Inquiries (EQs)

Internal Logical Files (ILFs)

External Interface Files (EIFs)

3 4 6

4 5 7

3 4 6

7 10 15

5 7 10

=

=

=

=

=

Count total

3

3

3

3

3


Architectural Design MetricsArchitectural Design Metrics

Architectural design metricsArchitectural design metrics Structural complexity = g(fan-out)Structural complexity = g(fan-out) Data complexity = f(input & output variables, fan-out)Data complexity = f(input & output variables, fan-out) System complexity = h(structural & data complexity) System complexity = h(structural & data complexity)

HK metric:HK metric: architectural complexity as a function architectural complexity as a function of fan-in and fan-outof fan-in and fan-out

Morphology metrics:Morphology metrics: a function of the number of a function of the number of modules and the number of interfaces between modules and the number of interfaces between modulesmodules


Metrics for OO Design-IMetrics for OO Design-I Whitmire [WHI97] describes nine distinct and measurable Whitmire [WHI97] describes nine distinct and measurable

characteristics of an OO design:characteristics of an OO design: SizeSize

Size is defined in terms of four views: population, volume, length, Size is defined in terms of four views: population, volume, length, and functionalityand functionality

ComplexityComplexity How classes of an OO design are interrelated to one anotherHow classes of an OO design are interrelated to one another

CouplingCoupling The physical connections between elements of the OO designThe physical connections between elements of the OO design

SufficiencySufficiency ““the degree to which an abstraction possesses the features required the degree to which an abstraction possesses the features required

of it, or the degree to which a design component possesses features of it, or the degree to which a design component possesses features in its abstraction, from the point of view of the current application.”in its abstraction, from the point of view of the current application.”

CompletenessCompleteness An indirect implication about the degree to which the abstraction or An indirect implication about the degree to which the abstraction or

design component can be reuseddesign component can be reused


Metrics for OO Design-IIMetrics for OO Design-II

CohesionCohesion The degree to which all operations working together to The degree to which all operations working together to

achieve a single, well-defined purposeachieve a single, well-defined purpose PrimitivenessPrimitiveness

Applied to both operations and classes, the degree to Applied to both operations and classes, the degree to which an operation is atomicwhich an operation is atomic

SimilaritySimilarity The degree to which two or more classes are similar in The degree to which two or more classes are similar in

terms of their structure, function, behavior, or purposeterms of their structure, function, behavior, or purpose VolatilityVolatility

Measures the likelihood that a change will occurMeasures the likelihood that a change will occur


Distinguishing Distinguishing CharacteristicsCharacteristics

Localization—the way in which information is concentrated in a Localization—the way in which information is concentrated in a programprogram

Encapsulation—the packaging of data and processingEncapsulation—the packaging of data and processing Information hiding—the way in which information about Information hiding—the way in which information about

operational details is hidden by a secure interfaceoperational details is hidden by a secure interface Inheritance—the manner in which the responsibilities of one Inheritance—the manner in which the responsibilities of one

class are propagated to anotherclass are propagated to another Abstraction—the mechanism that allows a design to focus on Abstraction—the mechanism that allows a design to focus on

essential detailsessential details

Berard [BER95] argues that the following characteristics require that special OO metrics be developed:


Class-Oriented Class-Oriented MetricsMetrics

weighted methods per classweighted methods per class depth of the inheritance treedepth of the inheritance tree number of childrennumber of children coupling between object classescoupling between object classes response for a classresponse for a class lack of cohesion in methodslack of cohesion in methods

Proposed by Chidamber and KemererProposed by Chidamber and Kemerer::


Class-Oriented Class-Oriented MetricsMetrics

class sizeclass size number of operations overridden by a number of operations overridden by a

subclasssubclass number of operations added by a subclassnumber of operations added by a subclass specialization indexspecialization index

Proposed by Lorenz and Kidd [LOR94]:Proposed by Lorenz and Kidd [LOR94]:


Class-Oriented MetricsClass-Oriented Metrics

Method inheritance factorMethod inheritance factor Coupling factorCoupling factor Polymorphism factorPolymorphism factor

The MOOD Metrics SuiteThe MOOD Metrics Suite


Operation-Oriented Operation-Oriented MetricsMetrics

average operation sizeaverage operation size operation complexityoperation complexity average number of parameters per average number of parameters per

operationoperation

Proposed by Lorenz and Kidd [LOR94]:Proposed by Lorenz and Kidd [LOR94]:


Component-Level Design Component-Level Design MetricsMetrics

Cohesion metrics:Cohesion metrics: a function of data objects and a function of data objects and the locus of their definitionthe locus of their definition

Coupling metrics:Coupling metrics: a function of input and output a function of input and output parameters, global variables, and modules calledparameters, global variables, and modules called

Complexity metrics:Complexity metrics: hundreds have been hundreds have been proposed (e.g., cyclomatic complexity)proposed (e.g., cyclomatic complexity)


Interface Design MetricsInterface Design Metrics

Layout appropriateness:Layout appropriateness: a function of layout a function of layout entities, the geographic position and the “cost” entities, the geographic position and the “cost” of making transitions among entitiesof making transitions among entities


Code MetricsCode Metrics

Halstead’s Software Science:Halstead’s Software Science: a comprehensive a comprehensive collection of metrics all predicated on the collection of metrics all predicated on the number (count and occurrence) of operators and number (count and occurrence) of operators and operands within a component or programoperands within a component or program It should be noted that Halstead’s “laws” have It should be noted that Halstead’s “laws” have

generated substantial controversy, and many believe generated substantial controversy, and many believe that the underlying theory has flaws. However, that the underlying theory has flaws. However, experimental verification for selected programming experimental verification for selected programming languages has been performed (e.g. [FEL89]).languages has been performed (e.g. [FEL89]).


Metrics for TestingMetrics for Testing

Testing effort can also be estimated using Testing effort can also be estimated using metrics derived from Halstead measuresmetrics derived from Halstead measures

Binder [BIN94] suggests a broad array of design Binder [BIN94] suggests a broad array of design metrics that have a direct influence on the metrics that have a direct influence on the “testability” of an OO system. “testability” of an OO system. Lack of cohesion in methods (LCOM). Lack of cohesion in methods (LCOM). Percent public and protected (PAP). Percent public and protected (PAP). Public access to data members (PAD). Public access to data members (PAD). Number of root classes (NOR). Number of root classes (NOR). Fan-in (FIN). Fan-in (FIN). Number of children (NOC) and depth of the inheritance Number of children (NOC) and depth of the inheritance

tree (DIT).tree (DIT).

Documents

Part 2