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

Class Diagrams - Download as PowerPoint by 7T34xCyj

VIEWS: 54 PAGES: 140

									Object Oriented Development
  Object and Class

                                                                     B916X5
                                 Item
                                                                     Bolt
                   method               property(변수)                 200       object
                                                                     0
             ItemID를 출력하라                   ItemID
class      Description을 출력하라              Description                S716X10
            Quantity를 출력하라                 Quantity                  Screw
               Item을 인도하라               NumberAllocated              350
               Item을 기록하라                                            300

   class Item                                                                 :
   {                                                         main( )
     private:                                                {
       char itemid;
                                                               Item bolt; // 객체생성
       char description;
                                                               bolt.reportprint(const int * quantity); // 생성된 객체로
       unsigned int quantity;
                                                                                                // 하여금 메소드를 실행
       unsigned int numallocate; // 클래스의 속성 정의                 Item screw;
                                                               screw.record(const char * itemid);
        public;                                              }
          Item( );                                                              :
          ~Item( );
          recordprint(const char* itemid); // 메소드
          reportprint(const int * quantity);              *보충설명 : 개개의 객체들은 클래스에 의해 정의되며
          record(const char * itemid);                            객체들을 생성할 수 있는 템플릿을 만들어
   };                                                             준다. 그러므로 객체는 클래스의 인스탄스이다.
                                                                  또한 클래스는 객체지향 소프트웨어 구축의
                                                                  근원이 된다.
               What is an Object?
• An object is a piece of code that owns things called
  attributes and provides services through methods (also called
  operations or functions). Typically the methods operate on
  private data -- also called instance data or object state -- that
  the object owns.
• A collection of like objects make up a class (sometimes
  called a type). A class acts as a template that describes the
  behavior of sets of like objects.
• Technically speaking, objects are run-time instances of a
  class. An object is identified by a unique ID (also known as
  a reference or handle)
               Robert Orfali, Dan Harkey
               Classes
             A class is a description of a set of
ClassName    objects that share the same attributes,
             operations, relationships, and semantics.
attributes
             Graphically, a class is rendered as a
             rectangle, usually including its name,
operations   attributes, and operations in separate,
             designated compartments.
객체의 동작원리

   객체들은 메시지를 보냄에 의해 서로간에 의사소통을 한다.


                               Amplify               Sound
            Play               Signal                Signal




                   Tape Deck             Amplifier            Speaker

                   Turn On               Turn On              Sound Signal
                   Turn Off              Turn Off
                   Play                  Set Volume
                   Stop                  Amplify Signal
객체의 동작원리
 객체들은 서비스를 윈하는 객체가 서비스를 제공하는 객체에게 메시지를 보냄으로써
  의사 소통을 한다.
 메시지 시그내쳐는 오퍼레이션 시그내쳐에 일치해야 한다. 즉 서비스 제공 객체가
  가지고 있는 오퍼레이션에 맞게 메시지를 보내야 한다는 것이다.
 객체는 오퍼레이션이 일치하는 지 확인하고 난 뒤 다시 서비스를 원하는 객체 즉,
  클라이언트 객체에게 그 결과값을 되돌려준다.

                                  서버 객체
       클라이언트 객체




                    메시지 시그내쳐


                     Play

                               Turn On, Turn Off,
                               Play, Pause, Stop
                                   오퍼레이션
객체의 동작원리


 메시지, 오퍼레이션, 메소드 간에 용어를 구별해야 한다.


                                                 Method:
                 Message:                        Play:
                   Play                          start motor
                                                 start laser
                                                 position laser
                                                 detect light signal
                                                 convert to ...
                                  Operation:
                      Turn On, Turn Off, Play, Pause, Stop

     Message         객체들 사이의 시그날(신호)이다.

     Operation       객체에 의해 제공되는 서비스이다.

     Method          오퍼레이션을 실질적으로 구현한 것이다.
                   Why OO?
• OO Approaches in General
  – OO approaches encourage the use of “modern”
    software engineering technology
  – OO approaches promote and facilitate software reuse
  – OO approaches facilitate interoperability
  – When done well, OO approaches produce solutions
    which closely resemble the original problem
                                            Why OO?
       – When done well, OO approaches result in
         software that is easily modified, extended, and
         maintained
• The Overall OO Approach
       – Traceability improves if an overall OO approach
         is used
       – There is a significant reduction in integration
         problems
       – The conceptual integrity of both the process and
         product improves

source: Motivation for an Object-Oriented Approach to Software Engineering, Edward Berard
Abstraction
                  Abstraction
• Practical Abstraction
Abstraction
                  Abstraction
• Better Abstraction
                 Abstraction
• Mapping abstraction to software
                    Abstraction
• The Progress of Abstraction
  – Assembly language is a small abstraction of the
    machine while imperative languages (C,
    BASIC, and FORTRAN) were abstractions of
    assembly language.
     • These are improvements over assembly language but
       still require you to think in terms of the structure of
       the computer rather than the structure of the problem
       you are trying to solve.
                Abstraction

– In the old model the programmer must establish the
  association between the machine model and the
  model of the problem being solved
– The OO approach provides tools for the programmer
  to represent elements in the problem space
                         Encapsulation
  One of the fundamental principles of object technology is that the internals of an
  object are private to that object and may not be accessed or even examined from
  outside the object
        - David Taylor, Author
        Business Engineering with Object Technology
        (Wiley, 1995)


• Encapsulation means “don’t tell me how you
  do it; just do it”

• An object publishes a public interface that
  defines how other objects can interact with it
 Encapsulation

method   Instance
           Data
method

method

method
                  Encapsulation
• The two main reasons for controlling access to an
  objects functions are:
   – Keep client programmers’ hands off portions they
     shouldn't touch -- parts that are necessary for the
     internal machinations of the object but not part of the
     interface that users need to solve their particular
     problem
   – Allow the library designer to change the internal
     workings of the structure without worrying about how it
     will affect the client programmer.
                 Encapsulation
• Java uses three explicit keywords and one
  implied keyword to set the boundaries in a
  class:
  –   public
  –   private
  –   protected
  –   implied ‘friendly’
                         Inheritance
  Children classes can enhance the behavior of their parents. And if
  parental behavior is enhanced, it is to the benefit of the children.
                - Steve Jobs

• Inheritance is the mechanism that allows you
  to create new child classes -- known as
  subclasses or derived classes -- from existing
  parent classes
• Child classes inherit their parent’s methods
  and data structures
                Inheritance

• You can add new methods to a child’s class or
  override (modify) inherited methods to define
  new class behaviors

• You use inheritance to extend objects; it
  means everything in that object plus ...
                     Inheritance

                             Car




                  Bus                    Truck



This is an example of a typical class hierarchy tree.
Note the arrows point upward from a class to its parent class --
the idea is that classes must know their parent class, but not
vice versa.
                Inheritance

• Some object models support single
  inheritance (Java) while others (C++) support
  multiple inheritance
• Abstract classes are classes whose main
  purpose is to be inherited by others
               Polymorphism

• Polymorphism is a fancy way of saying that
  the same method can do different things,
  depending on the class that implements it

• Objects in different classes receive the same
  message yet react in different ways
                                      Reuse
• Expected Benefits of Reuse
     –   Timeliness
     –   Decreased maintenance effort
     –   Reliability
     –   Efficiency
     –   Consistency
     –   Investment




Source B. Meyer, Object-Oriented Software Construction, 1997
                                    Reuse
• What Should we Reuse?
     –   Personnel
     –   Designs and Specifications
     –   Design Patterns
     –   Source Code
     –   Abstracted Modules




Source B. Meyer, Object-Oriented Software Construction, 1997
            Software Design


   Static Modeling using the
  Unified Modeling Language
            (UML)

                 Material based on
[Booch99, Rambaugh99, Jacobson99, Fowler97, Brown99]
Model Example: Map(1/2)




(a) Picture   (c) Incomplete
                  Representation
Model Example: Map(2/2)




(c) Geomorphology    (d) Geological
    Representation       Representation
             UML Diagrams




Class diagram        Use case diagram
Object diagram       Sequence diagram
Component diagram    Collaboration diagram
Deployment diagram   State diagram
                     Activity diagram
               UML Diagrams
  Structural Diagrams          Behavioral Diagrams
To visualize, specify,    To visualize, specify,
construct, and document   construct, and document
the static aspect of a    the dynamic aspect of a
system                    system

 Class diagram              Use case diagram
 Object diagram             Sequence diagram
 Component diagram          Collaboration diagram
 Deployment diagram         State diagram
                            Activity diagram
Object Oriented Development Process
                             Plan




                                 OOA
        Use Case           Conceptual Class       Sequence
        Diagram               Diagram              Diagram

         Sate Transition
                               Activity Diagram
            Diagram




                                OOD

        Detail Class          Component           Deployment
         Diagram               Diagram             Diagram




             Coding                     Testing
               Classes
             A class is a description of a set of
ClassName    objects that share the same attributes,
             operations, relationships, and semantics.
attributes
             Graphically, a class is rendered as a
             rectangle, usually including its name,
operations   attributes, and operations in separate,
             designated compartments.
             Class Names
              The name of the class is the only required
ClassName     tag in the graphical representation of a
              class. It always appears in the top-most
attributes    compartment.

operations
               Class Attributes

     Person

name : String       An attribute is a named property of a
address : Address   class that describes the object being modeled.
birthdate : Date    In the class diagram, attributes appear in
ssn       : Id      the second compartment just below the
                    name-compartment.
       Class Attributes (Cont’d)
                    Attributes are usually listed in the form:

     Person              attributeName : Type

name : String       A derived attribute is one that can be
address : Address   computed from other attributes, but
birthdate : Date    doesn’t actually exist. For example,
/ age     : Date    a Person’s age can be computed from
ssn       : Id      his birth date. A derived attribute is
                    designated by a preceding ‘/’ as in:

                       / age : Date
        Class Attributes (Cont’d)

      Person
                       Attributes can be:
+ name      : String
                              + public
# address : Address
                              # protected
# birthdate : Date
                              - private
/ age        : Date
                              / derived
- ssn       : Id
              Class Operations

     Person

name : String
address : Address
birthdate : Date
ssn       : Id
       eat          Operations describe the class behavior
      sleep         and appear in the third compartment.
      work
      play
          Class Operations (Cont’d)

                            PhoneBook


newEntry (n : Name, a : Address, p : PhoneNumber, d : Description)
getPhone ( n : Name, a : Address) : PhoneNumber



You can specify an operation by stating its signature: listing the
name, type, and default value of all parameters, and, in the case of
functions, a return type.
                 Depicting Classes
When drawing a class, you needn’t show attributes and operation
in every diagram.


      Person                 Person                 Person
                                              name : String
                                              birthdate : Date
      Person                                  ssn       : Id
       name                  Person                  eat()
      address                                       sleep()
     birthdate                 eat                  work()
                              play                  play()
            Class Responsibilities
A class may also include its responsibilities in a class diagram.

A responsibility is a contract or obligation of a class to perform
a particular service.

                          SmokeAlarm

                         Responsibilities

             -- sound alert and notify guard station
                when smoke is detected.

             -- indicate battery state
                    Relationships
In UML, object interconnections (logical or physical), are
modeled as relationships.

There are three kinds of relationships in UML:

   • dependencies

   • generalizations

   • associations
      Dependency Relationships
A dependency indicates a semantic relationship between two or
more elements. The dependency from CourseSchedule to
Course exists because Course is used in both the add and
remove operations of CourseSchedule.



     CourseSchedule
                                           Course
    add(c : Course)
    remove(c : Course)
Generalization Relationships

Person
          A generalization connects a subclass
          to its superclass. It denotes an
          inheritance of attributes and behavior
          from the superclass to the subclass and
          indicates a specialization in the subclass
          of the more general superclass.
Student
Generalization Relationships (Cont’d)
UML permits a class to inherit from multiple superclasses,
although some programming languages (e.g., Java) do not permit
multiple inheritance.


           Student                    Lecturer




                     TeachingAssistant
       Association Relationships
If two classes in a model need to communicate with each other,
there must be link between them.

An association denotes that link.



    Student                                     Instructor
Association Relationships (Cont’d)
We can indicate the multiplicity of an association by adding
multiplicity adornments to the line denoting the association.

The example indicates that a Student has one or more
Instructors:


    Student                                       Instructor
                                          1..*
Association Relationships (Cont’d)

The example indicates that every Instructor has one or more
Students:



    Student                                     Instructor
                 1..*
Association Relationships (Cont’d)
We can also indicate the behavior of an object in an association
(i.e., the role of an object) using rolenames.




                  teaches         learns from
    Student                                       Instructor
                 1..*                      1..*
Association Relationships (Cont’d)
            We can also name the association.




                        membership
  Student                                       Team
               1..*                    1..*
Association Relationships (Cont’d)
            We can specify dual associations.




                      member of
              1..*                    1..*
  Student                                       Team
              1       president of    1..*
                             Class Diagrams
           School                        Department
                         1    1..*                    1
        1..*                                  1..*



               *                              1..*               1..*
           Student   *               *     Course     *   1..*    Teacher



Every school has one or more (1..*) departments. Each department belongs to
one (1) school.
Every school has many (*) students. Each student can belong to one or more
schools.
Every student takes many courses. Each course is attended by many students.
Every department conducts one or more courses. Each course may be offered
by one or more departments.
Association Relationships (Cont’d)
We can constrain the association relationship by defining the
navigability of the association. Here, a Router object requests
services from a DNS object by sending messages to (invoking
the operations of) the server. The direction of the association
indicates that the server has no knowledge of the Router.




       Router                            DomainNameServer
Association Relationships (Cont’d)
Associations can also be objects themselves, called link classes
or an association classes.

                         Registration
                        modelNumber
                        serialNumber
                        warrentyCode




    Product                                       Warranty
Association Relationships (Cont’d)
            A class can have a self association.




                                                   1
                                                       탑승자
                                              운전자
     next                            운전한다 ▼            0..4 승객

 LinkedListNode
                    previous
Association Relationships (Cont’d)
We can model objects that contain other objects by way of
special associations called aggregations and compositions.

An aggregation specifies a whole-part relationship between an
aggregate (a whole) and a constituent part, where the part can
exist independently from the aggregate. Aggregations are
denoted by a hollow-diamond adornment on the association.


                                             Engine
        Car
                                          Transmission
Association Relationships (Cont’d)
A composition indicates a strong ownership and coincident
lifetime of parts by the whole (i.e., they live and die as a
whole). Compositions are denoted by a filled-diamond
adornment on the association.


                                                Scrollbar
                     1                  1

     Window                                      Titlebar
                     1                  1

                                                  Menu
                     1              1 .. *
                Interfaces

                  An interface is a named set of
                  operations that specifies the behavior
                  of objects without showing their inner
<<interface>>
                  structure. It can be rendered in the
ControlPanel
                  model by a one- or two-compartment
                  rectangle, with the stereotype
                  <<interface>> above the interface
                  name.
             Interface Services


    <<interface>>          Interfaces do not get instantiated.
    ControlPanel           They have no attributes or state.
                           Rather, they specify the services
getChoices : Choice[]      offered by a related class.
makeChoice (c : Choice)
getSelection : Selection
Interface Realization Relationship
                                      A realization relationship
 <<interface>>
                                      connects a class with an
 ControlPanel
                                      interface that supplies its
         specifier                    behavioral specification. It is
                                      rendered by a dashed line with
                                      a hollow triangle towards the
                                      specifier.
       implementation

VendingMachine                키보드                             <<Interface>>
                                                                 타자기
                                          <<realization>>
                        Ctrl()
                        Alt()
                                                            PgUp()
                        PgUp()
                                                            pgDown()
                        PgDown()

                                   • 타자기 의 행동을 실체화한 키보드 클래스
                      Interfaces
inputStream

                                             FileWriter
               {file must not be locked}



                        A class’ interface can also be rendered
   File                 by a circle connected to a class by a
                        solid line.



                     {file must exist}
                                             FileReader
outputStream
                Parameterized Class
A class that serves as a template for other classes, in which the template may
be parameterized by other classes, objects, and/or operations. This class
denotes a family of classes whose structure and behavior are defined
independent of its formal generic parameter(s).
  The mechanism which permits generic classes and the corresponding types
is called genericity. A parameterized class does not directly yield a type, one
has to provide first a list of types, its actual generic parameters, one for
each formal generic parameter.
  Typically, parameterized classes are used as container classes; the terms
generic class and parameterized class are interchangeable. Actually, a
generic class means that it is parameterized by types. Genericity is one of
the main reasons why classes and types are not identical notions, even if
closely connected.
A Class Definition with a Type
         Parameter
         Parameterized Class
              T   A parameterized class or
LinkedList        template defines a family of
                  potential elements.
    T
                  To use it, the parameter must be
     1 .. *
                  bound.

                  A template is rendered by a small
                  dashed rectangle superimposed on
                  the upper-right corner of the class
                  rectangle. The dashed rectangle
                  contains a list of formal parameters
                  for the class.
Parameterized Class (Cont’d)
              T
LinkedList
                  Binding is done with the <<bind>>
                  stereotype and a parameter to supply to
                  the template. These are adornments to
    T
                  the dashed arrow denoting the
     1..*
                  realization relationship.
                  Here we create a linked-list of names
                  for the Dean’s List.
 <<bind>>(Name)

DeansList
•       Using pseudocode with a C++/Java-like syntax, we might declare a List template as follows:
      template <class Element>
    public class List {
             // ...
            public void add(Element e) { ... }
            public Element get(int index) { ... }
            public boolean isEmpty() { ... }
             ... // other List methods
      }

Notice that many of the list operations are defined in terms of a type parameter called Element. Notice also that the template
     doesn’t actually define a class, but it defines a way of creating a class based on a given Element type. In order to use a
     template, we must first create a class based on the template, a process commonly referred to as instantiation, and then
     use the newly created list class for creating list objects. Some languages allow both of these steps to be combined in a
     single statement. Again using a C++/Java like syntax, we might use the above template as follows:

 // instantiate the template List
   class for Customers class CustomerList = new List<Customer>;
// create an object of class
   CustomerList CustomerList custList = new CustomerList();
// create a new customer object
   Customer c = new Customer();
    ... // do something with the customer object
 // put the customer on the list
      custList.add(c)

Many useful classes (e.g., list) and algorithms (e.g., sort) have the property that the types of objects they work with are not
    important to their overall purpose. Templates provide a mechanism which retains all of the benefits of strong typing
    but allow parameterization of classes by types.
                 Enumeration

                   <<enumeration>>
                       Boolean
                        false
                        true


An enumeration is a user-defined data type that consists
of a name and an ordered list of enumeration literals.
                 Exceptions

         <<exception>>      Exceptions can be modeled
           Exception        just like any other class.

         getMessage()       Notice the <<exception>>
        printStackTrace()   stereotype in the name
                            compartment.



<<exception>>        <<exception>>
KeyException         SQLException
             UML Diagrams




Class diagram        Use case diagram
Object diagram       Sequence diagram
Package diagram      Collaboration diagram
Component diagram    State diagram
Deployment diagram   Activity diagram
           Packages

            A package is a container-like element
            for organizing other elements into
            groups.
            A package can contain classes and
Compiler
            other packages and diagrams.
            Packages can be used to provide
            controlled access between classes in
            different packages.
             Packages (Cont’d)
Classes in the FrontEnd package and classes in the BackEnd
package cannot access each other in this diagram.




                           Compiler



                FrontEnd              BackEnd
             Packages (Cont’d)
Classes in the BackEnd package now have access to the classes
in the FrontEnd package.



                           Compiler



                FrontEnd              BackEnd
          Packages (Cont’d)

               We can model generalizations and
  Compiler     dependencies between packages.




JavaCompiler                  Java
            UML Diagrams
Class diagram       Use case diagram
Object diagram      Sequence diagram
Package diagram     Collaboration
Component diagram   diagram
Deployment          State diagram
diagram             Activity diagram
           Component Diagram
Component diagrams are one of the two kinds of diagrams
found in modeling the physical aspects of an object-oriented
system. They show the organization and dependencies
between a set of components.
Use component diagrams to model the static implementation
view of a system.
This involves modeling the physical things that reside on a
node, such as executables, libraries, tables, files, and
documents.
             - The UML User Guide, Booch et. al., 1999
               Component Diagram
path.dll               collision.dll




                                       Here’s an example of a component
                                       model of an executable release.
            driver.dll
            version = 8.1.3.2
                                       [Booch,99]
 IDrive


ISelfTest
              Component Diagram
          signal.h                signal.h               signal.h
          version = 3.5           version = 4.0          version = 4.1

                      “parent”                “parent”



                                                                         signal.cpp
                                          interp.cpp                     version = 4.1
Modeling source code.
[Booch, 99]
                          irq.h                          device.cpp
             UML Diagrams
Class diagram        Use case diagram
Object diagram       Sequence diagram
Package diagram      Collaboration
Component diagram    diagram
Deployment diagram   State diagram
                     Activity diagram
          Deployment Diagram
Deployment diagrams are one of the two kinds of diagrams
found in modeling the physical aspects of an object-oriented
system. They show the configuration of run-time processing
nodes and the components that live on them.
Use deployment diagrams to model the static deployment
view of a system. This involves modeling the topology of the
hardware on which the system executes.
               - The UML User Guide, [Booch,99]
           Deployment Diagram
A component is a physical unit of implementation with well-
defined interfaces that is intended to be used as a replaceable
part of a system. Well designed components do not depend
directly on other components, but rather on interfaces that
components support.
       - The UML Reference Manual, [Rumbaugh,99]

            component
                                  spell-check
              Dictionary                        interfaces
                                  synonyms
               Deployment Diagram
                                    <<database>>
                                                           stereotyped
                                      Account              component


            Transactions   Update              interface

                                                   usage dependency
component

                                            ATM-GUI

 realization dependency
                                            [Rumbaugh,99]
               Deployment Diagram
 server:HostMachine
                          <<database>>

                           meetingsDB    Deployment diagram
                                         of a client-server
            :Scheduler    reservations   system.
<<direct channel>>


 clientMachine:PC                        [Rumbaugh,99]


                         :Planner
       Deployment Diagram
                                                  당뇨병 정보 서비스 Unit Server
                         TCP/IP
                                                           객체 Database


Node들의 연결                                             건강 관리 영역




               생활 건강 정보 서비스 Unit Server

                 객체 Database

                                              <<connection>>
                 건강 관리 영역

   TCP/IP                                            의학 정보 설정
                 생활 건강 정보 서비스
                 Server application                  사용자 설정

                               Interface

 Windows PC                                Node         포함된 객체

    건강정보 서비스
    사용자 전면                 Component

     사용자 인터페이스
     Software Design


Dynamic Modeling using the
Unified Modeling Language
         (UML)
             UML Diagrams
Class diagram        Use case diagram
Object diagram       Sequence diagram
Package diagram      Collaboration
Component diagram    diagram
Deployment diagram   State diagram
                     Activity diagram
                        Use Case
“A use case specifies the behavior of a system or a part of a
system, and is a description of a set of sequences of actions,
including variants, that a system performs to yield an observable
result of value to an actor.”
        - The UML User Guide, [Booch,99]

“An actor is an idealization of an external person, process, or
thing interacting with a system, subsystem, or class. An actor
characterizes the interactions that outside users may have with
the system.”
        - The UML Reference Manual, [Rumbaugh,99]
             Use Case (Cont’d)


                       A use case is rendered as an ellipse
Register for Courses
                       in a use case diagram. A use case is
                       always labeled with its name.
          Use Case (Cont’d)


            An actor is rendered as a stick figure in a
            use case diagram. Each actor
            participates in one or more use cases.



Student
              Use Case (Cont’d)
Actors can participate in a generalization relation with other
actors.




         Student                         Person
    Use Case (Cont’d)

          Actors may be connected to use cases
          only by associations.




                        Register for Courses




Student
                  Use Case (Cont’d)
Here we have a Student interacting with the Registrar and the
Billing System via a “Register for Courses” use case.




                                               Billing System



        Student     Register for Courses



                                               Registrar
          Use Case (Cont’d)

예) 자판기 내용물 공급자와 수금원이 포함된 자판기 시스템의 유스케이스 다이어그램
  “내용물 보충하기” 유스케이스와 “수금하기” 유스케이스의 시나리오에서 공통으로 중복된 보안장치 해제나
  보안장치 설정과 관련된 진행 단계들을 따로 떼어내서 새로운 유스케이스로 만들고 포함 시켰다.



                       자판기 시스템
                음료수사기
  사용자                                                          보안장치 설정
                          <<include>>

               내용물보충하기
                                                 <<include>>
  공급자
                                        <<include>>

                수금하기
                                                               보안장치 해제
  수금원                     <<include>>
         Use Case (Cont’d)

- 포함(Include) – 유스케이스가 다른 유스케이스를 포함하는 관계
     • 여러 유스케이스에서 공통으로 중복되는 시나리오가 있다면 이
       시나리오를 따로 분리하여 새로운 유스케이스로 만들고, 새로만든
       유스케이스를 각 유스케이스 마다 포함 시키면 될 것이다.
     • 사용 하려는 유스케이스가 사용되어지는 유스케이스를 필수적으로
       포함해야 한다.
     • 포함된 유스케이스는 절대로 단독으로 존재할 수 없으며, 전체
       유스케이스의 부분으로만 존재한다.
     • 표현
        – 포함 관계에 있는 유스케이스 사이를 쇄선으로 잇고, 포함되어지는
          유스케이스 쪽에 화살표 머리를 둠.
        – 연결선 위에는 스테레오타입 <<include>> 를 붙여준다.
                                                     II.UML Diagram

             Use Case (Cont’d)
•   Extend 예) 정상적인 흐름에서는 “Place Order” 기본 유스케이스가
    실행되지만 우선 순위(Set Priority)라는 확장점(Extension Point)의 조건을
    만족한다면 “Place Rush Order” 확장 유스케이스가 실행된다.




                    Place Order
         기본유스케이스    Extension Point : Set Priority


                                <<extend>>
                                (Set priority)

        확장유스케이스     Place Rush Order
                                                  II.UML Diagram

           Use Case (Cont’d)
– 확장 (Extend) – 유스케이스와 그 유스케이스를 확장한 확장 유스케이스의
 관계
  • 유스케이스의 시나리오에서, 어떤 조건에 따라 특정한 진행 단계의
    행위(behavior)를 확장하고자, 다른 유스케이스를 참조 하는 것을 말함.
  • 이때 확장 용도로 사용 하기 위하여 참조 되는 유스케이스를 확장 유스케이스라
    함.
  • 확장 유스케이스를 참조하는 유스케이스를 기본(base) 유스케이스라 한다.
  • 확장 유스케이스를 참조하는 시나리오의 특정한 진행단계를 확장 포인트(extend
    point)라 한다.
  • 즉, 특별한 조건에서만 수행되는 부 흐름부를 모형화 한 것으로, 어떤 조건이
    부합되어야만 포함되는 유스케이스를 표현 함.
  • 따라서, 포함 관계의 유스케이스와 달리 확장 유스케이스와의 관계는
    선택적이다.
  • 확장된 유스케이스는 절대로 단독으로 존재할 수 없다  단지, 기본
    유스케이스에서 특정한 시나리오의 진행 단계의 확장이기 때문.
  • 표현
      –   두 유스케이스 사이를 쇄선으로 잇고, 기본 유스케이스쪽에 화살표 머리를 둔다.
      –   연결선 위에는 스테레오타입 <<extend>>를 붙여준다.
              Use Case사이의 Relationship

    • 예제




include relationship : 사용자 인증 Use Case의 행위는 반드시 주문처리 Use Case이 행위
                       에 포함되어야 한다.
extend relationship : 주문처리의 행위는 급한 주문 처리 Use Case의 행위의 어떤 조건에 부
                       합되었을 때 포함되어진다.
Generalization relationship : 패스워드 검색 Use Case의 행위는 사용자 인증 Use Case의
                              행위를 상속 받아서 사용한다.
     Actor와 Use Case사이의 Relationship과 의미




Relationship은 Association Relationship으로 실선으로 표시한다
Association Relationship은 Actor와 Use Case사이의 관계로 Actor와
  Use Case간의 정보교환을 의미한다
             Actor 추출법

우리는 시스템과의 상호작용을 하는 Actor를 몇 가지
 질문을 통해 그 대상을 Actor로 간주할 수 있다.

1)   시스템의 주기능을 사용하는 사람은 누구인가?
2)   누가 시스템으로부터 업무 지원을 받는가?
3)   누가 시스템을 운영, 유지 보수하는가?
4)   시스템과 정보를 교환하는 외부 시스템은 무엇인가?
5)   시스템이 내어놓은 결과물에 누가 관심을 가지는가?
           Use Case 추출법
Actor와 같이 Use Case또한 여러가지 질문을 통해 찾아낼 수 있다.

1) Actor가 요구하는 시스템의 주요 기능은 무엇인가?
2) Actor가 시스템의 어떤 정보를 수정, 조회, 삭제, 저장하는가?
3)시스템이 Actor에게 주는 어떠한 Event가 있는가?,
  Actor가 시스템에 주는 어떠한 Event가 있는가?
4)시스템의 입력과 출력으로 무엇이 필요한가? 그리고 입력과 출력이
   어디에서 오고 어디에로 가는가?
5)시스템의 구현에서 가장 문제가 되는 점은 무엇인가?
             UML Diagrams
Class diagram        Use case diagram
Object diagram       State diagram
Package diagram      Sequence diagram
Component diagram    Collaboration diagram
Deployment diagram   Activity diagram
                  State Machine

“The state machine view describes the dynamic behavior of
objects over time by modeling the lifecycles of objects of each
class. Each object is treated as an isolated entity that
communicates with the rest of the world by detecting events and
responding to them. Events represent the kinds of changes that
objects can detect... Anything that can affect an object can be
characterized as an event.”

       - The UML Reference Manual, [Rumbaugh,99]
                     State Machine
An object must be in some specific state at any given time during
its lifecycle. An object transitions from one state to another as the
result of some event that affects it.
You may create a state diagram for any class, collaboration,
operation, or use case in a UML model .
There can be only one start state in a state diagram, but there may
be many intermediate and final states.
                   State Machine
•   상태 다이어그램(State Diagram) 이란?
    –   사건이나 시간에 따라 시스템 객체의 상태 변화를 표현한 그림.
    –   “단일 객체”의 상태를 나타냄.
    –   시스템의 변화를 잡아내기 위하여 사용.
    –   분석가, 설계자, 개발자 들이 시스템내의 객체 행동을 이해하는데 큰 도움을 줌.
•   표현
    –   상태의 표현   : 모서리가 둥근 사각형으로 표현
    –   상태 전이의   시작점 : 속을 칠한 원으로 표현.
    –   상태 전이의   종료점 : 속을 칠한 원을 둘러싼 원으로 표현
    –   상태 전이선   : 화살표 머리가 달린 실선



                    상태정보



         시작점                   종료점
                    State Machine
•   상태 아이콘에 넣는 정보
    – 이름, 속성, 오퍼레이션의 세 영역으로 나누어 상세한 정보 넣을 수 있다.
       • 이름 – 상태 이름(필수)
       • 속성 – 상태 변수(옵션). 타이머나 카운터처럼 상태 진행에 도움을 주는 데이터.
       • 오퍼레이션 – 활동(Activity – 옵션). 사건(event)과 동작(action)으로 이루어짐.
       • 동작(event[guard]/action) – 전이(transition)와 연관. 빨리 발생하는 프로세스로
         간주되며 인터럽트를 받지 않는다.
       • 활동(do/activity) – 상태(State)와 관련, 오래 지속될 수 있으며 사건(event)이 인터럽터를
         일으킬 수도 있다.



           상태 이름
                                 활동
                                 자주 쓰이는 세가지
           상태 변수들
                                 진입(entry) – 시스템이 상태로 들어갈 때 일어남
                                 탈출(exit) – 시스템이 상태에서 빠져나올 때 일어남
            활동들                  활동(do) – 시스템이 상태 안에 있는 동안 일어남
                       State Machine
•   예) 팩스 기계의 상태 정보의 표현과 전이




                  전송
                                            대기(Idle)
                  (Faxing)

        Date = 현재날짜               Date = 현재날짜
        Time = 팩스 전송 시작 시간        Time = 현재 시간
        Phone Number = 소유주 전화번호   Phone Number = 소유주 전화번호
        Owner = 소유주 이름            Owner = 소유주 이름


        Entry / 수신팩스번호 입력         Entry / 전송완료
        Exit / 전송완료               Exit / 전송 시작
        Do / 날짜 붙이기               Do / 날짜 보이기
        Do / 시간 붙이기               Do / 시간 보이기
        Do / 송신측 전화번호 붙이기
        Do / 소유주 이름 붙이기
        Do / 페이지 매기기
                     State Machine
•   상태 전이 선에 추가 되는 정보 : 사건과 동작
    – 추가되는 정보 : 전이가 일어나는 원인을 제공하는 사건(촉발사건-trigger event)과
      실제로 수행되어 상태변화를 일으키는 연산(동작-action).
    – 사건과 동작은 상태 전이 선에 가깝게 붙여준다.
    – ‘/’ 를 사용하여 사건[조건]/동작을 구분 시켜준다.
    – 활동을 종료했기 때문에 일어나는 전이  촉발없는 전이(triggerless transition)라
      함.
    – 예) GUI의 상태 다이어그램




      스위치 ON                       스위치 Off
                   초기화       작동               종료
      / 전원공급()                     / 전원중단()


                 Do / 부팅
                       State Machine
•   상태 전이 선에 추가되는 정보 : 전이 조건
    –   어떤 조건에 따라 상태가 전이 될 때.
    –   조건에 따른 상태 전이의 분기가 일어날 때.
    –   ‘[ ]’ 를 사용하여 조건(Guard)을 명시함.
    –   예) 앞의 GUI 예에서 어떤 조건을 만족하면 스크린세이버가 작동하는 상태로 됨




        스위치 ON                                  스위치 Off
                     초기화                  작동               종료
        / 전원공급()                                / 전원중단()


                   Do / 부팅


                             [시간초과 했다면]        키누르기 또는 마우스움직이기/

                                     화면보호기
                                          작동
•   하위상태 : 상태 안에 상태가 있을 때, 안에 있는 상태를 말함.
•   순차적 하위 상태
    – 하위 상태의 전이가 순차적으로 이루어 짐.
    – 예) 앞의 GUI 예제에서 [작동] 상태의 하위 상태 전이를 나타낸다. 즉, [작동]
      상태인 동안 사용자의 입력을 화면에 표현 하는 하위 상태들의 전이 과정을 표현한
      것이다.



                           작동


             사용자         사용자        사용자 입력을
                    입력
             입력대기        입력을 등록     화면에 나타냄
State Machine
 start state               final state

   simple state

   concurrent composite state




           sequential composite state
                            State Machine
            download course offerings     downloading
unscheduled
                                                make a course selection

                                            selecting



    make a different selection                  verify selection

                                            verifying
                                                                   select another course


                                               check schedule
            sign schedule
                                        checking schedule

scheduled
                   State Machine

                    start


다음 아이템을 가져온다.
[아이템이 모두 점검되지 않았다]                        [모든 아이템이 점검 되었고,
                               점검         모든 아이템이 유효하다.]                    처리
                            행동/ 아이템을                               행동/ 운반 준비를
                                점검한다.                                  한다.

                                        아이템을 받는다.
                                        [모든 아이템이 유효하다.]
          [모든 아이템 점검되었고,                                         activity
          어떤 아이템은 재고품이 없다.]                                                  배달


 Self-transition
                                                    transition

                               대기                                           배달
 아이템을 받는다.
 [어떤 아이템은 재고품이 없다.]
                                            State
             UML Diagrams
Class diagram        Use case diagram
Object diagram       State diagram
Package diagram      Sequence diagram
Component diagram    Collaboration diagram
Deployment diagram   Activity diagram
               Sequence Diagram
A sequence diagram is an interaction diagram that emphasizes
the time ordering of messages. It shows a set of objects and the
messages sent and received by those objects.

Graphically, a sequence diagram is a table that shows objects
arranged along the X axis and messages, ordered in increasing
time, along the Y axis.

       - The UML User Guide, [Booch,99]
                   Sequence Diagram

                             registration               schedule                  available
                                 form                     form                     courses
Jon : Student
                1:enter id
                                    2:validate id




        3:enter current semester


        4:create new schedule
                                            5:display
                                                                   6:get course
                Sequence Diagram
an Order Line

                An object in a sequence diagram is rendered
                as a box with a dashed line descending from it.
                The line is called the object lifeline, and it
                represents the existence of an object over a
                period of time.
                      Sequence Diagram
an Order Line         a Stock Item
                                     Messages are rendered as horizontal
                                     arrows being passed from object to
            check()
                                     object as time advances down the
       [check = “true”]
          remove()                   object lifelines. Conditions ( such as
                                     [check = “true”] ) indicate when a
                                     message gets passed.

                                                          Simple Message

                                                          Synchronous Message


                                                          Asynchronous Message
                      Sequence Diagram
an Order Line         a Stock Item




            check()

       [check = “true”]
                                     Notice that the bottom arrow is different.
          remove()                   The arrow head is not solid, and there is
                                     no accompanying message.


                                     This arrow indicates a return from a
                                     previous message, not a new message.
                       Sequence Diagram
        an Order       a Order Line




               * prepare()
                                      An iteration marker, such as * (as
                                      shown), or *[i = 1..n] , indicates
Iteration
                                      that a message will be repeated as
marker                                indicated.
an Order Entry
   window
                     an Order    an Order Line         a Stock Item               [Fowler,97]
         prepare()
                                                                      Condition
                           * prepare()
Object
                                             check()

         Message                         [check = “true”]
                                            remove()          needsToReorder()
                          Iteration
                                                                                  Self-Delegation
                                             Return
                                                              [needsToReorder = “true”]
                                                             new
                                                                     A Reorder
                                                                       Item
                                         [check = “true”]
                                                                                     A Delivery
                                               new
                                                                                        Item


                                                              Creation
           Sequence Diagram
Other symbols:
• Return - dashed line with arrow head (         )
• Object deletion - symbol X
• Asynchronous message - line with half-
      arrowhead

Two control information:

     i) Condition - message is sent when the
                       condition is true.
     ii) Iteration - message is sent many times to
                       multiple objects.
                 Sequence Diagrams
 Emphasizes the time ordering of messages.
                                  Objects

       b: Bank                                                    w: Window
                 <<create>>
                                     a: Account

                 transaction( )                    getInputs( )

Time

                                                  update( )


                                                    display( )


                 closeWindow( )
             UML Diagrams
Class diagram        Use case diagram
Object diagram       State diagram
Package diagram      Sequence diagram
Component diagram    Collaboration diagram
Deployment diagram   Activity diagram
          Collaboration Diagram
A collaboration diagram emphasizes the relationship of the
objects that participate in an interaction. Unlike a sequence
diagram, you don’t have to show the lifeline of an object
explicitly in a collaboration diagram. The sequence of events are
indicated by sequence numbers preceding messages.
Object identifiers are of the form objectName : className, and
either the objectName or the className can be omitted, and the
placement of the colon indicates either an objectName: , or a
:className.
       Collaboration Diagram

• Collaboration diagram의 경우 객체들 사이의 행위를 나
타내는 것은 sequence diagram과 동일하다. 차이점은
sequence diagram이 시간에 따른 행위의 흐름에 역점을
두고 표현하지만 collaboration diagram의 경우 객체들 사
이의 정적인 구조에 더 역점을 두고 있다.
• Sequence diagram과 collaboration diagram이 모두 객
체들 사이의 상호작용(interaction)을 나타내므로
interaction diagram이라 통칭하기도 한다. 이런
interaction diagram이 필요한 경우는 하나의 use case내
부에 포함된 객체들 사이의 행위를 보일 때 필요하다. 하
지만 객체 상호간의 관계에 역점을 두었기 때문에 객체
하나의 행위를 정확하게 표현하기에는 부적절한다
          Collaboration Diagram
•   협력 다이어그램이란?
    – 객체 사이의 연관 관계 뿐만 아니라, 각 객체들이 주고 받는 메시지들을 공간에
      따라 배열 한 것.
    – 객체 다이어그램의 확장으로 볼 수 있다.
•   순차 다이어그램과의 유사점 및 차이점
    – 유사점 : 순차 다이어그램처럼 객체들 사이의 교류를 보여준다.  따라서, 순차와
      협력 다이어그램의 상호 변환이 쉽다.
    – 차이점 :
         • 순차 다이어그램: 객체간의 교류를 시간의 순서에 초점을 두어 표현.
         • 협력 다이어그램 : 공간에 따라 배열시킴  교류를 수행하는 객체들의 전체적인 조직과
           상황(Context)에 초점을 맞춤.
•   표현
    – 두 객체 사이를 연관 선으로 연결.
    – 연관선 위에 메시지가 전달되는 객체 쪽으로 화살표 방향을 가진 선을 긋는다.
    – 메시지의 의미는 “메시지를 받는 객체로 하여금 어떤 오퍼레이션을 실행하라”
      이다.
    – 메시지의 끝에 ‘()’ 붙임으로써 매개 변수를 넣을 수 있도록 함.
          Collaboration Diagram
: Order Entry Window                   Object
                                                     Sequence Number

           1: prepare()                Message

      : Order                   Self-Delegation
                                                     5: needToReorder()

           2*: prepare()   3: check()
                           4: [check == true] remove()
    : Order Line                                  : Stock Item

           7: [check == true] new                                6: new

   :Delivery Item                                 :Reorder Item

                                                                      [Fowler,97]
               Collaboration Diagram
•   예제) “음료수 뽑기” 예에서 “액수가 맞지 않는 경우”를 고려해 보자. 물론,
    이전의 순차 다이어그램을 참고하면서 보도록 한다. 만들 협력 다이어그램은
    다음이 조건을 처리해야 한다.
    –    1. 사용자가 음료수 가격보다 많은 돈을 투입한 경우.
    –    2. 음료수 자판기가 충분한 거스름 돈을 가진 경우.
    –    3. 음료수 자판기가 충분한 거스름 돈을 가지지 않은 경우.




                                insert(input, selection)

                                            :프론트
                    User
                                                             1 : add(input, selection)

           4 : deliver(selection)
                                                [잔돈이있다면] 3.2 : return(잔돈)


                        :디스펜서                                  :금전들록기                [input > price]
                                      [input = price] 2.1 : deliver(selection)       2.2 : 잔돈유무검사(input, price)
                                      [잔돈이있다면] 3.1 : deliver(selection)

        각 단계의 소수점 숫자의 표현 : 동일한 단계에서 여러 시나리오가 중첩(nesting) 됨을 나타냄.
        Collaboration Diagram
•   while 문을 표현 : *[조건]
•   객체의 생성 : 객체를 생성하는 메시지 앞에 스테레오타입 <<create>>
    붙인다.
•   여러 객체로 메시지 전송하기
    – 메시지를 받는 객체 사각형을 사선 방향으로 쌓는다.
    – 객체로 전송되는 메시지에는 ‘*’ 가 붙은 대괄호 조건문을 붙여준다.
    – 만약, 메시지 전송의 순서가 필요하다면, 조건 문에 1… n 처럼 순서의 의미를
      표시함.
    – 예제) 은행원이 여러 창구에 늘어선 고객들을 순서대로 맞아 서비스를 한다.



               :은행원


                      *[순번 = 1...n] 1 : 서비스()




                              :고객
          Collaboration Diagram
            Sequence Diagram


Both a collaboration diagram and a sequence diagram derive
from the same information in the UML’s metamodel, so you can
take a diagram in one form and convert it into the other. They
are semantically equivalent.
             UML Diagrams
Class diagram        Use case diagram
Object diagram       State diagram
Package diagram      Sequence diagram
Component diagram    Collaboration diagram
Deployment diagram   Activity diagram
               Activity Diagram
An activity diagram is essentially a flowchart, showing the
flow of control from activity to activity.
Use activity diagrams to specify, construct, and document the
dynamics of a society of objects, or to model the flow of
control of an operation. Whereas interaction diagrams
emphasize the flow of control from object to object, activity
diagrams emphasize the flow of control from activity to
activity. An activity is an ongoing non-atomic execution
within a state machine.
       - The UML User Guide, [Booch,99]
         Activity Diagram
• 업무과정(Business Process)를 표현하거나
  오퍼레이션(Operation)의 알고리즘을 효과적으로 나타내는데
  유용하게 사용된다.

• Flowchart와 상당히 흡사하다.
• State Diagram의 확장으로 볼 수 있다.
• 해당 활동내의 처리가 끝나면 그 다음의 활동으로 자동적으로
  옮겨진다.
  Activity Diagram

              시작 표기


        활동    활동 표기

진행 표기
              분기 표기



  활동         활동




              종료 표기
            Activity Diagram
•   동시경로




                 활동
                               동시에 실행 되었
                               다가 하나로 모이
    Fork                       는 두개의 처리 경
                               로로 활동 전이를
                               분리해야 할 경우
           활동1        활동2      굵은 선을 긋고, 이
                               선을 기준으로 하
    Join                       여 처리 경로를 그
                                려주면 된다.
               Activity Diagram
•   예제1) 짜장면 집에서 주문하는 과정.

    1.   손님이 메뉴에서 음식을 고른다.
    2.   웨이터를 부르고, 주문한다.
    3.   웨이터는 주방장에게 주문사항을 알린다.
    4.   만약 주문한 음식의 재료가 떨어졌으면 주방장은 웨이터에게 알린다.
    5.   웨이터는 손님에게 알린다.
    6.   다시 1 번부터 반복한다.
                Activity Diagram
• Activity Diagram




          메뉴에서 음식 고르기



           웨이터 호출 및 주문          손님에게 알림



            주방장에게 알림

                     [음식의 재료가 떨어졌다]
                                웨이터에게 알림
        [만들 수 있다]
              Activity Diagram
•   활동 다이어그램에 역할(role)을 표시함으로써 처리 과정에 속해있는 각
    활동의 책임이 누구에게 있는지를 나타낼 수 있다.



           손님           웨이터               주방장

       메뉴에서 음식 고르기



        웨이터 호출 및 주문   주방장에게 알림
                                               [만들 수 있다]

                              [음식의 재료가 떨어졌다]


                                      웨이터에게 알림
                      손님에게 알림
                                         Receive
                                          Order                                          [Fowler,97]

                                                                 Multiple Trigger


                                                          for each line
                                                   *     item on order

                                                    Check
    Cancel                     Authorize
                                                     Line
    Order          [failed]
                               Payment
                                                     Item

                                     [succeeded]        [in stock]


                                                   Assign to
                                                    Order


Synchronization Condition

                                                               [need to
                                                               reorder]        Reorder
                                                                                Item
               [stock assigned to
                all line items and
             payment authorized]

                                 Dispatch
                                  Order
                        References
[Booch99] Booch, Grady, James Rumbaugh, Ivar Jacobson,
The Unified Modeling Language User Guide, Addison Wesley, 1999

[Rambaugh99] Rumbaugh, James, Ivar Jacobson, Grady Booch, The Unified
Modeling Language Reference Manual, Addison Wesley, 1999

[Jacobson99] Jacobson, Ivar, Grady Booch, James Rumbaugh, The Unified
Software Development Process, Addison Wesley, 1999

[Fowler, 1997] Fowler, Martin, Kendall Scott, UML Distilled
(Applying the Standard Object Modeling Language),
Addison Wesley, 1997.

[Brown99] First draft of these slides were created by James Brown.

								
To top