Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

Analysis

VIEWS: 5 PAGES: 14

									          Analysis

    Analysis discovers and
concretizes the desired behavior
         of the system.
• Input:
  – List of requirements
  – Structured use-cases
  – Actor details
• Context:
  – Identify and develop w.r.t. vocabulary of the
    domain
  – Useful and critiqued by the domain experts
  – Model that map with domain artifacts
              Deliverables
• Analysis classes and relationships
• Use-cases realization – through the above
  classes
• Analyze
  – Architecture
  – Use-cases
  – Class
  – Package
• About 50 – 100 classes
• Application domain classes
• Do not make implementation decisions
• Minimize coupling – focus on association
  of classes
• Use inheritance only when there is a
  natural hierarchy
• Classes, relationship, and diagrams clarify
  the purpose/behavior of the system
• Keep it simple
                Objective
• Analysis Classes – model concepts of the
  domain
• Use-case realization – how the analysis
  classes interact to realize system behavior
  described using use-cases
       Objects and Classes
• Object Based System
• Object Oriented System
        Objects and Classes
• Basic OO blocks
• Basic construction and destruction
  mechanism
• Basics of behavior and state
• Object – a cohesive set of properties
  (data) and operations (methods)
• Data hides behind the methods
• Unique identifier
• Data correspond to attributes – color,
  blinkOnOff, etc.
• Methods implement operations –
  setblinkOn(), setcolor(), clearbackground()
• These functions are called Operations in
  Analysis; and methods in Design
• State of an object can affect its behavior
• The converse is also true – invoking an
  operation can change the state of an
  object
• UML Object notation has Name, and attribute
  compartments
• Object name is of the form
  Objectname:Classname
• The underlining is important!!!
• You can have just an object name, without a
  class name  object whose class is yet
  unknown
• You can have just the class name without an
  object name  an anonymous object
• Attributes are of the form
  Attributename:typename=value
• Classes – templates for objects.
• Every object is an instance of exactly one
  class.
• Classification is an important OO concept
• This allows discussion of behavior without
  an object in hand
• Classification schemes are not unique –
  depends on the perspective.
• Various types of class relationships exist
•   Inheritance – a form of is-a relation
•   Composition – a tight collection
•   Aggregation – a loose collection
•   UML class notation has three
    compartments
•   Name compartment – e.g. Account
•   Class name is not underlined
•   Attribute compartment
•   Attributes are of the form
    – Visibility name multiplicity : type = initialvalue
• Visibility pertains to public, private,
  protected, or package
• Denoted by +, -, #, and ~ respectively
• Name is mandatory
• Multiplicity is indicated if an array is
  prescribed
• Type is mandatory
• Initialvalue is optional
• All of these can have tags: of the form
  – Ex: { addedby:iyengar, addedon:9/30/03}
• Operations have similar visibility
• UML stipulates that the return type is part
  of the signature
• Attributes or operations have class or
  instance scope
• If they are described underlined then they
  are class scope
• Else – by default instance scope
• UML constructors are of the form +create()
• Destructors are of the form +finish()
       Abstract Classes and
            Interfaces
• Interfaces are described just as classes
  with <<interface>> above the name
• Abstract Classes are described just as
  classes with the Abstract above the name
• Classes implementing an Interface have a
  relationship similar to inheritance, and
  hence depicted using a notation similar to
  generalization - but the line is broken.

								
To top