1. Page 1W5D1 Models. Help us: Understand the system Verify the system Communicate with / coordinate development teams

2. Page 2W5D1 Requirements definition & specification (Models)‏ Requirements specification Structural - entities (class diagrams)‏ Dynamic - behaviour & interaction between entities How to identify classes / entities?

3. Page 3W5D1 Requirements definition & specification (Models)‏ Requirements specification Structural - entities (E-R, class diagrams)‏ Dynamic - behaviour & interaction between entities How to identify classes / entities? Requirements definition: Use cases (use cases from scenarios, scenarios after identifying actors)‏

4. Page 4W5D1 Actors… = external entities interacting with the system = role abstractions (not necessarily human)‏ They help define system boundary

5. Page 5W5D1 Actors… = external entities interacting with the system = role abstractions (not necessarily human)‏ They help define system boundary Which user groups are supported by the system? What groups perform main functions? What groups perform secondary functions (maintenance, system administration, …)? External systems?

6. Page 6W5D1 Scenarios “A narrative description of what people do and experience as they try to make use of computer systems and applications” [M. Carrol, Scenario-based Design, Wiley, 1995] A concrete, focused, informal description of a single feature of the system used by an actor. Scenarios can have many different uses during the software lifecycle –Requirements Elicitation: As-is scenario, visionary scenario –Client Acceptance Test: Evaluation scenario –System Deployment: Training scenario.

7. Page 7W5D1 How do we find scenarios? Don’t expect the client to be verbal if the system does not exist (greenfield engineering) Don’t wait for information even if the system exists Engage in a dialectic approach (evolutionary, incremental engineering)‏ –You help the client to formulate the requirements –The client helps you to understand the requirements –The requirements evolve while the scenarios are being developed

8. Page 8W5D1 Heuristics for finding Scenarios Ask yourself or the client the following questions: –What are the primary tasks that the system needs to perform? –What data will the actor create, store, change, remove or add in the system? –What external changes does the system need to know about? –What changes or events will the actor of the system need to be informed about? However, don’t rely on questionnaires alone. Insist on task observation if the system already exists (interface engineering or reengineering)‏

9. Page 9W5D1 Example: Accident Management System What needs to be done to report a “Cat in a Tree” incident? What do you need to do if a person reports “Warehouse on Fire?” Who is involved in reporting an incident? What does the system do, if no police cars are available? If the police car has an accident on the way to the “cat in a tree” incident? What do you need to do if the “Cat in the Tree” turns into a “Grandma has fallen from the Ladder”? Can the system cope with a simultaneous incident report “Warehouse on Fire?”

10. Page 10W5D1 Scenario Example: Warehouse on Fire Bob, driving down main street in his patrol car notices smoke coming out of a warehouse. His partner, Alice, reports the emergency from her car. Alice enters the address of the building, a brief description of its location (i.e., north west corner), and an emergency level. In addition to a fire unit, she requests several paramedic units on the scene given that area appears to be relatively busy. She confirms her input and waits for an acknowledgment. John, the Dispatcher, is alerted to the emergency by a beep of his workstation. He reviews the information submitted by Alice and acknowledges the report. He allocates a fire unit and two paramedic units to the Incident site and sends their estimated arrival time (ETA) to Alice. Alice received the acknowledgment and the ETA.

11. Page 11W5D1 Observations about Warehouse on Fire Scenario Concrete scenario –Describes a single instance of reporting a fire incident. –Does not describe all possible situations in which a fire can be reported. Participating actors –Bob, Alice and John

12. Page 12W5D1 Next goal, after the scenarios are formulated: Find all the use cases in the scenario that specifies all possible instances of how to report a fire –Example: “Report Emergency “ in the first paragraph of the scenario is a candidate for a use case Describe each of these use cases in more detail –Participating actors –Describe the Entry Condition –Describe the Flow of Events –Describe the Exit Condition –Describe Exceptions –Describe Special Requirements (Constraints, Nonfunctional Requirements

13. Page 13W5D1 ReportEmergency Use Cases A use case is a flow of events in the system, including interaction with actors, it is a generalization of a (several) scenario(s)‏ It is initiated by an actor Each use case has a name Each use case has a termination condition Graphical Notation: An oval with the name of the use case Use Case Model: The set of all use cases specifying the complete functionality of the system

14. Page 14W5D1 Example: Use Case Model for Incident Management ReportEmergency FieldOfficer Dispatcher OpenIncident AllocateResources

15. Page 15W5D1 Use Case Example: ReportEmergency Use case name: ReportEmergency Participating Actors: –Field Officer (Bob and Alice in the Scenario)‏ –Dispatcher (John in the Scenario)‏ Exceptions: –The FieldOfficer is notified immediately if the connection between her terminal and the central is lost. –The Dispatcher is notified immediately if the connection between any logged in FieldOfficer and the central is lost. Flow of Events: on next slide. Special Requirements: –The FieldOfficer’s report is acknowledged within 30 seconds. The selected response arrives no later than 30 seconds after it is sent by the Dispatcher.

16. Page 16W5D1 Use Case Example: ReportEmergency Flow of Events The FieldOfficer activates the “Report Emergency” function of her terminal. Thr system responds by presenting a form to the officer. The FieldOfficer fills the form, by selecting the emergency level, type, location, and brief description of the situation. The FieldOfficer also describes possible responses to the emergency situation. Once the form is completed, the FieldOfficer submits the form, at which point, the Dispatcher is notified. The Dispatcher reviews the submitted information and creates an Incident in the database by invoking the OpenIncident use case. The Dispatcher selects a response and acknowledges the emergency report. The FieldOfficer receives the acknowledgment and the selected response.

17. Page 17W5D1 Another Use Case Example: Allocate a Resource Actors: –Field Supervisor: This is the official at the emergency site.... –Resource Allocator: The Resource Allocator is responsible for the commitment and decommitment of the Resources managed by the system.... –Dispatcher: A Dispatcher enters, updates, and removes Emergency Incidents, Actions, and Requests in the system. The Dispatcher also closes Emergency Incidents. –Field Officer: Reports accidents from the Field

18. Page 18W5D1 Another Use Case Example: Allocate a Resource Use case name: AllocateResources Participating Actors: –Field Officer (Bob and Alice in the Scenario)‏ –Dispatcher (John in the Scenario) –Resource Allocator –Field Supervisor Entry Condition –The Resource Allocator has selected an available resource. –The resource is currently not allocated Flow of Events –The Resource Allocator selects an Emergency Incident. –The Resource is committed to the Emergency Incident. Exit Condition –The use case terminates when the resource is committed. –The selected Resource is now unavailable to any other Emergency Incidents or Resource Requests. Special Requirements –The Field Supervisor is responsible for managing the Resources

19. Page 19W5D1 Order of steps when formulating use cases First step: name the use case –Use case name: ReportEmergency Second step: Find the actors –Generalize the concrete names (“Bob”) to participating actors (“Field officer”)‏ –Participating Actors: Field Officer (Bob and Alice in the Scenario)‏ Dispatcher (John in the Scenario) Third step: Then concentrate on the flow of events –Use informal natural language

20. Page 20W5D1 Use Case Associations A use case model consists of use cases and use case associations –A use case association is a relationship between use cases Important types of use case associations: Include, Extends, Generalization Include –A use case uses another use case (“functional decomposition”)‏ Extends –A use case extends another use case Generalization An abstract use case has different specializations

21. Page 21W5D1 >: Functional Decomposition Problem: –A function in the original problem statement is too complex to be solvable immediately Solution: –Describe the function as the aggregation of a set of simpler functions. The associated use case is decomposed into smaller use cases ManageIncident CreateIncident HandleIncident CloseIncident >

22. Page 22W5D1 >: Reuse of Existing Functionality Problem: –There are already existing functions. How can we reuse them? Solution: –The include association from a use case A to a use case B indicates that an instance of the use case A performs all the behavior described in the use case B (“A delegates to B”)‏ Example: –The use case “ViewMap” describes behavior that can be used by the use case “OpenIncident” (“ViewMap” is factored out)‏ ViewMap OpenIncident AllocateResources > Base Use Case Supplier Use Case Note: The base case cannot exist alone. It is always called with the supplier use case

23. Page 23W5D1 > Association for Use Cases Problem: –The functionality in the original problem statement needs to be extended. Solution: –An extend association from a use case A to a use case B indicates that use case B is an extension of use case A. Example: –The use case “ReportEmergency” is complete by itself, but can be extended by the use case “Help” for a specific scenario in which the user requires help ReportEmergency FieldOfficerf Help > Note: The base use case can be executed without the use case extension in extend associations.

24. Page 24W5D1 Generalization association in use cases Problem: –You have common behavior among use cases and want to factor this out. Solution: –The generalization association among use cases factors out common behavior. The child use cases inherit the behavior and meaning of the parent use case and add or override some behavior. Example: –Consider the use case “ValidateUser”, responsible for verifying the identity of the user. The customer might require two realizations: “CheckPassword” and “CheckFingerprint” ValidateUser CheckPassword CheckFingerprint Parent Case Child Use Case

25. Page 25W5D1 From Use Cases to Classes/Objects Top Level Use Case Level 2 Use Cases Level 3 Use Cases Operations Participating Objects Lev el 2 Lev el 1 Lev el 2 Lev el 3 Lev el 3 Lev el 4 Lev el 4 Lev el 3 AB

26. Page 26W5D1 How to Specify a Use Case (Summary)‏ Name of Use Case Actors –Description of Actors involved in use case Entry condition –“This use case starts when…” Flow of Events –Free form, informal natural language Exit condition –“This use cases terminates when…” Exceptions –Describe what happens if things go wrong Special Requirements –Nonfunctional Requirements, Constraints

27. Page 27W5D1 How do you find classes/entities? Finding objects/entities is the central piece in requirements specification –Learn about problem domain: Observe your client –Apply general world knowledge and intuition –Take the flow of events and find participating objects in use cases –Try to establish a taxonomy –Do a syntactic analysis of problem statement, scenario or flow of events –Abbott Textual Analysis, 1983, also called noun-verb analysis Nouns are good candidates for classes Verbs are good candidates for operations

28. Page 28W5D1 Finding Participating Objects in Use Cases Pick a use case and look at its flow of events –Find terms that developers or users need to clarify in order to understand the flow of events –Look for recurring nouns (e.g., Incident), –Identify real world entities that the system needs to keep track of (e.g., FieldOfficer, Dispatcher, Resource), –Identify real world procedures that the system needs to keep track of (e.g., EmergencyOperationsPlan), –Identify data sources or sinks (e.g., Printer)‏ –Identify interface artifacts (e.g., PoliceStation)‏ Be prepared that some objects are still missing and need to be found: Model the flow of events with a sequence diagram Try to use the user’s terms

29. Page 29W5D1 Object Types Entity Objects –Represent the persistent information tracked by the system (Application domain objects, “Business objects”)‏ Boundary Objects –Represent the interaction between the environment and the system Control Objects: –Represent the control tasks performed by the system Having three types of objects leads to models that are more resilient to change. –The interface of a system changes more likely than the control –The control of the system change more likely than the application domain

30. Page 30W5D1 Example: 2BWatch Objects Year Month Day ChangeDate Button LCDDisplay Entity Objects Control ObjectsBoundary Objects

31. Page 31W5D1 Naming of Object Types in UML UML provides several mechanisms to extend the language: the stereotype mechanism > to present new modeling elements > Year > Month > Day > ChangeDate > Button > LCDDisplay Entity Objects Control ObjectsBoundary Objects

32. Page 32W5D1 Idea: Naming Convention for Object Types Objects ending with the “_Boundary” suffix are boundary objects Objects ending with the “_Control” suffix are control objects Entity objects do not have any suffix appended to their name. Year Month Day ChangeDate_ Control Button_Boundary LCDDisplay_Boundary

33. Page 33W5D1 Example: Flow of events The customer enters a store with the intention of buying a toy for his child with the age of n. Help must be available within less than one minute. The store owner gives advice to the customer. The advice depends on the age range of the child and the attributes of the toy. The customer selects a dangerous toy which is unsuitable for the child. The store owner recommends a more suitable doll.

34. Page 34W5D1 Mapping parts of speech to object model components [Abbott, 1983] Part of speechModel componentExample Proper nounobjectJim Smith Improper nounclassToy, doll Doing verbMethod/associationBuy, recommend being verbinheritanceis-a (kind-of)‏ having verbaggregationhas an modal verbconstraintmust be adjectiveattribute3 years old transitive verbmethodenter intransitive verbmethod (event)‏depends on

35. Page 35W5D1 Another Example The customer enters the store to buy a toy. It has to be a toy that his daughter likes and it must cost less than 50 Euro. He tries a videogame, which uses a data glove and a head-mounted display. He likes it. An assistant helps him. The suitability of the game depends on the age of the child. His daughter is only 3 years old. The assistant recommends another type of toy, namely the boardgame “Monopoly". Flow of events: Is this a good use Case? “Monopoly” is probably a left over from the scenario The use case should terminate with the customer leaving the store Not quite!

36. Page 36W5D1 Grammatical constructUML Component Concrete Person, ThingObject nounclass verbAssociation Classifying verbInheritance Possessive VerbAggregation modal VerbConstraint AdjectiveAttribute Intransitive verbOperation (Event)‏ Textual Analysis using Abbot‘s technique Example “Monopoly" “toy" “enters" “is a",“either..or", “kind of…" "Has a ", “consists of" “must be", “less than…" "3 years old" “depends on…."

37. Page 37W5D1 Class diagram from flow of events The customer enters the store to buy a toy. It has to be a toy that his daughter likes and it must cost less than 50 Euro. He tries a videogame, which uses a data glove and a head- mounted display. He likes it. An assistant helps him. The suitability of the game depends on the age of the child. His daughter is only 3 years old. The assistant recommends another type of toy, namely a boardgame. The customer buy the game and leaves the store Customer ? enter()‏ toydaughter suitable * storedaughter age toy price buy()‏ videogameboardgame enters

38. Page 38W5D1 Order of activities for requirements specification 1.Formulate a few scenarios with help from the end user and/or application domain expert. 2.Extract the use cases from the scenarios, with the help of application domain expert. 3.Analyse the flow of events, for example with Abbot's textual analysis. 4.Generate the class diagrams, which includes the following steps: 1.Class identification (textual analysis, domain experts). 2.Identification of attributes and operations (sometimes before the classes are found!)‏ 3.Identification of associations between classes 4.Identification of multiplicities 5.Identification of roles 6.Identification of constraints

39. Page 39W5D1 Ideas: Avoid Complex Models Customer Name CustomerId Account Amount Deposit()‏ Withdraw()‏ GetBalance()‏ CustomerId AccountI d Bank Name Has * * Savings Account Withdraw()‏ Checking Account Withdraw()‏ Mortgage Account Withdraw()‏ Don’t put too many classes into the same package: 7+-2 (or even 5+-2)‏ Don’t put too many classes into the same package: 7+-2 (or even 5+-2)‏

40. Page 40W5D1 Put Taxonomies on a separate Diagram Savings Account Withdraw()‏ Checking Account Withdraw()‏ Mortgage Account Withdraw()‏ Account Amount Deposit()‏ Withdraw()‏ GetBalance()‏ CustomerId AccountI d

41. Page 41W5D1 Process Heuristics Explicitly schedule meetings for object identification First just find objects Then try to differentiate them between entity, interface and control objects Find associations and their multiplicity –Unusual multiplicities usually lead to new objects or categories Identify Inheritance: Look for a Taxonomy, Categorize Identify Aggregation Allow time for brainstorming, Iterate, iterate

42. Page 42W5D1 Application domain vs solution domain Application domain: –The problem domain (financial services, accident management...). Application domain class: –An abstraction in the application domain. If we model business applications, these classes are also called business objects. –Example: Board game, Tournament Solution domain: –Domains that help in the solution of problems (tele communication, data bases ….)‏ Solution domain class: –An abstraction, that is introduced for technical reasons, because it helps in the solution of a problem. –Examples: Tree, Hashtable, Scheduler

43. Page 43W5D1 Dynamic Modeling Definition of dynamic model: –A collection of multiple state chart diagrams, one state chart diagram for each class with important dynamic behavior. Purpose: –Detect and supply methods How do we do this? –Start with use case or scenario –Model interaction between objects => interaction diagram –Model dynamic behavior of a single object => statechart diagram

44. Page 44W5D1 Start with Flow of Events from Use Case Flow of events from “Dial a Number” Use case: –Caller lifts receiver –Dial tone begins –Caller dials –Phone rings –Callee answers phone –Ringing stops –....

45. Page 45W5D1 What is an Event? Something that happens at a point in time Relation of events to each other: –Causally related: Before, after, –Causally unrelated: concurrent An event sends information from one object to another

46. Page 46W5D1 Interaction diagram From the flow of events in the use case or scenario proceed to the interaction diagram An interaction diagram is a graphical description of objects participating in a use case or scenario Relation to object identification: –Objects/classes have already been identified during object modeling –Objects are identified as a result of dynamic modeling Heuristic: –A event always has a sender and a receiver. –The representation of the event is sometimes called a message –Find them for each event => These are the objects participating in the use case

47. Page 47W5D1 UML Statechart Diagram Notation State2 State1 Event1(attr) [condition]/action entry /action exit/action 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 do/Activity Event trigger With parameters Guard condition

48. Page 48W5D1 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

49. Page 49W5D1 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

50. Page 50W5D1 UML Statechart Diagrams The UML statechart diagram for the Publication class from the Library class model