INTROSE Introduction to Software Engineering

1. INTROSE Introduction to Software Engineering Analysis Modeling (continued) Raymund Sison, PhD College of Computer Studies De La Salle University sisonr@dlsu.edu.ph

2. The Use Case Approach to Requirements Development From (Wiegers, 2003)

3. Analysis vs. Design Models • Analysis model • Contains primarily the application domain classes • Read by users, domain experts, analysts, designers • Design model • Contains both application and solution domain classes • Used by designers and implementers (programmers)

4. Analysis Modeling Activities • Identify entity objects • Identify boundary objects • Identify control objects • Map use cases to objects with sequence diagrams • Identify associations • Identify attributes • Review and revise the analysis model

5. Basic Approaches to Identifying Objects and Associations • Approaches: • Application domain approach • Ask application domain expert to identify relevant abstractions • Syntactic approach • Start with use cases, particularly the flows of events, from which the objects will be extracted. • Use noun-verb analysis (Abbot’s technique) and other heuristics to identify components of the object model.

6. Abbot’s Heuristics Part of speech Model component Example Proper noun object Jim Smith Improper noun class Toy, doll Doing verb method Buy, recommend being verb inheritance is-a (kind-of) having verb aggregation has an modal verb constraint must be adjective attribute 3 years old transitive verb method enter intransitive verb method (event) depends on

7. Identifying Entity Objects • An entity object… • is an object in the application domain. • Heuristics for identifying entity objects: • Terms that developers or users need to clarify in order to understand the use case • Recurring specific nouns in the use cases • Real-world entities that the system needs to track

8. Identifying Entity Objects • Real-world activities that the system needs to track • Data sources or sinks

9. Example • Use Case Name: Report Emergency • Entry condition: • The field officer activates the “Report Emergency” function of her terminal. • Flow: • The system responds by presenting a form to the officer. The form includes an emergency type menu (general emergency, fire, transportation), a location, incident description, resource report, and hazardous material fields. • The field officer completes the form by specifying minimally the emergency type and description fields. The field officer may also describe possible responses to the emergency situation and request specific resources. Once the form is completed, the field officer submits the form, at which point the dispatcher is notified.

10. Example • The dispatcher reviews the information submitted to the system by the field officer and creates an Incident in the database by invoking the Open Incident use case. All the information contained in the field officer’s form is automatically included in this incident. The dispatcher selects a response by allocating resources to the incident (with the Allocate Resources use case) and acknowledges the emergency report by sending an acknowledgment notice to the field officer. • Exit condition: • The field officer receives the acknowledgment and the selected response.

11. Example • Use Case Name: Report Emergency • Entry condition: • The field officer activates the “Report Emergency” function of her terminal. • Flow: • The system responds by presenting a form to the field officer. The form includes an emergency type menu (general emergency, fire, transportation), a location, incident description, resource report, and hazardous material fields. • The field officer completes the form by specifying minimally the emergency type and description fields. The field officer may also describe possible responses to the emergency situation and request specific resources. Once the form is completed, the field officer submits the form, at which point the dispatcher is notified.

12. Example • The dispatcher reviews the information submitted to the system by the field officer and creates an incident in the database by invoking the Open Incident use case. All the information contained in the field officer’s form is automatically included in this incident. The dispatcher selects a response by allocating resources to the incident (with the Allocate Resources use case) and acknowledges the emergency report by sending an acknowledgment notice to the field officer. • Exit condition: • The field officer receives the acknowledgment and the selected response.

13. Example • Entity objects for the Report Emergency use case: • Field officer • Emergency report • Dispatcher • Incident

14. Identifying Boundary Objects • A boundary object… • represents the system’s interface with the actors • In each use case, each actor interacts with at least one boundary object. • collects information from the actors and translates it into a form that can be used by both entity and control objects • models the GUI at a coarse level • They do not describe in detail the visual aspects of the user interface.

15. Identifying Boundary Objects • Heuristics for identifying boundary objects: • Identify user interface controls that the use needs to initiate the use case (e.g., Report Emergency button) • Identify forms that users need to enter data into the system • Identify notices and messages the system uses to respond to the user • When multiple actors are involved in a use case, identify actor terminals to refer to the user interface under consideration.

16. Identifying Boundary Objects • Do not model the visual aspects of the interface with boundary objects (user mock-ups are better suited for that). • Always use the end user’s terms for describing interfaces; do not use terms from the solution or implementation domains.

17. Example • Use Case Name: Report Emergency • Entry condition: • The field officer activates the “Report Emergency” function of her terminal. • Flow: • The system responds by presenting a form to the officer. The form includes an emergency type menu (general emergency, fire, transportation), a location, incident description, resource report, and hazardous material fields. • The field officer completes the form by specifying minimally the emergency type and description fields. The field officer may also describe possible responses to the emergency situation and request specific resources. Once the form is completed, the field officer submits the form, at which point the dispatcher is notified.

18. Example • The dispatcher reviews the information submitted to the system by the field officer and creates an Incident in the database by invoking the Open Incident use case. All the information contained in the field officer’s form is automatically included in this incident. The dispatcher selects a response by allocating resources to the incident (with the Allocate Resources use case) and acknowledges the emergency report by sending an acknowledgment notice to the field officer. • Exit condition: • The field officer receives the acknowledgment and the selected response.

19. Example • Boundary objects for the Report Emergency use case: • Field officer terminal • Emergency form • Incident form • Acknowledgment notice

20. Identifying Control Objects • A control object… • is responsible for: • coordinating boundary and entity objects • collecting data from the boundary object and dispatching it to entity objects • does not usually have a concrete counterpart in the real world • usually has a close relationship with a use case • A control object is usually created at the beginning of a use case and ceases to exist at its end.

21. Identifying Control Objects • Heuristics for identifying control objects: • Identify one control object per actor per use case. • The life span of a control object should cover the extent of the use case or the extent of a user session. • If it is difficult to identify the beginning and end of a control object activation, the corresponding use case probably does not have well-defined entry and exit conditions.

22. Example • Use Case Name: Report Emergency • Entry condition: • The field officer activates the “Report Emergency” function of her terminal. • Flow: • The system responds by presenting a form to the officer. The form includes an emergency type menu (general emergency, fire, transportation), a location, incident description, resource report, and hazardous material fields. • The field officer completes the form by specifying minimally the emergency type and description fields. The field officer may also describe possible responses to the emergency situation and request specific resources. Once the form is completed, the field officer submits the form, at which point the dispatcher is notified.

23. Example • The dispatcher reviews the information submitted to the system by the field officer and creates an Incident in the database by invoking the Open Incident use case. All the information contained in the field officer’s form is automatically included in this incident. The dispatcher selects a response by allocating resources to the incident (with the Allocate Resources use case) and acknowledges the emergency report by sending an acknowledgment notice to the field officer. • Exit condition: • The field officer receives the acknowledgment and the selected response.

24. Example • Control objects for the Report Emergency use case: • Report Emergency control • Manage Emergency control

25. Mapping Use Cases to Objects with Sequence Diagrams • A sequence diagram… • ties use cases with objects. • shows how the behavior of a use case (or scenario) is distributed among its participating objects • is usually not as good a medium for communication with the user as a use case is • represents a shift in perspective and allows the analyst/developer to find missing objects or gray areas in the requirements specification

26. Mapping Use Cases to Objects with Sequence Diagrams • Heuristics for drawing sequence diagrams: • The first column corresponds to the actor initiating the use case. • The second column is a boundary object (that the actor used to initiate the use case). • The third column is a control object that manages the rest of the use case. • Control objects are created by boundary objects initiating use cases.

27. Mapping Use Cases to Objects with Sequence Diagrams • Boundary objects are created by control objects. • Entity objects are accessed by control and boundary objects. • Entity objects never access boundary or control objects; this makes it easier to share entity objects across use cases.

28. Example

29. Identifying Associations • An association… • shows a relationship between two or more classes. • has several properties: • Name • Role at each end • Multiplicity at each end

30. Identifying Associations • Heuristics for identifying associations: • Examine verb phrases. • Name associations and roles precisely. • Use qualifiers as often as possible to identify namespaces and key attributes. • Eliminate any association that can be derived from other associations. • Do not worry about multiplicity until the set of associations is stable. • Too many associations make a model unreadable.

31. Identifying Attributes • Attributes… • are properties of an object • represent the least stable part of the object model • They can therefore be added later when the analysis model or the user interface sketches are validated.

32. Identifying Attributes • Heuristics for identifying attributes: • Examine possessive phrases. • Represent stored state as an attribute of the entity object. • Describe each attribute. • Do not represent an attribute as an object; use an association instead. • Do not waste time describing fine details before the object model is stable.