Building an Analysis Model of the System Under

Building an Analysis Model of the System Under Development 1

Question: How do you start an OO design? --components? --objects? --how will they interact? Answer: One common method is to start with components, along with any design patterns which can be identified. In general: • design is an iterative process • all team members should take an active part in exploring possible designs • simple designs are preferable to complex designs--but it may take several iterations to develop a simple design which meets the project requirements As explained previously, we will use a subset of UML to do 2 the project design.

Analysis model (UML version): --functional model (use cases and scenarios) --analysis object model (static: class and object diagrams) --dynamic model (state and sequence diagrams) As system is analyzed, specifications are refined and made more explicit; if necessary, requirements are also updated 3

Figure 5 -19 of text: an activity diagram for analyzing the system you are building: 4

“Review”: use case: Graphical description: Arms/disarms system Text description: Use case name Homeowner Accesses system via internet Sensors Participating actors Responds to alarm event Flow of events Encounters an error condition Entry condition(s) Exit condition(s) System administrator Quality requirements Reconfigures sensors and related system features Pressman, p. 163, Figure 7. 3 5

“Review”: Use case writing guide (p. 137 of text): --each use case should be traceable to requirements --name should be a verb phrase to indicate user goal --actor names should be noun phrases --system boundary needs to be clearly defined --use active voice in describing flow of events, to make clear who does what --make sure the flow of events describes a complete user transaction ---if there is a dependence among steps, this needs to be made clear --describe exceptions separately --DO NOT describe the user interface to the system, only functions --DO NOT make the use case too long—use extends, includes instead --as you develop use cases, develop associated tests 6

“Review”: Use case additions—simplifications of use case descriptions A. Include: one use case includes another in its flow of events (cases A and B both include case C) A B <<include>> C <<include>> B. Extend: extend one use case to include additional behavior (cases D and E are extensions of case F) <<extend>> D F <<extend>> E 7

“Review”: Use case additions C. Inheritance: one use case specializes the more general behavior of another G and H specialize behavior of J) Authenticate with password G H J authenticate Authenticate with card 8

Class and object diagrams: Identify Objects from Use Case Specifications: USE ENDUSER’s TERMS AS MUCH AS POSSIBLE Entity objects: “things”, for example: --nouns (customer, hospital, infection) --real-world entities (resource, dispatcher) --real-world activities to be tracked (evacuation_plan) --data sources or sinks (printer) Boundary objects: system interfaces, for example: --controls (report(emergencybutton) --forms (savings_deposit_form) --messages (notify_of_error) Control objects: usually one per use case --coordinate boundary and entity objects in the use case Use the identified objects in a sequence diagram to carry out the use case 9

Common classes Other common types of classes which the developer can look for include: • tangible things, e. g. , Mailbox, Document • system interfaces and devices, e. g. , Display. Window, Input Reader • agents, e. g. , Paginator, which computes document page breaks, or Input. Reader • events and transactions, e. g. , Mouse. Event, Customer. Arrival • users and roles, e. g. , Administrator, User • systems, e. g. , mailsystem (overall), Initialization. System (initializes) • containers, e. g. , Mailbox, Invoice, Event • foundation classes, e. g. , String, Date, Vector, etc. 10

Sequence Diagram: a sequence diagram also models dynamic behavior typically a sequence diagram shows how objects act together to implement a single use case messages passed between the objects are also shown sequence diagrams help to show the overall flow of control in the part of the program being modeled they can also be used to show: concurrent processes asynchronous behavior 11

Sequence Diagram--Syntax Objects in the sequence diagram are shown as boxes at the top below each object is a dashed vertical line--the object’s “lifeline” an arrow between two lifelines represents each message arrows are labeled with message names and can also include information on arguments and control information two types of control: condition, e. g. , [is greaterthan zero] iteration, e. g. , *[for all array items] “return” arrows can also be included 12

Sequence Diagram Example— text, chapter 5 13

ER diagrams Useful object relationships These diagrams represent the relationships between the classes in the system. These represent a static view of the system. There are three basic types of relationship: • inheritance ("is-a") • aggregation ("has-a”) • association ("uses") These are commonly diagrammed as follows: 14

ER diagram: is-a: draw an arrow from the derived to the base class: manager employee 15

ER diagram--has-a: draw a line with a diamond on the end at the "container" class. Cardinalities may also be shown (1: 1, 1: n, 1: 0…m; 1: *, i. e. , any number > 0, 1: 1…*, i. e. , any number > 1): car person 1 1 4 tire 2 arm tire & car can exist independently —shared aggregation arm is part of the person– composition aggregation 16

ER diagram--uses or association: there are many ways to represent this relationship, e. g. , car * * gasstation company 1 employs * n employee works for 1 17

CRC cards: class--responsibilities--collaborators cards "responsibilities" = operators, methods "collaborators" = related classes (for a particular operator or method) Make one actual card for each discovered class, with responsibilities and collaborators on the front, data fields on the back. CRC cards are not really part of UML, but are often used in conjunction with it. 18

CRC card--example Example (based on Horstmann, Practical Object-Oriented Development in C++ and Java): front back Class Mailbox Operations (Responsibilities) Relationships (Collaborators) get current message Message, Messagequeue play greeting ------ Class Mailbox Queue of new messages Queue of kept messages Greeting Extension number Passcode 19

State Diagram: another way of adding detail to the design--models dynamic behavior describes all the possible states a particular object can be in and how that object's state changes as a result of events that affect that object usually drawn for a single class to show behavior of a single object used to clarify dynamic behavior within the system, as needed 20

State Diagram--Properties A state diagram contains a "start" point, states, and transitions from one state to another. Each state is labeled by its name and by the activities which occur when in that state. Transitions can have three optional labels: Event [Guard] / Action. A transition is triggered by an Event. If there is no Event, then the transition is triggered as soon as the state activities are completed. A Guard can be true or false. If the Guard is false, the transition is not taken. An Action is completed during the transition. 21

State Diagram--Example: this state diagram example for an "order" in an orderprocessing system is from Fowler and Scott, UML Distilled (Addison-Wesley, 1997): start [not all items checked] /get next item /get first item Checking check item [all items checked && some items not in stock] Waiting item received [some items not in stock] [all items checked && all items available] item received [all items in stock] Dispatching initiate delivery delivered Delivered 22

Example—bank simulation (Horstmann) Horstmann, Mastering Object. Oriented Design in C++, Wiley, 1995 Teller 1 Customer 3 Customer 2 Customer 1 Teller 2 Teller 3 Teller 4 23

Example—bank simulation (Horstmann), cont. An initial solution (Horstmann, p. 388): Bank Statistics Customer Bank Application Arrival Departure Event. Queue Event 24

Example—bank simulation (Horstmann), cont. An improved solution (Horstmann, p. 391): Bank Statistics Customer Bank Simulation Arrival Departure Event. Queue Event 25

Comparison Bank Statistics What simplifications Customer have been made? Bank Application Arrival Departure Why? Event. Queue Event Bank Statistics Customer Bank Simulation Arrival Departure Event. Queue Event 26

Example: How would we use the tools described so far to design a Student Management system for UC? How would we develop test cases at each stage? Use cases? Class diagram? Sequence diagram? Classes / CRC cards? 27