Contract model
This presentation is the property of its rightful owner.
Sponsored Links
1 / 32

Contract Model PowerPoint PPT Presentation


  • 75 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

Contract Model

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Contract model

Contract Model

Phase 6

Start: Saturday14 April

End: Saturday 21 April


Important dates

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

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.


Contract1

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

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

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

Utilize Conceptual Model

To make contracts you have to use the conceptual model.


Contract2

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

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

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


Use case diagram

Use case diagram

Nurse

View Schedule

<<extends>>

Open File


Expanded use case make appointment

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.


Expanded use case make appointment1

Expanded use case – Make Appointment


Expanded use case make appointment2

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.


Conceptual model

Conceptual model

  • Concepts List:

  • Patient

  • Nurse

  • Appointment

  • Doctor

  • Department


Operation contract

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.


Operation contract1

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)


Operation contract2

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.


Contract model

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


Expanded use case format borrow resources

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

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


Expanded use case format example borrow resources cont1

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.


Contract model

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


Contract model

Partial conceptual Model


Contracts for use case borrow resources

Contracts for use case Borrow Resources

  • Contracts are:

    • Records the resources for registered borrowers.

    • Return resources with loan card.

    • Cancel Borrowing.


Contact records resources

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: 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: 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 contract

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)


  • Login