UML(Unified Modeling Language)

Presentation on theme: "UML(Unified Modeling Language)"— Presentation transcript:

1 UML(Unified Modeling Language)

2 Tutorial contents UML basic Use case diagram Class diagram
Sequence diagram, Collaboration diagram State Machine diagram Activity diagram Component diagram Deployment diagram

3 UML Diagram – What is UML?
The Unified Modeling Language (UML) is a standard  language for Specifying Visualizing Constructing Documenting Business Modeling Communications

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

5 Model Example: Map(2/2) (c) Geomorphology Representation
(d) Geological Representation

6 Different Views Users Analyzers Designers

7 UML: First Pass You can model 80% of most problems by using about 20 % UML We only cover the 20% here

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

9 History of UML

10 Object Oriented Development Process
Plan OOA Use Case Diagram Conceptual Class Diagram Sequence Diagram Sate Transition Diagram Activity Diagram OOD Detail Class Diagram Component Diagram Deployment Diagram Coding Testing

11 Use Case Diagrams Passenger PurchaseTicket
Used during requirements elicitation to represent external behavior Actors represent roles, that is, a type of user of the system Use cases represent a sequence of interaction for a type of functionality; summary of scenarios The use case model is the set of all use cases. It is a complete description of the functionality of the system and its environment Passenger PurchaseTicket

12 Use case diagram Actor overview the usage requirements
presentations project stakeholders "the meat" of the actual requirements Actor: An actor is a person, organization, or external system that plays a role in one or more interactions with your system Online C2C shopping

13 Use case diagram Actor overview the usage requirements
presentations project stakeholders "the meat" of the actual requirements Use case: A use case describes a sequence of actions that provide something of measurable value to an actor and is drawn as a horizontal ellipse Use case Online C2C shopping

14 Use case diagram System boundary Actor overview the usage requirements
presentations project stakeholders "the meat" of the actual requirements System boundary: indicates the scope of your system.  Anything within the box represents functionality that is in scope and anything outside the box is not Use case Online C2C shopping

15 Actors An actor models an external entity which communicates with the system: User External system Physical environment An actor has a unique name and an optional description. Examples: Passenger: A person in the train GPS satellite: Provides the system with GPS coordinates Passenger

16 Use Case A use case represents a class of functionality provided by the system as an event flow. A use case consists of: Unique name Participating actors Entry conditions Flow of events Exit conditions Special requirements PurchaseTicket

17 Use Case Diagram: Example
Name: Purchase ticket Participating actor: Passenger Entry condition: Passenger standing in front of ticket distributor. Passenger has sufficient money to purchase ticket. Exit condition: Passenger has ticket. Event flow: 1. Passenger selects the number of zones to be traveled. 2. Distributor displays the amount due. 3. Passenger inserts money, of at least the amount due. 4. Distributor returns change. 5. Distributor issues ticket. Anything missing? Exceptional cases!

18 The <<extends>> Relationship
<<extends>> relationships represent exceptional or seldom invoked cases. The exceptional event flows are factored out of the main event flow for clarity. Use cases representing exceptional flows can extend more than one use case. The direction of a <<extends>> relationship is to the extended use case Passenger PurchaseTicket <<extends>> OutOfOrder <<extends>> Cancel <<extends>> <<extends>> TimeOut NoChange

19 The <<includes>> Relationship
Passenger <<includes>> relationship represents behavior that is factored out of the use case. <<includes>> behavior is factored out for reuse, not because it is an exception. The direction of a <<includes>> relationship is to the using use case (unlike <<extends>> relationships). PurchaseMultiCard PurchaseSingleTicket <<includes>> CollectMoney <<includes>> NoChange <<extends>> Cancel <<extends>>

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

21 Actor 추출법 우리는 시스템과의 상호작용을 하는 Actor를 몇 가지 질문을 통해 그 대상을 Actor로 간주할 수 있다.
1)   시스템의 주기능을 사용하는 사람은 누구인가? 2)   누가 시스템으로부터 업무 지원을 받는가? 3)   누가 시스템을 운영, 유지 보수하는가? 4)  시스템과 정보를 교환하는 외부 시스템은 무엇인가? 5)  시스템이 내어놓은 결과물에 누가 관심을 가지는가?

22 Use Case 추출법 Actor와 같이 Use Case또한 여러가지 질문을 통해 찾아낼 수 있다.
Actor가 요구하는 시스템의 주요 기능은 무엇인가? 2) Actor가 시스템의 어떤 정보를 수정, 조회, 삭제, 저장하는가? 3)시스템이 Actor에게 주는 어떠한 Event가 있는가?, Actor가 시스템에 주는 어떠한 Event가 있는가? 4)시스템의 입력과 출력으로 무엇이 필요한가? 그리고 입력과 출력이 어디에서 오고 어디에로 가는가? 5)시스템의 구현에서 가장 문제가 되는 점은 무엇인가?

23 Use Cases are useful to…
Determining requirements New use cases often generate new requirements as the system is analyzed and the design takes shape. Communicating with clients Their notational simplicity makes use case diagrams a good way for developers to communicate with clients. Generating test cases The collection of scenarios for a use case may suggest a suite of test cases for those scenarios.

24 Classes A class is a rectangle divided into three parts Class name Class attributes (i.e. data members, variables) Class operations (i.e. methods) Graphically, a class is rendered as a rectangle, usually including its name, attributes, and operations in separate, designated compartments. ClassName attributes operations

25 UML Class Notation Modifiers - : Private + : Public # : Protected
/ : derived Abstract class: Name in italics Person + name : String # address : Address # birthdate : Date / age : Date - ssn : Id

26 Depicting Classes When drawing a class, you needn’t show attributes and operation in every diagram. Person Person Person name : String birthdate : Date ssn : Id eat() sleep() work() play() Person name address birthdate Person eat play

27 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

28 Class Diagram Class diagrams show the classes of the system, their interrelationships (including inheritance, aggregation, and association), and the operations and attributes of the classes. Name Associations Aggregation Generalization Relations Attributes Operations

29 Relationships between Class Diagrams
Lines or arrows between classes indicate relationships Association A relationship between instances of two classes, where one class must know about the other to do its work, e.g. client communicates to server indicated by a straight line( ) or arrow( ) Aggregation An association where one class belongs to a collection, e.g. instructor part of Faculty Indicated by an empty diamond on the side of the collection Composition Strong form of Aggregation Lifetime control; components cannot exist without the aggregate Indicated by a solid diamond on the side of the collection Generalization (Inheritance) An inheritance link indicating one class a superclass relationship, e.g. bird is part of mammal Indicated by triangle pointing to superclass

30 Binary Association Binary Association: Both entities “Know About” each other myB.service(); myA.doSomething(); Optionally, may create an Associate Class

31 Unary Association A knows about B, but B knows nothing about A
Arrow points in direction of the dependency 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)

32 Association: Multiplicity and Roles
student 1 * University Person 0..1 * teacher employer Multiplicity Symbol Meaning 1 One and only one 0..1 Zero or one M..N From M to N (natural language) * From zero to any positive integer 0..* From zero to any positive integer 1..* From one to any positive integer Role “A given university groups many people; some act as students, others as teachers. A given student belongs to a single university; a given teacher may or may not be working for the university at a particular time.” Role

33 UML Multiplicities Links on associations to specify more details about the relationship Multiplicities Meaning 0..1 zero or one instance. The notation n . . m indicates n to m instances. 0..*  or  * no limit on the number of instances (including none). 1 exactly one instance 1..* at least one instance

34 Association Details Can assign names to the ends of the association to give further information + getName () : string setName () - calcInternalStuff ( in x : byte , in y decimal ) Name ID long # Salary double adfaf bool Employee members Team group 1 individual *

35 Aggregation Aggregation is an association with a “collection-member” relationship Hollow diamond on the Collection side No sole ownership implied void doSomething() aModule.service();

36 Notation of Class Diagram: Aggregation
Container Class Aggregation: expresses a relationship among instances of related classes. It is a specific kind of Container-Containee relationship. It expresses a relationship where an instance of the Container-class has the responsibility to hold and maintain instances of each Containee-class that have been created outside the auspices of the Container-class. Aggregation should be used to express a more informal relationship than composition expresses. That is, it is an appropriate relationship where the Container and its Containees can be manipulated independently. Aggregation is appropriate when Container and Containees have no special access privileges to each other. Class C AGGREGATION Class E1 Class E2 Containee Classes Example Bag Apples Milk [From Dr.David A. Workman]

37 Class Diagrams School Department 1 1 ..* 1 1 ..* 1 ..* 1 ..* 1 ..* * 1 ..* Student * * Course * 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.

38 Aggregation vs. Composition
Composition is really a strong form of aggregation components have only one owner components cannot exist independent of their owner; both have coincident lifetimes components live or die with their owner e.g. (1) Each car has an engine that can not be shared with other cars.   (2) If the polygon is destroyed, so are the points. Aggregations may form "part of" the aggregate, but may not be essential to it. They may also exist independent of the aggregate. Less rigorous than a composition. e.g. (1) Apples may exist independent of the bag. (2) An order is made up of several products, but the products are still there even if an order is cancelled.

39 Composition Composition is Aggregation with:
Lifetime Control (owner controls construction, destruction) Part object may belong to only one whole object members[0] = new Employee(); … delete members[0]; Filled diamond on side of the Collection

40 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. Window Scrollbar 1 1 Titlebar 1 1 Menu 1 1 .. *

41 Inheritance Standard concept of inheritance Base Class Derived Class
class B() extends A …

42 Notation of Class Diagram: Generalization
Supertype Example: Customer Regular Customer Loyalty Customer Subtype1 Subtype2 or: Customer Generalization expresses a relationship among related classes. It is a class that includes its subclasses. Regular Customer Loyalty Customer

43 UML Class Example

44 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)

45 * Class Diagram example class * * * [from UML Distilled Third Edition]
Name class Order Multiplicity: mandatory Attributes -dateReceived -isPrepaid * Customer 1 -number :String -name -price : Money -address +dispatch() Association Operations +creditRating() : String() +close() 1 {if Order.customer.creditRating is Generalization "poor", then Order.isPrepaid must be true } Corporate Customer Personal Customer Constraint (inside braces{}} -contactName -creditCard# -creditRating Multiplicity: Many value -creditLimit +remind() +billForMonth(Integer) Multiplicity: optional * 0..1 Employee * OrderLine -quantity: Integer * 1 Product -price: Money -isSatisfied: Boolean [from UML Distilled Third Edition]

46 Object Diagrams Shows instances of Class Diagrams and links among them
An object diagram is a snapshot of the objects in a system At a point in time With a selected focus Interactions – Sequence diagram Message passing – Collaboration diagram Operation – Deployment diagram

47 Object Diagrams Format is Instance name : Class name
Attributes and Values Example:

48 Deployment Diagrams Shows the physical architecture of the hardware and software of the deployed system Nodes Typically contain components or packages Usually some kind of computational unit; e.g. machine or device (physical or logical) Physical relationships among software and hardware in a delivered systems Explains how a system interacts with the external environment

49 Some Deployment Examples

50 Deployment Example Often the Component Diagram is combined with the Deployment

51 Component Diagrams Shows various components in a system and their dependencies, interfaces Explains the structure of a system Usually a physical collection of classes Similar to a Package Diagram in that both are used to group elements into logical structures With Component Diagrams all of the model elements are private with a public interface whereas Package diagrams only display public items.

52 Component Diagram Illustrate the organizations and dependencies of the physical components in a system. Has a higher level of abstraction than a Class diagram - usually implemented by one or more classes. Symbols and Notations Components a large rectangle with two smaller rectangles on the side.

53 Component Diagram (cont.)
Interface An interface describes a group of operations used or created by components. It represents a declaration of a set of coherent public features and obligations, similar to a contract. Dependencies dashed arrows.

54 Component Diagram (cont.)
order customer account Order provides a component interface, which is a collection of one or more methods with or without attributes. Account and customer components are dependent upon the interface of the order.

55 Component Example - Interfaces
Restaurant ordering system Define interfaces first – comes from Class Diagrams

56 Component Example - Components
Graphical depiction of components

57 Component Example - Linking
Linking components with dependencies

58 Packages A package is a container-like element for organizing other elements into groups. A package can contain classes and other packages and diagrams. Packages can be used to provide controlled access between classes in different packages. Compiler

59 Packages (Cont’d) Classes in the FrontEnd package and classes in the BackEnd package cannot access each other in this diagram. FrontEnd BackEnd Compiler

60 Packages (Cont’d) Compiler
We can model generalizations and dependencies between packages. JavaCompiler Java

61 Interaction Diagrams Interaction diagrams are dynamic -- they describe how objects collaborate. A Sequence Diagram: Indicates what messages are sent and when Time progresses from top to bottom Objects involved are listed left to right Messages are sent left to right between objects in sequence

62 Sequence Diagrams – Object Life Spans
Lifelines The dotted line that extends down the vertical axis from the base of each object. Messages Labeled as arrows, with the arrowhead indicating the direction of the call. Activation bar The long, thin boxes on the lifelines are method-invocation boxes indicting that indicate processing is being performed by the target object/class to fulfill a message. Rectangle also denotes when object is deactivated. Deletion Placing an ‘X’ on lifeline Object’s life ends at that point A B Create X Deletion Return Lifeline Activation bar

63 Sequence Diagram Messages are rendered as horizontal
an Order Line a Stock Item Messages are rendered as horizontal arrows being passed from object to object as time advances down the object lifelines. Conditions ( such as [check = “true”] ) indicate when a message gets passed. check() [check = “true”] remove() Simple Message Synchronous Message Asynchronous Message Synchronous messaging is a two way communication. i.e. Sender sends a message to receiver and receiver receives this message and gives reply to the sender. Sender will not send another message until get reply from receiver. Asynchronous messaging involves a client that does not wait for a message from the server. It is a one way communication

64 Sequence Diagram Calls = Solid Lines Returns = Dashed Lines
An interaction diagram that details how operations are carried out. Calls = Solid Lines Returns = Dashed Lines Object: Class Message Operations Lifeline

65 Sequence Diagram Example
Hotel Reservation

66 Collaboration Diagram
협력 다이어그램이란? 객체 사이의 연관 관계 뿐만 아니라, 각 객체들이 주고 받는 메시지들을 공간에 따라 배열 한 것. 객체 다이어그램의 확장으로 볼 수 있다. 순차 다이어그램과의 유사점 및 차이점 유사점 : 순차 다이어그램처럼 객체들 사이의 교류를 보여준다.  따라서, 순차와 협력 다이어그램의 상호 변환이 쉽다. 차이점 : 순차 다이어그램: 객체간의 교류를 시간의 순서에 초점을 두어 표현. 협력 다이어그램 : 공간에 따라 배열시킴  교류를 수행하는 객체들의 전체적인 조직과 상황(Context)에 초점을 맞춤. 표현 두 객체 사이를 연관 선으로 연결. 연관선 위에 메시지가 전달되는 객체 쪽으로 화살표 방향을 가진 선을 긋는다. 메시지의 의미는 “메시지를 받는 객체로 하여금 어떤 오퍼레이션을 실행하라” 이다. 메시지의 끝에 ‘( )’ 붙임으로써 매개 변수를 넣을 수 있도록 함.

67 Collaboration Diagram
예제) “음료수 뽑기” 예에서 “액수가 맞지 않는 경우”를 고려해 보자. 물론, 이전의 순차 다이어그램을 참고하면서 보도록 한다. 만들 협력 다이어그램은 다음이 조건을 처리해야 한다. 1. 사용자가 음료수 가격보다 많은 돈을 투입한 경우 [input > price]. 2. 음료수 자판기가 충분한 거스름 돈을 가진 경우. [잔돈이있다면] 3. 음료수 자판기가 충분한 거스름 돈을 가지지 않은 경우. [잔돈이없다면] 혹은 [input < price] User insert(input, selection) :프론트 1 : add(input, selection) [잔돈이없다면] 혹은 [input < price] 3.3 : return(input 돈) 4 : deliver(selection) [잔돈이있다면] 3.2 : return(잔돈) :디스펜서 :금전등록기 [input > price] : 잔돈유무검사(input, price) [input = price] 2.1 : deliver(selection) [잔돈이있다면] 3.1 : deliver(selection) 각 단계의 소수점 숫자의 표현 : 동일한 단계에서 여러 시나리오가 중첩(nesting) 됨을 나타냄.

68 Interaction Diagrams: Collaboration diagrams (cont.)
User Catalog Reservations start 1: look up 2: title data 3 : [not available] reserve title 4 : title returned 5 : hold title 6 : borrow title 6: remove reservation 5: title available

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

70 State Machine 상태 다이어그램(State Diagram) 이란? 표현
사건이나 시간에 따라 시스템 객체의 상태 변화를 표현한 그림. “단일 객체”의 상태를 나타냄. 시스템의 변화를 잡아내기 위하여 사용. 분석가, 설계자, 개발자들이 시스템내의 객체의 행동을 이해하는데 큰 도움을 줌. 표현 상태의 표현 : 모서리가 둥근 사각형으로 표현 상태 전이의 시작점 : 속을 칠한 원으로 표현. 상태 전이의 종료점 : 속을 칠한 원을 둘러싼 원으로 표현 상태 전이선 : 화살표 머리가 달린 실선 상태정보 시작점 종료점

71 State Machine 상태 아이콘에 넣는 정보 이름, 속성, 오퍼레이션의 세 영역으로 나누어 상세한 정보 넣을 수 있다.
이름 – 상태 이름(필수) 속성 – 상태 변수(옵션). 타이머나 카운터처럼 상태 진행에 도움을 주는 데이터. 오퍼레이션 – 활동(Activity – 옵션). 사건(event)과 동작(action)으로 이루어짐. 활동(do/activity) – 상태(State)와 관련, 오래 지속될 수 있으며 사건(event)이 인터럽터를 일으킬 수도 있다. 동작(event[guard]/action) – 전이(transition)와 연관. 짧은 순간에 발생하는 프로세스로 간주되며 인터럽트를 받지 않는다. 상태 이름 상태 변수들 활동들 활동 자주 쓰이는 세가지 진입(entry) – 시스템이 상태로 들어갈 때 일어남 활동(do) – 시스템이 상태 안에 있는 동안 일어남 탈출(exit) – 시스템이 상태에서 빠져나올 때 일어남

72 State Machine 상태 전이 선에 추가 되는 정보 : 사건과 동작
추가되는 정보 : 전이가 일어나는 원인을 제공하는 사건(촉발사건-trigger event)과 실제로 수행되어 상태변화를 일으키는 연산(동작-action). 사건과 동작은 상태 전이 선에 가깝게 붙여준다. ‘/’ 를 사용하여 사건[조건]/동작을 구분 시켜준다. 활동을 종료했기 때문에 일어나는 전이  촉발없는 전이(triggerless transition)라 함. 예) GUI의 상태 다이어그램 초기화 Do / 부팅 작동 종료 스위치 ON / 전원공급() 스위치 Off / 전원중단()

73 State Machine 전이 조건 : 상태 전이 선에 추가되는 정보 어떤 조건에 따라 상태가 전이 될 때.
조건에 따른 상태 전이의 분기가 일어날 때. ‘[ ]’ 를 사용하여 조건(Guard)을 명시함. 예) 앞의 GUI 예에서 어떤 조건을 만족하면 스크린세이버가 작동하는 상태로 됨 초기화 Do / 부팅 시스템작동 종료 스위치 ON / 전원공급() 스위치 Off / 전원중단() 화면보호기 작동 [시간초과 했다면] 키누르기 또는 마우스움직이기/

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

75 State Machine start state final state simple state
concurrent composite state sequential composite state

76 State Machine 점검 대기 처리 배달 do / 아이템을 점검한다 . 운반 준비를 한다 다음 가져온다 [ 아이템이 모두
점검되지 않았다 ] 받는다 어떤 아이템은 재고품이 없다 .] 모든 아이템 점검되었고 , 유효하다 되었고 start Self-transition transition State activity

77 State Transition Example
Validating PIN/SSN

78 State Charts – Local Variables
State Diagrams can also store their own local variables, do processing on them Library example counting books checked out and returned

79 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]

80 Activity Diagram 업무과정(Business Process)를 표현하는 오퍼레이션(Operation)의 알고리즘을 효과적으로 나타내는데 유용하게 사용된다. Petri net + Flowchart와 상당히 흡사하다. State Diagram의 확장으로 볼 수 있다. 해당 활동내의 처리가 끝나면 그 다음의 활동으로 자동적으로 옮겨진다.

81 Sample Activity Diagram
Ordering System May need multiple diagrams from other points of view

82 Activities Diagram Start Fork
Activity diagrams describe the workflow behaviour of a system Branch Merge Joint End

83 Activity Diagram Example

84 Reading list http://www.agilemodeling.com/essays/umlDiagrams.htm
paradigm.com/VPGallery/diagrams/index.html 128.ibm.com/developerworks/rational/library/3101.html rial/index.htm