Using usecases to extract an object-oriented models: Extracting the dynamic model

1. Using usecases to extract an object-oriented models: Extracting the dynamic model A well-formed usecase can tell us which object requested what service from which other object and in what sequence. It also captures (although deficiently) whether there was simultaneity and parallel threads. This is almost all the information we need to extract an object-oriented dynamic model of the situation. This could be in the form of sequence diagrams, collaboration diagrams or later, state diagrams.

2. Extracting sequence diagrams: If we have a well-formed usecase, construction of a sequence diagram becomes rather trivial. A sequence diagram depicts the order of the exchange of messages between the various objects involved in order to achieve a certain goal. Usecases do exactly the same and well-formed ones contain all the necessary information to extract a sequence diagram.

3. The left-hand side object of any one line of usecase is a client object, the right-hand side one the server for a particular message request, which is the transformation of that given line. Therefore all objects needed for the sequence diagram all simply the left-hand side and the right-hand side words of the transformation set. A message (an arrow in a sequence diagram) is from a client to a server, thus it is from the life-line of a left-hand side object to the one of the right-hand side. The label on it is the name of the transformation. The order of the arrows are the order of the lines. Use rules of progression to figure out multi-threading.

4. TTD1:TTD TTD2:TTD Exchange:Connection Attempt_conn( ) Establish_call( ) Establish_call( ) Attemp_disconn( ) Disconnect( ) Reset( ) Use Case: Telephony Communication Actors: TTD 1, TTD 2 Initiating Actor: TTD 1 Events: 0TTD 1 req. ser. Attempt_connection( ) from Exchange 0 Exchange req. ser. Establish _call from TTD1 10Exchange req. ser. Establish_call( ) from TTD 2 0TTD 1 req. ser. Attempt_disconnect( ) from Exchange 0Exchange req. ser. Disconnect( ) from TTD 1T1Exchange req. ser. Reset( ) from TTD2T

5. Call-Register:Reg Dial-Register:Reg FSLX:LX TTD1:TTD NSLX:LX Connect( ) Sound_dial_tone( ) Dial( ) Receive_call( ) Routed( ) Use Case: Attempt_connection Actors: TTD 1 Initiating Actor: TTD 1 Events: 0TTD 1 req. ser. Connect( ) from NSLX 0NSLX req. ser. Sound_dial_tone( ) from TTD 1T1NSLX req. ser. Dial( ) from Dial_register 1Dial_register req. ser. Receive_call( ) from FSLX 1FSLX req. ser. Routed( ) from Call_registerT

6. Extracting collaboration diagrams: Collaboration diagrams contain the same essential information as sequence diagrams. A collaboration diagram also depicts the order of the exchange of messages between the various objects involved in order to achieve a certain goal. As we know usecases also do exactly the same and well-formed ones contain all the necessary information to extract a sequence diagram.

7. 1- Attemp_connect( ) 3- Attempt_disconnect( ) TTD1:TTD 4a- Disconnect( ) Exchange:Connection 2- Establish_call ( )4b- Reset( ) Use Case: Telephony Communication Actors: TTD 1, TTD 2 Initiating Actor: TTD 1 Events: 0TTD 1 req. ser. Attempt_connection( ) from Exchange 0Exchange req. ser. Establish_call( ) from TTD 2 0TTD 1 req. ser. Attempt_disconnect( ) from Exchange 0Exchange req. ser. Disconnect( ) from TTD 1T1Exchange req. ser. Reset( ) from TTD2T TTD2:TTD

8. 1. Connect( ) TTD1:TTD 2a. Sound_dial_tone( ) NSLX:LX 2b. Dial( ) Use Case: Attempt_connection Actors: TTD 1 Initiating Actor: TTD 1 Events: 0TTD 1 req. ser. Connect( ) from NSLX 0NSLX req. ser. Sound_dial_tone( ) from TTD 1T1NSLX req. ser. Dial( ) from Dial_register 1Dial_register req. ser. Receive_call( ) from FSLX 1FSLX req. ser. Routed( ) from Dial_registerT Dial-Register:Reg 4. Routed( ) 3. Receive_call( ) FSLX:LX

9. A well-formed usecase can tell us which object requested what service from which other object. Therefore a full set of well-formed and related usecases would contain in it all the objects that exchange messages in the system and the messages that they exchange. As each object must belong to a class, all classes required in the system are therefore identifiable. As each message is a request for an object to perform an operation, all the operations are also known. The hierarchy of usecases and their subordinate ones also indicate a structural hierarchy. This almost all the information we need to extract an object-oriented static model. This could be in the form of a class diagram.

10. Extracting a class diagram: Each object (right-hand side or left-hand side) must belong to a class. So each object named in a usecase implies a class. Each class has a number of operations that it has to perform. So the operations indicated by the usecase define the object as its class.

11. Each line of usecase at level n implies a pair of objects (therefore also classes) and an operation on the server class. This latter class may be (usually is) a complex class (an entire system or sub-system) and the operation implied with respect to it a complex behavior. This latter operation may however be now taken as the subject for a new usecase, implying that the server object at level n is now our “system”, with (for the moment) one goal; the operation it has to perform. Now we can start the system analysis effort over again, this time at the lower n+1 level of granularity. This implies new lower level (component) objects (and therefore

12. classes which would logically compose the higher level object at level n. So there is a compositional relationship between the levels of a usecase and objects with which we aught to deal.

13. Use Case: Telephony Communication Actors: TTD 1, TTD 2 Initiating Actor: TTD 1 Events: 0TTD 1 req. ser. Attempt_connection( ) from Exchange 0Exchange req. ser. Establish_call( ) from TTD 2 0TTD 1 req. ser. Attempt_disconnect( ) from Exchange 0Exchange req. ser. Disconnect( ) from TTD 1T1Exchange req. ser. Reset( ) from TTD2T Connection Attempt_connect( )Attempt_disconnect( )

14. Call_Register Local_exchange Dial_register Routed( ) Connect( )Receive_call( ) Dial( ) Use Case: Attempt_connection Actors: TTD 1 Initiating Actor: TTD 1 Events: 0TTD 1 req. ser. Connect( ) from NSLX 0NSLX req. ser. Sound_dial_tone( ) from TTD 1T1NSLX req. ser. Dial( ) from Dial_register 1Dial_register req. ser. Receive_call( ) from FSLX 1FSLX req. ser. Routed( ) from Call_registerT

15. Connection Attempt_connect( )Attempt_disconnect( ) Local_exchange Call_Register Dial_register a_Number a_Number Connect( )Receive_call( ) Dial( ) Routed( )

16. Connection Register Attempt_connect( )Attempt_disconnect( ) a_Number Local_exchange Call_register Dial_register Connect( )Receive_call( ) Dial( ) Routed( )

17. Reviewing usecases: • Like any other artifact in software engineering, usecases may also be reviewed . We review usecases from the perspective of: • Well-formedness • Completeness • Fit • We shall discuss these one at a time.

18. Well-formedness: A usecase is well-formed if it follows the one initiation, five progression and two termination rules. There may be other rules added to these to cater for architectural concerns, but that is of no concern to us here. Should extra rules exist, then following these is also a requirement of well-formedness. Additionally, to be well-formed, a usecase must be documented in one of the accepted usecase documentation formats. The one provided herein is recommended.

19. Completeness: There are two aspects to completeness; Essential completeness, and Structural completeness We must ensure both.

20. Essential completeness is ensured when there is covered traceability to at least the functional requirements set. This means that all stated and implied functional requirements must be covered by usecases. Structural completeness is ensured when all named transformations have been either expanded into lower level usecases or into procedural flow (if at leaf level). We also need to ensure that all necessary non-normal course usecases have been considered and documented. It is also necessary to ensure that there is a relevant entry in each cell of the usecase template and that those containing no entries are explicitly mentioned to be blank.

21. Fit: Here we must ensure that everyone is happy with our usecase set. We must check for understandability, logical consistency, and necessity (that there is nothing we don’t need). You need to review with all stakeholders: Review with Clients Review with Actors, and Review with Owners. Remember that there are several systems with which you are concerned here, not just a software specification.

22. A system to achieve goal X (the software specification) A system to develop system to do X A system to system administer the system that achieves X A system to deliver value for money A system to shine and stay employed or be promoted

23. Who should be present at the review? Project chief architect Project manager Chief analyst – usecase developer(s) Project Owner or representative Chief developer/programmer End user representatives

24. ATTRIBUTES An attribute is one aspect of reality relating to the class about which we need information. In fact an attribute is the shorthand for a question about the class. For example: This really means: What is the name of this person? Person name:

25. There are three general categories of attributes: • Nominal attributes: They give the object a name e.g. person’s SSN • Essential attributes or Intrinsic attributes: They describe some feature of the object, e.g. person’s DOB • Referential attribute: They relate one object to another e.g. person’s job In essence attributes are how the object is identified. In order to find the relevant attributes, ask the following questions: • How would anyone in this domain describe this class? • How would anyone in this domain recognize this class? • What questions would this class be responsible to answer in this domain?

26. Good attributes should have the following characteristics: • Relevant: An attribute must relate to the universe of discourse; e.g. color of check not relevant in a banking system • Atomic: An attribute must contain one value at any one time • Encompassing: An attribute must be characteristic of the entire object not a component of it; e.g. diameter is an attribute of a tire not of a car • Local(non-relational): The attribute of an object must not attempt to capture a characteristic of a relationship; e.g. permission_value is an attribute of Permission not of either a Person or a File.

27. OPERATIONS Operations are things that a class does (for other classes). They are the responsibilities of the class. This must be contrasted with things that class a does for itself. These are the private methods. We are concerned with operations (i.e. responsibilities). Operations can also be simple or complex. Simple operations are not necessary in an analysis model. Simple operations include: Connect(), get(), set(),disconnect().

28. Operations are found by looking for: • Action verbs in a problem statement or use case Responsibilities on a CRC card • Actions and activities of a state diagram (if available)

29. Object orientation is all about message passing between objects. For messages to pass between objects (programming view): ACCESS • Object C:c passes object B:b as an argument in a message to object A:a. • Object A:a contains object B:b. • Object A:a has a link to object B:b • Object A:a’s service belongs to object B:b CONTAINMENT ASSOCIATION INHERITANCE In the analysis domain, these are all forms of relationships

30. Technically speaking an association is a relationship between the classes of objects. This means that a link is established between these objects that are instances of this association. A link between two objects lets one object be mapped to the other. This is a static relationship between classes, it is NOT a path for a message or a dynamic link between two individual objects.

31. Look for the following categories: • A is a physical part of B e.g., Wing-Airplane • A is a logical part of B e.g., FlightLeg - Flight • A is physically contained in B e.g, Passenger, Aircraft • A is logically contained in B e.g., Passenger-Manifest • A is a description of B e.g. FlightPlan-Flight • A is a line item of B (aggregand) e.g. OrderLine-Order • A is a member of B e.g. Pilot-Airline • A is owned by B e.g., Aircraft-Airline • A has a contract with B e.g. Passenger-Airline • A is an organizational subunit of B e.g. Tower-Airport • A uses B e.g. Passenger-Flight

32. An association: • Indicates a relationship of some permanence (or at least duration) between classes. • The relationship is well defined, contextually meaningful and are usually an abstraction of a constant. • Can be shown as: A static mapping

33. AGGERGATION V. CONTAINMENT We said earlier that in UML, aggregation was modeled in two forms : Weak aggregation and Composition. (In fact there are seven forms of aggregation of which the above are only two examples but we shall not go into the details here). What is important is to note that containment IS NOT a form of aggregation.

34. Containment is that relationship when an object is temporarilyplaced inside another. For example a picnic basket in the trunk of a car. In contrast aggregation is the relationship between objects which has a compositional, more permanent (not necessarily perpetual), and emergent properties. Containment is always transitive, aggregation may or may not be. Yet both containment and aggregation are always asymmetric.

35. Example: An apple in a picnic basket in the trunk of a car (Containment) Left arm part of Houman, Houman part of CS department (Aggreg.) Now an apple, or a picnic basket although inside a car are not a part of the car in the sense that there is no emergent relationship or dependency between them. On the other hand, Houman’s arm is part of Houman and without it Houman will not be complete. Houman is also part of the CS department and without him (Houman hopes) the CS department is not complete.

36. Inheritance This is the parent-child relationship. UML’s label for this type of relationship is GENERALIZATION. In fact there are three main forms of inheritance all of which may be gainfully used in object orientation but only one of these conforms to a generalization. The three types are: Generalization Specialization Restriction

37. The trouble stems from the confusion between the two concepts of sub-typing and sub-classing. Sub-typing is when A is-a B or more correctly A can-act-as-a B. Sub-classing (that is not sub-typing) is the relationship where A is-derived-from B but can not act as it. Sub-typing implies extension Sub-classing implies specialization or restriction

38. As the name implies sub-typing is a logical relationship between types. Specialization and restriction are physical relationships between implementations of classes. Example: MOUSE is a sub-type of MAMMAL A BINARY_SEARCH_TREE is a sub-type of BINARY_TREE For B to be a sub-type of A, it first has to be an A. Then it can only ADD features, leaving all other features unchanged.

39. Specialization is the relationship between classes where one class is altered to yield another by changing one or several of its features. Example: Compound_Interest_Account v. Simple_Interest_Account Note: A C.I.A. is not or can not act as a S.I.A. but we can take a S.I.A and change its feature that calculates interest to obtain a C.I.A.

40. Restriction is the relationship between classes where one or several features of one class is restricted (locked) to yield another. Example: Interest_Bearing_Account v. No_Interest_Account Note: A N.I.A. is not or can not act as an I.B.A. but we can take an I.B.A and lock its feature that calculates interest to obtain a N.IA.

41. The major differences between ER Diagrams and Class Diagrams: ER Only models persistent data Class diagrams Model persistent AND transient objects ER The relationships are mappings Class diagrams The relationships are mappings and other structural ER Depicts only attributes (static individual state no information about possible operations that interact with this state Class diagrams Depicts attributes AND operations

42. CLASS-RESPONSIBILITY-COLLABORATION (CRC) The CRC technique is used either after use cases have been developed or whilst this is happening. It has essentially four uses: • To extract a model. To identify model elements such as classes, methods and associations • To validate or complete use cases • To refine a model • To validate a model and highlight model/design flaws

43. CRC CARDS The process of production of CRC cards is most aligned with the first utility mentioned: To identify model elements such as classes, methods and associations. A CRC card is a 4  6 or a 5  7 card one which there are three main compartments. These compartments are: • Class Name • Responsibility • Collaboration

44. Class Name Collaboration Responsibility We develop a CRC card for each new potential class.

45. Order Order Line Check if item in stock Determine price Order Line Check for valid payment :::::::::::::::::::::::::::::::::::: Dispatch Customer Example: On the back of the card there is usually one or sometimes up to four compartments:

46. The Attribute compartment is the most important and houses information regarding the attributes of the potential class. Attributes Project Hierarchy Description and comments Project Supply Logistics Attributes Hierarchy Cash order, Credit Order order no date etc. Description and comments Back of a CRC Card

47. USING CRC CARDS • Identify a potential class. This may be done with the help of a usecase. • Create a card for that class by first selecting a name and putting that name on the card. • Now identify one responsibility for which you feel this class must exist. Record this in the responsibilities column • Identify the potential object that requests this responsibility of the class identified. Record this in the collaboration column and in front of the responsibility concerned.

48. Identify the specific pieces of information needed to identify this class, or the class needs to hold. Write them as attributes on the back of the card. • If this potential class is in a hierarchy, depict the hierarchy. • Include some notes and comments if needed and identify the project. • Produce a similar card for any new potential class that was discovered.

49. CRC GAME Once you have a handful of inter-relating CRC cards that collectively describe the system or at least some of its functionality, you are ready to play the CRC game. The game is played in two different forms depending on whether the intent is to validate the model or to refine it. To refine the model, you have to have your CRC cards and one person to play the role of each class. To validate you have to have a reasonably complete set of cards, a reasonably comprehensive set of use cases, one person to play each class and one or several small bean bags, balls or similar objects.

50. Keep playing until every responsibility on every card has been either discharged or debated and discarded. Similarly for every attribute. Do not be afraid to combine classes, or split them as necessary, or indeed discard them. Add responsibilities as and when needed or delete them if not useful.