Understanding Object Oriented Analysis and Design

Object Oriented Analysis and Design is a five step process explained as below.

  • Gather requirements – We do not expect exhaustive list of requirements but we need basic requirements.
    • Functional Requirements: Features and capabilities of application
      • E.g. System should be able to calculate income tax for the year if provided bank statement and form 16
    • Non- Functional Requirements: Support, Security, Performance, Help, Legal
      • E.g. System should give income tax figure in not more than 5 seconds
    • A formal process is FURPS/FURPS+ to define requirements in large enterprises
      • These include functional, usability, reliability, performance and support requirements
      • In FURPS+ we also add design, implementation, physical and interface requirements
  • Describe what application need to do using use cases or user stories
    • You can do a mock demo at this stage
    • What is Use Case : One of the user of application described with User as focus. These should be casual use cases done within few days. In UML use case is shown as ellipse. Use case diagram shows which actor can do which use case
      • Title : What is goal :
        • It should phrase with active verb
        • E.g. Transfer funds, Register User
      • Actor : Who desires it
        • It can be user, administrator or another computer
        • Anyone who acts is actor
      • Steps / Scenario : How to get it done
        • E.g. Customer will select product
        • Customer will add it to cart
        • Customer will checkout etc.
    • What is user story : Its a placeholder for requirement. It does not have any details. One to two sentences in following format
      • As a (Type of User e.g Internet User)
      • I want (goal to be done e.g. I want to search web)
      • so that (reason e.g. I can find different documents online)
  • Identify the main objects of the application and discard everything else. For example modelling the application. You can follow these steps to find obejcts
    • Underline all Nouns from user stories or use cases e.g. User, Product etc. You can put them in diagram.
    • Then connect all boxes which communicate with each other as per use cases
    • Then write down relation e.g contains, paid by, users
object-model

object-model

  • Find out all interactions in between objects, it will also help to locate responsibility of the objects
    • One of the way to describe it is using sequence diagram
    • You can do it by writing down all verbs in the use cases
    • Once you write down and clean up you can place these responsibility in respective objects, these are nothing but behavior

      object-responsibility-modelling

      object-responsibility-modelling

  • Draw a class diagram that is pictorial representation of classes of the application mostly in Unified Modelling Language (UML)
    • Diagrams is worth thousand words hence its easy to represent app via class diagrams
    • UML diagram for class is giving class name , attributes with types and behaviors. After colon you can give type of attribute or return type of behavior. For attribute you can specify if attribute is private by – sign or public by +.
class-diagram-uml

class-diagram-uml

In agile or iterative development all these steps are repeated when necessary i.e. when requirement change.

Leave a Reply

Your email address will not be published. Required fields are marked *