Outline

1. Outline • Dynamic models • Sequence diagrams • Dynamic model of user interfaces • Analysis example • Requirements analysis document outline

2. Example of use case format Use case name: ReportEmergency Entry condition 1. The FieldOfficer activates the “Report Emergency” function of her terminal. Flow of events 2. FRIEND responds by presenting a form to the officer... 3. The FieldOfficer fills the form.... 4. The Dispatcher reviews the information submitted by FieldOfficer ... Exit condition 5. The FieldOfficer receives acknowledgment & the selected response.

3. How do you find classes? • Previously discussed • Application domain analysis: Client helps identify abstractions • Apply general world knowledge & intuition • Scenarios • Natural language formulation of a concrete use of the system • Use Cases • Natural language formulation of the system functions • Textual analysis of problem statement • From this lecture • Dynamic model (sequence diagrams) • Actions: class method candidates • Actors: object candidates • From future lectures • Design Patterns

4. Dynamic Modeling with UML • Sequence Diagram • Use case event flow rendered at class level. • State Charts: • Describes an object’s response to external stimuli (Events).

5. Dynamic Model • A dynamic model • A set of sequence diagrams, one for each class. • Purpose • Discover methods • How do we do this? • Start with use case • Model interaction between objects => sequence diagram • Model dynamic behavior of single objects => statechart diagram

6. Start with Flow of Events from Use Case • Flow of events from “Dial a Number” Use case • Caller lifts phone’s receiver • Caller phone dail tone begins • Caller dials callee • Callee phone rings • Callee answers phone • Callee phone ringing stops • ....

7. What is an Event? • Something that happens at a point in time • Relation of events to each other • Causally related: Event A must come [before, after] event B • Causally unrelated: concurrent • An event causes an object to message another. • Events form an event class hierarchy. • Event instance: “New IETM issued Thu. Sep. 14, 9:30 AM”. • Event class “New IETM” • Event attribute • IETM Update (9:30 AM, 9/14/99) • Car starts ( 4:45pm, Monroeville Mall, Parking Lot 23a) • Mouse button down(button#, tablet-location)

8. Sequence Diagram • Refine a use case’s flow of events into a sequence diagram • Relation to object identification • Initial classes have been identified during object modeling. • Classes are refined as a result of sequence diagram creation. • Heuristic • An event has a sender & a receiver. • These are the use case’s participating classes.

9. An Example • Flow of events in a “Get SeatPosition” use case 1. Establish connection between smart card & onboard computer 2. Establish connection between onboard computer & seat sensor 3. Get current seat position & store on smart card • Which are the objects?

10. Sequence Diagram for “Get SeatPosition” Seat Onboard Computer Smart Card • 1. Establish connection between smart card and onboard computer • 2. Establish connection between onboard computer and sensor for seat • 3. Get current seat position and store on smart card Establish Connection Establish Connection Accept Connection Accept Connection Get SeatPosition “500,575,300”

11. Heuristics for Sequence Diagrams • Layout • 1st column: The actor who initiates the use case • 2nd column: A boundary object • 3rd column: The control object that manages the rest of the use case • Creation • Control objects are created when the use case begins. • Boundary objects are created by control objects. • Access • Entity objects are accessed by control & boundary objects. • Entity objects never call boundary/control objects. • This makes: • it easier to share entity objects among use cases • entity objects resilient to changes in boundary objects.

15. State Chart Diagram vs. Sequence Diagram • State chart diagrams help to identify • Changes to objects over time • Sequence diagrams help to identify • The temporal relationship between objects over time • Sequence of operations as a response to an event

16. Dynamic Modeling of User Interfaces • Statechart diagrams can be used model user interface interaction • States: Name of screens • Graphical layout of the associated screens helps when presenting the interaction model to a user • Activities/actions are shown as bullets under screen name • Often only the exit action is shown • State transitions: Result of exit action • Button click • Menu selection • Cursor movements • Good for web-based user interface design

17. User Interface Interaction Example • Diagnostics • User moves cursor to Control Panel or Graph • Graph • User selects data group & type of graph • Control panel • User selects functionality of sensors • Selection • User selects data group • Field site • Car • Sensor group • Time range • User selects type of graph • time line • histogram • pie chart • Define • User defines a sensor event • from a list of events • Disable • User disables a sensor event from a list of sensor events • Enable • User enables a sensor event from a list of sensor events • Event list • User selects event(s) • Visualize • User views graph • User adds data groups for view • Sensor event list • User selects sensor event(s) • Link • User makes a link (doclink)

18. Summary: Requirements Analysis Functional Modeling • What are the functions? • Create scenarios & use case model • Talk to client, observe, get historical records, do thought experiments • What is the structure of the system? • Create class diagrams • Identify classes, associations? What is their multiplicity? • Identify are the attributes? • Identify operations? • What is its control structure? • Create sequence diagrams • Identify senders & receivers • Show sequence of events exchanged between objects. • Identify event dependencies. Object Modeling Dynamic Modeling

19. Let’s Do an Analysis 1. Analyze a problem statement • Identify functional requirements • Identify nonfunctional requirements • Identify constraints (pseudo requirements) 2. Build the functional model • Develop use cases to illustrate system functions 3. Build the dynamic model • Develop sequence diagrams to illustrate class interaction 4. Build the object model • Develop class diagrams showing the structure of the system

20. This actually is a state description Power is turned on Car goes forward, headlights on Power is turned off Car stops & headlights out. Power is turned on Headlights on. Power is turned off Headlights out. Power is turned on Car goes backward, headlights on. Power is turned off Car stops, headlights out. Power is turned on Headlights on. Power is turned off Headlights out. Power is turned on Car goes forward, headlights on. Problem Statement: Control for a Toy Car

21. Find the Functional Model: Create Use Case Model • Use case 1: System Initialization • Entry condition: Power off, car stationary, headlights off. • Flow of events: • Driver turns power on • Exit condition: Power on, car moving forward, headlights on. • Use case 2: Turn headlight off • Entry condition: Power on, car moves forward, headlights on. • Flow of events: • Driver turns power off, car stops, headlights go out. • Driver turns power on, headlights go on, car stationary. • Driver turns power off, headlights go out. • Exit condition: Power off, car stationary, headlights out.

22. Use Cases … • Use case 3: Move car backward • Entry condition: Power off, car stationary, headlights off. • Flow of events: • Driver turns power on • Exit condition: Power on, car moving backward, headlights on • Use case 4: Stop backward moving car • Entry condition: Power on, car moving backward, headlights on. • Flow of events: • Driver turns power off, car stops, headlights out. • Power is turned on, headlights go on, car stationary. • Power is turned off, headlights go out. • Exit condition: Power off, car stationary, headlights out. • Use case 5: Move car forward • Entry condition: Power is off, car stationary, headlights out. • Flow of events • Driver turns power on • Exit condition: • Power on, car moving forward, headlights on.

23. Use Case Pruning • Do we need use case 5? • Use case 1: System Initialization • Entry condition: Power is off, car is stationary, headlights are off. • Flow of events: • Driver turns power on. • Exit condition: Car moving forward, headlights are on. • Use case 5: Move car forward • Entry condition: Car not moving, headlights are out. • Flow of events • Driver turns power on • Exit condition: • Car moving forward, headlights are on.

24. Wheels Motion: (For ward, Reverse, Neutral) Toggle() Toy Car: Object Model Car Headlights Power Status: (On, Off) Status: (On, Off) Toggle() Toggle()

25. Sequence Diagram for Drive Car Use Cases Driver Power Switch Headlights Wheels Toggle() Toggle() Toggle() Toggle() Toggle() Toggle() Toggle() Toggle() Toggle() Toggle() Toggle() Toggle()

26. State Diagrams of PowerSwitch, Headlights, Wheels

27. Analysis: UML Activity Diagram

28. Requirements Analysis Document Outline 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 3.5.1 Scenarios 3.5.2 Use case model 3.5.3 Object model 3.5.3.1 Data dictionary 3.5.3.2 Class diagrams 3.5.4 Dynamic models 3.5.5 User interface 4. Glossary

29. Section 3.5 System Model 3.5.1 Scenarios - As-is scenarios, visionary scenarios 3.5.2 Use case model - Actors & use cases 3.5.3 Object model - Data dictionary - Class diagrams (classes, associations, attributes and operations) 3.5.4 Dynamic model - Sequence diagrams for collaborating objects (protocol) 3.5.5 User Interface - UI interactions

30. Section 3.3 Nonfunctional Requirements 3.3.1 User interface & human factors 3.3.2 Documentation 3.3.3 Hardware considerations 3.3.4 Performance characteristics 3.3.5 Error handling & extreme conditions 3.3.6 System interfacing 3.3.7 Quality issues 3.3.8 Physical environment 3.3.9 Security issues 3.3.10 Resource & management issues

31. Nonfunctional Requirements: Trigger Questions 3.3.1 User interface & human factors • What are the types of users? • What sort of training is required for each type of user? • Is it important that the system be easy to learn? • Is it 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? 3.3.2 Documentation • What kind of documentation is required? • What audience is to be addressed by each document? 3.3.3 Hardware considerations • What hardware is the proposed system to be used on? • What are the characteristics of the target hardware, including memory size & auxiliary storage space?

32. Nonfunctional Requirements … 3.3.4 Performance characteristics • Are there any speed, throughput, or response time constraints? • Are there size or capacity constraints on the data? 3.3.5 Extreme conditions • How should the system respond to extreme conditions? 3.3.6 System interfacing • Is input coming from external systems? • Is output going to external systems? • Are there restrictions on the format or medium that must be used for input / output?

33. Nonfunctional Requirements … • 3.3.7 Quality issues • What are the requirements for reliability? • Must the system trap faults? • Is there a maximum time for restarting the system after a failure? • What is the maximum system downtime per 24-hour period? • Is it important that the system be portable (able to move to different hardware or operating system environments)? • 3.3.8 Physical Environment • Where will the target equipment operate? • Will the target equipment be in one or several locations? • Will the environmental conditions be out of the ordinary (e. g., unusual temperatures, vibrations, magnetic fields)?

34. Nonfunctional Requirements … • 3.3.9 Security Issues • Must access to any data or the system itself be controlled? • Is physical security an issue? • 3.3.10 Resources & 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?

35. Pseudo Requirements • Pseudo requirement • Any client restriction on the solution domain • Examples • The target platform must be an IBM/360 • The implementation language must be Java • Documentation standard X must be used • A dataglove must be used • ActiveX must not be used

36. Project Agreement • It represents the client’s acceptance of the RAD. • The client & developers agree on system functions & features. • In addition, they agree on: • a priority list • a revision process • the system acceptance criteria • a schedule & a budget

37. Prioritizing requirements • High priority (“Requirements”) • Addressed during analysis, design, & implementation. • Demonstrated during client acceptance. • Medium priority (“Optional”) • May be addressed during initial analysis & design. • Usually implemented & demonstrated in the 2nd increment. • Low priority (“Fancy”) • Not addressed during initial analysis (“very visionary scenarios”). • Iteratively implement “requirements” • Optional features of 1st increment become requirements of 2nd increment.

38. Summary We described: • Sequence diagrams for identifying objects & operations. • The requirements analysis document (RAD) & its use when interacting with the client.