1. Phase 6 Start: Saturday14 April End: Saturday 21 April
Contract Model
Phase 6
Start: Saturday14 April
End: Saturday 21 April

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

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

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

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

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

7. Utilize Conceptual Model
To make contracts you have to use the conceptual model.

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

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

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

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

12. Use case diagram
Nurse
View Schedule
<<extends>>
Open File

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

14. Expanded use case – Make Appointment
System Response
Actor Action
1. 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.

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

16. Conceptual model Concepts List: Patient Nurse Appointment Doctor
Department

18. Operation contract 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.

19. Operation contract Contract CO3: Reserve Appointment
Operation: 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)

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

21. Use Case Diagram Lib system Browse Cancel Borrowing Visitor
<<Extend>>
Visitor
Borrow copy of Resources
Return copy of Resources
<<Include>>
Manage loan
Extend loan
Borrower
Delete Resources
Reserve books
Add Resources
Register Members
Librarian
Update Catalogue

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

23. Expanded Use Case Format Example: Borrow Resources(cont.)
System Response
Actor Action
1. 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.

24. Expanded Use Case Format Example: Borrow Resources(cont.)
Alternatives: Line 2. Borrower are not register cancel borrowing operation.
Line 3. Borrower exceed the number of allowed resources choose resources consider allowed number.

25. Use Case Diagram Lib system Browse Cancel Borrowing Visitor
<<Extend>>
Visitor
Borrow copy of Resources
Return copy of Resources
<<Include>>
Manage loan
Extend loan
Borrower
Delete Resources
Reserve books
Add Resources
Register Members
Librarian
Update Catalogue

26. Partial conceptual Model

27. Contracts for use case Borrow Resources
Contracts are:
Records the resources for registered borrowers.
Return resources with loan card.
Cancel Borrowing.

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

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

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

31. Startup Contract Contract: 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)
Borrower was associated with membership . (association formed)
Borrower was associated with Search . (association formed)