Chapter 7 Requiremets Modelig: Flow, Behavior, Patters, ad WebApps Slide Set to accompay Software Egieerig: A Practitioer s Approach, 7/e by Roger S. Pressma Slides copyright 1996, 2001, 2005, 2009 by Roger S. Pressma For o-profit educatioal use oly May be reproduced ONLY for studet use at the uiversity level whe used i cojuctio with Software Egieerig: A Practitioer's Approach, 7/e. Ay other reproductio or use is prohibited without the express writte permissio of the author. All copyright iformatio MUST appear if these slides are posted o a website for studet use. These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 1
Requiremets Modelig Strategies Oe view of requiremets modelig, called structured aalysis, cosiders data ad the processes that trasform the data as separate etities. Data objects are modeled i a way that defies their attributes ad relatioships. Processes that maipulate data objects are modeled i a maer that shows how they trasform data as data objects flow through the system. A secod approach to aalysis modeled, called objectorieted aalysis, focuses o the defiitio of classes ad the maer i which they collaborate with oe aother to effect customer requiremets. These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 2
Flow-Orieted Modelig Represets how data objects are trasformed at they move through the system data flow diagram (DFD) is the diagrammatic form that is used Cosidered by may to be a old school approach, but cotiues to provide a view of the system that is uique it should be used to supplemet other aalysis model elemets These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 3
The Flow Model Every computer-based system is a iformatio trasform... iput computer based system output These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 4
Flow Modelig Notatio exteral etity process data flow data store These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 5
Exteral Etity A producer or cosumer of data Examples: a perso, a device, a sesor Aother example: computer-based system Data must always origiate somewhere ad must always be set to somethig These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 6
Process A data trasformer (chages iput to output) Examples: compute taxes, determie area, format report, display graph Data must always be processed i some way to achieve system fuctio These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 7
Data Flow Data flows through a system, begiig as iput ad trasformed ito output. base height compute triagle area area These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 8
Data Stores Data is ofte stored for later use. report required sesor # look-up sesor data sesor umber sesor #, type, locatio, age type, locatio, age sesor data These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 9
Data Flow Diagrammig: Guidelies all icos must be labeled with meaigful ames the DFD evolves through a umber of levels of detail always begi with a cotext level diagram (also called level 0) always show exteral etities at level 0 always label data flow arrows do ot represet procedural logic These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 10
Costructig a DFD I review user scearios ad/or the data model to isolate data objects ad use a grammatical parse to determie operatios determie exteral etities (producers ad cosumers of data) create a level 0 DFD These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 11
Level 0 DFD Example user video source processig request NTSC video sigal digital video processor requested video sigal moitor These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 12
Costructig a DFD II write a arrative describig the trasform parse to determie ext level trasforms balace the flow to maitai data flow cotiuity develop a level 1 DFD use a 1:5 (approx.) expasio ratio These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 13
The Data Flow Hierarchy x a P b y level 0 a p1 c p2 f d level 1 p3 e p4 g 5 b These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 14
Flow Modelig Notes each bubble is refied util it does just oe thig the expasio ratio decreases as the umber of levels icrease most systems require betwee 3 ad 7 levels for a adequate flow model a sigle data flow item (arrow) may be expaded as levels icrease (data dictioary provides iformatio) These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 15
Process Specificatio (PSPEC) bubble PSPEC arrative pseudocode (PDL) equatios tables diagrams ad/or charts These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 16
DFDs: A Look Ahead aalysis model Maps ito desig model These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 17
Cotrol Flow Modelig Represets evets ad the processes that maage evets A evet is a Boolea coditio that ca be ascertaied by: listig all sesors that are "read" by the software. listig all iterrupt coditios. listig all "switches" that are actuated by a operator. listig all data coditios. recallig the ou/verb parse that was applied to the processig arrative, review all "cotrol items" as possible CSPEC iputs/outputs. These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 18
Cotrol Specificatio (CSPEC) The CSPEC ca be: state diagram (sequetial spec) state trasitio table decisio tables combiatorial spec activatio tables These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 19
Behavioral Modelig The behavioral model idicates how software will respod to exteral evets or stimuli. To create the model, the aalyst must perform the followig steps: Evaluate all use-cases to fully uderstad the sequece of iteractio withi the system. Idetify evets that drive the iteractio sequece ad uderstad how these evets relate to specific objects. Create a sequece for each use-case. Build a state diagram for the system. Review the behavioral model to verify accuracy ad cosistecy. These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 20
State Represetatios I the cotext of behavioral modelig, two differet characterizatios of states must be cosidered: the state of each class as the system performs its fuctio ad the state of the system as observed from the outside as the system performs its fuctio The state of a class takes o both passive ad active characteristics [CHA93]. A passive state is simply the curret status of all of a object s attributes. The active state of a object idicates the curret status of the object as it udergoes a cotiuig trasformatio or processig. These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 21
State Diagram for the CotrolPael Class These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 22
The States of a System state a set of observable circumstaces that characterizes the behavior of a system at a give time state trasitio the movemet from oe state to aother evet a occurrece that causes the system to exhibit some predictable form of behavior actio process that occurs as a cosequece of makig a trasitio These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 23
Behavioral Modelig make a list of the differet states of a system (How does the system behave?) idicate how the system makes a trasitio from oe state to aother (How does the system chage state?) idicate evet idicate actio draw a state diagram or a sequece diagram These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 24
Sequece Diagram These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 25
Writig the Software Specificatio Everyoe kew exactly what had to be doe util someoe wrote it dow! These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 26
Patters for Requiremets Modelig Software patters are a mechaism for capturig domai kowledge i a way that allows it to be reapplied whe a ew problem is ecoutered domai kowledge ca be applied to a ew problem withi the same applicatio domai the domai kowledge captured by a patter ca be applied by aalogy to a completely differet applicatio domai. The origial author of a aalysis patter does ot create the patter, but rather, discovers it as requiremets egieerig work is beig coducted. Oce the patter has bee discovered, it is documeted These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 27
Discoverig Aalysis Patters The most basic elemet i the descriptio of a requiremets model is the use case. A coheret set of use cases may serve as the basis for discoverig oe or more aalysis patters. A sematic aalysis patter (SAP) is a patter that describes a small set of coheret use cases that together describe a basic geeric applicatio. [Fer00] These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 28
A Example Cosider the followig prelimiary use case for software required to cotrol ad moitor a real-view camera ad proximity sesor for a automobile: Use case: Moitor reverse motio Descriptio: Whe the vehicle is placed i reverse gear, the cotrol software eables a video feed from a rear-placed video camera to the dashboard display. The cotrol software superimposes a variety of distace ad orietatio lies o the dashboard display so that the vehicle operator ca maitai orietatio as the vehicle moves i reverse. The cotrol software also moitors a proximity sesor to determie whether a object is iside 10 feet of the rear of the vehicle. It will automatically break the vehicle if the proximity sesor idicates a object withi 3 feet of the rear of the vehicle. These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 29
A Example This use case implies a variety of fuctioality that would be refied ad elaborated (ito a coheret set of use cases) durig requiremets gatherig ad modelig. Regardless of how much elaboratio is accomplished, the use case(s) suggest(s) a simple, yet widely applicable SAP the software-based moitorig ad cotrol of sesors ad actuators i a physical system. I this case, the sesors provide iformatio about proximity ad video iformatio. The actuator is the breakig system of the vehicle (ivoked if a object is very close to the vehicle. But i a more geeral case, a widely applicable patter is discovered --> Actuator-Sesor These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 30
Actuator-Sesor Patter I Patter Name: Actuator-Sesor Itet: Specify various kids of sesors ad actuators i a embedded system. Motivatio: Embedded systems usually have various kids of sesors ad actuators. These sesors ad actuators are all either directly or idirectly coected to a cotrol uit. Although may of the sesors ad actuators look quite differet, their behavior is similar eough to structure them ito a patter. The patter shows how to specify the sesors ad actuators for a system, icludig attributes ad operatios. The Actuator-Sesor patter uses a pull mechaism (explicit request for iformatio) for PassiveSesors ad a push mechaism (broadcast of iformatio) for the ActiveSesors. Costraits: Each passive sesor must have some method to read sesor iput ad attributes that represet the sesor value. Each active sesor must have capabilities to broadcast update messages whe its value chages. Each active sesor should sed a life tick, a status message issued withi a specified time frame, to detect malfuctios. Each actuator must have some method to ivoke the appropriate respose determied by the ComputigCompoet. Each sesor ad actuator should have a fuctio implemeted to check its ow operatio state. Each sesor ad actuator should be able to test the validity of the values received or set ad set its operatio state if the values are outside of the specificatios. These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 31
Actuator-Sesor Patter II Applicability: Useful i ay system i which multiple sesors ad actuators are preset. Structure: A UML class diagram for the Actuator-Sesor Patter is show i Figure 7.8. Actuator, PassiveSesor ad ActiveSesor are abstract classes ad deoted i italics. There are four differet types of sesors ad actuators i this patter. The Boolea, iteger, ad real classes represet the most commo types of sesors ad actuators. The complex classes are sesors or actuators that use values that caot be easily represeted i terms of primitive data types, such as a radar device. Noetheless, these devices should still iherit the iterface from the abstract classes sice they should have basic fuctioalities such as queryig the operatio states. These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 32
Actuator-Sesor Patter III Behavior: Figure 7.9 presets a UML sequece diagram for a example of the Actuator-Sesor Patter as it might be applied for the SafeHome fuctio that cotrols the positioig (e.g., pa, zoom) of a security camera. Here, the CotrolPael queries a sesor (a passive positio sesor) ad a actuator (pa cotrol) to check the operatio state for diagostic purposes before readig or settig a value. The messages Set Physical Value ad Get Physical Value are ot messages betwee objects. Istead, they describe the iteractio betwee the physical devices of the system ad their software couterparts. I the lower part of the diagram, below the horizotal lie, the PositioSesor reports that the operatio state is zero. The ComputigCompoet the seds the error code for a positio sesor failure to the FaultHadler that will decide how this error affects the system ad what actios are required. it gets the data from the sesors ad computes the required respose for the actuators. These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 33
Actuator-Sesor Patter III See SEPA, 7/e for additioal iformatio o: Participats Collaboratios Cosequeces These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 34
Requiremets Modelig for WebApps Cotet Aalysis. The full spectrum of cotet to be provided by the WebApp is idetified, icludig text, graphics ad images, video, ad audio data. Data modelig ca be used to idetify ad describe each of the data objects. Iteractio Aalysis. The maer i which the user iteracts with the WebApp is described i detail. Use-cases ca be developed to provide detailed descriptios of this iteractio. Fuctioal Aalysis. The usage scearios (use-cases) created as part of iteractio aalysis defie the operatios that will be applied to WebApp cotet ad imply other processig fuctios. All operatios ad fuctios are described i detail. Cofiguratio Aalysis. The eviromet ad ifrastructure i which the WebApp resides are described i detail. These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 35
Whe Do We Perform Aalysis? I some WebE situatios, aalysis ad desig merge. However, a explicit aalysis activity occurs whe the WebApp to be built is large ad/or complex the umber of stakeholders is large the umber of Web egieers ad other cotributors is large the goals ad objectives (determied durig formulatio) for the WebApp will effect the busiess bottom lie the success of the WebApp will have a strog bearig o the success of the busiess These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 36
The Cotet Model Cotet objects are extracted from use-cases examie the sceario descriptio for direct ad idirect refereces to cotet Attributes of each cotet object are idetified The relatioships amog cotet objects ad/or the hierarchy of cotet maitaied by a WebApp Relatioships etity-relatioship diagram or UML Hierarchy data tree or UML These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 37
Data Tree These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 38
The Iteractio Model Composed of four elemets: use-cases sequece diagrams state diagrams a user iterface prototype Each of these is a importat UML otatio ad is described i Appedix I These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 39
Sequece Diagram These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 40
State Diagram These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 41
The Fuctioal Model The fuctioal model addresses two processig elemets of the WebApp user observable fuctioality that is delivered by the WebApp to ed-users the operatios cotaied withi aalysis classes that implemet behaviors associated with the class. A activity diagram ca be used to represet processig flow These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 42
Activity Diagram These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 43
The Cofiguratio Model Server-side Server hardware ad operatig system eviromet must be specified Iteroperability cosideratios o the server-side must be cosidered Appropriate iterfaces, commuicatio protocols ad related collaborative iformatio must be specified Cliet-side Browser cofiguratio issues must be idetified Testig requiremets should be defied These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 44
Navigatio Modelig-I Should certai elemets be easier to reach (require fewer avigatio steps) tha others? What is the priority for presetatio? Should certai elemets be emphasized to force users to avigate i their directio? How should avigatio errors be hadled? Should avigatio to related groups of elemets be give priority over avigatio to a specific elemet. Should avigatio be accomplished via liks, via searchbased access, or by some other meas? Should certai elemets be preseted to users based o the cotext of previous avigatio actios? Should a avigatio log be maitaied for users? These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 45
Navigatio Modelig-II Should a full avigatio map or meu (as opposed to a sigle back lik or directed poiter) be available at every poit i a user s iteractio? Should avigatio desig be drive by the most commoly expected user behaviors or by the perceived importace of the defied WebApp elemets? Ca a user store his previous avigatio through the WebApp to expedite future usage? For which user category should optimal avigatio be desiged? How should liks exteral to the WebApp be hadled? overlayig the existig browser widow? as a ew browser widow? as a separate frame? These slides are desiged to accompay Software Egieerig: A Practitioer s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressma. 46