1. By : Dr. Abdulrahman H. Altalhi & Modified by: Dr. Shehab Gamalel-Din By : Dr. Abdulrahman H. Altalhi & Modified by: Dr. Shehab Gamalel-Din

2. 2 Introduction Our main aim in this and the next text-based chapter – Chapter 39 – is to examine the construction of dynamic models of the system. This involves identification of responsibilities and collaborations through consideration of the dynamic or behavioral aspects of the system.Our main aim in this and the next text-based chapter – Chapter 39 – is to examine the construction of dynamic models of the system. This involves identification of responsibilities and collaborations through consideration of the dynamic or behavioral aspects of the system.

3. 3 Introduction We present the activities involved in constructing dynamic models in two stages:We present the activities involved in constructing dynamic models in two stages:  In this chapter we begin to model what each part of the intended behavior of the system involves, referring to the structural model and concentrating on identifying responsibilities that involve using associations between classes.  In Chapter 39 we develop our models by detailing further responsibilities, and by describing the collaborations between objects which ensure that each object fulfils its responsibilities, and contributes appropriately to the overall system behavior.

4. 4 Introduction Responsibilities are the means by which we ensure that the overall system is capable of achieving its purpose as a collection of objects sending messages to one another.Responsibilities are the means by which we ensure that the overall system is capable of achieving its purpose as a collection of objects sending messages to one another. The distinction between responsibilities for recording information and responsibilities for doing something is an important.The distinction between responsibilities for recording information and responsibilities for doing something is an important. Responsibilities for recording information about something is helping us to identify what attributes are appropriate for that class.Responsibilities for recording information about something is helping us to identify what attributes are appropriate for that class. Responsibilities for doing something is helping us to identify what protocol is appropriate for that class.Responsibilities for doing something is helping us to identify what protocol is appropriate for that class. The concept of classes collaborating with each other helps us identify the nature of the messages that must be sent between objects.The concept of classes collaborating with each other helps us identify the nature of the messages that must be sent between objects.

5. 5 Introduction So, by considering the responsibilities that instances of a class must fulfill, we begin to obtain a detailed insight into:So, by considering the responsibilities that instances of a class must fulfill, we begin to obtain a detailed insight into:  the attributes of instances of the class;  the messages that instances of the class respond to (the services the class provides);  and the messages that instances of the class need to send to instances of other classes (the services that the class requires of its collaborators). Considering the responsibilities that instances of a class must fulfill also allows us to validate further the classes and associations we have identified previously.Considering the responsibilities that instances of a class must fulfill also allows us to validate further the classes and associations we have identified previously.  This can lead us both to discard some classes and/or associations as being unnecessary, and to introduce new classes and/or associations

6. 6 1 The Hospital Admission and Treatment system In this section we shall use the HAT system as an example to introduce the activities and concepts involved in the initial stage of analyzing the required behaviors of a system. In this section we shall use the HAT system as an example to introduce the activities and concepts involved in the initial stage of analyzing the required behaviors of a system. We begin to model what each part of the intended behavior of the system involves, concentrating on identifying responsibilities that involve using associations between classes in the structural model.We begin to model what each part of the intended behavior of the system involves, concentrating on identifying responsibilities that involve using associations between classes in the structural model.

7. 7 1 The Initial Structural Model for the HAT System

8. 8 1.1 Identifying use cases The first task is to extract from the negotiated statement of requirements (NSR) those parts that contain information about the required behavior of the system, that is, what the system is required to do.The first task is to extract from the negotiated statement of requirements (NSR) those parts that contain information about the required behavior of the system, that is, what the system is required to do. In the NSR for the HAT system, these behavioral requirements are found towards the end. The following excerpt from the NSR contains the relevant information.In the NSR for the HAT system, these behavioral requirements are found towards the end. The following excerpt from the NSR contains the relevant information.

9. 9 1.1 Identifying use cases The system has to be able to do the following.The system has to be able to do the following.  In response to an enquiry about the doctors who have treated a patient, the system should display the following information:  the team code of the team caring for the patient;  the name of the consultant doctor responsible for the patient;  a list of the names of the doctors who have treated the patient.  In response to an enquiry about the patients that a team cares for, the system should display the following information:  the names and dates of birth of the patients that are currently in the hospital and that the team cares for,  the names of the wards that they are in.

10. 10 1.1 Identifying use cases  When a patient is admitted, the system is given the following information, which it should record:  the new patient’s name, address and date of birth;  the name of the ward to which the patient has been admitted;  the team code of the team that is to care for the patient.  When a patient is treated by a doctor, the system is given the name of the patient, the name of the ward the patient is in, the name of the doctor and the code of the team the doctor is in. The system should record that the doctor has treated the patient.  When a patient is discharged, the system is given the name of the patient and of the ward the patient is on. The system should remove all information relating to that patient.

11. 11 1.1 Identifying use cases A use case can be thought of as a single piece of coherent behavior.A use case can be thought of as a single piece of coherent behavior. In the above quotation from the NSR for the HAT system, the required behavior is clearly partitioned into five separate behaviors, each of which will be a separate use case.In the above quotation from the NSR for the HAT system, the required behavior is clearly partitioned into five separate behaviors, each of which will be a separate use case. We shall name these use cases as follows (the letters prefixing the names are for later reference):We shall name these use cases as follows (the letters prefixing the names are for later reference): A List Patient’s TreatmentA List Patient’s Treatment B List Team’s PatientsB List Team’s Patients C Admit PatientC Admit Patient D Treat PatientD Treat Patient E Discharge PatientE Discharge Patient

12. 12 1.1 Identifying use cases For the use cases we have to:For the use cases we have to: 1.Analyze the NSR to find the main activities. 2.List the names of the use cases. 3.Identify what information is given to each use case and the goal of each use case (input & output) We need to be able to specify unambiguously exactly what each use case involves. We can do this by identifying what information is given to each use case and what the goal of the use case is.We need to be able to specify unambiguously exactly what each use case involves. We can do this by identifying what information is given to each use case and what the goal of the use case is. For the Treat Patient use case we could write: Given: A patient and the ward he is in. Goal: The system has to record the doctors who have treated the patient. For the rest of this lecture we will focus on the first use case (A) and use it as our example to apply all the new concepts.

13. 13 1.1 Identifying use cases A List Patient’s Treatment Given: A patient (identified by ward name and patient name). Goal: The following have to be returned: the team code of the team that cares for the patient; the name of the consultant doctor responsible for the patient; the names of the doctors who have treated the patient. These specifications are stated in terms of the application area. The main concern of this chapter is to translate such into clear specifications in terms of the domain model of the system.These specifications are stated in terms of the application area. The main concern of this chapter is to translate such specifications into clear specifications in terms of the domain model of the system.

14. 14 1.2 Communication with the user interface Each use case has to be initiated in some way.Each use case has to be initiated in some way. The user will cause a message to be sent from the user interface to the domain model.The user will cause a message to be sent from the user interface to the domain model. For this to be possible there needs to be some way that the domain model can communicate with a user interface that is ‘attached’ to it.For this to be possible there needs to be some way that the domain model can communicate with a user interface that is ‘attached’ to it. We introduce an extra class, called the orchestrating class, to the structural model. This class has just one instance, the orchestrating instance, and all communication with user interfaces is done through this orchestrating instance.We introduce an extra class, called the orchestrating class, to the structural model. This class has just one instance, the orchestrating instance, and all communication with user interfaces is done through this orchestrating instance.

15. 15 1.2 Communication with the user interface As far as the domain model is concerned, each use case is initiated by the orchestrating instance and, as far as a user interface is concerned, the orchestrating instance is the domain model.As far as the domain model is concerned, each use case is initiated by the orchestrating instance and, as far as a user interface is concerned, the orchestrating instance is the domain model. In this way we attempt to keep the domain model and the user interface as independent as possible, while still allowing the necessary communication to take place.In this way we attempt to keep the domain model and the user interface as independent as possible, while still allowing the necessary communication to take place. In the HAT example we name the orchestrating class Administration and the orchestrating instance hat.In the HAT example we name the orchestrating class Administration and the orchestrating instance hat. As hat has to deal with communication with the user interface, for each use case it will have responsibilities for the initial processing of any information provided by the user interface and for preparing any information for return to the user interface.As hat has to deal with communication with the user interface, for each use case it will have responsibilities for the initial processing of any information provided by the user interface and for preparing any information for return to the user interface.

16. 16 1.2 Communication with the user interface A List Patient’s TreatmentA List Patient’s Treatment Given: A patient (identified by ward name and patient name). Goal: The following have to be returned: the team code of the team that cares for the patient; the name of the consultant doctor responsible for the patient; the names of the doctors who have treated the patient. The initial processing in this use case consists of locating the instance of Patient that corresponds to the patient with the given name that is on the ward with the given ward name.The initial processing in this use case consists of locating the instance of Patient that corresponds to the patient with the given name that is on the ward with the given ward name. This is the responsibility of hat, and to see what it involves we return to the class diagram within the structural model.This is the responsibility of hat, and to see what it involves we return to the class diagram within the structural model.

17. 17 1.2 Communication with the user interface Here we see that Ward is associated with Patient via the association hasOn. In other words, each instance of Ward is linked to each instance of Patient that corresponds to a patient that is on the ward.Here we see that Ward is associated with Patient via the association hasOn. In other words, each instance of Ward is linked to each instance of Patient that corresponds to a patient that is on the ward. These links can be used to enable a Ward instance to locate the Patient instances that are on that ward.These links can be used to enable a Ward instance to locate the Patient instances that are on that ward. Because we want a Ward instance to be able to locate the associated Patient instances, we say that the association hasOn needs to be navigated in the direction from Ward to Patient.Because we want a Ward instance to be able to locate the associated Patient instances, we say that the association hasOn needs to be navigated in the direction from Ward to Patient.

18. 18 1.2 Communication with the user interface This is shown on the class diagram by adding an arrowhead at the Patient end of the association, as shown in the figure.This is shown on the class diagram by adding an arrowhead at the Patient end of the association, as shown in the figure. At the same time, we need to allocate explicitly the responsibility for locating the relevant Patient instance to Ward. There is more to this responsibility than just finding a linked Patient instance at random.At the same time, we need to allocate explicitly the responsibility for locating the relevant Patient instance to Ward. There is more to this responsibility than just finding a linked Patient instance at random. What will be required of a Ward instance is the ability to locate, from among all the linked Patient instances, the particular instance that has a given name.What will be required of a Ward instance is the ability to locate, from among all the linked Patient instances, the particular instance that has a given name. This requires a Ward instance to use patient names to keep track of the instances of Patient to which it is linked by the hasOn association.This requires a Ward instance to use patient names to keep track of the instances of Patient to which it is linked by the hasOn association.

19. 19 1.2 Communication with the user interface We express this by including a description of this responsibility in the text of the structural model. It is added to the description of the class under the heading Associations thus:We express this by including a description of this responsibility in the text of the structural model. It is added to the description of the class under the heading Associations thus: Note that we add the identifying letter [A] of the use case in brackets at the end of the responsibility.Note that we add the identifying letter [A] of the use case in brackets at the end of the responsibility. It is important for maintenance and testing purposes to be able to trace where each responsibility of a class is needed.It is important for maintenance and testing purposes to be able to trace where each responsibility of a class is needed.

20. 20 1.2 Communication with the user interface Of course, before we can navigate hasOn to locate the required Patient instance, we first need to locate the relevant Ward instance; that is, the one with the given name.Of course, before we can navigate hasOn to locate the required Patient instance, we first need to locate the relevant Ward instance; that is, the one with the given name. It is here that the orchestrating class, Administration, becomes relevant.It is here that the orchestrating class, Administration, becomes relevant. At the moment Administration is not connected in any way with the rest of the structural model.At the moment Administration is not connected in any way with the rest of the structural model. If we introduce an association between Administration and Ward that is navigated in the direction from Administration to Ward, then we can use this association to locate the required instance of Ward.If we introduce an association between Administration and Ward that is navigated in the direction from Administration to Ward, then we can use this association to locate the required instance of Ward. We call this association wards.We call this association wards.

21. 21 1.2 Communication with the user interface The relevant part of the class diagram is given in the figureThe relevant part of the class diagram is given in the figure

22. 22 1.2 Communication with the user interface At the same time, we assign the following responsibility to Administration:At the same time, we assign the following responsibility to Administration: Use ward names to keep track of instances of Ward linked via wards [A]. For this use case we can show what is required for the initial processing as follows.For this use case we can show what is required for the initial processing as follows. Given: A ward name, wName, and a patient name, pName.Given: A ward name, wName, and a patient name, pName. Locate the instance, aWard, of Ward with the name wName linked to hat via wards.Locate the instance, aWard, of Ward with the name wName linked to hat via wards. Locate the instance, aPatient, of Patient with the name pName linked to aWard via hasOn.Locate the instance, aPatient, of Patient with the name pName linked to aWard via hasOn.

23. 23 1.2 Communication with the user interface We have started breaking down the requirements of the use case into a set of steps.We have started breaking down the requirements of the use case into a set of steps. These steps are each expressed in terms of the domain model (classes, objects, attributes, associations and links).These steps are each expressed in terms of the domain model (classes, objects, attributes, associations and links). They form the start of what is called a walk-through of the use case.They form the start of what is called a walk-through of the use case. A walk-through is simply a series of steps that need to be carried out in the domain model in order to satisfy the requirements of a use case.A walk-through is simply a series of steps that need to be carried out in the domain model in order to satisfy the requirements of a use case. In other words, a walk-through is a detailed specification of the requirements of a use case in terms of the domain model; it is a list of what has to be done.In other words, a walk-through is a detailed specification of the requirements of a use case in terms of the domain model; it is a list of what has to be done.

24. 24 1.2 Communication with the user interface In determining user interface-related responsibilities we must also consider any results that have to be returned to the user interface to satisfy the requirements of a use case.In determining user interface-related responsibilities we must also consider any results that have to be returned to the user interface to satisfy the requirements of a use case. In the specification of the List Patient’s Treatment use case the goal indicates that a team code, a consultant doctor’s name and a list of doctor names have to be returned to the user interface.In the specification of the List Patient’s Treatment use case the goal indicates that a team code, a consultant doctor’s name and a list of doctor names have to be returned to the user interface. From the structural model we know that team code is an attribute of the class Team and doctor name is an attribute of Doctor.From the structural model we know that team code is an attribute of the class Team and doctor name is an attribute of Doctor. Therefore, to allow hat to return this information, it would be sensible for the steps of the walk-through to provide hat with the relevant Team object and ConsultantDoctor object, as well as a collection of the relevant Doctor objects.Therefore, to allow hat to return this information, it would be sensible for the steps of the walk-through to provide hat with the relevant Team object and ConsultantDoctor object, as well as a collection of the relevant Doctor objects. Then, by sending appropriate getter messages to these objects, hat should be able to get the team code and doctor names for return to the user interface.Then, by sending appropriate getter messages to these objects, hat should be able to get the team code and doctor names for return to the user interface.

25. 25 1.2 Communication with the user interface What is important here is that we have decided that for hat to carry out its responsibilities, the main part of this walk-through should provide hat with the relevant instances of Team, ConsultantDoctor and Doctor.What is important here is that we have decided that for hat to carry out its responsibilities, the main part of this walk-through should provide hat with the relevant instances of Team, ConsultantDoctor and Doctor.

26. 26 1.2 Communication with the user interface This is all we do with the use case at this stage. We have identified the following steps that are needed for communication with the user interface.This is all we do with the use case at this stage. We have identified the following steps that are needed for communication with the user interface. At the start of the walk-through:At the start of the walk-through: Given: A ward name, wName, and a patient name, pName. Locate the instance, aWard, of Ward with the name wName linked to hat via wards.Locate the instance, aWard, of Ward with the name wName linked to hat via wards. Locate the instance, aPatient, of Patient with the name pNamelinked to aWard via hasOn.Locate the instance, aPatient, of Patient with the name pNamelinked to aWard via hasOn. At the end of the walk-through:At the end of the walk-through: Retrieve the required data from the relevant instances of Team, ConsultantDoctor and Doctor.Retrieve the required data from the relevant instances of Team, ConsultantDoctor and Doctor. Result: The relevant team code, consultant name and doctor names.Result: The relevant team code, consultant name and doctor names.

27. 27 1.3 Walk-throughs and navigation of associations In the previous subsection we considered what is required by each use case in relation to communication with the user interface.In the previous subsection we considered what is required by each use case in relation to communication with the user interface. The steps we identified at the start of each walk-through locate the objects that are needed for the main part of the use case.The steps we identified at the start of each walk-through locate the objects that are needed for the main part of the use case. We now proceed to the analysis of the main part of each use case:We now proceed to the analysis of the main part of each use case: identifying in terms of the domain model the steps that are required, starting with these ‘given’ objects, in order to satisfy the goal of the use case.

28. 28 1.3 Walk-throughs and navigation of associations We now proceed to the analysis of the main part of each use case:We now proceed to the analysis of the main part of each use case: identifying in terms of the domain model the steps that are required, starting with these ‘given’ objects, in order to satisfy the goal of the use case. These steps should include the following:These steps should include the following: checking any conditions that the given objects must satisfy (as stated in the specification of the use case);checking any conditions that the given objects must satisfy (as stated in the specification of the use case); making any changes to the state of the system that are required (creation and deletion of objects and links, changes to values of attributes) and ensuring these changes do not violate any invariants;making any changes to the state of the system that are required (creation and deletion of objects and links, changes to values of attributes) and ensuring these changes do not violate any invariants; locating any objects that are needed to do the above or to allow retrieval of information to be returned to the user interface.locating any objects that are needed to do the above or to allow retrieval of information to be returned to the user interface. In the next stage of the process we continue to concentrate on locating objects, considering what must be done in terms of the domain model.In the next stage of the process we continue to concentrate on locating objects, considering what must be done in terms of the domain model.

29. 29 1.3 Walk-throughs and navigation of associations When we have done this for all use cases, we will have identified the overall navigational usage of each association.When we have done this for all use cases, we will have identified the overall navigational usage of each association. That is the direction(s) in which each association needs to be navigated to satisfy the requirements of all the use cases. That is the direction(s) in which each association needs to be navigated to satisfy the requirements of all the use cases.

30. 30 1.3 Walk-throughs and navigation of associations For the List Patient's Treatment use case, by analyzing the required steps, we can find the required associations and refined steps as follows:For the List Patient's Treatment use case, by analyzing the required steps, we can find the required associations and refined steps as follows: Given: A ward name, wName, and a patient name, pName. Locate the instance, aWard, of Ward with the name wName linked to hat via wards. (UI)Locate the instance, aWard, of Ward with the name wName linked to hat via wards. (UI) Locate the instance, aPatient, of Patient with the name pName linked to aWard via hasOn. (UI)Locate the instance, aPatient, of Patient with the name pName linked to aWard via hasOn. (UI) Locate the instance, aTeam, of Team linked to aPatient via caresFor.Locate the instance, aTeam, of Team linked to aPatient via caresFor. Locate all the instances of Doctor that are linked to aPatient via hasTreated.Locate all the instances of Doctor that are linked to aPatient via hasTreated. Locate the instance, aConsultant, of ConsultantDoctor linked to aTeam via isHeadedBy.Locate the instance, aConsultant, of ConsultantDoctor linked to aTeam via isHeadedBy. Retrieve the required data from aTeam, aConsultant and the instances of Doctor. (UI)Retrieve the required data from aTeam, aConsultant and the instances of Doctor. (UI) Result: The relevant team code, consultant name and doctor namesResult: The relevant team code, consultant name and doctor names

31. 31 1.3 Walk-throughs and navigation of associations Navigation required for List Patient’s Treatment

32. 32 Summary 1. 1.Identifying use cases:   We identify use cases from the negotiated statement of requirements. These are initially specified in terms of the application area. 2. 2.Communication with the user interface:   We introduce the orchestrating class and instance, and consider what is needed for successful translation between user interface data and domain model objects. There are two main aims: To identify the associations (and the navigation) required to locate the objects identified by data from the user interface. To identify the objects (if any) that the main part of the use case requires to return so that the orchestrating instance can extract from their attributes the data to be returned to the user interface.   In doing this we decide what associations from the orchestrating class are to be added to the structural model. Having done this we should know: which objects need to be located before the main part of the use case begins; which objects need to have been located by the end of the main part of the use case.

33. 33 Summary 3. 3.Walk-throughs and navigation of associations   We construct a walk-through for each use case in sufficient detail to specify what has to be done in terms of the domain model, and to identify all the steps that require objects to be located.   Each ‘locate’ step is expressed in terms of an association in the class diagram.   These steps allow us to determine the navigational usage of the associations, and to allocate the association responsibilities to the appropriate classes.   When constructing walk-throughs, care has to be taken to check that any conditions on the given objects are satisfied, and that any relevant invariants still hold at the end of the use case.

34. 34 Exercise Please go through the Other Use Cases of HAT.

35. 35 HAT: Class Diagram (augmented with navigations)

36. 36 HAT: Class Descriptions Class: Administration Attributes: None Associations: A Use ward names to keep track of the instances of Ward linked via wards. [A; C; D; E] Use team codes to keep track of the instances of Team linked via teams. [B; C; D] Class: Team Attributes: code "The unique code of the team" Associations: Use doctor names to keep track of the instances of Doctor linked via consistsOf. [D] A Keep track of the instance of ConsultantDoctor linked via isHeadedBy. [A] Keep track of the instances of Patient linked via caresFor. [B] Class: Ward Attributes: name "The unique name of the ward" Associations: A Use patient names to keep track of the instances of Patient linked via hasOn. [ A ; C; D; E] Class: Patient Attributes: name "The name of the patient" address "The address of the patient" dob "The date of birth of the patient" Associations: Keep track of the instance of Ward linked via hasOn. [B] A Keep track of the instance of Team linked via caresFor. [A; D; (E)] A Keep track of the instances of Doctor linked via hasTreated. [A; (E)]

37. 37 HAT: Class Descriptions (cont.) Class: Doctor "Abstract; generalizes JuniorDoctor and ConsultantDoctor" Attributes: name "The name of the doctor [A]" address "The address of the doctor" Associations: None Class: ConsultantDoctor "Specializes Doctor" Attributes: None Associations: None Class: JuniorDoctor "Specializes Doctor" Attributes: grade "The grade of the junior doctor" Associations: None

38. 38 Exercise 2: The Video Library system Please go through the Video Library System example as illustrated in the text book.

39. 39 3. Anthropomorphism Anthropomorphism is the attribution of human personality to software entities.Anthropomorphism is the attribution of human personality to software entities. An anthropomorphic language has a place in object-oriented software development.An anthropomorphic language has a place in object-oriented software development.