M256 Software development with Java Prepared By: Ms Samar Shilbayeh ,[email protected] Modified By: Mrs. Nibal Abu Samaa, [email protected]
Nov 18, 2014
M256Software development with Java
Prepared By: Ms Samar Shilbayeh ,[email protected] By: Mrs. Nibal Abu Samaa, [email protected]
Block 2Unit6
Core system design
3
Communication between user interface and the core system
Getting information Anthropomorphism Changing state
4
Outline
Section 1
Introduction
6
SoftWare development in M256
7
1) Introduces a simple way of dealing with communication between user interface and core systems.
2) Shows one way of dividing responsibility for a use case between the user interface and core system.
3) Analyses some use cases that do not involve changing the state of the core system.
4) Analyses some use cases that do involve changing the state of the core system .
Aims of Core System designs
8
5) For each use case, shows what is involved in producing a dynamic model that illustrates a design.
6) Shows how from a design, methods can be allocated to appropriate classes and explains what is involved in navigating and creating links.
7) Briefly considers the use of anthromorphic language in object-oriented software development.
Aims of core System designs
Implementation model It contains structural model Structural model include
◦ Class diagram ◦ Textual descriptions
Classes in the implementation model represent SW classes
Classes contain protocols, i.e. methods. and method specifications
Implementation model contains dynamic model, sequence diagrams.
9
The outcome of this stage
Section 2
Communication between user interface and core system
11
Core ObjectThe core system will contain software objects
that represents the real-world objects of the use case description.
For Example:In a Hospital management System...Patient and Doctor are two real world
object..
Communication between user interface and core system
12
The user interface tells the core system to begins its work.
The core system returns results to the user interface.
The division of communication between the user interface and core system.
13
user interface and the core system should be designed as separate components such that:
The core system is protected from threats to its integrity through misuse by the user interface.
The user interface is independent of how the core system is implemented.
The user interface is replaceable without significant impact on the core system.
A guiding principle:
It is done by causing a message to be sent from the user interface to the core system so that appropriate actions can be taken within the core system...
Example: TreatPatient use case,
◦ identify patient and doctor◦ instruct interface to send message to record
treatment◦ core system record treatment of the patient by
the doctor.
14
Initiating a use case
In a Hospital Management System..
recordTreatment ( patient5,.....)
Fig: The user interface sends a record Treatment message with a Patient Object, patient 5 as an argument.
15
Supplying information to the core system
userInterface
Objects will be used as arguments The coordinating object sends the resulted object to the user interface
The user interface displays what is needed from that object.
16
Supplying info to the core system
Can we let interface send the message directly to doctor?
Yes we can, But what if, at a certain point we want the
interface to send the message to the patient instead? Interface has to be changed!!
Interface in this case is dependent on core system
to solve this dependency issue we use the coordination object.Note: coordinating message = the coordinating method
17
The need for coordinating object
19
The behaviour for each use case will be initiated by the user interface sending a coordinating message to the coordinating object.
It is the coordinating object that ensures the appropriate messages are sent to the other objects.
the coordinating object is responsible for returning any information (objects) required to be displayed to the user.
The coordinating object
20
initial structural model, the class diagram of the Hospital System
21
The coordinating class
getPatients(Ward 3)
{patient2,patient4,patient6}
fig:Returning objects to the user interface
22
Returning Result
userInterface hospital
Putting information, ex: Treat patient Getting information, ex: List Ward’s Patients
Both The coordinating object is responsible for returning any results to be displayed to the user.
23
Returning results
The core object return results as objects rather than attributes
The user interface extract the attribute to be displayed to the user
The advantages of doing so: ◦the core system is independent of
changes that may be made to the interface in the future
◦The responsibility is split between core system and user interface.
24
Returning object as a result
Return oldest pupil in a form from the use case: the secretary identify the
form A message is sent from interface to the
coordinating object The argument in the message: Form Returned result (object): Pupil interface send getter message to Pupil to
get name attribute
25
Example
What the user interface will be able to do with the core objects?
The core system is protected by allowing only messages that get information about the attribute value
All state-changing must be done by the coordinating object.
User interface will not have access to messages that reveal the internal structure of the core system
26
Core system integrity
27
How the use case will be initiated?1. The user will send a message to the user
interface with the behavior that the system should do.
2. Each use case has a specific behavior, Each use case has (given and goal)
Given: the information given by the user and entered to the systemResult(The Goal) : the information result as the out put of the system :
1- getting information 2-or changing the state without any
output
How to create a use case
28
A use case can be thought of as a single piece of coherent behavior.
for the use cases we have to:◦Analyze the REQUIREMENT DOCUMENT
to find the main activities.◦List the names of the use cases.◦Identify what information is given to each
use case and the goal of each use case.
Identifying use cases
29
Use case: List Patient’s Treatment. Given: A patient 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 and the grade of the doctors who
have treated the patient.
Example (use case G)
30
Use case: List Teams patients Given: A team Goal: The following information have to be returned for each patient that the team cares for :The name and date of birth The name of the ward the patient is on
Example (use case F)
31
Use case: Admit patient Given: the patient’s name, sex and date of birth
and identifies the team that cares for the patient. a ward of the appropriate type with empty beds;
Goal: It records the following information: The patient’s name, sex and date of birth; The patient is under the care of the given team; The consultant that heads the team is
responsible for the patient; The patient is on the ward; It informs the administrator of the ward to
which the patient has been admitted.
Example (use case A)
Section 3
Getting Information
33
Use case E -List Ward’s Patients:The administrator identifies the ward.For each patient on the ward the system displays the patient’s name and age in years.
3.1Getting Simple Information:
example of the use case involving particular objects, namely, a Ward object, which we called ward3,and Patient objects, patient2, patient4,and patient6.
An example of a use case such as this is called a scenario.
For example, what is involved in the design of List Ward’s Patients will be examined in terms of the above scenario, whose objects we will shortly illustrate in an object diagram.
However, although the scenario involves specific objects, the reasoning will be general, and from it we will derive a design that is applicable to whatever Ward and Patient objects are involved.
The scenario must be considered in detail to determine what the core system must do and how it can be done.
Use case E -List Ward’s Patients:
Consider the example: List Ward’s Patients The relevant part of the class diagram
35
36
List Wards patients use case
navigation from ward to Patient
Use case: List Ward’s Patients:Given: The ward.Goal: For each
patient on the ward the system displays the patient’s name and age in years.
HospCoord
Ward
Patient
hasOn
hasWards
37
Step 1. Draw object diagramStep 2. Specify the coordinating method
Step 3. Implementing linksStep 4. The walk through and a sequence diagram
Step 5. Updating structural model
The process of creating a design for a use case.
the particular objects referred to in our scenario, by illustrating that the Ward object, ward3,is connected to each of the Patient objects patient2, patient4 and patient6 by a link of the hasOn association.
Step 1. Draw object digram
39
Step 2. Specify the coordinating method
Coordinating method specification consists of the following:
1- Collection<Patient> getPatients (Ward aWard)
2- Post-condition of the method : returns a collection of all the Patient objects linked to aWard.
40
Step 2. Specify the coordinating method
Return type
method name
argumentname
argument type
A link is implemented between two objects, by holding a reference for one or both of the linked object
The object ward3 references the Patient objects indirectly via a collection.
41
Step 3. Implementing links
Ward
Patient
hasOn0..*
1
The previous figure shows the direction from ward to patient, and note 0..*
For the other direction, each patient is in one ward.
42
Ward
Patient
hasOn0..*
1
We can now list in more detail (a walk-through of the use case ) what is involved for this particular scenario as follows:
Given: the Ward object ward3.Goals:
1. Access the collection of patients objects linked to ward3, which in this case: {patient2, patient4, patient6}
2. Return {patient2, patient4, patient6}
The steps of a walk through will be prompted by a sequence of message passing through the system initiated by the coordinating message. 43
Step 4. The walk through and a sequence diagram
44
Each object is represented by a rectangle, This rectangle contains an identifier for the object, but no attribute values.
Time is viewed as running vertically downwards. A dashed vertical line running down from an object
rectangle represents the lifeline of that object, that is, the time during which the object exists.
When an object receives a message An ‘endless’ activation rectangle indicates that the object has not completed its processing.
The activation rectangle for the user Interface object comes straight out of the object rectangle and always appears endless. This indicates that the user interface is continuously active, always listening for events (mouse clicks, for example) caused by the user.
A message is represented as a solid arrow.
Sequence diagram features
Adding walk through steps to the sequence diagram
The walk-through and sequence diagram form a dynamic model, providing the basis of a general design for how the core system will carry out its responsibility for listing a ward’s patients.
For List Ward’s Patients use case, the consequences of the design on the system structure must be recorded.
Additional responsibilities are required for objects of the classes ward and Hospcoord
46
Step 5. Updating structural model
Each ward object needs to hold a reference to a collection of all the Patient objects linked to it.
To enable this, an instance variable patients which references such a collection should be specified for the ward class.
Each ward object needs to respond to a getpatients() message,
so the ward protocol should include a specification for a method getPatients().
The method should return a collection of all the Patients object linked to the receiver ward object.
See page 26, 27.
47
Updating structural model
Updating structural model
These responsibilities, added to the class description for Ward, result in the following.:
Class Ward A hospital ward Attributes
name The unique name of the ward type Whether the ward is for male or female (M or F) patients capacity The maximum number of patients that can be on the ward at any one time /numberOfFreeBeds The number of free beds on the ward Links Collection<Patient> patients References a collection of all the linked Patient objects. Protocol Collection<Patient> getPatients() Post-condition: returns a collection of all the linked Patient objects.
49
The class details for HospCoord at this stage in the development simply include the coordinating method specification, as follows:
Class HospCoord Attributes None Links None Protocol Collection<Patient> getPatients(Ward aWard)
Post-condition: returns a collection of all the Patient objects linked to aWard.
Updating structural model
50
We have three types of responsibilities that should be represented in the class description: The attribute responsibility:Represented in the
class it self The association responsibility: is represented
by creating instance or collection of instances in the class that responsible for this association
The protocol responsibility: is represented by implement the method inside the class that receives this message in the dynamic diagram
important notes:
The consequences on the system structure are as follows:◦Class description is updated to include: new method link references
After the link reference is identified the corresponding arrow should be drawn, that is updating the class diagram described as navigating.
51
Updating the structural model
52
Updating the structural model
Here are excerpts class definitions which correspond to this design.
//Definition of coordinating class.Public class HospCoord{
//code omittedpublic Collection<Patient>getPatients(Ward aWard){return aWard.getPatients(); //send getPatients()to the argument}
//code omitted}
//Definition of wardPublic class Ward
{//code omittedprivate Collection<Patient>patients;//all the linked patient object.Collection<patient>getPatients(){
return patients();}//code omitted
}53
1. Starting from use case object diagram,◦ Develop scenario, involving objects and links, ex: ward3
linked to 3 patients 2, 4, and 6, ◦ object diagram◦ constructing the sequence diagram for the scenario as well.
2. Generalizing coordinating method specification3. Adding links4. Develop the walk through and the sequence
diagram.5. Updating the structural model (class description
and navigation arrows) .
See SAQ 6 page 29
54
Summary of the approach used
The walk through and sequence diagram constitute the dynamic model
Getting complex information -example
Involving more than one class Ex: ListTeamPatientAndWards(team2) The steps starting page 32:
◦ Object diagram◦ Sequence diagram◦ Specify coordinating method◦ Walk through and sequence diagram◦ From the walk through and sequence diagram:
Method specification, and link references Class diagram with the arrows according to link
references
56
Getting complex information
57
List Team’s Patients use case (labelled F in the requirements document). The administrator identifies the team. For each patient cared for by the team, the System displays:
◦the patient’s name; ◦the name of the ward that the patient is on.
List Team’s Patients
58
The part of the class diagram
59
THE NAVIGATION
The navigation that results from this use case
hasTeams is navigated from HospCoord to Team
caresFor is navigated from Team to Patient
hasOn is navigated from Patient to ward
hasTeams
HospCoord
Team ward
Patient
caresForhasOn
60
Use case : List Teams patient Given: The team For each patient cared for by the team,
Goal: System displays: The patient’s name; The name of the ward that the patient is on.
List Teams patient (use case F)
61
In a typical scenario, suppose that the Team object corresponding to the team identified by the administrator is team2, and that, based on the class diagram, the relevant Patient and Ward objects are as shown in the object diagram
scenario
Example: List Team’s Pateints Step1. Object diagram
62
Getting complex info. First method
63
Step 2. Specify the coordinating method
Map<Patient, Ward>getPatientsAndWards(Team
aTeam)
Post-condition: returns a map of pairs of
Patient Ward objects, such that for each
Patient object aPatient linked to aTeam, the
map contains the key-value pair
(aPatient,aWard), where aWard is linked to
aPatient64
Step 2. Specify the coordinating method
We don’t need step 3, since no new links needed.
65
66
Given: The Team object team2. Goal: 1. Access the collection of Patient objects linked to
team2, which in this case is {patient3, patient4, patient5}.
2. Create a new empty collection, results.3. For each Patient object, aPatient, accessed in
step 1.◦ access aWard, the Ward object linked to aPatient;◦ add(aPatient, aWard)to results.
4. Return results.
Step 4: WALK THROUGH
67
Step 4:Sequence Diagram
68
Step5 Update Structural Model Class Team LinksCollection<Patient> patients References a collection of all the linked Patient objects.
Protocol:Map<Patient,Ward> getPatientsAndWard()Post-condition: returns a map of pairs of
Patient and Ward objects, such that for each Patient object aPatient linked to the receiver, the map contains the key–value pair (aPatient, aWard), where aWard is linked to aPatient.
69
Step5 Update Structural Model class HospCoord Protocol Map<Patient, Ward>
getPatientsAndWards(Team aTeam)
Post-condition: returns a map of pairs of Patient Ward objects, such that for each Patient object aPatient linked to aTeam, the map contains the value pair (aPatientaWard), where aWard is linked to aPatien
class Patient LinksWard ward References the linked Ward
object. ProtocolWard getWard() Post-condition: returns
the linked Ward object.
70
Step5 : Update Structural Model