Your SlideShare is downloading. ×
Ooa 2 Post1
Ooa 2 Post1
Ooa 2 Post1
Ooa 2 Post1
Ooa 2 Post1
Ooa 2 Post1
Ooa 2 Post1
Ooa 2 Post1
Ooa 2 Post1
Ooa 2 Post1
Ooa 2 Post1
Ooa 2 Post1
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Ooa 2 Post1


Published on

Object-oriented analysis and design(OOAD) UML Slides. for more slides refer

Object-oriented analysis and design(OOAD) UML Slides. for more slides refer

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


    • Identify system events and system operations
    • Create system sequence diagrams for use cases
    • Create system class
    • Write contract to each system operations
  • 2. System Behavior:
    • Before proceeding to a logical design of how a software application will work, it is necessary to investigate and define its behavior as a “black box.”
    • System behavior is a description of “what a system does”, without explaining how it does .
    System as Black Box
  • 3. System sequence diagram for POST System
  • 4. Recording System Operations:
    • The set of all required system operations is determined by identifying the system events with parameters.
    • Where should these operations be recorded?
    • The UML includes notation to
    • record operations of a type, as
    • shown in Figure
    TypeX Operation1() operation2() Operations of the type POST enterItem(upc,quantity) endSale() makePayment(amount) Operations of the type
  • 5. Operation Contracts Post condition Pre- condition Responsibility Notes Exceptions Out Put
    • It is missing details necessary to understand the system response [i.e. system behavior]
    • In general, a contract is a document that describes what an operation commits to achieve.
    • It is usually “ declarative in style” , emphasizing “what will happen ”, rather than how it will be achieved.
  • 7. Responsibility Section
    • Under this section , an informal description of the responsibilities this operation must fulfill, should be written.
      • ( Responsibility of Operation is ” Functionality of an Operation in a specific context ”)
    Notes Section
    • The Notes section of the contract is a place where design statements may be made regarding the operation.
    • For example:
        • documenting a particular algorithm is preferred to handle this operation
        • Pseudocode for this algorithm
  • 8. Pre-conditions
    • The pre-conditions define assumptions about the state of the system at the beginning of the operation.
    • The most important part of the contract.
    • The post-conditions are “ not” actions to be performed during the operation, rather they are declarations about the system state that are true when the operation has finished
    • The intension of the contract is to emphasize a declaration of state changes , but not telling how a solution to be achieved.
    • Use these categories of state changes in the post-conditions:
        • Instance creation and deletion.
        • Attribute modification.
        • Associations formed and broken.
  • 9. How to Make A Contract
    • Apply the following advice to create contracts.
    • To make contracts for each use case:
        • Identify the system operations from the system sequence diagrams.
        • For each system operation, construct an contract.
        • Start by writing the Responsibilities section, informally describing the purpose of the operation.
        • Then complete the Post-conditions section, declaratively describing the state-changes that occur to objects in the conceptual model.
        • To describe the post-conditions, use the following categories:
            • Instance creation and deletion.
            • Attribute modification.
            • Associations formed and broken.
        • The effect of the system operations is described in contracts.
  • 10. Contracts and other Artifacts – Ex : POST use case: Buy Item Actors Action
  • 11. Advice on Writing Contracts
    • After filling in the operation name, fill in the Responsibilities section first, pre-conditions section next, post-conditions last.
    • These are the most important sections likely to be used later in the project.
    • Use the Notes section to discuss any design details, such as algorithm or the high-level sequential steps.
    • Use the Exceptions section to discuss the reaction to exceptional situations.
  • 12. The Most Common Mistake in Creating Contracts
    • Don’t forget!
    • The most common problem is forgetting to include the forming of associations.
    • Particularly when new instances were created, it is very likely that associations to several objects needs to have been established.