Your Federal Quarterly Tax Payments are due April 15th Get Help Now >>

Unified Method Class Diagrams by yurtgc548

VIEWS: 3 PAGES: 52

									UML
Overview




    UML Overview   1
    UNIFIED Modeling Language
OMG adopted UML in November 1997 as the standard
for object-oriented modeling

Combines commonly accepted concepts from many OO


methods

   Seamless from requirements to deployment

   Applicable to any domain

Language and platform independent





   Usable with any development process
                               UML Overview         2
    Unified MODELING Language
All engineering disciplines have adopted modeling
techniques


Allows to capture the important aspects of a system


while omiting the rest


Model is easier to use than final system





Help all software systems stakeholders understand
what the system will be and what are the possible
options available

                            UML Overview              3
Unified Modeling LANGUAGE
Language for:
  Visualizing: Graphical models with precise
  semantics

  Specifying: Models are precise, unambigous and
  complete to capture all important Analysis, Design,
  and Implementation decisions.

  Constructing: Models can be directly connected to
  programming languages, allowing forward and
  reverse engineering

  Documenting: Diagrams capture all pieces of
  information collected by development team,
  allowing to share and communicate the embedded
                            UML Overview                4
 UML Bird’s Eye View

• Building Blocks:
     Things: abstractions, main concepts in a model
     Relationships: tie the things together
     Diagrams: group interesting collections of things




                               UML Overview               5
                  UML in a Nutshell
   Static Structure


Dynamic Behavior





Model Management





Extensibility Constructs





                           UML Overview   6
Diagrams in the UML
 •   Class diagram
 •   Object diagram
 •   Use case diagram
 •   Sequence diagram
 •   Collaboration diagram
 •   Statechart diagram
 •   Activity diagram
 •   Component diagram
 •   Deployment diagram
                         UML Overview   7
Things in the UML
• Structural Things (7)
    static part of a model, conceptual or physical
   elements
   nouns of UML Models
• Behavioral Things (2)
      dynamic parts of models
   verb, representing behavior over time and space
• Grouping Things (1)
    Organizational parts of models, decomposition
   element
• Annotational Things (1)
    explanatory parts of models, comments about other
   elements
                                 UML Overview            8
    Behavioral Modeling
    Use Cases / Use Cases Diagrams
    Interactions / Interaction Diagrams
    Activity Diagrams




                               UML Overview   9
            Use Cases
   Description of a set of sequences of actions, that a
    system performs to yield an observable result to an
    end-user
   Categories of interactions between the system to be
    built and external actors
   Identify high-level services provided by the system
   Specify the behavior of a system
   Popularized by Ivar Jacobson with Objectory
   Have been adopted by or have influenced many
    methods (eg. OMT, Fusion, Booch)


                               UML Overview                10
               Use Cases (cont.)
   Can be applied to whole system as well as part of
    system such as a subsystem or a class
   Sources of integration tests and system tests
   May have variants: specialized use cases or extension
    of use cases.
   Do not specify any implementation detail
   Main communication tool with end-user
   Each use case must have a name (simple or path name)




                               UML Overview                 11
    Actors
   Objects outside the system which play a particular role
   Represent the user(s) of the system
   Interact with the system through use cases
   May participate in more than one use case
   May or may not be represented as a class or object in
    the object model
   Also known as agents (Jacobson)




                                UML Overview                  12
               UML Use Case
           Graphical Representation
           Storage depot system



              Delivery

                           Collection

Clerk            Status                             Storage




                                         Use case


                          Actor
 Manager

                                  UML Overview                13
    Why Modeling Use Cases
    Use Case model describes WHAT the system will do at
    a high-level
    User focus
      - Capture requirements from user's perspective.
      - Users are involved.

    Goal is to scope the project and give the
    application some structure
     -Use Cases are the unit of estimation
     -Uses Cases are smallest unit of delivery
     -One way of estimating the percentage of
     requirements captured.
     -Prioritizing use cases for "phased delivery" according
     to user's immediate needs.
                                UML percentage of
     -Better way of estimating theOverview                 14
    Benefits of use cases
    Good way to start identifying objects from
    scenarios.
    Test plan can be immediately generated based on
    use cases.
    Easier user validation.
    Helps technical writers in structuring the overall
    work on the users manuals at an early stage.
    Better traceability throughout the system
    development process.
    Quality of the software is improved by identifying
    the exception scenarios earlier in the development
    process.


                               UML Overview               15
    Problems with use cases

    What is the right granularity
    What is a correct Use Case
    Explosion of different scenarios
    Focus on functions, with potential for functional
    decomposition
    Too often too informal




                                UML Overview             16
    Use Cases and Scenarios
    Scenario is a specific sequence of actions
    Scenario is one instance of a Use Case
    Typically many scenarios correspond to one Use
     Case
    Example:
     Use Case = Hire Employee
     Scenarios
      - Hire at Job Fair
      - Hire through newspaper ad
      - Hire from internal promotion
      - Hire Temp


                              UML Overview            17
    Use Cases and Collaborations
     Use Case captures WHAT the system does
     Use Cases do not specifies HOW the System does it
     Development effort is aimed at implementing the
     use cases by creating a society of classes working
     together
     These interacting classes are modeled using
     Collaborations
     A Collaboration is the realization of a Use Case
     A Collaboration represents how responsibilities are
     distributed across objects
     A Collaboration has a Static and a Dynamic aspect


                               UML Overview                 18
 Organizing Use Cases
Relationships: Generalization, Include (Use) and Extend
Generalization:
   –   Like for Classes
Include:
     - Use: Contains another complete use-case

Extend:
       - Extends another use-case
       - used for optional separate flow (exception)

Beware:
       - Over-use of extends = functional decomposition
       - Rumbaugh says Use = aggregation and Extend =
         inheritance
                                UML Overview              19
    Hints and Tips
•     Each Use Case should represent a single, identifiable
     and reasonably atomic part of the behavior of the
     system
•     Factors Common Behavior by pulling such behavior
     from other use cases that it includes
•     Factors variants by pushing such behavior into other
     use cases that extend it
•     Describe flow of vents clearly enough for anyone to
     easily understand it
•     Each Use Case is described by a number of scenarios
     that specify the normal and variants



                                UML Overview                  20
Use Case Diagrams
   system is represented by a large rectangle
   uses cases are represented as ellipses within the
    system rectangle
   actors are represented as stick figure outside the
    system
   an arrow connects the initiating actor to the use
    case (ending at the use case)
   other participating actors are joined by arrows
    terminating at the actor




                              UML Overview               21
Banking System Use Case Diagram

             open_account                   Cash
                                            Dispenser

             withdraw_cash
  Customer

              clear_checks              Clerk


             loan_application


  Manager      get_report               Loan Officer




                         UML Overview                   22
Use Case Identification Steps
•Determine the boundary of the system
-consider system as a single “black box” object
•Identify who is going to be using the system directly -
 e.g. hitting keys on the keyboard. These are the Actors
-start by considering physical object
-an individual object may play several roles
•Choose One of these Actors and determine the
 fundamental ways in which each actor uses the system
-each of these is a use case
-must be enumerable
-for each of those Use Cases decide on the most usual course
 when that Actor is using the system. What normally happens.
 This is the basic course

                               UML Overview                    23
    Use Case Identification Steps (2)
•    Describe it as "Actor does something, system does
    something. Actor does something, system does
    something." but keep it at a high level.
        do not mention any GUI specifics
     only describe things that the system does that the actor
     would be aware of and conversely you only describe
     what the actor does that the system would be aware of.
     do not worry about the alternate paths (extends) or
     common courses (uses) - Yet -
•  Review each Use Case descriptions against the
  descriptions of the other Use Cases.
• Once basic course is OK, consider the alternates
  and add those as extending use cases.

                                    UML Overview                 24
 Use Case Identification Steps (3)
• Good way of getting started with Use Case
  modelling.
• Once started and comfortable with this process,
  next step:
   understand the trade-offs that can be made
   simplicity versus "completeness"
   putting too much in is the most common mistake.




                            UML Overview              25
Use Case Textual Descriptions
OPEN_ACCOUN       - a clerk requests the system to create a
 T                  new account
WITHDRAW_CAS      - a customer requests the system to withdraw
 H                  a specified amount of money from a
                    specified account

CLEAR_CHECKS      - a clerk instructs the system to update all
                    accounts according to specified transactions
                    including checks

LOAN_APPLICATIO - a customer files a loan application
 N


GET_REPORT        - a manager or loan officer requests a report
                    of the days transactions from the system


                                UML Overview                       26
    Use Cases Diagram Hint and Tips
•     Put all the Use Cases that describe one aspect of
     the system together
•     Contains only those use cases and actors essential
     to understanding that aspect
•     Diagram should be named to communicate its
     purpose
•     Minimize crossing lines
•     Don’t draw too many use cases or too many
     relationships in one diagram




                               UML Overview                27
          UML
Basic Structural Modeling




             UML Overview   28
 Basic Structural Modeling
• Classes
     Attributes, Operations, Responsibilities

• Relationships
  Dependency, Generalization, Association, Role,
  Multiplicity, Aggregation

• Common Mechanisms
  Specifications, Adornments, Common Divisions,
  Extensibility Mechanisms

• Diagrams
     Class , Object , Component , Deployment Dagrams
                               UML Overview             29
Classes
Most important building block of any object-oriented
system
   Description of a set of Objects
   Implements one or more interfaces
Abstraction of the entities existing in the problem
domain


        Planet         Astronaut                  Shuttle::Astronaut

             simple names                           path names




                                   UML Overview                        30
Attributes
   named properties of classes that describe a range
    of values
   represent some property of the thing being modeled
   each attribute has one value for each object
   listed in the attribute compartment underneath the
    name box
   normally no need for an explicit “ID” attribute
           Shuttle                               Mission

       weight : Integer                    start : Date
       age : Integer                       end : Date
       status: enum = on-ground            cost : Dollars


                                  UML Overview              31
Operations
    implementation of a service that can be requested
     from any object of the class
    what you can do to/with an object
    are listed in an additional box underneath the
     attribute box
    SYNTAX- name (arg1 : type, arg2 : type ...) :
     result
                           Shuttle

                   start_engines()
                   stop_engines()
                   fuel_level() : integer
                   launch(t:time)


                                   UML Overview          32
 Organizing Attributes and Operations
• Ellided
• Empty compartment
       drawing an empty compartment makes no
        statement about the absence of attributes or
        operations
• Prefix groups with Stereotypes to
        group together attributes / operations with
        common characteristics
        represent a metaclassification of the attributes /
        operations




                                UML Overview                  33
Responsibility
• Contract or obligation of a class
• Starting point for modeling a class
• Responsibilities are translated into a set of
  attributes and operations
• Free-form text, in separate compartment at the
  bottom of the class

                       Shuttle


                   Responsibilities
                -- Carry astronauts
                   and payload to low
                   orbit space


                              UML Overview         34
 Other Features
• When need to separate the implementation of a
  class from its specification, use Interface
• Advanced features such as
      attribute or operation visibility
      language-specific features

• Common pre-specified classes modeled with
      active classes
      components
      nodes

                                  UML Overview    35
  Modeling Classes
• What is a Class?

• Where do I find a Class?

• Where do I find Attributes?

• What the difference between a Class and an
  Attribute?

• How do I set responsibilities within Classes ?

                             UML Overview          36
 Hints and Tips
• Classes should map to relevant abstraction in
  problem (and solution) domain
• Embodies small set of well defined
  responsibilities
• Understandable and simple, yet extensible and
  adaptable
• Contain only the relevant properties




                         UML Overview             37
    Relationships
•   Connection among things
•   How Classes are related to one another
•   (Almost) As important as Classes
•   Ways things collaborate
•   Three main type:
        Dependencies
        Generalizations
        Associations




                           UML Overview      38
 Dependency
• Using Relationships
• A Change in one thing may affect the other
  thing that uses it.
• Most often between a class that uses another
  clas as a parameter to an operation


             Shuttle

     start_engines()                         Engine
     stop_engines()
     fuel_level() : integer
     launch(t:time)


                              UML Overview            39
Generalization
• Relationship which organizes classes based on
  their similarities and differences
• Relationship between a general thing (the
  superclass) and a more specific thing (the
  subclass)
• sometimes called “is-a-kind-of” or “is-a”
  relationship
• Child is substitutable for the parent
• Child inherit properties of parent
• corresponds to inheritance in object-oriented
  languages
• NOTATION -
        Spacecraft             Shuttle

                             next to the specialization
       an arrow whose head is UML Overview                 40
Subclasses
   inherit the attributes, operations and associations
    of their superclass(es)
   must obey all semantic restrictions of their
    superclass(es)
   can override the implementation of an operation

                           vehicle
                            size
                            speed



           water vehicle              land vehicle
            draft                       wheels
                                 UML Overview             41
    Ancestors/Descendants
   the terms ancestor and descendant refer to
    generalization across multiple levels.
   an instance of a class is simultaneously an
    instance (transitively) of all its ancestors

                        fruit


               ...
                                         apple



              ...               cox                  granny smiths

                                      UML Overview                   42
    Associations
   describe a group of links with common structure and
    semantics
   are to links what classes are to objects
   can have a different name in each direction



              Person
                                        Works-for
                                     Dan Goldin     NASA

        Employs   Works-for           Bill Gates   Microsoft
                                     John Smith    Rockwell
            Organization                 ...           ...
                               UML Overview                    43
    Associations Continued
   defined solely by the classes which they connect
   associations are not part of the participating
    classes
   associations should not be modelled by attributes

       Astronaut                      Mission
                                                        WRONG
    assigned_to : string           full_name : string




                   Assigned_to         Mission
     Astronaut                                          RIGHT
                                   full_name : string


                                 UML Overview                   44
    Roles
   correspond to one end of an association
   each end of an association may be assigned a role
    which serves as its unique identifier
   provide a way of traversing a binary association
    from one object to a set of related objects
   represent a form of specialization
   are written next to the association line


                  0..*     conducts                   0..*
      Astronaut                                              Experiment
                  mission-specialist

                                       UML Overview                       45
Multiplicity
   the number of instances of one class that may be
    related to an instance of another
   constrains the number of links between objects

             1                                   1..*
                     Class                               Class
                   exactly one          mandatory (one or more)
                             0..*
                                    Class
                         many (zero or more)

            0..1                            2..4, 6..8
                     Class                               Class

       optional (zero or one)               numerically specified
                                      UML Overview                  46
Aggregation
   a special form of association between a whole
    and its parts
   relates an assembly class to its component
    classes
   is transitive but not symmetric (commutative)
   depicted by a diamond at the assembly end
   two kinds -
       physical - a part cannot be in more than one
                  “whole”
       catalog    - a part can be in several “wholes”


                                UML Overview            47
Aggregation Examples
             1..*   1..*                 *        1..*
Document                   Sentence                      Word


             *      4..6
  Crew                     Astronaut


                             2
                                      Wings
   Shuttle                   3
                                      Engines


                            1..*
 Space Center                       Building


                                   UML Overview                 48
Aggregation Example - Graphical interface


                              Window




                               *          0..2
          TitleBar           Pane      ScrollBar               Border



                                      2

 Close Button        Title          Arrow          Indicator


                                    UML Overview                        49
Aggregation - Tree-like Notation

                             Window




                               *       0..2
         TitleBar           Pane      ScrollBar               Border




                                      2
Close Button        Title          Arrow          Indicator


                                   UML Overview                        50
 Lab Work on UML - Part 1

• Review Use Case Development Process from
  Rational Unified Process
      Use Case Finding
      Use Case Details
• Develop Use Case Model using Rational Rose
• Develop Use Case Specification Document




                          UML Overview         51
 Lab Work on UML - Part 2

• Review Class Diagram Development Process from
  Rational Unified Process
• Develop Class Model using Rational Rose




                        UML Overview          52

								
To top