A dvanced S ystems A nalysis and D esign Fall 2006

1. Advanced Systems Analysis and Design Fall 2006 Convener: Houman Younessi 1-860-548-7880 youneh@rpi.edu

2. 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.

3. 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.

4. 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.

5. TTD1:TTD TTD2:TTD Exchange:Connection Attempt_conn( ) 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 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

6. 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

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

8. 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

9. 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 Call_registerT Dial-Register:Reg 4. Routed( ) 3. Receive_call( ) FSLX:LX

10. 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.

11. 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.

12. 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

13. 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.

14. 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( )

15. 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

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

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

18. 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.

19. 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.

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

21. 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.

22. 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.

23. 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

24. 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

25. Enabling Review KEEPING THE RIGHT CLASSES Applying these techniques shall identify many potential classes from the domain. We now need to sift through these and select a coherent set of the “right” classes, discarding the rest. To do so we apply a number of heuristics (Younessi et al.; 1995): The Domain Relevance Test The Absorption Test The Attribute/Function Test The Domain Relevance Test The Absorption Test The Attribute/Function Test

26. The Domain Relevance Test: Ask the following: Does the Provisional Class/Object relate to the purpose for which the system exists? Is information retained within the relevant system about this Class/Object? Does this PCO have a behavior that is needed by the system? Does this PCO have more than one attribute and/or behavior?

27. The Absorption Test; First identify all PCOs that have identical or semantically close names. Investigate if these names actually refer to the same entity. This may not always be the case: Clerk LoanClerk or TaxationClerk In such situations rename all for clarity. Investigate if different PCOs have the same name. Resolve.

28. Attribute/Function Test: Isolate PCOs that have only one attribute or function. Isolate PCOs whose name is a quantity which is simply derived by computation. Absorb these PCOs into other PCOs that can logically contain them.

29. 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:

30. 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?

31. 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.

32. 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().

33. 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)

34. 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

35. 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.

36. 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

37. 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

38. 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.

39. 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.

40. 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.

41. 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

42. 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

43. 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.

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

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

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

47. 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

48. 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

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

50. 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: