Docstoc

Introduction To UML

Document Sample
Introduction To UML Powered By Docstoc
					                        Introduction To UML


                                 N.L. Hsueh
                                 2004/6/10
                                 OIT, FCU




Software Engineering Lab., FCU                1
                                 !


Software Engineering Lab., FCU       2
                                 ?   ?   ?


Software Engineering Lab., FCU               3
                         What is Elephant?




Software Engineering Lab., FCU               4
                      The Importance of Modeling

        What is a model?
           a model is a simplification of reality
        Why do we model?
           we build models so that we can better understand the system we
            are developing
           we build models of complex systems because we cannot
            comprehend such a system in its entirety
           four aims to achieve
               help us to visualize a system
               permit us to specify the structure/behavior of a system
               give us a template that guides us in constructing systems
               document the decisions we have made


Software Engineering Lab., FCU                                               5
                         Object-Oriented Modeling

        Different models are organized for their foci
           algorithmic perspective
                focus on control and the decomposition of larger algorithms into
                 smaller ones (functional decomposition)
                not easy to maintain
           object-oriented perspective
                the main building block is object or class
                     user interface layer: buttons, menus, dialog boxes…
                     middle layer: higher-level views of problem entities, such as
                      customers, products and orders
                     database layer: tables representing entities from the problem domain,
                      including customers, products, and orders
                Visualizing,  specifying, constructing, and documenting object-
                 oriented systems is exactly the purpose of UML



Software Engineering Lab., FCU                                                                6
                                  What is the difference?


                              create a meeting
                                                                                attend a meeting
                                                    participant

             initiator
                                     cancel a meeting
                                  functional                          object
                                  decomposition                       decomposition
                                                                                             Case A
                         System
                                                                            A           D
         Case A          Case B        Case C                Case B                       Case D
                                                                            B
                                                                                                   Case C
  function      Case D       function         function                G
                                                                                                   Z
                                                                            C
         function        function                                                            F
                                                                                E

Software Engineering Lab., FCU                                                                              7
                          Data Abstraction

                                     door
                                         manufacturer
                                         model number
                                         type
                                         swing direction
                                         inserts
                                         lights
                                            type
                                            number
                                         weight
                                         opening mechanism


                             implemented as a data structure

     Abstraction is one of the fundamental ways that we as
     humans cope with complexity
     G. Booch
Software Engineering Lab., FCU                                 8
                       Procedure Abstraction


                                      open

                                         details of enter
                                         algorithm




                           implemented with a "knowledge" of the
                           object that is associated with enter




Software Engineering Lab., FCU                                     9
                     From modeling to programming

        Modeling the reality of the world.


         Reality


         Model

        Permeable model representation:




Software Engineering Lab., FCU                      10
                  Characteristics of Object-Orientation

        Objects are abstractions of real-world or system entities and
         manage themselves
        Objects are independent and encapsulate state and representation
         information.
        System functionality is expressed in terms of object services
        Shared       data       areas       are     eliminated.       Objects
         communicate by message passing
        Objects     may       be     distributed    and     may       execute
         sequentially or in parallel
        Objects are appropriate reusable components
            Data structures and the operations that manipulate them are
             merged in a single named entity



Software Engineering Lab., FCU                                                   11
            Class – basic element of object orientation

                      occurrences                 roles
                           things                  organizational units
                                                    places
                external entities
                                                          structures



                                    class name

                                    attributes:




                                    operations:




Software Engineering Lab., FCU                                            12
                 Encapsulation / Information hiding

    Encapsulation: separate the external aspects of an object from the
     internal implementation details of the object, which are hidden
     from other objects

                          method      method
                            #1          #2
                                   data


                      method
                        #6


                           method         method
                             #5             #4




Software Engineering Lab., FCU                                            13
                  Encapsulation – another view




                         module          • algorithm
                          controlled
                          interface      • data structure
                                         • details of external interface
                                         • resource allocation policy
          clients             "secret"




           a specific design decision




Software Engineering Lab., FCU                                             14
                     An object is a state machine

       s tate 1                     t
                                 sta e3                     s tate 4

         O1                        O3                         O4




       s tate 2                  s tate 6                   s tate 5
         O2                        O6                         O5




     A software system is a set of interacting objects, with their own private
     state, rather than as a set of functions that share a global data



Software Engineering Lab., FCU                                              15
                          An Overview of UML

        Unified Modeling Language
           a object-oriented modeling language, rather than a modeling
            method
           support different perspectives for constructing a base model
           a language for
               visualizing: an explicit model facilitates communication
               specifying: a precise, unambiguous, and complete model
               constructing: mapping UML models to programming language
               documenting: requirements, architecture, analysis, design, …




Software Engineering Lab., FCU                                                 16
                                  History

        End of 1994, Rumbaugh and Booch
        1995, Jacobson
        Oct, 1997, publication of UML1.1



             Jacobson, OOSE      Rumbaugh, OMT      Booch, OOD




              Requirement         Object-oriented   Object-oriented
               Elicitation           Analysis           Design




Software Engineering Lab., FCU                                        17
                                               Conti.
              Use Case View             Logical View                   Physical View         Deployment V.


     Focus        Expression of          Expressing     Representing     Implementing         Deployment of
                  requirements           Behavior       Structure      Objects and Classes    Executable Code


                    use case             statechart        class
                    diagrams              diagrams       diagrams

                                                                          component
  Involving                                             object             diagrams
   Diagram                sequence                                                            deployment
                                                       diagrams
                          diagrams                                                             diagrams
                        collaboration                   activity
                          diagrams                     diagrams


                      Actors                    Objects                    Modules                Nodes
    Major          Use cases                    Classes                   Subroutines           Modules
  Modeling           Classes                 Collaborations                 Tasks             Main Programs
Components        Collaborations              Interactions                Subsystems
                                               Categories

  Software Engineering Lab., FCU
                UML Uses Various Diagrams to Model the System from Different Perspectives                  18
                             deployment
         use case             diagrams
         diagrams                                 statechart
                                                   diagrams



   sequence                                           class
    diagrams                                        diagrams



      collaboration                                  object
        diagrams                                    diagrams
                                      component
                         activity
                                       diagrams
                        diagrams


Software Engineering Lab., FCU                                 19
                      Getting Started -- Hello, World!
                                                                           Container

                                                                       Panel

                                                             Applet
   Import java.awt.Graphics
   class HelloWorld extends java.applet.Applet {
     public void paint (Graphics g) {
       g.drawString (“Hello, World!“, 10, 10)              HelloWorld
     }
   }                                                         Paint()               Graphics

                    Java Code                                          Class Diagram



               HelloWorld               applet
                                                    awt
                 Paint()
                                                                  lang

                                         Package Diagram

Software Engineering Lab., FCU                                                                20
                                  Hello, World!


              :Thread         :Toolkit         :ComponentPeer      :ComponentPeer
        run
                        run

                                     callbackLoop



                                         handleExpose
                                                                paint




                                     Sequence Diagram



Software Engineering Lab., FCU                                                      21
                           Hello, World!




                                 HelloWorld.Class
                                                    hello.java




             hello.html
                                 hello.jpg




Software Engineering Lab., FCU                                   22
                    Activity Diagram




Software Engineering Lab., FCU         23
                            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]
Software Engineering Lab., FCU                                                     24
                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


Software Engineering Lab., FCU                                           25
               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



Software Engineering Lab., FCU                                                  26
                    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




Software Engineering Lab., FCU                                            27
Page 557 UML specification

Software Engineering Lab., FCU   28
                                 Page 564 UML specification

Software Engineering Lab., FCU                           29
                     Use Case Diagram




Software Engineering Lab., FCU          30
                         Use Case Diagram



          Package
                         SimpleWatch



                Actor
                                 ReadTime



                                 SetTime
    WatchUser                               WatchRepairPerson


          Use case
                            ChangeBattery




Software Engineering Lab., FCU                              31
                                    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
         ATM: the client is an actor who can withdraw money from an
          account, transfer money to an account, or check balance of an account




Software Engineering Lab., FCU                                                    32
                                      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
Software Engineering Lab., FCU                                        33
                                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.




Software Engineering Lab., FCU                                                   34
                       Use Case Structure
       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.




Software Engineering Lab., FCU                                                 35
                          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.



Software Engineering Lab., FCU                                                36
                           Passenger




                         PurchaseTicket

            <<extend>>


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


                         Cancel           NoChange


Software Engineering Lab., FCU                                        37
                         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.


Software Engineering Lab., FCU                                                  38
                   Explorative prototypes

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




Software Engineering Lab., FCU              39
                         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 happens?



Software Engineering Lab., FCU                                              40
                       PurchaseMultiCard
                                                  Cancel
                         <<include>>          <<extend>>
      Passenger
                       <<include>>     CollectMoney
                                                 <<extend>>

                  PurchaseSingleTicket
                                                NoChange




Software Engineering Lab., FCU                                41
                         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



Software Engineering Lab., FCU                                                 42
                  A use case is a complete course!!




                                  Input password


              Client
                                   Check Balance



                                 Withdraw Money




Software Engineering Lab., FCU                        43
      Class Diagram – Basic Elements




Software Engineering Lab., FCU         44
                              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.




Software Engineering Lab., FCU                                              45
                                     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)




Software Engineering Lab., FCU                                             46
                                   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




Software Engineering Lab., FCU                                               47
                          Parameterized Class

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




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

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




Software Engineering Lab., FCU                                   48
                               Abstract Class

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

                              GeomFigure
                              {abstract}




         Triangle                Circle              Rectangle




Software Engineering Lab., FCU                                   49
                                 Utility Class

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

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




Software Engineering Lab., FCU                           50
                                   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)



Software Engineering Lab., FCU                                                 51
                                   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}




Software Engineering Lab., FCU                                                  52
                                    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.


Software Engineering Lab., FCU                                                             53
                             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




Software Engineering Lab., FCU                                               54
                          Object Diagram




Software Engineering Lab., FCU             55
                                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



Software Engineering Lab., FCU                                                  56
                                Interface class

        Realization relationship


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




                   String

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


Software Engineering Lab., FCU                                              57
                                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




Software Engineering Lab., FCU                                                58
                              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
 Software Engineering Lab., FCU                                                           59
                                 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

Software Engineering Lab., FCU                                   60
                                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}




Software Engineering Lab., FCU                                                    61
                                 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




Software Engineering Lab., FCU                                                  62
                                       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}




Software Engineering Lab., FCU                                                     63
          Class Diagram - Association




Software Engineering Lab., FCU          64
                      Generalization/Specialization


                                  Button




                  CancelButton                ZoneButton



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




Software Engineering Lab., FCU                                               65
                               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




Software Engineering Lab., FCU                                           66
                           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
Software Engineering Lab., FCU                                        67
                                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
                                                                      scale
   Reason for overriding:                                            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

Software Engineering Lab., FCU                                                       68
                             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.
Software Engineering Lab., FCU                                            69
                                 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


Software Engineering Lab., FCU                                          70
                          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

Software Engineering Lab., FCU                                 71
                               Associations
    recursive association

                             Employee
                             name                   clerk
                             staffNo                *
                             roomNo

                                 manager 1


    qualified association

              Directory                     File    Unqualified
                                        fileName


              Director    file name          File     Qualified
              y

Software Engineering Lab., FCU                                    72
                              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}


Software Engineering Lab., FCU                                               73
                      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




Software Engineering Lab., FCU                                                 74
                Attributed Associations Example

    A route connect two city


                  City
                  name              connect
                                    1

                            1



                                 route
                                 path
                                 search




Software Engineering Lab., FCU                    75
                          N-ary Associations



                 project                 Language



                               person




                project       Manager   Language



                               person



Software Engineering Lab., FCU                      76
                                  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




Software Engineering Lab., FCU                                                77
                               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


Software Engineering Lab., FCU                                              78
                                   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.




Software Engineering Lab., FCU                                                            79
                               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

Software Engineering Lab., FCU                                                    80
           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.



Software Engineering Lab., FCU                                                  81
                                          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
Software Engineering Lab., FCU                                                                    82
                   Ches s

                name                                  Ches sBoard
                status
                side                                   size
                                                       bgCo lor
                eat
                move
                j ump                             pl ayboard   1



                         select/move/eat

                                                          1
                   Player                                 Ga me
                                     wi n/l ose
                name            2                     status
                side
                status                                start
                                                      clo se


Software Engineering Lab., FCU                                      83
                  Ches s

 +CLOSED:i nt=0
                                                                          Ches sBoard
 +OPENED:i nt=1
 +SELECT ED:int=2
                                                             -rowCount:i nt
 +DIED:i nt=3
                                                             -co lumnCount:int
                                                             -ch essCou nt:int
 +open():voi d
 +unSelect():voi d
                                          32   contain   1   +getChess(l oc:i nt):Chess
 +sele ct():void
                                                             +canEa t(c1:Ch ess,c2:Che ss):bool ean
 +canEa t(c:Che ssBoard.Chess):boolea n
                                                             +canMove(c:Chess,newLoc:i nt):boole an
 +eatChess(c:ChessBoard.Ch ess):voi d
                                                             +moveTo(c:Ch ess,newLoc:int):void
 +sele cted():bool ean
                                                             +i sVacancy(l oc:i nt):boolean
 +moveTo(x:i nt):voi d
                                                             +i sNeighb or(a:i nt,b:int):bool ean
 +canJump():boolea n
                                                             +canJump(a :i nt,b:i nt):boole an
                                                             +generateChesses():voi d
  weig ht:int
  location:i nt
  name:Stri ng
  si de:int
  statu s:int




    You construct a class diagram incrementally
Software Engineering Lab., FCU                                                                   84
                Interaction Diagram




Software Engineering Lab., FCU        85
                             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.

Software Engineering Lab., FCU                                                     86
                           Sequence Diagram

                                 Object
                    :SimpleWatch           :LCDDisplay             :Time
    :WatchUser

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

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



                                 Message
          Activation


Software Engineering Lab., FCU                                             87
              Sequence Diagrams: Nested Messages



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


                                                  price
                                                displayPrice(price)
    pickupChange()


     pickUpTicket()
                                                    Dataflow


Software Engineering Lab., FCU                                                  88
                         Sequence Diagram




Software Engineering Lab., FCU              89
                         Sequence Diagram




Software Engineering Lab., FCU              90
                         Sequence Diagram




Software Engineering Lab., FCU              91
                                 Open a chess


                  Chess player




           Moving from user view to system view


Software Engineering Lab., FCU                    92
                          app
                       ChessApp
                                                                                       System view:
      player-1
                                                   cb
                                                                                       Interaction in Chess program
                             1: new            ChessBoard


                                                                                   chesse s
                                                         1.1:*[1..32] //new         Chess

                                             cre ate 32 ch esses o n the
                                             board

                                                                                                         buttons
                             2:*[1..32] //n ew                                                           JButton

                                              cre ate a b utton for each cell

            3: press

                                                                                3.1: acti onPerformed //play


                                  3.1.1: loc:=getLocation(button) //Àò±o button ªº¦ì¸m

                             3.1.2:[l oc ¤W¦³´Ñ¤l ] chess:=getChess(l oc) //Àò±o¬Û¹ïÀ³ªº´Ñ¤l




                             3.1.3: status:=getStatus //Àò±o chess ªºª¬ºA




                             3.1.4:[che ss is CLOSED] open //open


                             3.1.5: setText(chess.getName()) //show chess name




Software Engineering Lab., FCU                                                                                        93
                          Collaboration Diagram

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




Software Engineering Lab., FCU                                         94
                  Statechart Diagram




Software Engineering Lab., FCU         95
                           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
Software Engineering Lab., FCU                                         96
                                Statechart Diagram




                          entry/op2                    entry/op6        op6
                  op1
                           do/op3                       do/op7
          event/action   AnEvent/op4   event/action   AnEvent/op8   event/action
                           exit/op5                     exit/op9

  initial state                                                            final state
                                        Transition




Software Engineering Lab., FCU                                                           97
                        Generalization of states



                   A              B                  A                 B
                                            =


                         C                                   C




                                                          push R
                 Transition
                                                Neutral              Reverse
                                                        push N
                                      push F          push R

                 Forward          upshift                  upshift
                         First                  Second                 Third
                       stop      downshift                downshift




Software Engineering Lab., FCU                                                 98
                             Statechart Diagram

        Aggregation of states

                             X

                                                    Y                 A



                                 Z                                    B


                                       Accelerator                          Brake
                                                   OFF                          OFF
                                     accelerator


                                                        accelerator
                                                        depress




                                                                      release
                    Transition




                                                                                     brake
                                                                                     depress
                                                                      brake
                                     release




                                                   ON                           ON


Software Engineering Lab., FCU                                                                 99
      When you chess board receive a message, what does it do?


                                                     red_side


                                     selected                      unsel ected

                                                                                  al l black chesses are die d
     [fi rst open is black]


      cre ated                                    move or e at

                                                                                  al l red chesses are di ed
                                                    bl ack_si de
        [fi rst open is red]
                                       selected                     unsel ected




                               State modeling of the ChessBoard object



Software Engineering Lab., FCU                                                                                 100
                Architecture Diagram




Software Engineering Lab., FCU         101
                                                  <<Category>>
                      <<Framework>>
     <<interface>>                                    User
                         Widgets
                                                    Interface


                                                         <<proxy>
                      <<Framework>>               << Category >>
                                                                    << Category >>
     <<control>>          Control                    Machine
                                                                     Instructions
                        Command                       tools




                      << Category >>              << Category >>
    <<persistence>>
                         Comms                      Persistence




                                       << Category >>
                                         Operating
                                           System



Software Engineering Lab., FCU                                                       102
                                                  BPEL4WS            BPEL4WS            Message
                        : Service Developer                                                                              :
                                                                                                       : Service Provision Service Delivery
                                                 Authoring Tool    Excution Engine      Dispatcher

                                  execute subsystem

                                                  create an empty service


                                                                    query services
                                                                                                        query services
                                                                                                         query result
                                                                                         retrieve service description
                                                                                             service description
                                                                  service description
                                     show interface



  Each one is a sub-system
                                model business process

                                  show process model

                                     deploy service

                                              generate deployment documents

                                                          deploy service


                                                             response
                                       response


                                                                                        Validate your architecture

                                        Moving from user view to architecture view
Software Engineering Lab., FCU                                                                                                                103
             Implementation Diagram




Software Engineering Lab., FCU        104
                           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




Software Engineering Lab., FCU                                   105
                           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,


Software Engineering Lab., FCU                                                   106
                        Component Diagram




Software Engineering Lab., FCU              107
                       Modeling source code




Software Engineering Lab., FCU                108
                 Modeling an Executable Release




Software Engineering Lab., FCU                    109
                   Modeling a physical database




Software Engineering Lab., FCU                    110
                         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




Software Engineering Lab., FCU                                           111
                       Deployment Diagram


                                            node




                                                   component
                   dependency




Software Engineering Lab., FCU                                 112
                       Deployment Diagram




Software Engineering Lab., FCU              113
                      Putting Together




Software Engineering Lab., FCU           114
                  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

                        Refer to our SIMCom Example Physical
               Conceptual

Software Engineering Lab., FCU                                             115
                          Generic Approach to OO Development
   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
                   Additional FCU
Software Engineering Lab., process, if any                                                                116

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:8
posted:8/25/2012
language:English
pages:116