UML

Document Sample
UML Powered By Docstoc
					                        What is UML?
                                                           Kim, Hyeon Soo


   Model
        description of some thing
        describes the different aspects of the product or system
        describes the specific aspects of the product or system

   Importance of models
        planning for cost & time estimation
        work distribution
        resource allocation

   Usable models
        accurate : correctly describe the system
        consistent : different views don’t have conflicts….
        easy to communicate to others
        easy to change
        understandable : as simple as possible
   Unified Modeling Language
        Method Wars
              Booch
              OMT                                  UML
              OOSE/Objectory
              Fusion
              Coad/Yourdon
                                                                       1
                        What is UML?
                                                                  Kim, Hyeon Soo


   Goals of UML
       to model systems using object-oriented concepts
       to establish an explicit coupling to conceptual as well as
        executable artifacts
       to address the issues of scale inherent in complex, mission-
        critical systems
       to create a modeling language usable by both humans and
        machines


   Phases of System Development
       Requirements Analysis
             to capture the requirements of the customer
             use-case modeling
       Analysis
             to perform abstractions on the problem domain
             class diagram
       Design
             to expand the result of analysis into a technical solution
       Programming
             to convert to actual code in OOPL
       Testing
                                                                              2
                     Overview of UML
                                                                     Kim, Hyeon Soo


   Views
       A system is described with a number of different aspects:
             functional : static structure, dynamic interactions
             nonfunctional : timing req. reliability, ….
             organizational : work organization
       A system is described in a number of views that contain
        information that emphasizes a particular aspect of the system.

   Views of UML
       Use-case view
             functionality of the system as perceived by external actors
             use case : generic description of a usage of the system
             customers, designers, developers, testers
             described in use-case diagrams and activity diagrams
             used to validate and verify the system
                    “Is this what you want?”
                    “Does the system work as specified?”
       Logical view
             how the functionality is designed
             designers, developers
             looks inside the system
             describes system’s static structure and dynamic behavior
             static structure => class, object diagrams
             dynamic => state, sequence, collaboration, activity diagrams
                                                                                 3
                   Overview of UML
                                                                  Kim, Hyeon Soo


   Views of UML
       Component view
            description of the implementation modules and their dependencies
            developers
            component diagram


       Concurrency view
            address the problems with communication & synchronization
            the system is dealt with processes and processors
            efficient resource usage, parallel execution, handling of
             asynchronous events
            developers, integrators
            described in dynamic diagrams and implementation
             diagrams(component, deployment diagrams)


       Deployment view
            deployment of the system into the physical architecture
            developers, integrators, testers
            described in deployment diagram




                                                                              4
                     UML - diagrams
                                                                 Kim, Hyeon Soo


   Use-Case Diagram
       shows external actors and their connection to the use cases that the
        system provides
       described only as viewed externally by the actor (that is, system
        behavior of the user perspective)
       does not provide how to operate and implement internal functions of the
        system


       Use-case diagram for an insurance business




                                    Signing an
                                 insurance policy



                                  Sales statistics



        Customer                 Customer statistics
                                                            Insurance
                                                           Salesperson




                                                                               5
                     UML - diagrams
                                                                   Kim, Hyeon Soo


   Class Diagram
       shows the static structure of classes in the system
       shows relationship between classes : associated, dependent, specialized,
        packaged


       Class diagram for financial trading




                        Owns4                      3Handles
        Customer                     Portfolio                     Trader
                                       3Contains




                                    Instrument




                                                         Stock
                    Bond              Stock
                                                         Option




                                                                               6
                     UML - diagrams
                                                                   Kim, Hyeon Soo


   Object Diagram
       variant of a class diagram
       shows a number of object instances of classes
       same notation as for class diagrams is used with two exceptions:
        underlined naming scheme, all instances representation


       Class diagram and object diagram


                    Author                         Computer
                                     Uses4
                 name : String                    name : String
                 age : Integer                    mem : Integer




                                                 Bob’s Job PC:
                                                  Computer
                                                 name : “Dell
                                                         466”
                 Bob: Author                     mem : 64

                name : “Bob J.”
                age : 32                        Bob’s Home PC:
                                                  Computer
                                                 name : “Compaq
                                                 Pentium MMX”
                                                 mem : 32




                                                                               7
                            UML - diagrams
                                                                         Kim, Hyeon Soo


   State Diagram
        shows all the possible states that objects of the class can have, events,
         and transition
        event : another object or some condition


        State diagram for an elevator




                                On         go up(floor)        Moving
              arrive at     first floor                         up
              first floor

         Moving to                                        arrive at        go up(floor)
         first floor                                        floor

                                            arrive at
                            Moving            floor
                                                                 Idle
                             down
                                          go down(floor)

                                     time-out




                                                                                          8
                        UML - diagrams
                                                                             Kim, Hyeon Soo


   Sequence Diagram
        shows a dynamic collaboration between a number of objects
        shows a sequence of messages sent between objects


        Sequence diagram for a print server



     Print (file)
                    :Computer      :PrinterServer           :Printer             :Queue


                           Print (file)
                                             Print (file)
                                                                  Store (file)




                                                                                          9
                            UML - diagrams
                                                                     Kim, Hyeon Soo


   Collaboration Diagram
        shows a dynamic collaboration, just like the sequence diagram
        shows exchange of messages(interaction) + the objects and their
         relationships(context)
        time or sequence is important aspect => sequence diagram
        context is important => collaboration diagram
        is drawn as an object diagram


        Collaboration diagram for a printer server



                   :Computer                             :Queue


                                   [printer busy]
          1: Print (file)          1.2: Store (file)




                  :PrinterServer                         :Printer
                                      [printer free]
                                     1.1: Print (file)




                                                                                10
                           UML - diagrams
                                                                             Kim, Hyeon Soo


   Activity Diagram
        shows a sequential flow of activities
        used to describe the activities performed in an operation
        specifications of activities + specifications of messages


        Activity diagram for a printer server




                                                              Show
                                                            MessageBox
                                          [disk full]
            PrintFile( )


                                          [free disk          Show
                                            space]          MessageBox




                            Remove    ^Printer.Print(file) Create
                           MessageBox                     postscript file




                                                                                        11
                     UML - diagrams
                                                              Kim, Hyeon Soo


   Component Diagram
       shows physical structure of the code in terms of code components
       component : source code comp, binary comp, or executable comp
       shows dependencies between the components


       Component diagram showing dependencies between code comps




                            Comm Hand
                           (comhnd.cpp)
                                                      Comm Hand
                                                      (comhnd.obj)




              Main Class
              (main.cpp)
                                                        Main Class
                                                        (main.obj)




                                                                           12
                      UML - diagrams
                                                               Kim, Hyeon Soo


   Deployment Diagram
       shows the physical architecture of the hardware and software in the
        system
       actual computers, devices, connections, type of connections


       Deployment diagram showing physical architecture of a system




           ClientA:
          Compaq PC
                          TCP/ IP
                                    Application
                                                   DecNet    Database
                                      Server:
                                                              Server:
                                      Silicon
                                                               VAX
                          TCP/ IP   Graphics O2

           ClientB:
          Compaq PC




                                                                              13
                 UML - Model Elements
                                            Kim, Hyeon Soo


   Common model elements

         Class               Object

       Attributes          Attributes   State

      Operations           Operations




       Use Case             Node
                                          Interface




                                        Component
        Package
                              Note




   Some relationships

                         Dependency


                      Generalization


                         Association


                         Aggregation

                                                       14
                    Use-Case Modeling
                                                                 Kim, Hyeon Soo


   What is a Use Case?
        “A use case is a description of a set of sequences of actions,
         including variants, that a system performs to yield an
         observable result of value to an actor”
        “A use case specifies a complete functionality”
              The functionality define the boundaries of the system.
        Use cases describe processes.
        A process is a sequence of events , actions, and transactions
         required to produce something of value to an organization or
         actor.
              Withdraw cash from account
              Order a product
              Register for classes




                                                                            15
                    Use-Case Modeling
                                                            Kim, Hyeon Soo


   Scenarios vs. Use Cases
        A scenario is a sequence of actions carried out to achieve a
         specific goal.
        A use case defines the set of all scenarios possible for a given
         functionality.
              A scenario is an instance of a use case
        Example: A “handle withdraw request on account with
         insufficient funds” scenario is an instance of a “handle
         withdraw request” use case.




                                                                       16
                   Use-Case Modeling
                                                               Kim, Hyeon Soo


   Purposes for Use Cases
        to decide and describe the functional requirements of the
         system
              results in an agreement between the customer and software
               developers
        to give a clear and consistent description of what the system
         should do
              used throughout the development process to communicate to all
               developers those requirements
        to provide a basis for performing system tests that verify the
         system
        to provide the ability to trace functional requirements into
         actual classes and operations in the system
        to simplify changes and extensions to the system by altering
         the use-case model




                                                                           17
                    Use-Case Modeling
                                                                      Kim, Hyeon Soo


   Use Case Modeling
       defining the system
       finding actors
       finding use cases
       describing the use cases
       defining the relationship between use cases
       validating the model


   Use-Case Diagram
       shows external actors and their connection to the use cases that the
        system provides
       described only system behavior of the user perspective
       contains the following model elements: the system, the actors, and the
        use cases
       description of the use-case contents is given in plain text



                                    Signing an
                                 insurance policy


                                 Sales statistics



               Customer          Customer statistics
                                                        Insurance
                                                       Salesperson
                                                                                 18
                                  Actors
                                                                  Kim, Hyeon Soo


   System
        boundaries of the system developed
        software system, business, or a machine
        defining the boundaries and the overall responsibility of the
         system is not always easy
        to identify the basic functionality
        to define a stable and well-defined system architecture


   Actors
        An actor is a role that an external agent plays when interacting
         with the system.
              The external agent can be human, a hardware device, or another
               automated system
              Example: For a Banking System, a person can play the role of a
               Loan Officer, and, if the same person also has an account there, a
               Customer.
        Actors carry out use cases
              primary actors vs. secondary actors
        A use case has
              one initiating actor (stimulus) and
                     who sends a message to the system
              possibly several participating actors
                                                                             19
                              Actors
                                                              Kim, Hyeon Soo


   Finding Actors
        Who will use the main functionality of the system (primary
         actors)?
        Who will need support from the system to do their daily tasks?
        Who will need to maintain, administrate, and keep the system
         working (secondary actors)?
        Which hardware devices does the system need to handle?
        With which other systems does the system need to interact?
        Who or what has an interest in the results that the system
         produces?


   Actors in UML
        actor class can have both attributes and behavior



              <<Actor>>
            Insurance Agent




                                           Insurance Agent




                                                                         20
                                  Actors
                                                                   Kim, Hyeon Soo


   Generalization between Actors



                                  Customer




        Personal Visit Customer              Telephone Customer




                                                                              21
                              Use Cases
                                                                  Kim, Hyeon Soo


   Characteristics of a use case
        always initiated by an actor
        provides value to an actor
        must be a complete description
              avoid to divide a use case into too smaller use cases
              A use case is not complete until the end value is produced.


   Finding Use Cases
        starts with the actors previously defined
              Which functions does the actor require from the system? What
               does the actor need to do?
              Does the actor need to read, create, destroy, modify, or store some
               kind of information in the system?
              Does the actor have to be notified about events in the system, or
               does the actor need to notify the system about something? What
               do those events represent in terms of functionality?
        Other question that don’t involve one of the current actors
              What input/output does the system need? Where does this
               input/output come from or go to?
              What are the major problems with the current implementation of
               this system?


                                                                              22
                               Use Cases
                                                                   Kim, Hyeon Soo


   Describing Use Cases
        objective for the use case
               ultimate objectives
        how/when the use case is initiated
               actor
               situations
        typical flow of messages between actors and the use case
        alternative flow in the use case
               not to describe them in too much detail
        how/when the use case finishes with a value to the actor
        when interactions with participating actors take place


   Description of Use Cases
        text
               clear and consistent so that a customer can understand and validate
                it
               avoid complicated sentences
        activity diagram
               sequence of activities, ordering, and optional decisions




                                                                              23
                    Use Case Example
                                                             Kim, Hyeon Soo


Uc 1 Validate User
Actor: Customer (initiator)
Entry condition: System displays Enter PIN prompt.
Main flow: Customer keys in PIN and submits to system. The system
    validates the PIN. If the PIN is valid then the system acknowledges
    valid entry and the use case ends.
Alternative flow 1: If the PIN is invalid then the use case is restarted. If
    this occurs 3 consecutive times then the system cancels the
    transaction and prevents the customer from interacting for 60
    seconds.
Alternative flow 2: The Customer can cancel the validation at anytime.
    Cancellation causes the use case to restart.
Alternative flow 3: The Customer can clear and reenter the PIN any
    number of times before submitting the PIN.




                                                                        24
                  Alternative Description
                                                        Kim, Hyeon Soo


Uc 1 Validate User
Actor: Customer
Entry condition: System displays Enter PIN prompt.
Customer                       System Response
1. Enter and submit PIN        2. If PIN valid acknowledge validity,
                                 else if PIN invalid and attempts < 3
                                      then restart use case,
                                 else if PIN invalid and attempts = 3
                                      then cancel transaction and
                                      block customer for 60 seconds


Exceptions: ...




                                                                   25
                              Use Cases
                                                          Kim, Hyeon Soo


   Other Use Case Types
        Primary use case: describes a common process
        Secondary use case: describes a process that is rarely
         performed
        Optional use case: describes a process that may not be
         performed


   Use Case Template
     Use case name: name of use case
     Actors: list of actors
     Type: (real, essential); (primary, secondary, optional)
     Cross-Reference: reference to system function or other use cases
     Entry condition: action that starts use case
     Typical flow: typical flow of activities
     Exit condition: action that ends use case
     Alternative flow: alternative flow of activities




                                                                     26
                           Classes, Objects
                                                               Kim, Hyeon Soo


   Classes and Objects
         Many similar objects can be specified by the same general
          description.
         A class is a description of an object type.
         Every object is an INSTANCE of a class.




                                         Employee Kim
          Class Employee
                                          Name=Kim
                                          Address=Seoul
         Data                             Tel.no=1459
          Name                            Salary=15000
          Address                         Internal ref     Employee Choi
          Tel. no
          Salary
                                                        Name=Choi
          ...
                                                        Address=Chun Chon
         Methods                                        Tel.no=1501
          Add_Name                                      Salary=15000
          Add_Addr                                      Internal ref
          Add_Tel_No
          Modify_Salary                  Employee Ahn
          ...
                                       Name=Ahn
                                       Address=Seoul
                                       Tel.no=1459
                                       Salary=15000
                                       Internal ref




                                                                            27
                        Classes, Objects
                                                           Kim, Hyeon Soo


   Rendering Classes
        A depicted class diagram has the following structure:
              Name compartment (mandatory)
              Attributes compartment (optional)
              Operations compartment (optional)
              Responsibilities compartment (optional)
        Every class must have a distinguishing name.
        An empty compartment indicates only that information is
         omitted from the diagram.
        You can explicitly specify that there is missing information by
         inserting ``...'' .
        The number of objects of a class that can coexist is called the
         class multiplicity.




                                                                      28
                              Attributes
                                                             Kim, Hyeon Soo


   Responsibilities
        A responsibility is a statement of the goals each object of a
         class is obligated to support.
        Class attributes and operations are the features used by each
         object to carry out its responsibilities.
        Responsibilities are expressed in free-form natural language.



   Attributes
        An attribute is a named property.
        Attributes describe the characteristics of the objects.
        Attributes have no identity outside an object.


   Basic Attribute Properties
        Attribute type: set of values that can be assigned to attribute.
        Attribute multiplicity: the number of values associated with the
         attribute
              Default multiplicity is 1
              Note multiplicity when it is not 1




                                                                         29
                       Rendering Classes
                                                                      Kim, Hyeon Soo


   Rendering Classes

                     WashingMachine

              + modelName: String
              - serialNumber : Integer
              + capacity : Integer                  {capacity = 16, 18, or 20lb}


              + addClothes( )
              + removeClothes( )
              + addDetergent( )
              + turnOn( )

                Taking dirty clothes as input and
                producing clean clothes as output




        Java Implementation
          public class WashingMachine                WashingMachine washM1 =
          {                                                   new WashingMachine( );
                public String modelName;             washM1.addClothes( );
                private int serialNumber;            washM1.turnOn( );
                public int capacity;


                public void addClothes( )
                {
                    // Java code for addClothes
                } ….
          }
                                                                                   30
                        Finding Classes
                                                                      Kim, Hyeon Soo


   Finding Classes
        from the problem domain
        A requirement specification and a business analysis should be
         used as a basis.
        some questions to identify classes
              Do we have information that should be stored or analyzed?
                     Information : possible candidate for a class
              Do we have external systems?
                     External system might be seen as classes
              Do we have any patterns, class libraries, components, and so on?
                     They normally contain class candidates.
              Are there devices that the system must handle?
                     Something that handle these devices are class candidates.
              Do we have organizational parts?
              Which roles do the actors in the business play?
                     Roles can be class candidates; e.g. user, system operator,...




                                                                                 31
                           Relationships
                                                                    Kim, Hyeon Soo


   static relationships:
        Associations
               describe a set of links defined as a semantic connection
        Generalizations
               represent generalization/specialization class structures
        Dependency
               relationship between one independent element and one dependent.
        Refinement
               two descriptions of the same thing at different levels of abstraction



   Associations
        OOA associations represent conceptual relationships among
         problem concepts.
        Association properties
               Multiplicity
               Role
               Constraints
               Predefined properties
        Example: “An author uses a computer.”

                                 uses
               Author                             Computer

                                                                                32
                           Associations
                                                             Kim, Hyeon Soo


   Association Multiplicity
        A multiplicity specifies the range of allowed cardinalities.
              Cardinality: number of elements in a set
        Each end of an association has a multiplicity.
        An association multiplicity constrains the number of objects at
         the association end that can be associated with a single object
         of the class at the opposite end of the association.



   Multiplicity Forms
        *, 0..* : 0 or more
        p..*: p or more
        p..m (p  m) : at least p and at most m
        General form: a multiplicity is a set of ranges.
              Example (1..3,5..7,78..100)
        default : 1




                                                                        33
                      Associations
                                                             Kim, Hyeon Soo


   Example (Interpretation for the below model)
         An insurance company has insurance contracts, which refer to one
          or more customers.
         A customer has insurance contracts (zero or more), which refer to
          one insurance company.
         An insurance contract is between an Insurance company and one
          or more customers. The insurance contract refers to both a
          customer (or customers) and an insurance company.
         The insurance contract is expressed in an (zero or one) insurance
          policy (a written contract of insurance).
         The insurance policy refers to the insurance contract.




                                                                        34
                          Associations
                                                            Kim, Hyeon Soo


   Java Implementation


         Insurance    1      contracts      0..*   Insurance
          company             refers to             contract




         // Insurance_company.java file
         public class Insurance_company
         {
             /* methods */


             // Insurance_contractVector is a specialization of the Vector.
             // Vector is a standard Java class for dynamic arrays.
             private Insurance_contractVector contracts;
         }


         // Insurance_contract.java file
         public class Insurance_contract
         {
             /* methods */


             private Insurance_company refer_to;
         }
                                                                       35
                            Associations
                                                               Kim, Hyeon Soo


   Recursive Associations
        An association from a class to itself is said to be recursive
         association.
        Role names or association names must be given for recursive
         associations.
        A link of a recursive association relates different objects of the
         same class.


                                  *       Node

                                             *
                                 connects



   Association Roles
        The role name indicates the role played by the class.
        You can name the role that a class plays in an association by
         placing the name at the class's association end.
        Role names are part of the association and not part of the
         classes.


                        *        drives            *
            Person                                      Car
                        driver            company car
                                                                          36
                           Associations
                                                            Kim, Hyeon Soo


   Qualified Association
        The qualifier specifies how a specific object at the many end of
         the association is identified.
        a kind of key


              Canvas      figure id              Figure




   Or-Association
        indicates mutually exclusive associations
        only one of the associations is valid at a time


                       Insurance
                        contract

                                      {or}



                         Person              Company




                                                                       37
                           Associations
                                                                     Kim, Hyeon Soo


   Qualified Association

                                            0..1     OrderLine
                  Order   Product
                                       lineItems
                                                   amount: Number




        Java Implementation
         class Order
         {
             public OrderLine getLineItem(Product aProduct);
             public void addLineItem(Number amount, Product forProduct);
             ….
             private Map _lineItems;
         }




                                                                                38
                         Associations
                                                               Kim, Hyeon Soo


   Association Classes
        Associations can be associated with properties expressible as
         attributes and operations.
        An association class specifies properties of an association.
        Association class is used to add extra information on a link.
        Structures with association classes can be converted to
         structures that consist of no association classes.




                        *                        1..*
          Company       employer            employee
                                                        Person



                                   Job
                              description
                              dateHired
                              salary




                                                                          39
                   Associations
                                                       Kim, Hyeon Soo


   Association Classes


                   *                         1..*
        Company    employer             employee
                                                    Person



                              Job
                          description
                          dateHired
                          salary




                   *                         1..*
        Company    employer             employee
                                                    Person
             1                                          1



                              Job
                          description
                          dateHired
                          salary


                                                                  40
                               Associations
                                                                   Kim, Hyeon Soo


   Binary and N-ary Associations
          A binary association relates two classes.
          An n-ary association relates n (n > 2) classes.
          N-ary associations can often be modeled as binary
           associations.




         Insurance   1          0..*   Insurance
          company    insurer            contract

                                       0..*



                                                           0..1   Insurance
                                                                    policy




                                       1..* policyholder

                                        Person




                                                                              41
                           Aggregation
                                                                   Kim, Hyeon Soo


   Aggregation
       Aggregation is a special form of association
             reflects whole-part relationships
       The whole delegates responsibilities to its parts
             the parts are subordinate to the whole
             unlike associations in which classes have equal status

   UML Forms of Aggregation
       Composition (strong aggregation)
             A composition aggregation owns its parts
             parts are generated at the same time, before, or after the whole is
              created (depending on multiplicity at whole end) and parts are
              deleted before or at the same time the whole dies
             multiplicity at whole end must be 1 or 0..1
             role name -> attribute, class name -> attribute type




                                                                               42
                          Aggregation
                                                                  Kim, Hyeon Soo


       Shared (weak aggregation)
             The parts may be parts in any wholes.
             multiplicity at whole end is other than one (1).



                          *                    *
                Team                                 Person
                                 Members




   Rendering UML Aggregation
       Aggregation rendered as a diamond-headed line, with the
        diamond at the whole end
       Composition: black diamond
       Shared: unfilled diamond
       Other adornments same as association adornments




                                                                             43
                        Generalizations
                                                                   Kim, Hyeon Soo


   Generalization/Specialization
        A generalization is a relationship between a general and a
         specific class.
              Objects of specialization can be used anywhere an object of a
               generalization is expected (but not vice versa).
        Example: Mechanical Engineer and Aeronautical Engineer are
         specialization of Engineer



   Rendering Generalizations
        Generalization is rendered as a solid directed line with a large
         hollow triangle at the superclass end of the line.
        A discriminator can be used to identify the type of
         specialization


   Visibility
                              outside          inside         subclass
           public                +                +               +
           private                -               +               -
           protected              -               +               +


                                                                               44
                                Generalizations
                                                                                Kim, Hyeon Soo


   Abstract vs. Concrete Class
          Abstract class
                   does not have any objects
                   describes common attributes and behavior
                   has at least one abstract operations
                             abstract operation : has no implementation method; only
                              signature is shown.
          Concrete class
                   has objects
                   has implementations for all operations



                                              Vehicle
                                             {abstract}

                                         color


                                         drive( ){abstract}




                    Car                          Boat                          Truck


         drive( )                        drive( )


                      drive() starts                          drive() starts
                       the wheels                             the propeller                45
                      Generalizations
                                                           Kim, Hyeon Soo


   Predefined Constraints on Generalizations
        complete: indicates all subclasses have been defined; no others
         permitted
        incomplete: indicates that other subclasses are permitted
        disjoint: an object can belong to at most one subclass.
        overlapping: an object can belong to more than one subclass




                                Person




                                                            {complete}


                  Man                         Woman




                                                                      46
             Dependency / Refinement
                                                           Kim, Hyeon Soo


   Dependency Relationships
        a semantic connection between two model elements, one
         independent and one dependent model element.
        A change in the independent element will affect the dependent
         element.
        e.g. one class takes an object of another class as a parameter


   Refinement Relationships
        a relationship between two descriptions of the same thing, but
         at different levels of abstraction.


                                        dependency
                                        relationship


           Information
             System
                                                       Company


                               refinement
                              relationship


           Computer-based
         Information System


                                                                      47
                     Object Modeling
                                        Kim, Hyeon Soo


   Object modeling process
        Identify objects
        Select classes
        Identify associations
        Identify attributes
        Simplify using inheritance
        Test the model




                                                   48
                       Object Modeling
                                                                    Kim, Hyeon Soo


   Identify Objects
        Underline all nouns in the problem statement using the
         following criteria:
              begin with the nouns from the problem statement
              use relevance to the problem as the only criteria for selection
              include physical entities as well as concepts
              do not try to organize using aggregation or generalization at this
               time
              do not try to differentiate between objects and attributes at this
               time


   Select Classes
        Eliminate redundant classes
        Eliminate irrelevant classes
        Eliminate classes that should be attributes
              names that describe objects are attributes rather than objects
        Eliminate classes that should be operations
              name that describes an operation that is applied to classes
        Eliminate classes that should be roles
              e.g. waiter, busboy versus employee
        Eliminate implementation constructs
              e.g. table, tree (Data structure), CPU, subroutines, Algorithm
        Clarify classes that are vague                                          49
                     Object Modeling
                                                             Kim, Hyeon Soo


   Creating Class Diagram
        Establish the class diagram early in the process
        Begin the class diagram with the classes found during the
         select classes step
        Use the model to stimulate input from experts and users
        Make the class diagram the repository for all collected
         information
        The class diagram will change continually throughout the
         process




                                                                        50
       Case Study (Object Modeling)
                                                        Kim, Hyeon Soo


   Payroll system problem statement


    Create a payroll system for restaurants and hotels. Make
    certain that the usual deductions are taken into
    consideration. The payroll must accommodate both salaried
    and hourly employees. The waiters are salaried employees,
    but the busboys are hourly employees. The payroll system
    must print checks weekly. The system will produce a payroll
    register which will be turned over to auditors monthly.
    Income and tax reports including W-2s must be prepared
    according to legal requirements. Reports concerning
    voluntary deductions will be prepared for various agencies
    on a quarterly basis. Restaurant employees will be able to
    eat meals at their restaurant but will have the cost of the
    meals deducted from their paycheck. Hotel employees will
    have room costs deducted if they live in the hotel. There are
    voluntary deductions and mandatory government deductions
    that must be taken into account.
                                                                   51
       Case Study (Object Modeling)
                                                        Kim, Hyeon Soo


   Payroll system problem statement


    Create a payroll system for restaurants and hotels. Make
    certain that the usual deductions are taken into
    consideration. The payroll must accommodate both salaried
    and hourly employees. The waiters are salaried employees,
    but the busboys are hourly employees. The payroll system
    must print checks weekly. The system will produce a payroll
    register which will be turned over to auditors monthly.
    Income and tax reports including W-2s must be prepared
    according to legal requirements. Reports concerning
    voluntary deductions will be prepared for various agencies
    on a quarterly basis. Restaurant employees will be able to
    eat meals at their restaurant but will have the cost of the
    meals deducted from their paycheck. Hotel employees will
    have room costs deducted if they live in the hotel. There are
    voluntary deductions and mandatory government deductions
    that must be taken into account.
                                                                   52
        Case Study (Object Modeling)
                                                  Kim, Hyeon Soo


    Preliminary Objects

                 HOURLY       INCOME
     SYSTEM                                          BASIS
                EMPLOYEE      REPORT

                               TAX              RESTAURANT
    PAYROLL      WAITERS
                              REPORT            EMPLOYEES

RESTAURANT      BUSBOYS           W-2               MEALS

                 PAYROLL                           COST OF
     HOTEL                 REQUIREMENT
                  SYSTEM                            MEALS

DEDUCTION        CHECKS      REPORTS              PAYCHECK

    CONSIDER    PAYROLL     VOLUNTARY              HOTEL
     -ATION     REGISTER    DEDUCTION            EMPLOYEES

    SALARIED
                 AUDITOR     AGENCIES            ROOM COST
    EMPLOYEE

                                                MANDATORY
       HOURS       VOL. DEDUCT.                 DEDUCTION
      WORKED         REPORTS
                                        I/O
                                                  ACCOUNT
        TAX
                   DEPARTMENT
      PROFILE                           Identified objects after applying
                                                               53
                                        real world knowledge
        Case Study (Object Modeling)
                                             Kim, Hyeon Soo


    Select Classes

                  HOURLY         INCOME
     SYSTEM                                    BASIS
                 EMPLOYEE        REPORT

                                  TAX       RESTAURANT
    PAYROLL       WAITERS
                                 REPORT     EMPLOYEES

RESTAURANT        BUSBOYS            W-2       MEALS

                  PAYROLL                     COST OF
     HOTEL                    REQUIREMENT
                   SYSTEM                      MEALS

DEDUCTION         CHECKS        REPORTS      PAYCHECK

    CONSIDER     PAYROLL       VOLUNTARY      HOTEL
     -ATION      REGISTER      DEDUCTION    EMPLOYEES

    SALARIED
                  AUDITOR       AGENCIES    ROOM COST
    EMPLOYEE

                                            MANDATORY
       HOURS          VOL. DEDUCT.          DEDUCTION
      WORKED            REPORTS
                                             ACCOUNT
        TAX
                      DEPARTMENT
      PROFILE
                                                        54
         Case Study (Object Modeling)
                                                     Kim, Hyeon Soo


     Initial Class Diagram for Payroll System


       HOTEL          RESTAURANT



               DEPARTMENT



            HOTEL      RESTAURANT      SALARIED      HOURLY
          EMPLOYEES    EMPLOYEES       EMPLOYEE     EMPLOYEE



                            PAYROLL
                                                  W-2
                            REGISTER

                             HOURS
                                            PAYCHECK
                            WORKED



     INCOME
     REPORT                                 DEDUCTION
                        COST OF
       TAX              MEALS
      REPORT                           MANDATORY    VOLUNTARY
                      ROOM COST        DEDUCTION    DEDUCTION
    VOL. DEDUCT.
      REPORTS
                                                                55
      Case Study (Object Modeling)
                                                  Kim, Hyeon Soo


   Modified Class Diagram for Payroll System


     HOTEL         RESTAURANT



             DEPARTMENT


                                 EMPLOYEE




                          PAYROLL
                                                 W-2
                          REGISTER

                           HOURS
                                           PAYCHECK
                          WORKED
    REPORT




                COST
                                          DEDUCTION


      COST OF                        MANDATORY   VOLUNTARY
                   ROOM COST         DEDUCTION   DEDUCTION
      MEALS


                                                             56
       Case Study (Object Modeling)
                                                                Kim, Hyeon Soo


   Partial Class Diagram for Payroll System



                                    Employee




        Hotel             Restaurant       Hourly           Salaried
       Employee           Employee        Employee         Employee




                 Cost




     Meal Cost          Room Cost
                                                  Report




                                                                Vol. Deduct.
                                Tax Report     Income Report
                                                                  Report



                                                                           57
                        Object Modeling
                                                                   Kim, Hyeon Soo


   Identify Associations
        Identify associations and aggregations among the object
         classes
        Eliminate associations
              with eliminated classes
              that are implementation-specific
              that are irrelevant
              that are redundant
                      associations that can be defined by other associations
        Estimate multiplicity for each association
        Refine associations
              correct misnamed associations
              clarify ambiguous associations
              decompose higher order associations
              reduce multiplicity of associations




                                                                                58
                       Object Modeling
                                                                     Kim, Hyeon Soo


   Identifying Associations and Aggregations
        associations and aggregations are stated as verbs or verb
         phrases in the problem statement
              physical location (next to, part of, contained in)
              directed actions (drives)
                     e.g. Taxes are deducted from paychecks
              communication (talks to)
              ownership (has, part of)
                     e.g. Company owns hotels and restaurants
              Satisfaction of some condition (works for, manages)
                     e.g. Employee works for company
        association shows dependencies between two or more classes
        aggregation is a strong form of association which relates two
         or more classes through physical location or ownership
        No need to distinguish between associations and aggregations
         initially




                                                                                59
                       Object Modeling
                                                                   Kim, Hyeon Soo


   Determining Multiplicity
        Is the association optional, i.e., should zero be included in the
         range?
              An association is optional unless the link exists for every instance
               in the class.
        Is the association to-one, i.e., should the range be one?
              If the application domain contains any situation where more than
               one instance may be linked, then it is not truly one-to-one. There
               are very few associations that are truly one-to-one.
        Is the association to-many, i.e., should the range allow more
         than one?
              If more than one instance can be linked, then the association is a
               to-many association.




                                                                               60
                       Object Modeling
                                                                  Kim, Hyeon Soo


   Refine associations
        Correct misnamed associations
             say what the association is, not how it came about
             operations are not associations, they are indicators that an
              association between the acting and acted upon classes is likely to
              exist
             multiple operations between two classes does not necessitate
              multiple associations… there might only be one association
             e.g. Suppose you are developing a printing system. Each printer
              has a queue associated with it.
                     There are multiple operations specified between the printer
                      and the queue:
                            Printers can modify the order of items in the queue
                            Printers can delete queued items
                            Printers can deny access to the queue
                            Printers handle queue overflows
                     There is only one association between the printer and the
                      queue: Printer is connected to the queue




                                                                              61
                      Object Modeling
                                                                 Kim, Hyeon Soo


   Refine associations
        Clarify Ambiguous Associations
             Add role names to identify the ends of an association
             This is especially important for reflexive associations
             e.g. “Person manages Person” should be “Boss manages worker”




                            worker
                                      Person

                                          Boss
                                manages




                                                                            62
       Case Study (Object Modeling)
                                                        Kim, Hyeon Soo


   Explicit Associations for Payroll system


    Create a payroll system for restaurants and hotels. Make
    certain that the usual deductions are taken into
    consideration. The payroll must accommodate both salaried
    and hourly employees. The waiters are salaried employees,
    but the busboys are hourly employees. The payroll system
    must print checks weekly. The system will produce a payroll
    register which will be turned over to auditors monthly.
    Income and tax reports including W-2s must be prepared
    according to legal requirements. Reports concerning
    voluntary deductions will be prepared for various agencies
    on a quarterly basis. Restaurant employees will be able to
    eat meals at their restaurant but will have the cost of the
    meals deducted from their paycheck. Hotel employees will
    have room costs deducted if they live in the hotel. There are
    voluntary deductions and mandatory government deductions
    that must be taken into account.
                                                                   63
         Case Study (Object Modeling)
                                                            Kim, Hyeon Soo


   Implicit Associations for Payroll system

        Employees receive paychecks
        Employees submit hours worked
        Hours worked adds to the paycheck
        Voluntary and mandatory deductions are taken from paychecks
        Tax deductions contribute to the amount printed in the W-2
         form
        Payroll register reflects the information printed in the
         paychecks




                                                                       64
        Case Study (Object Modeling)
                                                                      Kim, Hyeon Soo


   Partial Class Diagram for Payroll System


    HOTEL            RESTAURANT



         *            *
                                1   *    EMPLOYEE
                                                             2             W-2
        DEPARTMENT

                      submits
                                                             incurs
                                        receives
         *                               *                                   *
                           3                            4        *
       HOURS          *             PAYCHECK                             COST
      WORKED
                                                    *
                                    *
                is recorded in                               is recorded on
                                             is reduced by
        PAYROLL                              *
        REGISTER                    DEDUCTION *
                                                        5 *           REPORT




1: is staffed by          VOLUNTARY          MANDATORY *              is recorded on
2: receives               DEDUCTION          DEDUCTION
3: are paid for in
4: is reduced by
5: is recorded on                                                                65
                         Object Modeling
                                                        Kim, Hyeon Soo


   Identify Attributes
        Identify attributes
              attributes from the problem statement
              additional attributes
        Refine object attributes
              identify derived attributes
              identify link attributes
              identify qualifiers
        Discard unneeded attributes
              objects
              internal identifiers
              internal states
              out-of-place attributes
              keep appropriate level of detail




                                                                   66
                        Object Modeling
                                                                  Kim, Hyeon Soo


   Identify attributes
        Attributes from the problem statement
              attributes are properties of individual objects
                     e.g. name, address, age
              attributes are usually nouns followed by possessive phrases
                     e.g. The “name” of the employee
              adjectives can be specific enumerated values of the attribute
                     e.g. Blue is the color of the car.
              some attributes may be found when eliminating classes from the
               initial class list


        Additional attributes
              Most attributes are discovered from knowledge of the application,
               not in the problem statement
              It is not necessary to list every attribute
              Get most important attributes first, details can always be added
              During analysis avoid attributes that are only for implementation


        [Question] Identify attributes of the object “employee”




                                                                               67
                       Object Modeling
                                                                         Kim, Hyeon Soo


   Refine object attributes
        Identify derived attributes
              some of the attributes identified may actually be derived from
               other attributes
              derived attributes are included in object models to simplify
               implementation

                  Article

                cost_price
                sales_price
                /profit           {profit = sales_price - cost_price}


        Identify link attributes
              Does the attribute depend on the link being there?
              Link attributes are frequently found on many-to-many associations
              e.g. Suppose an employee can work for many departments and a
               department employs many workers


                              *              Works for            * Department
                 Employee




                                          Job description



                                                                                    68
                       Object Modeling
                                                                      Kim, Hyeon Soo


   Discard unneeded attributes
        Is the attribute really an object?
              If the entity is important rather than its value then it is a separate
               object and not an attribute
              If the entity has attributes of its own within the application then it
               is an object and not an attribute


        Is the attribute really an internal identifier?
              If the identifiers are for internal processing, they should not be
               part of the object model.
              e.g. employee number        vs. log number


        Is the attribute really a hidden internal value?
              See if an attribute describes the internal state of the object
              See if this internal state is invisible outside the object
              eliminate internal values from the analysis
              e.g. Living expenses within the analysis of payroll application




                                                                                  69
                         Object Modeling
                                                                      Kim, Hyeon Soo


   Discard unneeded attributes
        Is the attribute out-of-place?
              See if one attribute is totally unrelated to all other attributes
              This may mean that the class should be split into two distinct
               classes
              Each class should be simple and coherent
              Unfocused classes need to be clarified and refined


        Keep the level of detail correct
              Keep only the major attributes during analysis
              See if each attribute affects most of the application operations
              If the attribute has only minor effects then discard it
              e.g. number of children vs. number of dependents




                                                                                   70
                      Object Modeling
                                                                  Kim, Hyeon Soo


   Simplify using inheritance
        Bottom up
             Search classes and look for similar attributes, associations or
              operations
             Define a superclass and assign the common attributes, association
              or operations to the superclass
             e.g. hourly employees, salaried employees ==> “employee”
             common attributes: name, address, social security no.
             common operations: hire, assign to department, promote


        Top down
             Refine existing classes into specialized subclasses
             Subclasses should be defined if they will be treated differently in
              the application
             e.g. Mandatory deductions can be further refined into
                    Federal withholding tax
                    State withholding tax
                    Local withholding tax




                                                                                71
        Case Study (Object Modeling)
                                                                      Kim, Hyeon Soo


   Partial Class Diagram for Payroll System


    HOTEL            RESTAURANT



         *            *
                                1   *    EMPLOYEE
                                                             2             W-2
        DEPARTMENT

                      submits
                                                             incurs
                                        receives
         *                               *                                   *
                           3                            4        *
       HOURS          *             PAYCHECK                             COST
      WORKED
                                                    *
                                    *
                is recorded in                               is recorded on
                                             is reduced by
        PAYROLL                              *
        REGISTER                    DEDUCTION *
                                                        5 *           REPORT




1: is staffed by          VOLUNTARY          MANDATORY *              is recorded on
2: receives               DEDUCTION          DEDUCTION
3: are paid for in
4: is reduced by
5: is recorded on                                                                72
           Case Study (Object Modeling)
                                                                         Kim, Hyeon Soo


      Partial Class Diagram for Payroll System



                     incurs                               receives
                                      EMPLOYEE


                         submits
                                                     receives
            *                                    *
         HOURS           *      3                       * is recorded on
                                       PAYCHECK
        WORKED
                                      *
                is recorded in                                                  W-2
                                                is reduced by
                                            *
        PAYROLL
        REGISTER                    REDUCTION

                                                                REPORT

                                                                    *
                *        COST         DEDUCTION *
                                                         is recorded on




                                Voluntary        Mandatory      *        is recorded on
                                Deduction        Deduction

    3: are paid for in
                                                                                    73
       Case Study (Object Modeling)
                                                                Kim, Hyeon Soo


   Partial Class Diagram for Payroll System



                                    Employee




        Hotel             Restaurant       Hourly           Salaried
       Employee           Employee        Employee         Employee




                 Cost




     Meal Cost          Room Cost
                                                  Report




                                                                Vol. Deduct.
                                Tax Report     Income Report
                                                                  Report



                                                                           74
                      Object Modeling
                                                                 Kim, Hyeon Soo


   Test the model
        Access paths
             trace access paths through the model diagram
                    When a unique result is expected, see if the model will yield
                     that result
             think of questions that might be asked, see if the model answers
              them
                    For any questions that can not be answered, alter the model


        Walk through
             After you have done all that you can to test the model
                    have a review cycle or walk through with peers
                    have the ultimate user walk through the model with you




                                                                             75
               Exercise: Aggregation
                                                        Kim, Hyeon Soo


1. Draw the class diagram for a file directory structure
   using aggregation


2. Model the following partially redundant Computer
   Network
   1. The network consists of several computers and two couplers, a
   primary and a backup coupler.
   2. Each coupler is connected to each of the computers. No computer
   is directly connected to another.
   3. The couplers are hardwired to each other.
   4. The computers have unique addresses, by which they are known
   to the couplers.
   5. Bringing the whole network of computers up or down causes
   each computer to be brought up or down in some known order.
   Each computer can be brought up or down independently.
   6. Each computer-coupler connection may be of different baud rate,
   and each can be brought up or down independently.




                                                                   76
             Exercise: Class Diagram
                                                         Kim, Hyeon Soo


3. Draw the class diagram for polygons and points. The
   smallest number of points required to construct a
   polygon is three.


4. Draw the class diagram for a graphical document
   editor that supports grouping, which is a concept used
   in a variety of graphical editors. Assume that a document is
   composed of several sheets. Each sheet contains drawing objects,
   including text, geometrical objects, and groups. A group is simply a
   set of drawing objects, possibly including other groups. A group
   must contain at least two drawing objects. A drawing object can be
   a direct member of at most one group. Geometrical objects include
   circles, ellipses, rectangles, lines, and squares.




                                                                    77
            Exercise: Class Diagram
                                                         Kim, Hyeon Soo


5. A system for distributing electronic mail over a
   network is needed. Each user of the system should be able to
   send mail from any computer account and receive mail on one
   designated account. There should be provisions for answering or
   forwarding mail, as well as saving messages in files or printing
   them. Also, users should be able to send messages to several other
   users at once through distribution lists. Each computer on the net

   should hold any messages destined for computers which are down.




                                                                      78
                      Sequence Diagram
                                                                    Kim, Hyeon Soo


   Generic and Instance form
        Generic form
              all possible alternatives in a scenario
                     includes branches, conditions, and loops
        Instance form
              a specific scenario in detail: one possible interaction for just the
               chosen scenario
                     does not include branches, conditions, or loops


   Message
        can be signals, operation calls, or ….
        When a message is received, the receiving object starts
         activation
              activation
                     executing its own code
                     waiting for the return of another object
        can have conditions
              conditions
                     used to model branches or to decide whether or not to send
                      a message




                                                                                 79
                           Sequence Diagram
                                                                               Kim, Hyeon Soo


   Sequence diagram for a print server


     Print (file)
                    :Computer         :PrinterServer           :Printer         :Queue


                       a     Print (file)
           {b-a < 5 sec}
                                                  [printer free]
                       b                           Print (file)      [printer busy]
          {b’-b < 1 sec}
                                                                      Store (file)
                      b’




   Recursion

                            oper( )
                                            object:class



                                                           oper( )




                                                                                          80
                     Sequence Diagram
                                                                 Kim, Hyeon Soo


    Creating and Destroying Objects

    NewCustomer (Data)
                         :CustomerWindow


                                    Customer (Data)
                                                           :Customer




    RemoveCustomer ( )
                         :CustomerWindow                   :Customer




                                      DeleteCustomer ( )




                                                                            81
                     Sequence Diagram
                                                                      Kim, Hyeon Soo


   Example: Initial Sequence Diagram for Gas Pump


     :Customer                         :Pump                     :Corp.Credit


          “Select method of payment”
                 Selects “credit”
                  “Insert card”
             Slides card thru reader
            “Checking authorization”           Verify card account
                  “Select grade”                 Returns “OK”

                 Selects “Plus”
                   “Pump On”
                  Removes nozzle
                 Initialize display
                 Depresses nozzle
                 Updates display

                  Releases nozzle
                 Replaces nozzle
          “Pump Off; Receipt Printing”
                  “Take receipt”
                 Removes receipt

          “Select method of payment”



                                                                                 82

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:29
posted:8/15/2011
language:English
pages:82