70
M256 Software development with Java Prepared By: Ms Samar Shilbayeh ,[email protected] Modified By: Mrs. Nibal Abu Samaa, [email protected]

L6 m256 block2_unit6

Embed Size (px)

DESCRIPTION

 

Citation preview

Page 1: L6 m256 block2_unit6

M256Software development with Java

Prepared By: Ms Samar Shilbayeh ,[email protected] By: Mrs. Nibal Abu Samaa, [email protected]

Page 2: L6 m256 block2_unit6

Block 2Unit6

Core system design

Page 3: L6 m256 block2_unit6

3

Page 4: L6 m256 block2_unit6

Communication between user interface and the core system

Getting information Anthropomorphism Changing state

4

Outline

Page 5: L6 m256 block2_unit6

Section 1

Introduction

Page 6: L6 m256 block2_unit6

6

SoftWare development in M256

Page 7: L6 m256 block2_unit6

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

Page 8: L6 m256 block2_unit6

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

Page 9: L6 m256 block2_unit6

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

Page 10: L6 m256 block2_unit6

Section 2

Communication between user interface and core system

Page 11: L6 m256 block2_unit6

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

Page 12: L6 m256 block2_unit6

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.

Page 13: L6 m256 block2_unit6

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:

Page 14: L6 m256 block2_unit6

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

Page 15: L6 m256 block2_unit6

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

Page 16: L6 m256 block2_unit6

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

Page 17: L6 m256 block2_unit6

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

Page 18: L6 m256 block2_unit6
Page 19: L6 m256 block2_unit6

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

Page 20: L6 m256 block2_unit6

20

initial structural model, the class diagram of the Hospital System

Page 21: L6 m256 block2_unit6

21

The coordinating class

Page 22: L6 m256 block2_unit6

getPatients(Ward 3)

{patient2,patient4,patient6}

fig:Returning objects to the user interface

22

Returning Result

userInterface hospital

Page 23: L6 m256 block2_unit6

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

Page 24: L6 m256 block2_unit6

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

Page 25: L6 m256 block2_unit6

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

Page 26: L6 m256 block2_unit6

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

Page 27: L6 m256 block2_unit6

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

Page 28: L6 m256 block2_unit6

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

Page 29: L6 m256 block2_unit6

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)

Page 30: L6 m256 block2_unit6

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)

Page 31: L6 m256 block2_unit6

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)

Page 32: L6 m256 block2_unit6

Section 3

Getting Information

Page 33: L6 m256 block2_unit6

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:

Page 34: L6 m256 block2_unit6

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:

Page 35: L6 m256 block2_unit6

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

35

Page 36: L6 m256 block2_unit6

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

Page 37: L6 m256 block2_unit6

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.

Page 38: L6 m256 block2_unit6

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

Page 39: L6 m256 block2_unit6

39

Step 2. Specify the coordinating method

Page 40: L6 m256 block2_unit6

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

Page 41: L6 m256 block2_unit6

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

Page 42: L6 m256 block2_unit6

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

Page 43: L6 m256 block2_unit6

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

Page 44: L6 m256 block2_unit6

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

Page 45: L6 m256 block2_unit6

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.

Page 46: L6 m256 block2_unit6

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

Page 47: L6 m256 block2_unit6

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

Page 48: L6 m256 block2_unit6

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.

Page 49: L6 m256 block2_unit6

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

Page 50: L6 m256 block2_unit6

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:

Page 51: L6 m256 block2_unit6

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

Page 52: L6 m256 block2_unit6

52

Updating the structural model

Page 53: L6 m256 block2_unit6

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

Page 54: L6 m256 block2_unit6

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

Page 55: L6 m256 block2_unit6

Getting complex information -example

Page 56: L6 m256 block2_unit6

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

Page 57: L6 m256 block2_unit6

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

Page 58: L6 m256 block2_unit6

58

The part of the class diagram

Page 59: L6 m256 block2_unit6

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

Page 60: L6 m256 block2_unit6

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)

Page 61: L6 m256 block2_unit6

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

Page 62: L6 m256 block2_unit6

Example: List Team’s Pateints Step1. Object diagram

62

Getting complex info. First method

Page 63: L6 m256 block2_unit6

63

Step 2. Specify the coordinating method

Page 64: L6 m256 block2_unit6

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

Page 65: L6 m256 block2_unit6

We don’t need step 3, since no new links needed.

65

Page 66: L6 m256 block2_unit6

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

Page 67: L6 m256 block2_unit6

67

Step 4:Sequence Diagram

Page 68: L6 m256 block2_unit6

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.

Page 69: L6 m256 block2_unit6

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.

Page 70: L6 m256 block2_unit6

70

Step5 : Update Structural Model