Docstoc

Lecture for Chapter 2_ Modeling with UML

Document Sample
Lecture for Chapter 2_ Modeling with UML Powered By Docstoc
					                        UML




         Part III
Unified Modeling Language



OOSE                          1
                      UML




         Chapter 6
       Introduction



OOSE                        2
                                                                 UML

     UML (Unified Modeling Language)
 An   industrial defacto standard for modeling object-oriented software.
     Resulted   from the convergence of notations from three leading object-
       oriented methods:
     OMT      (James Rumbaugh), OOSE (Ivar Jacobson), OOD (Grady
      Booch)
     UML II
 Supports the entire software development lifecycle, diverse applications
  areas
     Supported by several CASE tools, e.g. Rational ROSE, Together/J
 Three categories (Notation-wise)
     Modeling Elements (Things)
     Relationships
     Diagrams
 Formal semantics
     Object Constraint Language (OCL)

OOSE                                                                         3
                                                                          UML

                         Modeling Elements
 Structural elements
    class, interface, collaboration, use case, active class, component
 Behavioral elements
    interaction, state machine
 Grouping elements
    package, subsystem
 Other elements
    note




      OOSE                                                                      4
                                                                        UML

                        Relationships
 Generalization/Specialization
                                                multiplicity


 Association                          0..1         relation_name   *
                             Class 1                                    Class 2
                                       role_name1          role_name2
 Aggregation


       Composition


 Dependency


 Refinement/Realization



OOSE                                                                              5
                                    UML

             Extension Mechanisms

 Stereotype
 Tagged value
 Constraint




OOSE                                      6
                                                   UML

              UML Core Conventions

 Rectangles are classes or instances
 Ovals are functions or use cases
 Instances are denoted with an underlined names
     myWatch:SimpleWatch
     Joe:Firefighter
 Types are denoted with nonunderlined names
     SimpleWatch
     Firefighter
 Diagrams are graphs
     Nodes are entities
     Arcs are relationships between entities




OOSE                                                     7
                                                             UML

                           Diagrams

 A diagram is a view of a model
    Presented from the aspect of a particular stakeholder
    Provides a partial representation of the system
    semantically consistent with other views
 There are 9 standard diagrams
    Use case diagram
    Class (object) diagram
    Behavior diagram
         activity, collaboration, sequence, state
     Implementation    diagrams
         Component, Deployment,


OOSE                                                               8
                                                                    UML

                           Diagrams
 Use case diagrams
    Describe the functional behavior of the system as seen by the user,
     that is I.e. how to use the system
    Illustrate actors, use cases, and their relationships
 Class diagrams
    Describe the static structure of the system: Objects, Attributes,
     and Associations.
    Shows classes and their relationships with each other.
 Activity diagrams
    Model the workflow of the system.
    Shows activities, object states, states, state transitions, and events.
 Collaboration diagram
    Shows objects and their relationships, including their spatially
     structure message exchange


OOSE                                                                           9
                                                              UML

                     Diagrams(con’t)
 Sequence diagrams
    Describe the dynamic behavior between actors and the system and
      between objects of the system.
    Illustrate    objects and their relationships, including their
      chronologically structured message exchange
 State diagrams
    Describe the dynamic behavior of an individual object as a finite
      state machine.
    Illustrate state, state transitions, and events
 Component diagram
    Illustrate components and their relationships
 Deployment diagram
    Illustrate components, nodes and their relationships



  OOSE                                                                   10
                          UML




           Chapter 7
       Use Case Diagram



OOSE                            11
                                                                    UML


                   Use Case Diagram
 A graph of actors, a set of use cases, possibly some interfaces, and
  the relationships between these elements.

 The relationships are associations between the actors and the use
  cases, generalizations between the actors, and generalizations,
  extends, and includes among the use cases.

 The use cases represent functionality of a system or a classifier, like
  a subsystem or a class.


 Developed by analysts and domain experts




OOSE                                                                        12
                                                                   UML

                   Use Case Diagram

 Purposes of use case diagram

     Describe   the interaction between a set of use case and the actors

     Capture   system functionality as seen by users

     Used during requirements elicitation to represent external
      behavior of system

     Drive   implementation and generate test cases




OOSE                                                                        13
                                               UML

                    Use Case Diagram


      Package
                      SimpleWatch



            Actor
                           ReadTime



                           SetTime
WatchUser                               WatchRepairPerson


      Use case
                        ChangeBattery




OOSE                                                    14
                                                                  UML

                               Actors

 An external entity communicates with the system by sending and
  receiving messages, and exchanging data and events.
     user, external system, physical environment, a user of the system
     A description to represent roles that play the system functions
     A person can play a number of roles (actors)
 Examples:
     Passenger: A person in the train
     GPS satellite: Provides the system with GPS coordinates
     ATM: the client is an actor who can withdraw money from an
      account, transfer money to an account, or check balance of an account




   OOSE                                                                       15
                                                                   UML

                                 Actors
 Notation
    Textual stereotyping                         <<actor>>
                                                  Customer

     Visual    stereotyping

     Textual   and visual stereotyping           <<actor>>
                                                  Customer

 Generalization/specialization


                                   Office clerk




                   Home insurance Car insurance    Field service
                       clerk          clerk            clerk
  OOSE                                                                   16
                                                         UML

                              Actors
 Other parties
    <<boundary>>, <<interface>>:
     dialogs and other interaction
     interfaces
                                         Contract file


    <<control>>:   controller control
     the interaction between different
     objects                              Controller



    <<entity>>:    passive   objects
     needed in use case                    Schedule



  OOSE                                                         17
                                                                   UML


                           Use Case

 A use case representing a coherent unit of functionality provided by
  a system, a subsystem, or a class.
 A sequences of messages exchanged among the system and the
  actors together with actions performed by the system.
 A scenario that describes a “thread of usage” for a system
 Describe a set of activities of a system from the point of view of its
  actor
 Be always initiated by an actor
 Extension points may be listed in a compartment of the use case
  with the heading extension points.
 The name of an abstract use case may be shown in italics.




OOSE                                                                       18
                                                               UML


                         Use Case
 A use case can be described as the content-related structuring text
    Unique name of use case
    Participating actors
    Entry conditions, preconditions
    Exit conditions, post conditions
    Invariants: conditions must always be satisfied
    Special requirements, non-functional requirements
    Flow of events, process description
    Exceptions, error situations
    Variations: deviations and exceptions from the normal process and
     description of alternative process for these case.




 OOSE                                                                    19
                                                              UML


                          Use Case

  Business   rules, validation rules
  Services
  Contact  partners
  Notes / open questions: design decisions / design alternatives
  Documents, reference, dialog samples, references: screen shots,
   instructions, manuals
  Diagrams: UML diagram




OOSE                                                                 20
                                       UML


              Explorative prototypes

 To communication with users
    Concrete screen dialog
    Business forms
    Sample print-outs
    Visual material




 OOSE                                        21
                                                                  UML

                 The Relationships of Use Case

 Extend (A to B)
    B is extended (for specific conditions) by the behavior of A. The
     behavior of A is inserted at the extension point in B.
    The direction is to the extended use case


 Include (C to D)
     C contains the behavior of D.
     To extract identical section occurring in several use cases in order to
      prevent redundancy.
     The direction is to the using use case


 Generalization (E to F)
    E is a specialization of F.


  OOSE                                                                      22
                                                             UML

            Developing a Use Case

  What are the main tasks or functions that are performed by the
   actor?

  What system information will the the actor acquire, produce or
   change?

  Will the actor have to inform the system about changes in the
   external environment?

  What information does the actor desire from the system?

  Does the actor wish to be informed about unexpected changes?



OOSE                                                                23
                                                            UML

                  Use Case Example(1)

Name: Purchase ticket            Event flow:
                                 1. Passenger selects the number
Participating actor: Passenger      of zones to be traveled.
                                 2. Distributor displays the amount
Entry condition:                    due.
 Passenger standing in front    3. Passenger inserts money, of
  of ticket distributor.            at least the amount due.
 Passenger has sufficient       4. Distributor returns change.
  money to purchase ticket.      5. Distributor issues ticket.

Exit condition:              Anything missing?
 Passenger has ticket.



OOSE                                                                  24
                                                           UML



                      Passenger




                    PurchaseTicket

       <<extend>>


              <<extend>>
                                          <<extend>>
  OutOfOrder                 <<extend>>                TimeOut


                    Cancel           NoChange




OOSE                                                             25
                                                        UML



                 PurchaseMultiCard
                                            Cancel
                   <<include>>          <<extend>>
Passenger
                 <<include>>     CollectMoney
                                           <<extend>>

            PurchaseSingleTicket
                                          NoChange




                            Validate




                 validate            validate
                 with PIN           with card

OOSE                                                          26
                                                             UML

                 Use Cases Example(2)

  ATM. The client (actor) can withdraw money from an account,
   transfer money to an account, or check the balance of an account.
   These operations, correspond to flows, which can be represented
   by use cases.



                           Transfer Money


        Client
                            Check Balance



                          Withdraw Money



OOSE                                                                   27
                             UML

       Use Case Example(3)




OOSE                               28
                       UML




         Chapter 8
       Class Diagram



OOSE                         29
                                                            UML

                    Class Diagram

 Captures the structure of a system
    during requirements analysis to model problem domain concepts
    during system design to model subsystems and interfaces
    during object design to model classes.




OOSE                                                                 30
                                                                   UML

                             Class

 To represent a concept and encapsulates state (attributes) and
  behavior (operations).
    attribute has a type.
    operation has a signature.




                           TariffSchedule
                      Table zone2price
                                                             Name
                      Enumeration getZones()
  Signature           Price getPrice(Zone)




OOSE                                                                     31
                                                                     UML

                          MetaClass

 Classes of class objects (underline for operation and attribute)
    A class operation is new
    A class attribute is numberOfInstances




         Person
                                                   <<metaclass>>
 numInstance:Integer          <<instance of>>
                                                    PersonClass
 Name:String
                                                numInstance:Integer
 birthDate:Date
                                                new(name)
 new(name)
 age():Integer




OOSE                                                                       32
                                                          UML

               Parameterized Class

 Template class (in C++)
    With generic formal parameters




        i:Element
                                           WaittingRoom
WaittingQueue
                       <<bind>>(patient)

Add()                   <<bind>>(Car)
Remove()                                    TrafficJam




OOSE                                                            33
                                                          UML

                     Abstract Class

 Virtual class (in C++)
    Never used to generate object instance

                        GeomFigure
                        {abstract}




  Triangle                Circle              Rectangle




OOSE                                                            34
                                                  UML

                        Utility Class

 Collections of global variables and functions
    Math class in Java

                        <<utility>>
                            Math
                             Pi
                           Sin()
                           Cos()




OOSE                                                    35
                                                              UML

                           Object

 An Object is a unit which actually exists and acts in the current
  system, a phenomenon.
 An alternative term is instance
     The name of an instance is underlined and can contain the class
      of the instance.
     The attributes are represented with their values.
 Multiple classification: an object is an instance of more than one
  class
 Dynamic classification: an object can became an instance of more
  than one class
                       aCircle: Circle
                          radius=25
                       Center = (10,10)



OOSE                                                                    36
                                                                UML

                          Attribute

 An attribute is a data element which is contained in the same way in
  each object of a class
     Name
     Constraint: restrict the value range
     Tagged value: specify special properties
 Derived attributes: /
 Class attributes                  Circle
 Visibility                        #name:String =“Unknow”
     Private: -                    -radius{radius>0}
                                    +Center = (10,10)
     Protected: #
                                    /perimeter:Interger
     Public: +                     {perimeter=2*Pi*radius}




OOSE                                                                     37
                                                                      UML

                             Operation
 Operation
    Operation is a service that an object may be requested to perform
    By message passing
    Signature: visibility returnType name(argument: argumentType);
    Tagged value: {abstract}
    constrain: {r>0}                 Circle
                                      #name:String =“Unknow”
 Visibility                          -radius{radius>0}
    Private: -                       +Center = (10,10)
    Protected: #                     /perimeter:Interger
    Public: +                        {perimeter=2*Pi*radius}
                                      +double area(r:integer)
 Naming                                                               method body
                                      {r>0}
    Try to use active verbs
 Method
    A method can implement an operation
    The algorithm of a method may be indicated in a note attached to the
      operation entry.


OOSE                                                                                 38
                                                            UML

                    Object Diagram

 Built during analysis and design
    Illustrate data/object structures
    Specify snapshots
    Captures instances and links
 Developed by analysts, designers, and implementers

 Comparison
    Actor: an entity outside the system to be modeled, interacting
     with the system
    Class: an abstraction modeling entity in the problem domain,
     inside the system to be modeled
    Object: a specific instance of a class




OOSE                                                                  39
                        UML

       Object Diagram




OOSE                          40
                                                                UML

                      Interface class

 Interface class describe the externally visible behavior of model
  elements
 Interface class is an abstract classes which define abstract
  operations
     Contain only operations
 Interface class can extend several other interfaces
 A common class can implement several interface
     The different interfaces do not contain homonymous signatures
 make the interface concept more powerful, to specify constraints for
  each signature
     Precondition
     Postcondition
     Invariants
     Exported exceptions



OOSE                                                                     41
                                                              UML

                       Interface class

   Realization relationship


String                         <<implements>> <<interface>>
                                              Sortable
isEqual(String):Boolean
Length():Integer                            isEqual(String):Boolean




              String

              isEqual(String):Boolean          Sortable
              Length():Integer


   OOSE                                                               42
                                                                UML

                      Interface class

 dependency relationship
    SortedStringList as the interface user is only dependent on the
     operation of the String class

                                        String
                      <<use>>
  SortedStringList
                                         isEqual(String):Boolean
                                Sortable Length():Integer




OOSE                                                                   43
                                                                           UML

                          Extension Mechanisms

        Constraint
           Restrict the possible contents, states, or the semantics of a model
            element and which must always be satisfied
           Describes a condition or integrity rule
           Describe the legal set of values of a attributes, specify pre- or
            postconditions
           be formulated free text or a formula-like description

                Project                                   Project    project
                                                                     Self.projectMembers->
         has              consists of              has               includes(self.projectLe)
               {Subset}                                  {Subset}
                                                                      consists of

projectLeader 1       1..* projectMembers projectLeader 1      1..* projectMembers

               Employee                                  Employee
    Constraint with dependency relation         Constraint with OCL expression
       OOSE                                                                              44
                                                          UML

                       Constraints

 OR
                          has 
         Person                      Domestic Address
                       {OR}
                                      Foreign Address
                            has 
 Values
                        Rectangle
                        a {a>0}
                        b {b>0}


  Oredr
                  1        contains     1..* Person
       NameList                               lastName
                      {ordered: lastName}
                                              firstName

OOSE                                                            45
                                                               UML

                       Tagged value

 user-defined, keyword/value pairs
 add specific additional properties
 allow individual instance of existing model elements to be extended by
  specific properties



                      {abstract version = 2.1}
                            GeomFigure
                    visible: Boolean {readonly}
                        display( ) {abstract}
                        remove( ) {abstract}




OOSE                                                                       46
                                                                 UML

                         Stereotypes

 extend the metamodel by a new elements
 be applied to affect directly the semantic of model element
 apply the class, relationship, or package
 four types
     decorative: look more visually appealing, e.g. <<actor>>,
      <<entity>>, <<control>> in use case diagram
     descriptive: describe contexts of usage, e.g. <<business class>>,
      <<process control>> in class diagram
     restrictive: <<interface>>
     redefining: metamodel modification




OOSE                                                                      47
                                                                UML

                             Notes

 be comments to a diagram or an arbitrary element in a diagram
    development state, version of a class, developer responsible for the
      class

                    Person
               birthDate: Date
                     /age


                                 {/age = today – birthDate}




OOSE                                                                        48
                                                                UML

                           Package
 collections of model elements of arbitrary types which are used to
  structure the entire model into smaller, clearly visible units
 may contain different model elements, e.g. use cases and class




OOSE                                                                   49
                           UML




         Chapter 9
      Class Diagram
   (Relational Elements)



OOSE                             50
                                                            UML

         Generalization/Specialization

                            Button




            CancelButton               ZoneButton



 Generalization relationships denote inheritance between classes.
 The children classes inherit the attributes and operations of the
  parent class.




OOSE                                                                  51
                                                           UML

                        Generalization
 Disjoint: default, inverse constraint of overlapping

 Overlapping: for multiple inheritance to control combination of
  common properties from separate inheritance paths

 Complete: all subclass are specified

 Incomplete: further subclass are expected




 OOSE                                                               52
                                                  UML

                Generalization
                    Vehicle
                     name
                  manufacture

                   {overlapping}
        WaterVehicle         WindPoweredVehicle
           draft                minWindForce


                  SailingBoat
                   numOfSail

                                  disjointSailingBoat
overlappingSailingBoat              waterVehicle.name
         name                   windPoweredVehilcle.name
      manufacture               waterVehicle.manufacture
         draft                windPowerVehicle.manufacture
                                          draft
OOSE                                                         53
                                                                       UML

                           Specialization
                                                                    Figure
Extension : add a new operation and attributes.                   Color
                                                                   ...
Redefinition(overriding)                                          move
                                                                   select
    retainthe original interface                                  rotate
    but recode a particular method                                display

Restriction :
                                                                   2 Dimensional
    inherita subset of operations / or tighten
                                                                   orientation
    the type of attribute or operation output                     free type
Reason for overriding:                                             scale
                                                                    fill
    to specify behavior that depends on the subclasse
    to tighten the specification of a feature.
                                                                       Circle
    for better performance                         extension         diameter

                                                    redefinition       display
                                                                       rotate

    OOSE                                                                           54
                                                               UML

                        Specialization

          Specialization class relationship type relationship

          Extension          subclass            subtype

          Redefinition       subclass           same type

          Restriction         subclass          supertype

class membership
    by rule (predicate) (implicitly)
        a rule defines a condition for membership in a class ; all
         objects whose values satisfy the rule belong to the class.
    by enumeration (explicitly)
        an object has explicit class membership and the attributes
         flows from its class.
 OOSE                                                                 55
                                                                    UML

                         Associations
 Associations denote relationships between classes.
   cardinality: number of elements
   multiplicity: range of allowed cardinalities

                          <<stereotypes>>
                           RelationName 
      class A                                             class B
                     1 {constraint/propertyValue} 1

                         role a                role b



                                  Assist 
              Students                          Faculty
                                   Advice



                  Take                       Teach
                                   Courses


 OOSE                                                                     56
                                                       UML

                 Associations

 TarifSchedule                             TripLeg
 Enumeration
 getZones()                                price
 Price
                      * many-to-many *     zone
 getPrice(Zone)


                          Has 
       Country                               City
                  1      capital    1
  name:String                            name:String
                          1-to-1


   Polygon                                   Point
                  1                 *
                        1-to-many         x:Integer
       draw()                             y:Integer

OOSE                                                         57
                                                               UML

                          Associations
 recursive association

                          Employee
                          name                   clerk
                          staffNo                *
                          roomNo

                              manager 1


 qualified association

           Directory                     File    Unqualified
                                     fileName


           Director    file name          File     Qualified
           y

 OOSE                                                                58
                                                                    UML

                         Associations
 association constraints: an association satisfies specific conditions

    Person                                               Address
                                   Has 
                           {delete related object}


 derived associations
                   1 belong to     *
      Enterprise                        Department
                   employer
                                              
                                              works in

                    /work for     * Employee
                {Employee.employer=
                Employee.department.employer}


 OOSE                                                                     59
                                                                    UML

              Attributed Associations
 attributed association: an association with additional class properties
 association class: a class with additional association properties

            Company                           Person
            name                              name
            address                           SSN
                                              address
                           WorkFor
                           salary
                           job title




 OOSE                                                                       60
                                          UML

     Attributed Associations Example
 A route connect two city


               City
               name             connect
                                1

                         1



                             route
                             path
                             search




 OOSE                                           61
                                       UML

          N-ary Associations


        project             Language



                   person




       project    Manager   Language



                   person



OOSE                                         62
                                                                UML

                          Aggregation
 An aggregation is a special case of association denoting a “consists of”
  hierarchy.
 The aggregate is the parent class, the components are the children class.




                                {order}
                    Polygan               Point




   OOSE                                                                   63
                                                           UML

                       Composition

 A solid diamond denote composition, a strong form of aggregation
  where components cannot exist without the aggregate.

                                          3
             TicketMachine                    ZoneButton



                       Window
                       scrollbar[2]: Slider
                       title: Header
                       body: Panel

                         2       1        1

              Slider         Header           Panel


OOSE                                                                 64
                                                                       UML

                           Dependency
 Indicates a situation in which a change to the target element may require
  a change to the source element in the dependency.
     a class uses a specific interface of another class
     a class is dependent on another class
     an operation is dependent on a class
     a package is dependent on another package (a class in one of the
      package is dependent on a class in the other package)

              dependent                               independent
       Example: Person depends on House.
           House could be pass in as a parameter to some operation inside Person.




OOSE                                                                                 65
                                                                      UML

                Refinement/realization
 realization is relation between an interface and its implementation
 refinement is relation between similar elements of different degrees
  of detail

  String                                             <<interface>>
                             <<implements>>
                                                       Sortable
  isEqual(String):Boolean
  Length():Integer                               isEqual(String):Boolean

 refinement

            Tariffing                    Tariffing1

                    performance optimized;
                    calculation now running on
                    locally replicated data

OOSE                                                                        66
                                                                  UML

          Problem Statements: An Example

 A person has a name, address, and social security number. A person may
  charge time to projects and earn a salary. A company has a name, address,
  phone number, and primary product. A company hires and fires persons.
  Person and Company have a many-to-many relationship.
 There are two types of persons: workers and managers. Each worker works
  on many projects; each manager is responsible for many projects. A project
  is staffed by many workers and exactly one manager. Each project has a
  name, budget, and internal priority for securing resources.
 A company is composed of multiple departments; each department within a
  company is uniquely identified by its name. A department usually, but not
  always, has a manager. Most managers manage a department; a few
  managers are not assigned to any department. Each department
  manufactures many products; while each product is made by exactly one
  department. A product has a name, cost, and weight.



    OOSE                                                                       67
                                                                                   UML

                                        Class Diagram
                                                       Company
                          Person
                     1..* name                         name
                                     employee employer
                                                       address
                          address
                                    1..* work_for 1..* phone number
                          SSN
              salary                                   primary product
                                                       hire
                                position               fire
charge_time




                                                                department
                                                                  name

                   Worker              Manager 0..*
                   1..* staff           staff         manage

                   1..*                                        Department             Product
                                                               name          produce name
                   Project                              0..*
              1..* name                                                          1..* cost
                   budget       1..*                                                  weight
                   priority
               OOSE                                                                             68
                                                 UML

   Extended Entity Relation Diagram
                      work-on



            PERSON          COMPANY


                                manage
       WORKER    MANAGER              DEPARTMENT


   staff
                                       PRODUCT
            PROJECT




OOSE                                                   69
                            UML




          Chapter 10
       Behavioral Diagram



OOSE                              70
                                                                  UML

                         Activity Diagrams
 A special case of a state chart diagram in which states are activities
  (“functions”)
 Purpose
     Model business workflows, flow control within a system, and
      operations
     Captures dynamic behavior (activity-oriented)
 Three types of states:
     Action state:
         Cannot be decomposed any further
         Happens “instantaneously” with respect to the level of abstraction
           used in the model
     Activity state:
         Can be decomposed further
         The activity is modeled by another activity diagram
     object   [state]
  OOSE                                                                         71
                                                           UML

     Activity Diagram: Modeling Decisions

                         [lowPriority]
    Open                                                  Allocate
  Incident                                               Resources

                                [fire & highPriority]

    [not fire & highPriority]
                                      Notify
                                    Fire Chief
Object
[State]
                   Notify
                Police Chief


      Handle               Document                      Archive
     Incident              Incident                     Incident


  OOSE                                                               72
                                                                       UML

   Activity Diagrams: Modeling Concurrency
 Synchronization of multiple activities
 Splitting the flow of control into multiple threads




      Splitting                                            Synchronization

                                   Allocate
                                   Resources


        Open                      Coordinate                   Archive
      Incident                    Resources                    Incident


                                    Document            {AND/OR/XOR}
                                    Incident



    OOSE                                                                     73
                                                          UML

       Activity Diagrams: Swim lanes

 Actions may be grouped into swim lanes to denote the object or
  subsystem that implements the actions.




                                                     Dispatcher
                          Allocate
                          Resources


   Open                   Coordinate                Archive
 Incident                 Resources                 Incident

                                                   FieldOfficer
                           Document
                           Incident




OOSE                                                               74
                                                               UML
              Collaboration Diagram
 Captures dynamic behavior (message-oriented)
 Purpose
    Model flow of control
    Illustrate coordination of object structure and control




OOSE                                                                 75
                                                               UML
              Collaboration Diagram
 Synchronization conditions
    simple, sequential:    accepted by receiver and processed
     completely

     synchronous:   the sender waits until the receiver has accepted
       the message

     restricted:the exchange is aborted if the receiver does not
       immediately accept the message
                          ˇ


     time-dependent:   the exchange is aborted if the receiver does
       not accept the message within a specific delay

     asynchronous: end   up in the waiting queue of the receiver


OOSE                                                                    76
                                                                  UML

                    Sequence Diagram
 Used during requirements analysis
     To refine use case descriptions
     to find additional objects (participating objects)
 Used during system design
     to refine subsystem interfaces
 Classes are represented by columns
 Messages are represented by arrows
 Activations are represented by narrow rectangles to sent the message, and
  is as long as all nested activations
 Lifelines are represented by dashed lines
 Purpose
     Captures dynamic behavior (time-oriented) in terms of interactions.
     Model flow of control
     Illustrate typical scenarios
     Complement the class diagrams which represent structure.

  OOSE                                                                        77
                                                                   UML
                  Sequence Diagram

                             Object
                :SimpleWatch           :LCDDisplay             :Time
:WatchUser

      pressButton1()        blinkHours()
      pressButton1()        blinkMinutes()

      pressButton2()                         incrementMinutes()
                                                 refresh()
      pressButtons1And2()
                                             commitNewTime()
                            stopBlinking()



                             Message
      Activation


OOSE                                                                     78
                                                                   UML

       Sequence Diagrams: Nested Messages


           TicketMachine
Passenger
     selectZone()
                                          ZoneButton     TarifSchedule   Display
                           Passenger
                                selectZone()
     insertCoins()                             lookupPrice(selection)


                                                 price
                                               displayPrice(price)
    pickupChange()


     pickUpTicket()
                                                   Dataflow


     OOSE                                                                      79
                          UML

       Sequence Diagram




OOSE                            80
                          UML

       Sequence Diagram




OOSE                            81
                          UML

       Sequence Diagram




OOSE                            82
                                                               UML

                       State Diagram
 Captures dynamic behavior (event-oriented)
 Purpose
    Model object lifecycle
    Model reactive objects (user interfaces, devices, etc.)




OOSE                                                                 83
                                                        UML
                      State Diagrams
Event                            Initial state             State
  button1&2Pressed                 button2Pressed
                        Blink                       Increment
                        Hours                         Hours


        Transition           button1Pressed


   button1&2Pressed                button2Pressed
                        Blink                       Increment
                       Minutes                       Minutes


                             button1Pressed

                                   button2Pressed
    Stop                Blink                       Increment
  Blinking             Seconds                       Seconds
          button1&2Pressed

             Final state
  OOSE                                                             84
                                                         UML

               State Generalization
                                                   SuperState
                      Super State                   contour
   event1             (abstract state)
                 substate1        substate2


                    event3               event2
 Generalization is the or-relationship
 States may have substates that inherit the transition of their
  superstates.
     e.g.                                 Active
                                   on-hook
                      Idle
                                off-hook

OOSE                                                               85
                      UML




       Chapter 11
 Implementation Diagram



OOSE                        86
                                                          UML

                Component Diagram

 Captures the physical structure of the implementation
 Built as part of architectural specification
 Purpose
    Organize source code
    Construct an executable release
    Specify a physical database
 Developed by architects and programmers




OOSE                                                            87
                                                              UML

                Component Diagram

 Component. A component is a physical module of code, including
    source code library
    executable
 Types of components
    Component. A software module with well-defined interface.
    Subprogram. A collection of subroutines.
    Package specification and body. The implementation of a class.
        Specification: a header file which contains function prototype
          information for the class, e.g., .JAVA file
        Body: the code for the operations of the class.
    Task specification (e.g., .exe) and body. Independent threads of
     control,


OOSE                                                                      88
                           UML

       Component Diagram




OOSE                             89
                           UML

       Component Diagram




OOSE                             90
                                                         UML

              Deployment Diagram

 Captures the topology of a system’s hardware
 Illustrate the structure of the runtime system, including the
  configuration of runtime processing elements and the software
  components, processes, and objects that live on them.
 Built as part of architectural specification
 Purpose
     Specify the distribution of components
     Identify performance bottlenecks
 Developed by architects, networking engineers, and system
  engineers
 Example: A browser-based three-tier account management system




OOSE                                                              91
                                   UML

       Deployment Diagram

                        node




                               component
       dependency




OOSE                                       92
                            UML

       Deployment Diagram




OOSE                              93
                                                              UML

    Representing System Architecture

  Logical View                        Implementation View



 End-user                                        Programmers
 Functionality                            Software management
                      Use Case View
  Process View                             Deployment View

 System integrators                       System engineering
 Performance
                                              System topology
 Scalability
                                          Delivery, installation
 Throughput
                                              Communication

         Conceptual                         Physical

OOSE                                                                94
                                                               UML

                          Process
 To concentrate only on a few notations:
    Functional model: use case diagram
    Static model: class diagram
    Dynamic model: sequence diagrams, and activity diagrams



     Use case dia-
     gram & desc-
     ription
                          Class diagram         Refined
                                             Class diagram

        scenarios
                          Use case dia-
                          gram & desc-     Implementation diagram
                          ription           (package, component,
        Activity                            deployment diagram)
        diagram

OOSE                                                                 95
                        Generic Approach to OO Development                               UML

Requirements                       Analysis                Design                 Implementation
                                                                                  and Testing
Business Process                          State Diagrams   Deployment
Reengineering or                                            Diagram
                                                                            Screen or
Context Diagram
                            Activity Diagram                                Web Pages
                                                           Component
Use Case Diagram                                            Diagram
with Descriptions            Sequence Diagram

                     Scenarios                             Package                      RDB or OODB
                                                            Diagram
Ideal Object Model           Class Diagram
  (MVC Model)                (Architectural Patterns)
                                                            Updated
                                                             Sequence
                                                             Diagram
   CRC Cards                            Object Diagram

                             Collaboration                    (Design
                              Diagram                         Patterns)                 Java Bytecode
                                                           Elaborated
                                                            Class Diagram
                        Basic process
       Legend




                        Optional

    OOSE                Additional process, if any
                                                                                                        96
                       UML




        Chapter 12
Object Constraint Language



OOSE                         97
                                                                 UML

             Object Constraint Language(OCL)
 A simple formal language which allows additional semantics to be
  added to UML models.
 With the OCL:
    Specify constraints of a model;
    Indicate invariants, precondition, and postconditions of operations
      and similar;
    Describe navigation paths of an object network.
 Simple examples
  employee.salary < boss.salary
  person.age > 18
  person.addresses-> is Empty
  person.addresses-> size
  employee-> select(age > 30)

        set operations

 OOSE                                                                      98
                                                           UML
                            OCL
 Complex example:
                          CarRentalContract
                             self.driver-> forAll (d | d.age >=18)
    Car rental contract   CarRentalContract
                             self.driver -> select (d | d.age < 25
                                                   and d. isMale)
                          CarRentalContract
                             self.driver ->select (d | d .birthDate =
Authorized                   today) -> firstName)
drivers                   CarRentalContract
                             self.driver -> forAll (d1, d2 | p1 < >p2
                *                implies p1.customer = p2.customer)

           Driver

   OOSE                                                                 99
                                                      UML

                             OCL

 Precedence
    Dot operation(„.‟)
    Unary operation(„not‟)
    Binary operation(„+‟, ‟and‟)
    Bracketing‟(„ and ‟)‟ forces a different order




OOSE                                                        100
                                                                     UML
                                OCL

 The operations predefined for the basic types:
   Types                   Operations
   Boolean                and, or, xor, not, implies, if ..then ..else, =
   Integer, Real          =,+(integer), +(real), round
   Collection             =, s.size(number of elements of s), sum,
                          includes, isEmpty, exists, forAll
   Set                    union, intersection, -, include, exclude, select,
                           reject, collect, asSequence, asBag
   Bag                    union, intersection, include, exclude, select,
                           reject, collect, asSequence, asSet
   Sequence               append, prepend, first, last, at, include,
                          exclude, select, reject, collect, asBag, asSet



  OOSE                                                                        101

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:9
posted:8/17/2011
language:English
pages:101