Modeling with UML eerin gin n are E oftw S ted rien ject-o b O

Transcription

1 Object-Oriented Software Engineering Modeling with UML

2 What is modeling? Modeling consists of building an abstraction of reality. Abstractions are simplifications because: They ignore irrelevant details and They only represent the relevant details. What is relevant or irrelevant depends on the purpose of the model.

3 Example: street map

4 What is a good model? Relationships, which are valid in reality R, are also valid in model M. I : Mapping of real things in reality R to abstractions in the model M abbildet (Interpretation) f M : relationship between abstractions in M f R : relationship between real things inr In a good model the following diagram is commutative: I M R f M f R M R I

5 Systems, Models and Views A model is an abstraction describing a subset of a system A view depicts selected aspects of a model A notation is a set of graphical or textual rules for depicting views Views and models of a single system may overlap each other Examples: System: Aircraft Models: Flight simulator, scale model Views: All blueprints, electrical wiring, fuel system

6 Systems, Models and Views System Aircraft Blueprints Model 1 View 1 Flightsimulator Model 2 View 2 View 3 Scale Model Electrical Wiring

7 Why model software? Why model software? Software is getting increasingly more complex Windows XP > 40 mio lines of code A single programmer cannot manage this amount of code in its entirety. Code is not easily understandable by developers who did not write it We need simpler representations for complex systems Modeling is a mean for dealing with complexity

8 Dealing with Complexity 1. Abstraction 2. Decomposition 3. Hierarchy

9 1. Abstraction Inherent human limitation to deal with complexity The phenomena Chunking: Group collection of objects Ignore unessential details: => Models

10 Model-based software Engineering: Code is a derivation of object model Problem Statement : A stock exchange lists many companies. Each company is identified by a ticker symbol Analysis phase results in cbject model (UML Class Diagram): StockExchange Implementation phase results in code public class StockExchange { public Vector m_company = new Vector(); }; * Lists * Company tickersymbol public class Company { public int m_tickersymbol public Vector m_stockexchange = new Vector(); }; A good software engineer writes as little code as possible

11 Concepts and Phenomena Phenomenon An object in the world of a domain as you perceive it Example: The lecture you are attending Example: My black watch Concept Describes the properties of phenomena that are common. Example: Lectures on software engineering Example: Black watches Concept is a 3-tuple: Name (To distinguish it from other concepts) Purpose (Properties that determine if a phenomenon is a member of a concept) Members (The set of phenomena which are part of the concept)

12 Concepts and phenomena Name Purpose Members Clock A device that measures time. Abstraction Classification of phenomena into concepts Modeling Development of abstractions to answer specific questions about a set of phenomena while ignoring irrelevant details.

13 Models are used to provide abstractions System Model: Object Model: What is the structure of the system? What are the objects and how are they related? ====>(class d.) Functional model: What are the functions of the system? How is data flowing through the system? ===>(use case d.) Dynamic model: How does the system react to external events? How is the event flow in the system? ==>(Interaction/activity/state d.)

14 2. Decomposition A technique used to master complexity ( divide and conquer ) Functional decomposition The system is decomposed into modules Each module is a major processing step (function) in the application domain Modules can be decomposed into smaller modules Object-oriented decomposition The system is decomposed into classes ( objects ) Each class is a major abstraction in the application domain Classes can be decomposed into smaller classes Which decomposition is the right one?

15 Functional Decomposition System Function Top Level functions Read Input Transform Produce Output Level 1 functions Read Input Transform Produce Output Level 2 functions Load R10 Add R1, R10 Machine Instructions

16 Functional Decomposition Functionality is spread all over the system Maintainer must understand the whole system to make a single change to the system Consequence: Codes are hard to understand Code that is complex and impossible to maintain User interface is often awkward and non-intuitive Example: Microsoft Powerpoint s Autoshapes

17 Functional Decomposition: Autoshape Autoshape Mouse click Change Draw Change Rectangle Change Oval Change Circle Draw Rectangle Draw Oval Draw Circle

18 What is This?

19 Possible Object Model: Eskimo Cave lighting entrance enter() leave() livesin * Shoe Size Color Type Wear() Eskimo Size Dress() Smile() Sleep() Coat Size Color Type Wear()

20 Alternative Model: The Head of an Indian Indian Hair Dress() Smile() Sleep() Ear Size listen() * Face Nose smile() close_eye() Mouth NrOfTeeths Size open() speak()

21 Class Identification Class identification is crucial to object-oriented modeling Basic assumption: 1. We can find the classes for a new software system: We call this Greenfield Engineering 2. We can identify the classes in an existing system: We call this Reengineering 3. We can create a class-based interface to any system: We call this Interface Engineering Why can we do this? Philosophy, science, experimental evidence What are the limitations? Depending on the purpose of the system different objects might be found How can we identify the purpose of a system?

22 What is this Thing?

23 Modeling a Briefcase BriefCase Capacity: Integer Weight: Integer Open() Close() Carry()

24 A new Use for a Briefcase BriefCase Capacity: Integer Weight: Integer Open() Close() Carry() SitOnIt()

25 Questions Why did we model the thing as Briefcase? Why did we not model it as a chair? What do we do if the SitOnIt() operation is the most frequently used operation? The briefcase is only used for sitting on it. It is never opened nor closed. Is it a Chair or a Briefcase? How long shall we live with our modeling mistake?

26 3. Hierarchy We got abstractions and decomposition This leads us to chunks (classes, objects) which we view with object model Another way to deal with complexity is to provide simple relationships between the chunks One of the most important relationships is hierarchy 2 important hierarchies "Part of" hierarchy "Is-kind-of" hierarchy

27 Part of Hierarchy Computer I/O Devices CPU Memory Cache ALU Program Counter

28 Is-Kind-of Hierarchy (Taxonomy) Cell Muscle Cell Blood Cell Nerve Cell Striate Smooth Red White Cortical Pyramidal

29 Where are we right now? Three ways to deal with complexity: Abstraction Decomposition (Technique: Divide and conquer) Hierarchy (Technique: Layering) Two ways to deal with decomposition: Object-orientation and functional decomposition Functional decomposition leads to unmaintainable code Depending on the purpose of the system, different objects can be found What is the right way? Start with a description of the functionality (Use case model). Then proceed by finding objects (object model). What activities and models are needed? This leads us to the software lifecycle we use in this class

30 Software Lifecycle Activities...and their models Requirements Elicitation Analysis System Design Object Design Implementation Testing Expressed in Terms Of Structured By Realized By Implemented By Verified By Use Case Model Application Domain Objects Subsystems Solution Domain Objects class... class... class... Source Code Test Cases? class...?

31 Object-Oriented Software Engineering Requirements Elicitation

32 First Step in Establishing the Requirements: System Identification The development of a system is not just done by taking a snapshot of a scene (domain) Two questions need to be answered: How can we identify the purpose of a system? Crucial is the definition of the system boundary: What is inside, what is outside the system? These two questions are answered in the requirements process The requirements process consists of two activities: Requirements Elicitation: Definition of the system in terms understood by the customer ( Problem Description ) Requirements Analysis: Technical specification of the system in terms understood by the developer ( Problem Specification )

33 Requirements Elicitation Very challenging activity Requires collaboration of people with different backgrounds Users with application domain knowledge Developer with solution domain knowledge (design knowledge, implementation knowledge) Bridging the gap between user and developer: Scenarios: Example of the use of the system in terms of a series of interactions with between the user and the system Use cases: Abstraction that describes a class of scenarios

34 System Specification vs Analysis Model Both models focus on the requirements from the user s view of the system. System specification uses natural language (derived from the problem statement): an analytical description of required features. The analysis model uses formal or semi-formal notation (for example, a graphical language like UML) The RASD (req. analisys and spec. document) is the living document produced in req. analisys activity. System specs. and UML model are both part of the RASD (see end of notes for a RASD template).

35 Ingredients of a Problem Statement Current situation: The Problem to be solved Description of one or more scenarios Requirements Functional and Nonfunctional requirements Constraints ( pseudo requirements ) Project Schedule Major milestones that involve interaction with the client including deadline for delivery of the system Target environment The environment in which the delivered system has to perform a specified set of system tests Client Acceptance Criteria Criteria for the system tests

36 Types of Requirements Functional requirements: Describe the interactions between the system and its environment independently from implementation Examples: An operator should be able to define a new order. Nonfunctional requirements: User visible aspects of the system not directly related to functional behavior. Examples: The response time must be less than 1 second The server must be available 24 hours a day Constraints ( Pseudo requirements ): Imposed by the client or the environment in which the system operates The implementation language must be Java The system must be able to dynamically interface to existing data bases.

37 What is usually not in the requirements? System structure Development methodology Development environment Implementation language Reusability It is desirable that none of these above are constrained by the client. Fight for it!

38 Prioritizing requirements High priority ( Core requirements ) Must be addressed during analysis, design, and implementation. A high-priority feature must be demonstrated successfully during client acceptance. Medium priority ( Optional requirements ) Must be addressed during analysis and design. Usually implemented and demonstrated in the second iteration of the system development. Low priority ( Fancy requirements ) Must be addressed during analysis ( very visionary scenarios ). Illustrates how the system is going to be used in the future if not yet available technology enablers are available

39 Requirements Validation Requirements validation is a critical step in the development process, usually after requirements engineering or requirements analysis. Also at delivery (client acceptance test). Requirements validation criteria: Correctness: The requirements represent the client s view. Completeness: All possible scenarios, in which the system can be used, are described, including exceptional behavior by the user or the system Consistency: There are functional or nonfunctional requirements that contradict each other Realism: Requirements can be implemented and delivered Traceability: Each system function can be traced to a corresponding set of functional requirements

40 Requirements Validation Problem with requirements validation: Requirements change very fast during requirements elicitation. Tool support for managing requirements: Store requirements in a shared repository Provide multi-user access Automatically create a system specification document from the repository Allow change management Provide traceability throughout the project lifecycle RequisitPro from Rational

41 Verification and Validation of models R Analysis M Analysis System Design M System Object Design M Object Implementation M Impl f R f MA f MS f MD f Impl R M Analysis M System M Object M Impl Validation Verification Verification Verification I M R f M f R M R I

42 What is This?

43 System and Object identification Development of a system is not just done by taking a picture of a scene or domain Two important problems during requirements engineering and requirements analysis: Identification of objects Definition of the system purpose Depending on the purpose of the system, different objects might be found What object is inside, what object is outside? How can we identify the purpose of a system? Scenarios Use cases: Abstractions of scenarios

44 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) 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

45 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?

46 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 appear 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.

47 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

48 Next goal, after the scenarios are formulated: Find a use case 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 this use case in more detail Describe the entry condition Describe the flow of events Describe the exit condition Describe exceptions Describe special requirements (constraints, nonfunctional requirements)

49 Example of steps in formulating a use case First name the use case Use case name: ReportEmergency Then 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)? Then concentrate on the flow of events Use informal natural language

50 Example of steps in formulating a use case Formulate the Flow of Events: The FieldOfficer activates the Report Emergency function on her terminal. FRIEND 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. Start using Abbot s technique for object identification in parallel to the use case modeling!

51 Example of steps in formulating a use case Write down the 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. Identify and write down any 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.

52 How to Specify a Use Case (Summary) Name of Use Case Actors Description of actors involved in use case Entry condition Use a syntactic phrase such as This use case starts when Flow of Events Free form, informal natural language Exit condition Star with This use cases terminates when Exceptions Describe what happens if things go wrong Special Requirements List nonfunctional requirements and constraints

53 Use Case Diagrams Used during requirements elicitation to represent external behavior Passenger Actors represent roles, that is, a type of user of the system Use cases represent a sequence of interaction for a type of functionality The use case model is the set of all use cases. It is a complete description of the functionality of the system and its environment PurchaseTicket

54 Actors Passenger An actor models an external entity which communicates with the system: User External system Physical environment An actor has a unique name and an optional description. Examples: Passenger: A person in the train GPS satellite: Provides the system with GPS coordinates

55 Use Case A use case represents a class of functionality provided by the system as an event flow. PurchaseTicket A use case consists of: Unique name Participating actors Entry conditions Flow of events Exit conditions Special requirements

56 Use Case Diagram: Example Name: Purchase ticket Participating actor: Passenger Entry condition: Passenger standing in front of ticket distributor. Passenger has sufficient money to purchase ticket. Event flow: 1. Passenger selects the number of zones to be traveled. 2. Distributor displays the amount due. 3. Passenger inserts money, of at least the amount due. 4. Distributor returns change. 5. Distributor issues ticket. Exit condition: Passenger has ticket. Anything missing? Exceptional cases!

57 The <<extends>> Relationship Passenger PurchaseTicket <<extends>> relationships represent exceptional or seldom invoked cases. The exceptional event flows are factored out of the main event flow for clarity. Use cases representing exceptional flows can extend more than one use case. The direction of a <<extends>> relationship is to the extended use case <<extends>> <<extends>> <<extends>> OutOfOrder <<extends>> TimeOut Cancel NoChange

58 The <<includes>> Relationship Passenger PurchaseMultiCard PurchaseSingleTicket <<includes>> <<includes>> <<includes>> relationship represents behavior that is factored out of the use case. <<includes>> behavior is factored out for reuse, not because it is an exception. The direction of a <<includes>> relationship is to the using use case (unlike <<extends>> relationships). <<extends>> CollectMoney <<extends>> NoChange Cancel

59 Use Case Diagrams: Summary Use case diagrams represent external behavior Use case diagrams are useful as an index into the use cases Use case descriptions provide meat of model, not the use case diagrams. All use cases need to be described for the model to be useful.

60 Use Case Model for Incident Management FieldOficer Dispatcher OpenIncident ReportEmergency AllocateResources

61 Use Case Associations Use case association = relationship between use cases Important types: Extends A use case extends another use case Include A use case uses another use case ( functional decomposition ) Generalization An abstract use case has different specializations

62 <<Include>>: 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 CreateDocument <<include>> <<include>> <<include>> Scan OCR Check

63 <<Include>>: 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) Note: The base case cannot exist alone. It is always called with the supplier use case <<include>> Base Use Case OpenIncident ViewMap <<include>> AllocateResources Supplier Use Case

64 <Extend>> 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 Note: In an extend assocation, the base use case can be executed without the use case extension FieldOfficer <<extend>> Help ReportEmergency

65 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 CheckPassword Parent Case ValidateUser CheckFingerprint Child Use Case

66 How do I find use cases? Select a narrow vertical slice of the system (i.e. one scenario) Discuss it in detail with the user to understand the user s preferred style of interaction Select a horizontal slice (i.e. many scenarios) to define the scope of the system. Discuss the scope with the user Use mock-ups as visual support Find out what the user does Task observation (Good) Questionnaires (Bad)

67 From Use Cases to Objects Le vel 1 Top Level Use Case Le vel 2 Level 2 Level 2 Use Cases Level 3 Level 3 Level 3 Level 3 Use Cases Level 4 Level 4 Operations A B Participating Objects

68 Finding Participating Objects in Use Cases For any use case do the following Find terms that developers or users need to clarify in order to understand the flow of events Always start with the user s terms, then negotiate: FieldOfficerStationBoundary or FieldOfficerStation? IncidentBoundary or IncidentForm? EOPControl or EOP? Identify real world entities that the system needs to keep track of. Examples: FieldOfficer, Dispatcher, Resource Identify real world procedures that the system needs to keep track of. Example: EmergencyOperationsPlan Identify data sources or sinks. Example: Printer Identify interface artifacts. Example: PoliceStation Do textual analysis to find additional objects (Use Abott s technique) Model the flow of events with a sequence diagram

69 Summary In this lecture, we reviewed the requirements elicitation activities aimed at defining the boundary of the system: Scenario identification Use case identification and refinement Identification of participating objects Requirements elicitation is to build a functional model of the system which will then be used during analysis to build an object model and a dynamic model.

70 Object-Oriented Software Engineering Analysis: Object Modeling

71 Outline From use cases to class diagrams Model and reality A little discourse into philosophy Activities during object modeling Object identification Object types entity, boundary and control objects Object naming Abbott s technique helps in object identification Users of class diagrams

72 From Use Cases to Objects Level 1 Level 1 Use Case Le vel 2 Level 2 Level 2 Use Cases Le vel 3 Level 3 Level 3 Level 3 Use Cases Level 4 Level 4 Operations A B Participating Objects

73 From Use Cases to Objects: Why Functional Decomposition is not Enough Level 1 Scenarios Le vel 2 Level 2 Level 1 Use Cases Le vel 3 Level 3 Level 3 Level 2 Use Cases Level 4 Level 4 Operations A B Participating Objects

74 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 Always use the user s terms

75 Object Types Entity Objects Represent the persistent information tracked by the system (Application domain objects, Business objects ) Boundary Objects Represent the interaction between the user 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 Object types originated in Smalltalk: Model, View, Controller (MVC)

76 Example: 2BWatch Objects Year ChangeDate Button Month LCDDisplay Day Entity Objects Control Objects Interface Objects

77 Naming of Object Types in UML UML provides several mechanisms to extend the language UML provides the stereotype mechanism to present new modeling elements <<Entity>> Year <<Entitity>> Month <<Entity>> Day <<Control>> ChangeDate <<Boundary>> Button <<Boundary>> LCDDisplay Entity Objects Control Objects Boundary Objects

78 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 kind of unsuitable for the child. The store owner recommends a more yellow doll.

79 Mapping parts of speech to object model components [Abbott, 1983] 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

80 Another Example 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. Is this a good use Case? Not quite! 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". Monopoly is probably a left over from the scenario The use case should terminate with the customer leaving the store

81 Textual Analysis using Abbot s technique Example Monopoly" toy" "3 years old" enters" depends on." is a", either..or", kind of " "Has a ", consists of" must be", less than " Grammatical construct Concrete Person, Thing noun Adjective verb Intransitive verb Classifying verb Possessive Verb modal Verb UML Component Object class Attribute Operation Operation (Event) Inheritance Aggregation Constraint

82 Generation of a class diagram from flow of events Customer store? enter() daughter age 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. videogame suitable * Toy price buy() like() boardgame 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

83 Order of activities in modeling 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

84 Avoid Ravioli Models Bank Name * Account Amount CustomerId AccountId AccountId * Has Customer Name Deposit() Withdraw() GetBalance() CustomerId Savings Account Checking Account Mortgage Account Don t put too many classes into the same package: 7+-2 (or even 5+-2) Withdraw() Withdraw() Withdraw()

85 Put Taxonomies on a separate Diagram Account Amount CustomerId AccountId AccountId Deposit() Withdraw() GetBalance() Savings Account Checking Account Mortgage Account Withdraw() Withdraw() Withdraw()

86 Object-Oriented Software Engineering Analysis: Dynamic Modeling

87 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 for the object model How do we do this? Start with use case or scenario Model interaction between objects => sequence diagram Model dynamic behavior of a single object => statechart diagram

88 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... From the flow of events in the use case or scenario proceed to the sequence diagram

89 Sequence Diagram A sequence diagram is a graphical description of objects participating in a use case or scenario using a DAG (direct acyclic graph) notation 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

90 An Example Flow of events in a Get SeatPosition use case : 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 Which are the objects?

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

92 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 are created by 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.

93 Is this a good Sequence Diagram? First column is not the actor It is not clear where the boundary object is It is not clear where the control object is Smart Card Onboard Computer Seat Establish Connection Establish Connection Accept Connection Accept Connection Get SeatPosition 500,575,300

94 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)

95 Fork Diagram Much of the dynamic behavior is placed in a single object, ususally the control object. It knows all the other objects and often uses them for direct questions and commands.

96 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 hel with a specific behavior.

97 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

98 Summary: Requirements Analysis 1. What are the transformations? Create scenarios and use case diagrams Functional Modeling 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.

99 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

100 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

101 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

102 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

103 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?

104 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?

105 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,...)?

106 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?

107 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

108 Project Agreement The project agreement represents the acceptance of (parts of) the analysis model (as documented by the requirements analysis document) by the client. The client and the developers converge on a single idea and agree about the functions and features that the system will have. In addition, they agree on: a list of prioritized requirements a revision process a list of criteria that will be used to accept or reject the system a schedule, and a budget