ECSE Software Engineering HO 7 © HY 2012 Lecture 7 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.

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 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.

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 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.

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 TTD1:TTD Exchange:Connection Attempt_conn( ) TTD2:TTD Attemp_disconn( ) Reset( ) Disconnect( ) Establish_call( ) 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 1T 1Exchange req. ser. Reset( ) from TTD2T Establish_call( )

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 TTD1:TTD NSLX:LX Connect( ) Receive_call( ) Routed( ) Dial( ) Dial-Register:RegFSLX:LX Sound_dial_tone( ) 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 1T 1NSLX req. ser. Dial( ) from Dial_register 1Dial_register req. ser. Receive_call( ) from FSLX 1FSLX req. ser. Routed( ) from Call_registerT Call-Register:Reg

ECSE Software Engineering HO 7 © HY 2012 Lecture 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.

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 TTD2:TTD Exchange:Connection 1- Attemp_connect( ) 3- Attempt_disconnect( ) 4a- Disconnect( ) 2- Establish_call ( ) 4b- Reset( ) TTD1:TTD 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 1T 1Exchange req. ser. Reset( ) from TTD2T

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 TTD1:TTD NSLX:LX 1. Connect( ) 3. Receive_call( ) 4. Routed( ) 2b. Dial( ) Dial-Register:Reg FSLX:LX 2a. Sound_dial_tone( ) 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 1T 1NSLX req. ser. Dial( ) from Dial_register 1Dial_register req. ser. Receive_call( ) from FSLX 1FSLX req. ser. Routed( ) from Dial_registerT

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 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.

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 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.

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 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

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 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.

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 Attempt_connect( ) Attempt_disconnect( ) Connection 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 1T 1Exchange req. ser. Reset( ) from TTD2T

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 Dial( ) Dial_register Routed( ) Call_Register Connect( ) Receive_call( ) Local_exchange 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 1T 1NSLX req. ser. Dial( ) from Dial_register 1Dial_register req. ser. Receive_call( ) from FSLX 1FSLX req. ser. Routed( ) from Call_registerT

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 Dial( ) Dial_register Routed( ) Call_Register Connect( ) Receive_call( ) Local_exchange Attempt_connect( ) Attempt_disconnect( ) Connection a_Number

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 Dial( ) Dial_register Routed( ) Call_register Connect( ) Receive_call( ) Local_exchange Attempt_connect( ) Attempt_disconnect( ) Connection Register a_Number

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 Reviewing usecases: Like any other artifact in software engineering, usecases may also be reviewed. We review usecases from the perspective of: 1.Well-formedness 2.Completeness 3.Fit We shall discuss these one at a time.

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 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.

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 Completeness: There are two aspects to completeness; Essential completeness, and Structural completeness We must ensure both.

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 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.

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 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.

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 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

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 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

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 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: name: Person This really means: What is the name of this person?

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 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?

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 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.

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 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().

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 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)

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 Object orientation is all about message passing between objects. For messages to pass between objects (programming view): 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 ACCESS CONTAINMENT ASSOCIATION INHERITANCE In the analysis domain, these are all forms of relationships

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 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.

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 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

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 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: An association: A static mapping

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 AGGERGATION V. CONTAINMENT We said earlier that in UML, aggregation was modeled in two forms : Weak aggregation and Composition. What is important is to note that containment IS NOT a form of aggregation. (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).

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 Containment is that relationship when an object is temporarily placed 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.

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 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.

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 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 Inheritance

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 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

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 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.

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 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.

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 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.

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 The major differences between ER Diagrams and Class Diagrams: ER Only models persistent data Class diagramsModel persistent AND transient objects ER The relationships are mappings Class diagramsThe relationships are mappings and other structural ER Depicts only attributes (static individual state no information about possible operations that interact with this state Class diagramsDepicts attributes AND operations

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 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 CLASS-RESPONSIBILITY-COLLABORATION (CRC)

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 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

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 Class Name Responsibility Collaboration We develop a CRC card for each new potential class.

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 Example: Order Check if item in stock Determine price Check for valid payment Dispatch :::::::::::::::::::::::::::::::::::: Order Line Customer On the back of the card there is usually one or sometimes up to four compartments:

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 Project Hierarchy Attributes Description and comments Back of a CRC Card The Attribute compartment is the most important and houses information regarding the attributes of the potential class. Project Hierarchy Attributes Description and comments order no date etc. Supply Logistics Cash order, Credit Order

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 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.

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 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.

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 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.

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 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.

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 MODEL REFINEMENT Give each person the card they are to play the role of. Start at a logical place with some class. Debate if it is needed or if it needs to change. Start a thread that can be initiated by invoking one of the responsibilities of that class. Identify the collaborator (target) class. Pass control to that class by calling the service you need of that class. If collaborator class does not exist, create it.

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 MODEL VALIDATION Give each person the card they are to play the role of. Also nominate a person to play each external actor. Start with your top ranking use case. Identify the actor who initiates things and give him or her the bean bag. The actor starts a thread that can be initiated by passing the bag to the correct class according to the use case.

ECSE Software Engineering HO 7 © HY 2012 Lecture 7 The class checks if it can accept the bag. If yes, it does so, if not we raise an alarm and debate and rectify the model. The class now passes the bag to a class whose service it needs (calls), a class for which it is a collaborator. Keep playing until the use case is complete and update the model if necessary Go to the next use case