Slides copyright 1996, 2001, 2005, 2009 by Roger S. Pressman

Transcription

1 Chapter 7 Requirements Modeling: Flow, Behavior, Patterns, and WebApps Slides in this presentation were taken from two sources: Software Engineering: A Practitioner s Approach, 7/e by Roger S. Pressman Slides copyright 1996, 2001, 2005, 2009 by Roger S. Pressman Object-Oriented Software Engineering: Using UML, Patterns, and Java, 2/e, Chapter 5 by Bernd Bruegge and Allen H. Dutoit The footer information identifies the source for each slide.

2 Requirements Modeling Strategies One view of requirements modeling, called structured analysis, considers data and the processes that transform the data as separate entities. Data objects are modeled in a way that defines their attributes and relationships. Processes that manipulate data objects are modeled in a manner that shows how they transform data as data objects flow through the system. A second approach to analysis modeled, called objectoriented analysis, focuses on the definition of classes and the manner in which they collaborate with one another to effect customer requirements.

3 Flow-Oriented Modeling Represents how data objects are transformed at they move through the system data flow diagram (DFD) is the diagrammatic form that is used Considered by many to be an old school approach, but continues to provide a view of the system that is unique it should be used to supplement other analysis model elements

4 The Flow Model Every computer-based system is an information transform... input computer based system output

5 Flow Modeling Notation external entity process data flow data store

6 External Entity A producer or consumer of data Examples: a person, a device, a sensor Another example: computer-based system Data must always originate somewhere and must always be sent to something

7 Process A data transformer (changes input to output) Examples: compute taxes, determine area, format report, display graph Data must always be processed in some way to achieve system function

8 Data Flow Data flows through a system, beginning as input and transformed into output. base height compute triangle area area

9 Data Stores Data is often stored for later use. report required sensor # look-up sensor data sensor number sensor #, type, location, age type, location, age sensor data

10 Data Flow Diagramming: Guidelines all icons must be labeled with meaningful names the DFD evolves through a number of levels of detail always begin with a context level diagram (also called level 0) always show external entities at level 0 always label data flow arrows do not represent procedural logic

11 Constructing a DFD I review user scenarios and/or the data model to isolate data objects and use a grammatical parse to determine operations determine external entities (producers and consumers of data) create a level 0 DFD

12 Level 0 DFD Example user video source processing request NTSC video signal digital video processor requested video signal monitor

13 Constructing a DFD II write a narrative describing the transform parse to determine next level transforms balance the flow to maintain data flow continuity develop a level 1 DFD use a 1:5 (approx.) expansion ratio

14 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

15 Flow Modeling Notes each bubble is refined until it does just one thing the expansion ratio decreases as the number of levels increase most systems require between 3 and 7 levels for an adequate flow model a single data flow item (arrow) may be expanded as levels increase (data dictionary provides information)

16 Process Specification (PSPEC) bubble PSPEC narrative pseudocode (PDL) equations tables diagrams and/or charts

17 DFDs: A Look Ahead analysis model Maps into design model

18 Control Flow Modeling Represents events and the processes that manage events An event is a Boolean condition that can be ascertained by: listing all sensors that are "read" by the software. listing all interrupt conditions. listing all "switches" that are actuated by an operator. listing all data conditions. recalling the noun/verb parse that was applied to the processing narrative, review all "control items" as possible CSPEC inputs/outputs.

19 Control Specification (CSPEC) The CSPEC can be: state diagram (sequential spec) state transition table decision tables combinatorial spec activation tables

20 Behavioral Modeling The behavioral model indicates how software will respond to external events or stimuli. To create the model, the analyst must perform the following steps: Evaluate all use-cases to fully understand the sequence of interaction within the system. Identify events that drive the interaction sequence and understand how these events relate to specific objects. Create a sequence for each use-case. Build a state diagram for the system. Review the behavioral model to verify accuracy and consistency.

21 State Representations In the context of behavioral modeling, two different characterizations of states must be considered: the state of each class as the system performs its function and the state of the system as observed from the outside as the system performs its function The state of a class takes on both passive and active characteristics [CHA93]. A passive state is simply the current status of all of an object s attributes. The active state of an object indicates the current status of the object as it undergoes a continuing transformation or processing.

22 State Diagram for the ControlPanel Class

23 The States of a System state a set of observable circumstances that characterizes the behavior of a system at a given time state transition the movement from one state to another event an occurrence that causes the system to exhibit some predictable form of behavior action process that occurs as a consequence of making a transition

24 UML Statechart Diagram Notation Event trigger With parameters State1 do/activity entry /action exit/action Event1(attr) [condition]/action Guard condition State2 Also: internal transition and deferred events Notation based on work by Harel Added are a few object-oriented modifications A UML statechart diagram can be mapped into a finite state machine Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 17

25 Statechart Diagrams Graph whose nodes are states and whose directed arcs are transitions labeled by event names. We distinguish between two types of operations in statecharts: Activity: Operation that takes time to complete associated with states Action: Instantaneous operation associated with events associated with states (reduces drawing complexity): Entry, Exit, Internal Action A statechart diagram relates events and states for one class An object model with a set of objects has a set of state diagrams Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 18

26 State An abstraction of the attributes of a class State is the aggregation of several attributes a class Basically an equivalence class of all those attribute values and links that do no need to be distinguished as far as the control structure of the system is concerned Example: State of a bank A bank is either solvent or insolvent State has duration Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 19

27 Example of a StateChart Diagram Idle Collect Money coins_in(amount) / add to balance coins_in(amount) / set balance cancel / refund coins [item empty] [select(item)] [change<0] do: test item and compute change [change=0] [change>0] do: dispense item do: make change Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 20

28 Nested State Diagram Activities in states are composite items denoting other lower-level state diagrams A lower-level state diagram corresponds to a sequence of lower-level states and events that are invisible in the higher-level diagram. Sets of substates in a nested state diagram denote a superstate are enclosed by a large rounded box, also called contour. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 21

29 Example of a Nested Statechart Diagram Idle coins_in(amount) / set balance cancel / refund coins Collect Money coins_in(amount) / add to balance [item empty] [select(item)] [change<0] Superstate do: test item and compute change [change=0] [change>0] do: dispense item do: make change Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 22

30 Expanding activity do:dispense item Dispense item as an atomic activity: [change=0] do: dispense item Dispense item as a composite activity: do: move arm to row arm ready do: move arm to column arm ready do: push item off shelf Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 23

31 Superstates Goal: Avoid spaghetti models Reduce the number of lines in a state diagram Transitions from other states to the superstate enter the first substate of the superstate. Transitions to other states from a superstate are inherited by all the substates (state inheritance) Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 24

32 Modeling Concurrency Two types of concurrency 1. System concurrency State of overall system as the aggregation of state diagrams, one for each object. Each state diagram is executing concurrently with the others. 2. Object concurrency An object can be partitioned into subsets of states (attributes and links) such that each of them has its own subdiagram. The state of the object consists of a set of states: one state from each subdiagram. State diagrams are divided into subdiagrams by dotted lines. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 25

33 Example of Concurrency within an Object Splitting control Synchronization Emitting Do: Dispense Cash Cash taken Setting Up Ready Ready to reset Do: Eject Card Card taken Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 26

34 State Chart Diagram vs Sequence Diagram State chart diagrams help to identify: Changes to an individual object over time Sequence diagrams help to identify The temporal relationship of between objects over time Sequence of operations as a response to one ore more events Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 27

35 Behavioral Modeling make a list of the different states of a system (How does the system behave?) indicate how the system makes a transition from one state to another (How does the system change state?) indicate event indicate action draw a state diagram or a sequence diagram

36 Sequence Diagram

37 Heuristics for Sequence Diagrams Layout: 1st column: Should correspond to the actor who initiated the use case 2nd column: Should be a boundary object 3rd column: Should be the control object that manages the rest of the use case Creation: Control objects are created at the initiation of a use case Boundary objects can create new control objects Access: Entity objects are accessed by control and boundary objects, Entity objects should never call boundary or control objects: This makes it easier to share entity objects across use cases and makes entity objects resilient against technology-induced changes in boundary objects. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 5

38 League Owner An ARENA Sequence Diagram : Create Tournament newtournament (league) :Tournament Boundary :Arena :League setname(name) «new» :Announce Tournament Control checkmax Tournament() setmaxplayers (maxp) commit() createtournament (name, maxp) create Tournament (name, maxp) «new» :Tournament Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 6

39 Impact on ARENA s Object Model Let s assume, before we formulated the previous sequence diagram, ARENA s object model contained the objects League Owner, Arena, League, Tournament, Match and Player The Sequence Diagram identified new Classes Tournament Boundary, Announce_Tournament_Control Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 7

40 LeagueOwner Attributes Operations Tournament_ Boundary Attributes Operations Announce_ Tournament_ Control Attributes Operations 1 * League Attributes Operations Tournament Attributes Operations Attributes Player Operations * * Attributes Match Operations Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 8

41 Impact on ARENA s Object Model (ctd) The Sequence Diagram also supplied us with a lot of new events newtournament(league) setname(name) setmaxplayers(max) Commit checkmaxtournaments() createtournament Question: Who owns these events? Answer: For each object that receives an event there is a public operation in the associated class. The name of the operation is usually the name of the event. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 9

42 Example from the Sequence Diagram League Owner newtournament (league) :Tournament Boundary createtournament :Arena :League is a (public) operation owned by Announce_Tournament_Control setname(name) «new» :Announce Tournament Control checkmax Tournament() setmaxplayers (maxp) commit() createtournament (name, maxp) create Tournament (name, maxp) «new» :Tournament Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 10

43 League Owner Attributes Operations Tournament_ Boundary Attributes Operations 1 * Attributes League Operations Announce_ Tournament_ Control Attributes createtournament (name, maxp) Tournament Attributes Operations Attributes Player Operations * * Attributes Match Operations Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 11

44 What else can we get out of sequence diagrams? Sequence diagrams are derived from the use cases. We therefore see the structure of the use cases. The structure of the sequence diagram helps us to determine how decentralized the system is. We distinguish two structures for sequence diagrams: Fork and Stair Diagrams (Ivar Jacobsen) Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 12

45 Heuristics for developing sequence diagrams Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 13

46 Fork Diagram Much of the dynamic behavior is placed in a single object, usually the control object. It knows all the other objects and often uses them for direct questions and commands. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 14

47 Stair Diagram The dynamic behavior is distributed. Each object delegates some responsibility to other objects. Each object knows only a few of the other objects and knows which objects can help with a specific behavior. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 15

48 Fork or Stair? Which of these diagram types should be chosen? Object-oriented fans claim that the stair structure is better The more the responsibility is spread out, the better However, this is not always true. Better heuristics: Decentralized control structure The operations have a strong connection The operations will always be performed in the same order Centralized control structure (better support of change) The operations can change order New operations can be inserted as a result of new requirements Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 16

49 Writing the Software Specification Everyone knew exactly what had to be done until someone wrote it down!

50 Patterns for Requirements Modeling Software patterns are a mechanism for capturing domain knowledge in a way that allows it to be reapplied when a new problem is encountered domain knowledge can be applied to a new problem within the same application domain the domain knowledge captured by a pattern can be applied by analogy to a completely different application domain. The original author of an analysis pattern does not create the pattern, but rather, discovers it as requirements engineering work is being conducted. Once the pattern has been discovered, it is documented

51 Discovering Analysis Patterns The most basic element in the description of a requirements model is the use case. A coherent set of use cases may serve as the basis for discovering one or more analysis patterns. A semantic analysis pattern (SAP) is a pattern that describes a small set of coherent use cases that together describe a basic generic application. [Fer00]

52 An Example Consider the following preliminary use case for software required to control and monitor a real-view camera and proximity sensor for an automobile: Use case: Monitor reverse motion Description: When the vehicle is placed in reverse gear, the control software enables a video feed from a rear-placed video camera to the dashboard display. The control software superimposes a variety of distance and orientation lines on the dashboard display so that the vehicle operator can maintain orientation as the vehicle moves in reverse. The control software also monitors a proximity sensor to determine whether an object is inside 10 feet of the rear of the vehicle. It will automatically break the vehicle if the proximity sensor indicates an object within 3 feet of the rear of the vehicle.

53 An Example This use case implies a variety of functionality that would be refined and elaborated (into a coherent set of use cases) during requirements gathering and modeling. Regardless of how much elaboration is accomplished, the use case(s) suggest(s) a simple, yet widely applicable SAP the software-based monitoring and control of sensors and actuators in a physical system. In this case, the sensors provide information about proximity and video information. The actuator is the breaking system of the vehicle (invoked if an object is very close to the vehicle. But in a more general case, a widely applicable pattern is discovered --> Actuator-Sensor

54 Actuator-Sensor Pattern I Pattern Name: Actuator-Sensor Intent: Specify various kinds of sensors and actuators in an embedded system. Motivation: Embedded systems usually have various kinds of sensors and actuators. These sensors and actuators are all either directly or indirectly connected to a control unit. Although many of the sensors and actuators look quite different, their behavior is similar enough to structure them into a pattern. The pattern shows how to specify the sensors and actuators for a system, including attributes and operations. The Actuator-Sensor pattern uses a pull mechanism (explicit request for information) for PassiveSensors and a push mechanism (broadcast of information) for the ActiveSensors. Constraints: Each passive sensor must have some method to read sensor input and attributes that represent the sensor value. Each active sensor must have capabilities to broadcast update messages when its value changes. Each active sensor should send a life tick, a status message issued within a specified time frame, to detect malfunctions. Each actuator must have some method to invoke the appropriate response determined by the ComputingComponent. Each sensor and actuator should have a function implemented to check its own operation state. Each sensor and actuator should be able to test the validity of the values received or sent and set its operation state if the values are outside of the specifications.

55 Actuator-Sensor Pattern II Applicability: Useful in any system in which multiple sensors and actuators are present. Structure: A UML class diagram for the Actuator-Sensor Pattern is shown in Figure 7.8. Actuator, PassiveSensor and ActiveSensor are abstract classes and denoted in italics. There are four different types of sensors and actuators in this pattern. The Boolean, integer, and real classes represent the most common types of sensors and actuators. The complex classes are sensors or actuators that use values that cannot be easily represented in terms of primitive data types, such as a radar device. Nonetheless, these devices should still inherit the interface from the abstract classes since they should have basic functionalities such as querying the operation states.

56 Actuator-Sensor Pattern III Behavior: Figure 7.9 presents a UML sequence diagram for an example of the Actuator-Sensor Pattern as it might be applied for the SafeHome function that controls the positioning (e.g., pan, zoom) of a security camera. Here, the ControlPanel queries a sensor (a passive position sensor) and an actuator (pan control) to check the operation state for diagnostic purposes before reading or setting a value. The messages Set Physical Value and Get Physical Value are not messages between objects. Instead, they describe the interaction between the physical devices of the system and their software counterparts. In the lower part of the diagram, below the horizontal line, the PositionSensor reports that the operation state is zero. The ComputingComponent then sends the error code for a position sensor failure to the FaultHandler that will decide how this error affects the system and what actions are required. it gets the data from the sensors and computes the required response for the actuators.

57 Actuator-Sensor Pattern III See SEPA, 7/e for additional information on: Participants Collaborations Consequences

58 Requirements Modeling for WebApps Content Analysis. The full spectrum of content to be provided by the WebApp is identified, including text, graphics and images, video, and audio data. Data modeling can be used to identify and describe each of the data objects. Interaction Analysis. The manner in which the user interacts with the WebApp is described in detail. Use-cases can be developed to provide detailed descriptions of this interaction. Functional Analysis. The usage scenarios (use-cases) created as part of interaction analysis define the operations that will be applied to WebApp content and imply other processing functions. All operations and functions are described in detail. Configuration Analysis. The environment and infrastructure in which the WebApp resides are described in detail.

59 When Do We Perform Analysis? In some WebE situations, analysis and design merge. However, an explicit analysis activity occurs when the WebApp to be built is large and/or complex the number of stakeholders is large the number of Web engineers and other contributors is large the goals and objectives (determined during formulation) for the WebApp will effect the business bottom line the success of the WebApp will have a strong bearing on the success of the business

60 The Content Model Content objects are extracted from use-cases examine the scenario description for direct and indirect references to content Attributes of each content object are identified The relationships among content objects and/or the hierarchy of content maintained by a WebApp Relationships entity-relationship diagram or UML Hierarchy data tree or UML

61 Data Tree

62 The Interaction Model Composed of four elements: use-cases sequence diagrams state diagrams a user interface prototype Each of these is an important UML notation and is described in Appendix I

63 Sequence Diagram

64 State Diagram

65 The Functional Model The functional model addresses two processing elements of the WebApp user observable functionality that is delivered by the WebApp to end-users the operations contained within analysis classes that implement behaviors associated with the class. An activity diagram can be used to represent processing flow

66 Activity Diagram

67 The Configuration Model Server-side Server hardware and operating system environment must be specified Interoperability considerations on the server-side must be considered Appropriate interfaces, communication protocols and related collaborative information must be specified Client-side Browser configuration issues must be identified Testing requirements should be defined

68 Navigation Modeling-I Should certain elements be easier to reach (require fewer navigation steps) than others? What is the priority for presentation? Should certain elements be emphasized to force users to navigate in their direction? How should navigation errors be handled? Should navigation to related groups of elements be given priority over navigation to a specific element. Should navigation be accomplished via links, via searchbased access, or by some other means? Should certain elements be presented to users based on the context of previous navigation actions? Should a navigation log be maintained for users?

69 Navigation Modeling-II Should a full navigation map or menu (as opposed to a single back link or directed pointer) be available at every point in a user s interaction? Should navigation design be driven by the most commonly expected user behaviors or by the perceived importance of the defined WebApp elements? Can a user store his previous navigation through the WebApp to expedite future usage? For which user category should optimal navigation be designed? How should links external to the WebApp be handled? overlaying the existing browser window? as a new browser window? as a separate frame?

70 Summary: Requirements Analysis 1. What are the transformations? Functional Modeling Create scenarios and use case diagrams Talk to client, observe, get historical records, do thought experiments 2. What is the structure of the system? Object Modeling Create class diagrams Identify objects. What are the associations between them? What is their multiplicity? What are the attributes of the objects? What operations are defined on the objects? 3. What is its behavior? Dynamic Modeling Create sequence diagrams Identify senders and receivers Show sequence of events exchanged between objects. Identify event dependencies and event concurrency. Create state diagrams Only for the dynamically interesting objects. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 31

71 Let s Do Analysis 1. Analyze the problem statement Identify functional requirements Identify nonfunctional requirements Identify constraints (pseudo requirements) 2. Build the functional model: Develop use cases to illustrate functionality requirements 3. Build the dynamic model: Develop sequence diagrams to illustrate the interaction between objects Develop state diagrams for objects with interesting behavior 4. Build the object model: Develop class diagrams showing the structure of the system Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 32

72 Problem Statement: Direction Control for a Toy Car Power is turned on Car moves forward and car headlight shines Power is turned off Car stops and headlight goes out. Power is turned on Headlight shines Power is turned off Headlight goes out. Power is turned on Car runs backward with its headlight shining. Power is turned off Car stops and headlight goes out. Power is turned on Headlight shines Power is turned off Headlight goes out. Power is turned on Car runs forward with its headlight shining. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 33

73 Find the Functional Model: Do Use Case Modeling Use case 1: System Initialization Entry condition: Power is off, car is not moving Flow of events: Driver turns power on Exit condition: Car moves forward, headlight is on Use case 2: Turn headlight off Entry condition: Car moves forward with headlights on Flow of events: Driver turns power off, car stops and headlight goes out. Driver turns power on, headlight shines and car does not move. Driver turns power off, headlight goes out Exit condition: Car does not move, headlight is out Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 34

74 Use Cases continued Use case 3: Move car backward Entry condition: Car is stationary, headlights off Flow of events: Driver turns power on Exit condition: Car moves backward, headlight on Use case 4: Stop backward moving car Entry condition: Car moves backward, headlights on Flow of events: Driver turns power off, car stops, headlight goes out. Power is turned on, headlight shines and car does not move. Power is turned off, headlight goes out. Exit condition: Car does not move, headlight is out. Use case 5: Move car forward Entry condition: Car does not move, headlight is out Flow of events Driver turns power on Exit condition: Car runs forward with its headlight shining. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 35

75 Use Case Pruning Do we need use case 5? Use case 1: System Initialization Entry condition: Power is off, car is not moving Flow of events: Driver turns power on Exit condition: Car moves forward, headlight is on Use case 5: Move car forward Entry condition: Car does not move, headlight is out Flow of events Driver turns power on Exit condition: Car runs forward with its headlight shining. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 36

76 Find the Dynamic Model: Create sequence diagram Name: Drive Car Sequence of events: Billy turns power on Headlight goes on Wheels starts moving forward Wheels keeps moving forward Billy turns power off Headlight goes off Wheels stops moving... Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 37

77 Sequence Diagram for Drive Car Scenario :Headlight Billy:Driver :Wheel Power(on) Power(on) Power(off) Power(off) Power(on) Power(on) Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 38

78 Toy Car: Dynamic Model Headlight Wheel Forward power off Off power on power on power off On Stationary Stationary power off power on Backward Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 39

79 Toy Car: Object Model Car Power Headlight Wheel Status: (On, Off) TurnOn() TurnOff() Status: (On, Off) Switch_On() Switch_Off() Motion: (Forward, Backward, Stationary) Start_Moving() Stop_Moving() Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 40

80 When is a model dominant? Object model: The system has objects with nontrivial state. Dynamic model: The model has many different types of events: Input, output, exceptions, errors, etc. Functional model: The model performs complicated transformations (e.g. computations consisting of many steps). Which of these models is dominant in the following three cases? Compiler Database system Spreadsheet program Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 41

81 Dominance of models Compiler: The functional model most important. (Why?) The dynamic model is trivial because there is only one type input and only a few outputs. Database systems: The object model most important. The functional model is trivial, because the purpose of the functions is usually to store, organize and retrieve data. Spreadsheet program: The functional model most important. The dynamic model is interesting if the program allows computations on a cell. The object model is trivial, because the spreadsheet values are trivial and cannot be structured further. The only interesting object is the cell. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 42

82 Requirements Analysis Document Template 1. Introduction 2. Current system 3. Proposed system 3.1 Overview 3.2 Functional requirements 3.3 Nonfunctional requirements 3.4 Constraints ( Pseudo requirements ) 3.5 System models Scenarios Use case model Object model Data dictionary Class diagrams Dynamic models User interface 4. Glossary Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 43

83 Section 3.5 System Model Scenarios - As-is scenarios, visionary scenarios Use case model - Actors and use cases Object model - Data dictionary - Class diagrams (classes, associations, attributes and operations) Dynamic model - State diagrams for classes with significant dynamic behavior - Sequence diagrams for collaborating objects (protocol) User Interface - Navigational Paths, Screen mockups Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 44

84 Section 3.3 Nonfunctional Requirements User interface and human factors Documentation Hardware considerations Performance characteristics Error handling and extreme conditions System interfacing Quality issues System modifications Physical environment Security issues Resources and management issues Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 45

85 Nonfunctional Requirements: Trigger Questions User interface and human factors What type of user will be using the system? Will more than one type of user be using the system? What sort of training will be required for each type of user? Is it particularly important that the system be easy to learn? Is it particularly important that users be protected from making errors? What sort of input/output devices for the human interface are available, and what are their characteristics? Documentation What kind of documentation is required? What audience is to be addressed by each document? Hardware considerations What hardware is the proposed system to be used on? What are the characteristics of the target hardware, including memory size and auxiliary storage space? Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 46

86 Nonfunctional Requirements, ctd Performance characteristics Are there any speed, throughput, or response time constraints on the system? Are there size or capacity constraints on the data to be processed by the system? Error handling and extreme conditions How should the system respond to input errors? How should the system respond to extreme conditions? System interfacing Is input coming from systems outside the proposed system? Is output going to systems outside the proposed system? Are there restrictions on the format or medium that must be used for input or output? Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 47

87 Nonfunctional Requirements, ctd Quality issues What are the requirements for reliability? Must the system trap faults? What is the maximum time for restarting the system after a failure? What is the acceptable system downtime per 24-hour period? Is it important that the system be portable (able to move to different hardware or operating system environments)? System Modifications What parts of the system are likely candidates for later modification? What sorts of modifications are expected? Physical Environment Where will the target equipment operate? Will the target equipment be in one or several locations? Will the environmental conditions in any way be out of the ordinary (for example, unusual temperatures, vibrations, magnetic fields,...)? Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 48

88 Nonfunctional Requirements, ctd Security Issues Must access to any data or the system itself be controlled? Is physical security an issue? Resources and Management Issues How often will the system be backed up? Who will be responsible for the back up? Who is responsible for system installation? Who will be responsible for system maintenance? Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 49

89 Constraints (Pseudo Requirements) Constraint: Any client restriction on the solution domain Examples: The target platform must be an IBM/360 The implementation language must be COBOL The documentation standard X must be used A dataglove must be used ActiveX must be used The system must interface to a papertape reader Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 50