Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 1 Outline  Dynamic models  Sequence diagrams  Dynamic model of user interfaces  Analysis example  Requirements analysis document outline

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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 The FieldOfficer fills the form The Dispatcher reviews the information submitted by FieldOfficer... Exit condition 5. The FieldOfficer receives acknowledgment & the selected response.

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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).

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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 ....

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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)

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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.

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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?

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 10 Sequence Diagram for “Get SeatPosition” Smart Card Onboard Computer Seat Establish Connection Accept Connection Get SeatPosition “500,575,300” 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

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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.

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 12

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 13

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 14

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 17 User Interface Interaction Example Diagnostics User moves cursor to Control Panel or Graph Graph User selects data group & type of graph Selection User selects data group Field site Car Sensor group Time range User selects type of graph time line histogram pie chart Visualize User views graph User adds data groups for view Link User makes a link (doclink) Control panel User selects functionality of sensors Disable User disables a sensor event from a list of sensor events Define User defines a sensor event from a list of events Enable User enables a sensor event from a list of sensor events Sensor event list User selects sensor event(s) Event list User selects event(s)

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 18 Summary: Requirements Analysis  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. Dynamic Modeling Functional Modeling Object Modeling

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 20 Problem Statement: Control for a Toy Car 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. 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.  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.

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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.

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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.

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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.

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 24 Toy Car: Object Model Wheels Motion: (Forward, Neutral) Reverse, Toggle() Headlights Status: (On, Off) Toggle() Power Status: (On, Off) Toggle() Car

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 25 Sequence Diagram for Drive Car Use Cases HeadlightsDriver Wheels Power Switch Toggle()

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 26 State Diagrams of PowerSwitch, Headlights, Wheels

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 27 Analysis: UML Activity Diagram

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 28 Requirements Analysis Document Outline 1.Introduction 2.Current system 3.Proposed system 3.1Overview 3.2Functional requirements 3.3Nonfunctional requirements 3.4Constraints (“Pseudo requirements”) 3.5System models Scenarios Use case model Object model Data dictionary Class diagrams Dynamic models User interface 4. Glossary

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 29 Section 3.5 System Model Scenarios - As-is scenarios, visionary scenarios Use case model - Actors & use cases Object model - Data dictionary - Class diagrams (classes, associations, attributes and operations) Dynamic model - Sequence diagrams for collaborating objects (protocol) User Interface - UI interactions

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 30 Section 3.3 Nonfunctional Requirements User interface & human factors Documentation Hardware considerations Performance characteristics Error handling & extreme conditions System interfacing Quality issues Physical environment Security issues Resource & management issues

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 31 Nonfunctional Requirements: Trigger Questions 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? 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 & auxiliary storage space?

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 32 Nonfunctional Requirements … Performance characteristics  Are there any speed, throughput, or response time constraints?  Are there size or capacity constraints on the data? Extreme conditions  How should the system respond to extreme conditions? 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?

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 33 Nonfunctional Requirements …  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)?  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)?

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 34 Nonfunctional Requirements …  Security Issues  Must access to any data or the system itself be controlled?  Is physical security an issue?  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?

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 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 1 st increment become requirements of 2 nd increment.

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 38 Summary We described:  Sequence diagrams for identifying objects & operations.  The requirements analysis document (RAD) & its use when interacting with the client.