Contract ModelPhase 6Start: Saturday14 April End: Saturday 21 April

Important dates

1- phase 6: Contract Model (Start: Saturday14 April End at Saturday 21 April ).

2- phase 7:Collaboration Model + presentation about what you done tell now (Start at Saturday 28 April "receive phase 6 feedback" End at Saturday 5 May).

3-Last phase 8: work on class model without waiting for collaboration feedback (Start at Saturday 5 May then will you receive feedback of collaboration model at Monday 7 May correct the collaboration model and keep working on class model with out consider collaboration feedback (no time to do that) then submit class diagram with whole SRS document after you correct collaboration model at 12 May).

Contract • Contracts are documents that describe system behavior.

• Contracts may be defined for system operations.

• Operations that the system (as a black box) offers in its public interface to handle incoming system events.

• The entire set of system operations across all use cases, defines the public system interface.

Contract • A contract is a document that describes what an operation

commits to achieve.

• Emphasizing what will happen rather than how it will be achieved.

• Contracts can be expressed by pre- and post- conditions.

Use Case Realizations

• A use case realization describes how a use case is realized in terms of collaborating objects.

• UML interaction diagrams are used to illustrate use case realizations.

• Recall Process Sale: from main scenario we identified a number of system events (operations).

• Each system event was then described by a contract.

Conceptual Model and Contracts

• A Conceptual Model is a visual representation of conceptual classes or real-world objects in a domain of interest.

• Contracts describe detailed system behavior in term of state changes to objects in the Domain Model, after a system operation has executed.

Utilize Conceptual Model

• To make contracts you have to use the conceptual model.

Contract • Contract CO#: Operation name.• Operation: operation name (type of parameters: name of

parameters).• Cross References: Use Cases: name of use case• Pre-conditions: are assumptions about the state of the system

before execution of the operation. • Post-conditions: A Postcondition is an assumption that refers

to the state of the system after completion of the operation.• The postconditions are not actions to be performed during the

operation.• Describe changes in the state of the objects in the Domain

Model (instances created, associations are being formed or broken, and attributes are changed).

How to write a contract

• Identify system operations of system (use case).

• For each system operation, construct a contract.

• Write the preconditions section.

• Write the postconditions section describing the state changes that occur to concepts in the conceptual model. Postconditon categories:• Instance creation and deletion.• Attribute modification.• Associations formed and broken.

Writing Contracts leads to Domain Model Updates• It is also common to discover the need to record new

concepts, attributes or associations in the Domain Model.• For example:• If in one of the postconditions, you wanted to create an instance

to store some values in it, and it was not presented by any Concept in the domain model.

• Then you should go back and correct your domain model by adding this concept.

The most common mistake in creating contract• The most common problem in creating contracts is forgetting

to include the forming of associations. Particularly, when new instances are created, it is very likely that associations to several objects need be established.

• Don’t forget to include all the associations formed and broken

Open File

Nurse

View Schedul

e

<<extends>>

Use case diagram

Use Case: Make appointment.

Actor: Patient (initiator), Nurse.

Purpose: To record a new appointment.

Overview (Success Scenario):This use case begins when the customer ask a nurse to reserve an appointments with a certain doctor. On completion, an appointment slip is printed.

Type: Primary, Essential.

Expanded use case – Make Appointment

System Response Actor Action1. This use case begins when the patient

come to the nurse or call her to ask for an appointment.

3. Show patient information. 2. The nurse request the patient id from the patient and enter it. (to get patient information)

5. System returns all possible appointment dates and times for the specified doctor.

4. Nurse ask the patient for doctor name and department and enter them. (to find appointment)

7. Reserves the appointment. 6. Nurse tell the patient about all the possibilities and get from him/her the most desired one, and reserve it.

9. Generate appointment slip. 8. The nurse request the appointment slip.

10. The nurse gives the printed appointment slip to the patient.

11. The patient leaves with appointment slip.

Expanded use case – Make Appointment

Alternatives: Line 2. If patient was a new one, then a new file should be created; see open file use case.Line 2. If patient forgot ID, provide Phone number.Line 3. If the ID was wrong, the system will display a message to indicate that.

Expanded use case – Make Appointment

Concepts List:

Patient Nurse Appointment Doctor Department

Conceptual model

Contract CO1: Request Patient Information Operation: ReqPatientInfo (PID: String)Cross References: Use case: Make Appointment.Pre-conditions: None.Post-conditions: None. Contract CO2: Find Appointment Operation: FindAppointment (Dname: String, Dept: String)Cross References: Use case: Make Appointment.Pre-conditions: None.Post-conditions: None.

Operation contract

Contract CO3: Reserve AppointmentOperation: ReserveAppointment ( Date: Date, Time: Time, PID: String, Dname: String )Cross-Ref: Use case: Make Appointment.Pre-conditions: None.Post-conditions: An Appointment instance A was created. (instance creation)A.Date was set to Date and A.Time was set to Time. (attribute modification)A was associated with the current Nurse. (association formed)A was associated with the Patient, based on PID match. (association formed) A was associated with the Doctor, based on Dname match. (association formed)

Operation contract

Contract CO4: Print Appointment SlipOperation: PrintAppointmentSlip ()Cross-Ref: Use case: Make Appointment.Pre-conditions: All appointment information have been entered.Post-conditions: None.

Operation contract

Borrower

Borrow copy of Resources

Return copy of Resources

Extend loan

Reserve books

Visitor

Librarian

Browse

Add Resources

Use Case Diagram

Lib system

Manage loan

Register Members

Delete Resources

Update Catalogue

<<Include>>

Cancel Borrowing

<<Extend>>

Expanded Use Case Format: Borrow Resources• Use Case: Borrow Resources.

• Actor: Borrower (initiator), library clerk.

• Purpose: Capture borrowing information.

• Overview (Success Scenario): A Borrower arrives at a checkout with Resources(books and journals) to Borrow. The library clerk records the Borrowed resources and calculate loans. On completion, the Borrower leaves the library with the resources..

• Type: Primary, Essential .

• Cross References: none.

Expanded Use Case Format Example: Borrow Resources(cont.)

23

System Response Actor Action1. This use case begin when Borrower

arrives at the checkpoint after browsing a list of resources to borrow.

3. The system will check member ship and calculate the number of resources, check resources overdue then issues loans card for it.

2. The Library Clerk records the resources for registered borrowers.

5. Logs the completed borrowing. 4. The clerk will give borrower resources with loan card.

5.The Borrower will leave with resources and load card.

Expanded Use Case Format Example: Borrow Resources(cont.)

24

• Alternatives: Line 2. Borrower are not register cancel borrowing operation.

• Line 3. Borrower exceed the number of allowed resources choose resources consider allowed number.

Borrower

Borrow copy of Resources

Return copy of Resources

Extend loan

Reserve books

Visitor

Librarian

Browse

Add Resources

Use Case Diagram

Lib system

Manage loan

Register Members

Delete Resources

Update Catalogue

<<Include>>

Cancel Borrowing

<<Extend>>

Partial conceptual Model

Contracts for use case Borrow Resources

• Contracts are:

1. Records the resources for registered borrowers.

2. Return resources with loan card. 3. Cancel Borrowing.

Contact Records Resources

Contract Co1:Records resources for registered borrower.

Operation: Records Resources (String:ID, Resoucses:Resources, int:quantity).Cross References: Use Cases: Borrow Copy of Resources.Pre-conditions: the Borrower is member of library.

Post-conditions: • A Borrowing instance borrowing was created (instance creation).

• A loan instance lo was created (instance creation).

• A payment instance pa was created (instance creation).

• borrowing.BorrowerID is set to the member ID (attribute modification).

• Borrowing was associated with CheckPoint. (association formed).

• Borrowing was associated with Library. (association formed).

• Borrowing was associated with current Borrower based on match ID (association formed).

• Borrowing was associated with current loan based on match B_serial (association formed).

• Lo was associated with current payment based on match L_serial (association formed).

• lo.resource_ISBN was set to resources ISBN (attribute modification).

• lo.number_resources was set to number of resources (attribute modification).

• lo.borrowingdate was set to today date (attribute modification).

Contract: Return resources with loan card

Contract Co2:Return resources with loan card.

Operation: Return Resource with loan card ( ).Cross References: Use Cases: Borrow Copy of

Resources.Pre-conditions: the Borrower is member of

library.Post-conditions: • Lo.cuontdays was set (attribute modification).

• Pa.amount was set (attribute modification)”to record taxes”.

Contract: Cancel Borrowing • Contract Co3:Cancel Borrowing.• Operation: Cancel Borrowing( ).• Cross References: Use Cases: Borrow Copy of Resources.• Pre-conditions:• Post-conditions: • Borrowing instance Bo was deleted. (instance deleted).

Startup ContractContract: StartUp

Operation: StartUp ()Cross References: Use Cases: Register Member .Pre-conditions: None.Post-conditions: A Library,search, CheckPoint, ResourceCatalogue, ResourcesSpecifications, Clerk and

Borrower,Membership have been created. (instance creation) ResourceCatalog was associated with ResourceSpecifications. (association formed) Library was associated with ResourceCatalog. (association formed) Library was associated with CheckPoint (association formed) CheckPoint was associated with Clerk. (association formed) CheckPoint was associated with Clerk. (association formed) Borrower was associated with membership . (association formed) Borrower was associated with Search . (association formed) Borrower was associated with membership . (association formed)