Ooa 2 Post1


Published on

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

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

No notes for slide

Ooa 2 Post1

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