The document discusses software development with Java. It covers various topics like core system design, communication between the user interface and core system, use cases that involve changing the state of the core system, and implementation models. The document uses examples from a hospital management system to illustrate concepts like dividing responsibility between the user interface and core system, specifying coordinating methods, and updating class diagrams based on use case designs. Overall, the document provides an overview of object-oriented analysis and design approaches for a software system using Java.

1. Software development with Java
Prepared By: Ms Samar Shilbayeh ,sshilbayeh@arabou.edu.sa
Modified By: Mrs. Nibal Abu Samaa, nebal_samaan@yahoo.com

2. Core system design

3. 3

4. 



Communication between user interface and
the core system
Getting information
Anthropomorphism
Changing state
4

6. 6

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

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 objectoriented software development.
8

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

11. Core Object
The 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..

11

12.  The user interface tells the core
system to begins its work.
 The core system returns results
to the user interface.
12

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

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

15. In a Hospital Management System..
userInterface
recordTreatment ( patient5,.....)
Fig: The user interface sends a record Treatment message with a Patient
Object, patient 5 as an argument.
15

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

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

18. 18

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

20. 20

21. 21

22. userInterface
hospital
getPatients(Ward 3)
{patient2,patient4,patient6}
fig:Returning objects to the user interface
22

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

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

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

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

27. 
1.
2.
How the use case will be initiated?
The user will send a message to the user
interface with the behavior that the system
should do.
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 system
Result(The Goal) : the information result as
the out put of the system :
1- getting information
2-or changing the state without any output
27

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

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

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

30

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

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

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

35. Consider the example: List Ward’s Patients
 The relevant part of the class diagram
35

36. 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
hasWards
Ward
hasOn
Patient
navigation from ward to
Patient
36

37. Step 1. Draw object diagram
Step 2. Specify the coordinating method
Step 3. Implementing links
Step 4. The walk through and a
sequence diagram
Step 5. Updating structural model
37

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

39. 39

40. 
Coordinating method specification consists of the
following:
1- Collection<Patient> getPatients (Ward aWard)
Return
type
argument
name
method
name
argument
type
2- Post-condition of the method : returns a collection
of all the Patient objects linked to aWard.
40

41. 

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.
Ward
1
hasOn
0..*
Patient
41

42. 

The previous
figure shows
the direction
from ward to
patient, and
note 0..*
For the other
direction, each
patient is in
one ward.
Ward
1
hasOn
0..*
Patient
42

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

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

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

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

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

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

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

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
50

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

52. 52

53. Here are excerpts class definitions which correspond to
this design.
//Definition of coordinating class.
Public class HospCoord
{
//code omitted
public Collection<Patient>getPatients(Ward aWard)
{
return aWard.getPatients(); //send getPatients()to the argument
}
//code omitted
}
//Definition of ward
Public class Ward
{
//code omitted
private Collection<Patient>patients;//all the linked patient object.
Collection<patient>getPatients()
{
return patients();
}
//code omitted
}

54. Starting from use case  object diagram,
1.
◦
◦
◦
2.
3.
4.
5.
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.
Generalizing  coordinating method specification
Adding links
Develop the walk through and the sequence
diagram.
Updating the structural model (class description
and navigation arrows) .
The walk through and sequence diagram
constitute the dynamic model
See SAQ 6 page 29
54

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

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

58. 58

59. 


hasTeams is
navigated from
HospCoord to
Team
caresFor is
navigated from
Team to
Patient
hasOn is
navigated from
Patient to ward
HospCoord
hasTeams
Team
ward
hasOn
caresFor
Patient
The navigation that results
from this use case
59

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

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
61

62. 

Example: List Team’s Pateints
Step1. Object diagram
62

63. 63

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

65.  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.

◦
◦
4.
access aWard, the Ward object linked to aPatient;
add(aPatient, aWard)to results.
Return results.
66

67. 67

68. Class Team
 Links
Collection<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.
68

69. class HospCoord
 Protocol
Map<Patient, Ward>
getPatientsAndWards(T
eam 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
 Links
Ward ward
References the linked Ward
object.
 Protocol
Ward getWard()
Post-condition: returns the
linked Ward object.

69

70. 70