Detailed Object-Oriented Requirements Definitions

2. Detailed Object-Oriented Requirements Definitions The Object-Oriented approach has a set of Diagrams that together document the user’s needs and define the System Requirements. • It may seem complex at first to have so many different types of Diagrams, but as you use them , you will learn to appreciate how they all fit together to produce a complete Specification. • Each Diagram describes a different aspect of the System, so you only focus on one aspect at a time. • Analysts use a collection of Models (Diagrams) based on Use Cases with the Object- Oriented approach. • Four Models are used to describe the System Use Cases from various points of view. This Approach is referred to as “Use Case Driven” • Use Case Diagrams • Use Case Descriptions • Activity Diagrams • System Sequence Diagrams (SSD) Object-Oriented Analysis and Design with the Unified Process

3. Detailed Object-Oriented Requirements Definitions Each of the Four models are takes each Use Case , one by one, and extend the Requirements in more detail. • Statechart, however is not Use Case Driven but Object Driven. • The Use Case Diagram shows the Various User roles and the way those Users interact with the System. - The Use Case Diagram can be derived directly from the Event Table; Thus a Use Case Diagram is a convenient way to to document the System Events. • Sometimes a single comprehensive Diagram is used to identify all Use cases for an entire System. Sometimes a set of narrower Use Case Diagrams is used. • Each Use Case in the Diagram must be described in detail either by a narrative description of the steps that the User and the System do together to complete the Use Case. Activity Diagrams can also be used to describe any business processes done by people in an organization. Object-Oriented Analysis and Design with the Unified Process

4. Detailed Object-Oriented Requirements Definitions Activity Diagram is a type of workflow Diagram that describes the Users activities and their sequential flows. Can also be used to describe processes that include both Manual and Automated System Activities. System Sequence Diagram: Is a Diagram showing the Sequence (SSD) of Messages between an Actor and the System during a Use Case Scenario. SSDs are used to describe the Input and Output s and the sequential order of them. SSDs used in conjunction with Detailed Use Case Descriptions and/or with Activity Diagrams to show processing steps and interactions between the Actor and the System. Object-Oriented Analysis and Design with the Unified Process

5. Detailed Object-Oriented Requirements Definitions Class Diagrams:Are used to identify the real-world “Things” that determine the structure of the Programming Classes. Constructing a Class Diagram help Analyst identify information about the real-world objects that will be part of the new System. Statechart Diagram; Is a Diagram showing the Life of an Object in a set of “States” and “Transitions”. Since the Real-world objects are mirrored inside the Computer System, often the Status Conditions of the real Objects are an important piece of information that the Analyst can use to define the Business Rules to be implemented in the Computer System. Statecharts are also using during the Design to identify various States of the System itself and the allowable events that can be processed. Therefore Statecharts can be considered as an Analysis tool or as a Designer Tool. Object-Oriented Analysis and Design with the Unified Process

6. Requirements Diagrams With UML Models Object-Oriented Analysis and Design with the Unified Process

7. A USE CASE / SCENARIO VIEW A Use Case can be defined at an Overview Level or at a Detailed Level. • Event table provides an Overview of all Use Cases for a System. • Detailed information abut each Use Case is described with a Use Case Description., an Activity Diagram, and a System Sequence Diagram, or a combination of these Models. USE CASES AND ACTOR The Actor is the person or things that actually touches or interacts with the System.An Actor is a role played by people or things. - An Actor is always outside Automation boundary of the System . Eg. A Customer might be a Actor if He/she places the Order directly through the Internet. Object-Oriented Analysis and Design with the Unified Process

8. THE USE CASE DIAGRAM Use Case Diagram Symbols • Stick figureis given a name that characterizes the role the Actor is playing. • An Actor can be Other Systems that interfaces with the System being developed. In that case the Actor illustrated either with an appropriately named stick figure or with a Rectangle. • E.g. Purchasing Subsystem. • Oval figure is given a name of the Use Case inside. • The Connecting Lines between Actor and the Use Cases indicate which Actor uses (Utilizes) which Use Cases. • Automation Boundary denotes the boundary between the environment , where the Actors resides. And the internal components of the Computer System.. Object-Oriented Analysis and Design with the Unified Process

9. A Simple Use Case with an Actor Object-Oriented Analysis and Design with the Unified Process

10. A Use Case Diagram of the Order-Entry Subsystem for RMO, Showing a System Boundary Object-Oriented Analysis and Design with the Unified Process

11. THE USE CASE DIAGRAM There are two popular ways to Organize Use Case Diagrams to depict different point of view: • Organize Use Cases by Subsystem • Organize the Use Cases that involve a Specific Actor This approach is useful for showing all of the Business Events that are accessible through Internet. Analyst chooses to draw the Use Case Diagrams based on the needs of the Project Team. Object-Oriented Analysis and Design with the Unified Process

12. A Use Case Diagram of the Customer Support System (by Subsystem) Object-Oriented Analysis and Design with the Unified Process

13. « Includes » Relationships «includes» or «uses» Relationship • During the Development of a Use Case Diagram it is reasonable for more than one Use Case to use the services of a Common Subroutine. • Examples: “Create new Order” and “Update Order” Use Cases may need to validate the Customer Account. In that case two Common subroutines may be defined to carry the function of Customer Account Validation, “Validate Customer Account” and “Look Up Item Availability” . • The Common Subroutine itself becomes additional Use Case. • These Relationship is called as <<includes>> or <<uses>>> Notation • The Relationship between these Use cases is denoted by Connecting Line with arrow. • The Direction of the Arrow indicates which Use Case is Included as apart of the Major Use Cases. Object-Oriented Analysis and Design with the Unified Process

14. An Example of the Order-entry Subsystem With «Includes» Use Cases Object-Oriented Analysis and Design with the Unified Process

15. DEVELOPING A USE CASE DIAGRAM • Business Modeling helps Analysts understand the Business processes. As a result of Business Modeling Business Events are identified and documented in the Event Table. • Event Table is used to identify the Use Cases. However, the Analysts often need to make some adjustments when building a Use Case Diagram. - One major Adjustment is that frequently Business Events may be combined into single Use Case.e.g. Adding new Customer and changing Customer information may be done by two different but from the System point of view can be combine into a single Use “Maintain Customer Information” - Analysts also make adjustment by splitting a single Event into multiple Use Cases. These additional Use Cases can be identified either <<includes>> relationships or when another Use Case is defined from recognizing a common subroutine • Special attention should be paid to Temporal and State Events. Although these Events are not requested by any Actors they must be included in the System Requirements. Therefore, Analyst often connect these business Events to an “Administrator Actor” that might invoke them as a Special Procedure Object-Oriented Analysis and Design with the Unified Process

16. DEVELOPING A USE CASE DIAGRAM The Process for moving from Business Events to defining Use Cases requires two steps done in iteration:1. Identify the Actor for each Use Case.(Remember other Systems may also be Actors of a System) 2. Extract the information from the Business Events that describe the System responses to the Business Events. Remember to adjust the Use Cases so that Goals are System tasks such as “Process a Sale”, “Accept Goods Return” etc… Also remember that you must assume “Perfect Technology”. Be sure that Use Cases are based on Business Events not on Technical Activities such as :Logging on to the System” Object-Oriented Analysis and Design with the Unified Process

17. USE CASE DESCRIPTIONS • The Use Case Diagram helps identify the various processes that Users perform and that the new System must support. • However, careful System Development requires much more detailed level of description or Diagrams. To create a comprehensive, robust System that needs Users’ needs, Analyst must understand all of the derailed internal steps within a single Use Case. Internally a Use Case includes a whole sequence of steps to complete a Business process and frequently several variations of the Business steps (flows of Activities) exist within a Single Use Case. These different flow of Activities are called “Scenarios” or “Use Case Instances”. • SCENARIO is a unique set of internal activities within a Use Case and represents a unique path through the Use Case.A Use Case may have many different Scenarios. Object-Oriented Analysis and Design with the Unified Process

18. USE CASE DESCRIPTIONS(continued) • Use Case Descriptions are written at three levels of detail • Brief Description • Intermediate Description • Fully Developed DescriptionWritten Descriptions and Activity Diagrams can be used in any combination depending on Analyst’s need. • Brief Description Can be used for very simple Use Cases especially when the System to be developed is also small and well understood application.Simple Use case would normally have a single Scenario and very few (if any) exception Conditions. It is used in conjunction with an Activity Diagram adequately describes a simple Use Case. Object-Oriented Analysis and Design with the Unified Process

19. Brief Description of Create New Order Use Case Object-Oriented Analysis and Design with the Unified Process

20. USE CASE DESCRIPTIONS(continued) • INTERMEDIATE DESCRIPTION It extends the Brief Description to include the “Internal Flow of Activities” for the Use Case. If there are multiple Scenarios for a Use Case , then each internal flow of Activities is described individually.e.g. Create Order Use case has two Scenarios ( Order ClerkCcreatesTelephone Order , and Customer creates Web Orders)This description resembles a type of writing “Structured English” which can include Sequence , Select (Davison) and Reputation blocks. - Notice that Intimidate Description describes what the User and the System need to carry out the processing for the Scenario.- Each Step is identified with a number to make it easy to read. - Exception Conditions are also documented if they are needed. Object-Oriented Analysis and Design with the Unified Process

21. Intermediate Description of Telephone Order Scenario for Create New Order Use Case Object-Oriented Analysis and Design with the Unified Process

22. USE CASE DESCRIPTIONS(continued) • FULLY DEDVELOPED DECRIPTIONIt is the Most formal Method and preferred method for documenting a Use Case despite the fact that it takes a little more time to define the Internal Flow Of Activities for a Use case. • Creating a Fully Developed Use Case description helps Analyst to get a deep understanding of the Users’ needs. It will alsoincrease the probability of thoroughly understand the Business Processes and the ways the System must support them. • Fully developed Use Case Description • Superset of Intermediate and Brief Descriptions • Consists of eleven compartments • User, Actor, Stakeholder, EBP, and Conditions identified Object-Oriented Analysis and Design with the Unified Process

23. USE CASE DESCRIPTIONS(continued) FULLY DEDVELOPED DECRIPTIONPrecondition states what conditions must be true before a Use Case begins. (What the state of the System must be for the Use Case to beginPostcondition Identifies what must be true upon completion of the Use Case.Tips for writing Use Case Descriptions: - Keep Pre- and Post conditions fairly basic. - The Scope of a Use Case begins when the System is at a stable point and ends when it is again stable. This consideration will help you identify the Pre and Postconditions - Assume Perfect Technology such as the System is up and running, User is logged on , the Database connection is active and so forth… Object-Oriented Analysis and Design with the Unified Process

24. Fully Developed Description of Telephone Order Scenario for Create New Order Use Case Object-Oriented Analysis and Design with the Unified Process

25. USE CASE DESCRIPTIONS (continued) • Activity Diagram is another way to Document a Use Case Scenario. - Since an Activity Diagram is an easily understood Diagram, Analysts use it to document the workflows of Business Processes as well as Documenting the flow of Activities for Use Case Scenarios. • An Activity Diagram can be used to support any three levels of Use Case Descriptions. It is similar to Two-column Description - (Actor and System) in the fully Developed Use Case Description. . • The Benefits of creating an Activity diagram is that it is more visual and so can help both the User and System Developer as they work together to fully document the Use Case. • Activity Diagrams are also helpful in developing System Sequence Diagrams (SSD). Object-Oriented Analysis and Design with the Unified Process

26. Activity Diagram of the Telephone Order Scenario Object-Oriented Analysis and Design with the Unified Process

27. SYSTEM SEQUENCE DIAGRAM(SSD) • System Sequence Diagram is a type of “Interaction Diagram”. It is used to describe the flow of information into and out of the Automated System. • SSD documents the Inputs and the Outputs and identifies the interaction between Actors and the System. • SSD NOTATIONS • The “Stick” figure represents an Actor • The Box labeled as :system is an Object that represents the entire Automated System ( As opposed to the Class Diagram notation in SSD Object notation is used. Object notation indicates that the box refers to an individual Object and not to the Class of all similar Objects.) • A Rectangle with the name of the Object identified - the colon ( : ) is optional • Underneath the Actor and the :system are vertical dashed lines called “LIFELINES” • A Lifeline is simply the extension of that Object, throughout the duration of the SSD. • The Arrows between the Lifelines represent the Messages that are sent or received. • Lifelines indicate the Sequence of the Messages sent and received by the Actor and Object • A Message is Labeled to describe both the message’s purpose and any input data being sent • A Message is a command that has a syntax (Input parameters) • Output Message has shown as dashed arrow a slightly format and meaning. An Optional note can be added to explain output Messages Object-Oriented Analysis and Design with the Unified Process

28. Sample System Sequence Diagram Object-Oriented Analysis and Design with the Unified Process

29. SYSTEM SEQUENCE DIAGRAM(SSD) • The same Message may be sent multiple times (i.e Repeated) (e.g. The message “Add An Item to an Order” may be sent multiple tines ) • The Repetition of a Message in a Condition Loop can be represented in two ways: • The Message and its return are located inside a larger Rectangle to indicate the Repeating Loop. • * [True/False Condition] - Asterisk (*) indicates that Message repeats as long as the True/ False condition evaluates true. The True / False Condition is used for Control of the Loop as well as to determine as to whether a Message is sent or not. Object-Oriented Analysis and Design with the Unified Process

30. SYSTEM SEQUENCE DIAGRAM(SSD) THE COMPLETE NOTATION FOR A MESSAGE * [true/false Condition] return-value := message-name (parameter – list) Note: Any part of the message may be omitted • Indicates repeat or Looping of the Message • Brackets [ ] indicates true / false Condition. • Message-name is the description of the requested service. It is omitted on the dashed-line return messages. Which only show the Return Data Parameter. • Parameter-list (with parentheses on input Messages and without parenthesis on Return Messages) shows what data are passed with the Message • Return-value on the same line as the Message requires Assignment Operator (: =) which is used to describe Data being returned from the destination Object to the source Object in response to the message. Object-Oriented Analysis and Design with the Unified Process

31. Repeating Message (A) Detailed Notation (B) Alternate Notation Object-Oriented Analysis and Design with the Unified Process

32. DEVELOPING A SYSTEM SEQUENCE DIAGRAM • Begin with Detailed Description of the Use Case either Fully Developed form or as with Activity Diagrams • One Advantage of using Activity Diagrams is that it is easy to identify when an Input or Output occurs. Input an Output occurs whenever an arrow in an Activity Diagram goes from an External Actor to the Computer System. • FOUR Step Process for turning Activity Diagram into SSD [1] Identify the Input Messages [2] Describe messages from External Actor to System [3] Identify / apply special Conditions to Input Messages [4] Identify and add the Output Return Messages  Object-Oriented Analysis and Design with the Unified Process

33. DEVELOPING A SYSTEM SEQUENCE DIAGRAM 1. Identify the Input Messages At each location where the workflow crosses the Automation boundary, Input data are required therefore a Message is needed. 2. Describ Messages from External Actor to System Name the Messages to reflect the services that the Actor is requesting of the System. (eg. startOrder, addItem etc The other information required is the Parameter List for each Message. The important principle for identifying Data parameters is to base the List on the attributes on the Class Diagram. Looking at the Attributes with an understanding of what the System needs to do will help you find the right Attributes. 3. Identify / Apply special Conditions to Input Messages Including Iterations and True / False conditions 4. Identify and Add the Output Return Messages Object-Oriented Analysis and Design with the Unified Process

34. A Simplified Diagram of the Telephone Order Scenario Object-Oriented Analysis and Design with the Unified Process

35. An SSD of Simplified Telephone Order Scenario for the Create New Order Use Case Object-Oriented Analysis and Design with the Unified Process

36. THE STATECHART DIAGRAM Statechart Diagram describes the collection of States of each Objects. • Statechart shows the ‘Behavior’ or ‘Life of an Object’ in “States” and “Transitions”. • Status Conditionis a Condition during and Object Life when it satisfy some criterion, performs some Action, or waits for an Event. • Transition is the movement of an object from one State to another State. • State of each Object are an important piece of information that an Analyst can use to help define the ‘Business Rules’ to be implemented in a Computer System. • Statechart Can be developed for any Problem Domain Classes that have Complex “Behaviors” or “Status Condition” that need to be tracked by the System. • Not all Problem Domain Classes require Statechart. • A Statechart is not necessary for a Class that does not have Status Condition to Control Processing . Object-Oriented Analysis and Design with the Unified Process

37. THE STATECHART DIAGRAM • Statechart Diagram Symbols • Ovals represent “Status of Object” • Arrows represent “Transitions” • Pseudostate (Black dot) denotes start of Statechart flow   Object-Oriented Analysis and Design with the Unified Process

38. Simple Statechart for a Printer Object-Oriented Analysis and Design with the Unified Process

39. STATECHART DIAGRAM • State of an objectis a Condition that occurs during its Life when it satisfies some criterion, performs some Action or waits for an Event. • States are Semi-permanent conditions. Transitions interrupt them and cause them to end. • Transitionis the movement of an Object from one State to another State. Transition is like a trigger that fires or an event that occurs. • Origin Stateis the original State of an Object from which a Transition occurs. • Destination Stateis the State to which an Object moves during a Transition. • Message Eventis the Trigger for a Transition which causes an Object to leave its original State. Object-Oriented Analysis and Design with the Unified Process

40. STATECHART DIAGRAM • Transition Label consists of three components:- transition-name (parameters) [guard-condition] / action-expression • Transition-nameis the name of a “Message Event” that triggers the Transition and causes the Object to leave the Origin state. • Message Names and Transition Names almost use the same Syntax • Transitions are caused by Messages coming to the Object • Parameters comes directly from the Message Parameters. • Guard-conditionis the qualifier or test on the Transition and it is simply a “True / False” condition that must be satisfied before Transition can fire. • Sometimes a Transaction has only Guard-Condition and no Triggering Event; in that case the Trigger is constantly firing and whenever the Guard-Condition becomesTrue the Transition occurs. • Action-expression is a Procedural Expression that executes when the Transition fires. It describes the Action to be performed. • Any of the three components (i.e transaction-name, guard-condition, or action-expression) may be empty. • If either the Transition-name or Guard-condition is empty then it automatically evaluates to ‘True” . Either of them may be complex with AND an OR connectives. Object-Oriented Analysis and Design with the Unified Process

41. Statechart Diagram Guidelines to help identify Object States There are two ways to identify the Valid States Check Naming convention for Status Conditions. • A State may have a name of a simple Condition such as such as “On” or “In repair” • A Complex States labeled with Gerunds or Verb phrases • Example: “Being shipped” • Active States usually not labeled with Nouns. (If you use a noun to name a State‘ you have an incorrect idea about the States of Object Classes.) • Rethink your Analysis and describe only States of being of the Object itself Think about Status Conditions that may need to be reported to Management or Customers (e.g. “Shipped”) Object-Oriented Analysis and Design with the Unified Process

42. Nested States And Concurrency The BVehavior of Objects in the real world is more complex than simply being in one State at a time. • The condition of an Object being in more than one State at a time is called ‘Concurrency’[ or ‘oncurrent States’ • The Two ways to represent Concurrent States1. Show Concurrency with a Synchronization Bar and Concurrent Paths. (Pathis a sequential set connected States and Transitions) 2. Show Concurrency with States Nested inside other, higher-level States. (Nest low-level States inside Higher-level States) Higher-level states also called “Composite States” • A Composite State represents a Higher Level of abstraction and can contain multiple Levels and Transitions (Nested States and Transitions.) • To show Composite States we draw Lower- Level Statecharts within the Higher-Level State. Object-Oriented Analysis and Design with the Unified Process

43. Sample Composite States for the Printer Object When the Printer enters the “ON” State , it automatically begins at the nested black dot and moves to the “IDLE” State. So the Printer is both in the “On” State and the “Idle” State When Print Message is received the Printer makes the transition to the “Working” State but also remains in “On State.”. The Lower compartment contains “action-expression” - (Load: and Print Sheets) while printer is in Working State. Object-Oriented Analysis and Design with the Unified Process

44. Nested States And Concurrency • Object Behavior is frequently more complex than simpleNested States. • An Object may have entire set of States and Transitions (Multiple Paths – that are actively concurrent) • To document Concurrent Behavior of a single Object we draw Composite State with the Lower portion divided into multiple compartments , one for each concurrent Path of Behavior. • Example: A Printer that has an Input Bin to hold paper also cycles between two States in its work cycle of “Idle” and “Working” States. • If we describe one Path as the States of Input Paper Try and the other path as the States of the Printing mechanism (Idle and Working ) • In first Path (Input Paper try ) will have States of : “Empty”, “Full” and “ Low”. -In the Second Path will have States of “Idle” and “Working”. These two paths are independent. The movement between States in one compartment is completely independent of movement between States in the other compartment. Object-Oriented Analysis and Design with the Unified Process

45. Nested States And Concurrency • Object Behavior is frequently more complex than simple Nested States. • An Object may have entire set of States and Transitions (Multiple Paths – that are active concurrently) • To document Concurrent Behavior of a single Object we draw Composite State with the lower portion divided into multiple compartments , one for each concurrent Path of Behavior. Concurrent Paths for the Printer in the On State Object-Oriented Analysis and Design with the Unified Process

46. Rules for Developing Statecharts • The primary challenge in building a Statechart is to identify the right “States” for the Object. • The other major problem is to identify and handle “Composite States” with Nested Threads. (Due to Lack of experience!) • Remember to consider “Exception Conditions” especially when you see the word “Verify” and “Check” . Normally there will be Transitions out of States that Verify something (one for Accept and one for Reject} • The best solution is to remember that developing Statechart is an iterative behavior, more so than developing any other type of UML Diagram. (Analysts seldom get a Statechart right the first time! Thus, you should draw it and refine it again and again. Object-Oriented Analysis and Design with the Unified Process

47. Rules for Developing Statecharts The following Rules can help to develop Statecharts for Classes in the Problem Domain [1]Review Class Diagram and Select the Classes that will require Statecharts(Include those Classes that have various Status Conditions important to track in the System [2]Make a List all the Status Conditions for each Object group Think the Life Cycle of an Object! How does it come into existence in the System, when and how it is modified or deleted from the System. Does it have Active / Inactive States ., Waiting States etc. [3] Begin building Statechart fragments by identifying the “Transitions” that cause an object to leave the identified State. (e.g. If an Order is in the State of “Ready to be Shipped”, a Transition such as ‘beginShipping’ will cause the Order to leave the State. [4]Sequence State-transition” combinations in correct Order and Aggregate these combinations into large fragments.As fragments aggregated into Larger Paths begin to look for a natural Life Cycle for the Object. Continue to build longer Paths in the Statechart by combining the Fragments. Object-Oriented Analysis and Design with the Unified Process

48. Rules for Developing Statecharts (continued) [5] Review the Paths and look for independent, Concurrent Paths. The two States may be on independent Path; one can change without affecting the other. Alternatively, one State may be a Composite state, so that the two States should be Nested, one inside the other. - One way to identify a candidate for a Composite State is to determine if it is concurrent with several other States, and the other States depend on the Origin State. [6] Look for additional TransitionsOne method to identify the additional Transitions is to take every paired combination of States and ask whether there is a valid Transition between the States. Test them in both directions. [7]appropriate Expand each Transition with Message Event, Guard Condition and Action-expression.Include with each State appropriate “Action-expression” Much of it have been done as the Statechart fragments were being built Statechart. [8]Review and test each Statechart. Test Statechart by “Desk-checking” and review them by doing the followings: a) Make sure your States are really States of the Object in the Class. Ensure that the name truly describes States of being of the Object b) Follow the Object Life Cycle from its coming to existence to its being deleted from the system.. Be sure that possible combinations are covered and that the paths are accurate.c) Be sure to cover all Exception Conditions as well as the normally expected flow of Behaviors.d) Check again for Concurrent Behavior (Multiple Paths) and the possibility of Nested Paths. Object-Oriented Analysis and Design with the Unified Process

49. DEVELOPING RMO STATECHARTS • Review the Domain Class Diagram • Select Classes with Status Conditions that need to be tracked • Candidate Classes : Order, OrderItem, InventoryItem, Shipment, Customer • Choose Order and OrderItem as an exampleContinue Developing Statechart according to Eight rules • Identify possible Status Conditions of interest • “Ready to be shipped” • “On back order” • “Shipped” Object-Oriented Analysis and Design with the Unified Process

50. States and Exit Transitions for Orderitem Object-Oriented Analysis and Design with the Unified Process