Dice Game Case Study 11 30 6
Upcoming SlideShare
Loading in...5
×
 

Dice Game Case Study 11 30 6

on

  • 4,229 vues

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

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

Statistics

Vues

Total Views
4,229
Views on SlideShare
4,221
Embed Views
8

Actions

Likes
0
Downloads
72
Comments
0

1 intégré 8

http://www.slideshare.net 8

Accessibilité

Détails de l'import

Uploaded via as Microsoft PowerPoint

Droits d'utilisation

© Tous droits réservés

Report content

Signalé comme inapproprié Signaler comme inapproprié
Signaler comme inapproprié

Indiquez la raison pour laquelle vous avez signalé cette présentation comme n'étant pas appropriée.

Annuler
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Votre message apparaîtra ici
    Processing...
Poster un commentaire
Modifier votre commentaire

Dice Game Case Study 11 30 6 Dice Game Case Study 11 30 6 Presentation Transcript

  • An Example of Object – Oriented Analysis and Design “A Dice Game”
        • Play Rules / Business Rules:
        • A “dice game” in which a player rolls two dice.
        • If the total is seven, they win; otherwise, they lose .
    The dice game is very simple problem, presented in order to focus on some of the steps and artifacts in object – oriented analysis and design rather than on the problem domain.
  • Most essential and commonly used steps in OOAD Define use cases Define conceptual model Define collaboration diagrams Define design class diagrams System Behavior diagram Analysis Design
  • Define use cases
    • Understanding the requirements includes, in part, understanding the
    • domain processes and the external environment – external actors who
    • participate in processes.
    • These domain processes can be expressed in use cases –
    • narrative descriptions of domain processes in a structured text format
    • For example , in the dice game, here is the Play Game High level
    • usecase
        • Use case : Play a Game
        • Actors : Player
        • Description : This use case begins when then
        • the player picks up and rolls the
        • dice. If the dice total seven, they
        • win; other wise, they lose
  • Expanded Usecase: Alternate path to 2a : the total is 7 then the player looses the game SI No Actors Action SI No System Response 1 This use case begins when the Player starts the game by picking up the dice and then player rolls the the dice 2       2a Die Game will collect face value of each dice and then adds up to give the sum of the face value( total ) for a particular roll.   If the dice total is 7 then system will indicate the player that he win’s , and request the player to continue the game.
  • Usecase Diagram
    • A decomposition of the problem domain involves an identification of
          • concepts
          • attributes
          • associations
    • in the domain that are considered important.
    • The result can be expressed in a conceptual model, which is
    • illustrated in a set of diagrams that depict concepts (objects).
    Define conceptual model
  • Conceptual model of the Dice game The conceptual model is not a description of software components; it represents concepts in the real – world problem domain .
  • Defining Collaboration Diagrams
    • Collaboration diagrams show the flow of messages between instances and the invocation of methods
    • Object - oriented design is concerned with defining logical software specifications that fulfill the functional requirements based on decomposition by classes of objects.
    • An essential step in this phase is the allocation of responsibilities to objects and illustration how they interact via messages, expressed in collaboration diagrams .
  • Defining Collaboration Diagrams Illustrating messages between software objects For example, assume that a simulation in software of the dice game is desired. This collaboration diagram in Figure illustrates the essential step of playing by sending messages to instances of the Player and die classes.
  • Defining Design Class Diagrams
    • “ These illustrate class definitions that are to be implemented
    • in software”
    • In order to define a class, several questions must be answered
      • How do objects connect to other objects?
      • What are the methods of a class?
    • To answer these questions, inspect the collaboration diagrams, which suggests the necessary connections between objects, and the methods that each software class must define
  • Design class diagram of software components . For example, in the dice game, an inspection of the collaboration diagram leads to the following design class diagram. In contrast to the conceptual model, this diagram does not illustrate real – world concepts; it describes software components
  • Design class diagram of software components........
    • Since a play message is sent to a Player instance, Player requires a play method, while Die requires a roll method.
    • To illustrate how objects connect to each other via attributes, a line with an arrow at the end may suggest an attribute.
    • For example, Dice Game has an attribute that points to an instance of a Player.(visibility issues)