Contract Model

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

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. • Pre-conditions: None. • Post-conditions: None.

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 Register Members Manage loan Cancel Borrowing Delete Resources Update Catalogue Browse Extend loan Return copy of Resources Borrow copy of Resources Add Resources Reserve books Lib system <<Extend>> Visitor <<Include>> Borrower Librarian

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

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 Register Members Manage loan Cancel Borrowing Delete Resources Update Catalogue Browse Extend loan Return copy of Resources Borrow copy of Resources Add Resources Reserve books Lib system <<Extend>> Visitor <<Include>> Borrower Librarian

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) • 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)