1. 소프트웨어공학 원리 (SEP521)
Introduction to UML
Jongmoon Baik

2. Design using UML 2.0

3. Contents Why model What is UML UML history UML 2.0
Diagram/View paradigm
UML diagrams
Use case
Class
Sequence
State machine

4. Here, we focus on.. Tau G2 Analyst Designer
Requirement Analysis Technique
Software Architecture/
Design Technique
Analyst
Design
Analysis
Programmer
Telelogic
DOORS
Software Configuration Management
Eclipse, Jbuilder etc.
Requirement Elicitation Technique
Programming Technique
SW Development
Process
Conceptualization
Code
Software Requirement Management
Process
Technology
People
Maintenance
Test

5. Why model
To easily communicate information between different stakeholders in an unambiguous way
To specify target-language-independent designs
To provide structure for problem solving
To provide mechanisms(abstractions, views, filtering, structure) to manage complexity
To be able to easily experiment to explore multiple solutions

6. What is UML? Unified Modeling Language
Visual language for specifying, constructing and documenting
Maintained by the OMG (Object Management Group)
Website:
Object-oriented
Model / view paradigm
Target language independent
UML은 Unified Modeling Language의 약자로서 정해진 기호와 다이어그램을 통해 개발하는 시스템을 명세하고, 구축하고, 문서화하는 기능을 제공하게 됩니다.
(시스템을 원하는 모습으로 가시화,
시스템의 구조(structure)와 행동(behavior)을 명세화,
시스템 기본 형태 구축,
시스템 분석(analysis),설계(design)의 문서화)
따라서 UML은 시스템에 대한 청사진을 작성하는 표준언어로써 개발에 참여하는 사람들이 공통된 비전을 가질 수 있게 됩니다.
UML은 객체지향 모델링 언어로써 시스템의 기본요소를 객체 또는 클래스로 파악하여 문제영역을 모형화합니다.
UML은 모델/뷰 패러다임으로써 현실을 모델로 단순화하고 모델을 여러 각도에서 바라봄으로써 개발하는 시스템에 대한 이해를 높인다.

7. UML history Fall ‘2008 Summer ‘03 UML 2.x Fall ‘01 UML 1.4 Fall ‘99
OMG Acceptance, Nov ‘97
UML 1.1
UML Partners
UML 1.0
Web – June ‘96
UML 0.9
In October 1994 Grady Booch and Jim Rumbaugh began unifying Booch and OMT, resulting in a draft version of the Unified Method in October 1995 presented at OOPSLA ‘95.
In June 1995, an OMG-hosted meeting of all major methodologists resulted in the first worldwide agreement to seek methodology standards, under the umbrella of the OMG process.
In June 1996 the UML 0.9 document was released and invited and incorporated feedback from the general community.
UML partners expertise released version 1.0 January ‘97 as proposal to OMG.
In January 1997 separate responses were incorporated by the consortium, resulting in the release of UML 1.1, which improved the clarity of UML 1.0 semantics.
It was submitted to the OMG for their consideration and adopted on the 17th of November 1997.
1.4 Minor revision, based on user and vendor feedback.
Refine extension and profile mechanisms to improve support user customizations.
2.0 Major revision
Increase customizability
Improve component-based development methods.
OOPSLA = Conference on Object-Oriented Programming, Systems, Languages and Application.
Unified
OOPSLA ‘95
Method 0.8
OOSE
Other methods
OMT
Booch method

8. UML 2.0
UML 2.0 leverages the industry’s investment in UML 1.x and makes UML comprehensive, scalable and mature
UML 2.0 designed to solve the key UML 1.x issues
Major improvements in UML 2.0 include:
New internal structure diagrams support precise definition of architecture, interfaces and components
Improved scalability in state machine and sequence diagrams
Better semantic foundation enables advanced model verification and full code generation

9. Diagram/view paradigm
Each diagram is just a view of part of the system
Together, all diagrams provides a complete picture
Underlying System Model
The diagrams are views into the underlying semantic system model; each kind of diagram emphasizes some aspect of the model, e.g. dynamic aspects (messaging: sequence diagrams; behavior: state chart diagrams) or static aspects (use cases: use case diagram; class relationships: class diagram).
It is interesting to note that the diagrams that UML defines “out of the box” could be taken as “serving suggestions”. These pre-defined diagram types are not necessarily the only kinds of diagrams that could be produced based on the underlying semantic model.

10. UML diagrams Class Diagram Package Diagram Composite Structure Diagram
Activity Diagram
State Machine Diagram
Object Diagram
Behavioral Diagram
Structural Diagram
Use Case Diagram
Deployment Diagram
Interaction Diagram
Component Diagram
Timing Diagram
Communication Diagram
Interaction Overview Diagram
Sequence Diagram

11. Use Case Diagram Describe WHAT the system will do at a high-level
Subject
Subject Name
Telephone Catalog
Association
Check Status
Use Case
Place Order
Use Case Name
<<include>>
Customer
<<include>>
Dependency
Supply Customer Data
Arrange Payment
Actor
System Boundary

12. Actor
Someone or some thing that must interact with the system under development
Users, external systems, devices
Telephone Catalog
Check Status
Place Order
<<include>>
<<include>>
Customer .
Supply Customer Data
Arrange Payment
Actor

13. Use Case Functionality that the system shall offer to an actor
Interaction between one or more actors and the system
Telephone Catalog
Check Status
Use Case
Place Order
Use Case Name
<<include>>
<<include>>
Customer
Supply Customer Data
Arrange Payment

14. Subject Symbol Indicate system boundary
Represent the system begin developed
All actors who interact with the system are outside of it
Telephone Catalog
Subject Name
Subject
Check Status
Place Order
<<include>>
<<include>>
Customer
Supply Customer Data
Arrange Payment
System Boundary

15. Association Drawn between an actor and a use case
Represent bi-directional communication between the actor and the system
Telephone Catalog
Check Status
Association
Place Order
<<include>>
<<include>>
Customer
Supply Customer Data
Arrange Payment

16. Dependency – Include
Represent relationship from a base to an inclusion use case
Imply a Use Case calls another Use Case
Primarily used to reuse behavior common to several Use Cases
Telephone Catalog
Check Status
Base Use Case
Place Order
Dependency
<<include>>
<<include>>
Customer
Supply Customer Data
Arrange Payment
Inclusion Use Cases

17. Class Diagram Description of static structure
Showing the types of objects in a system and the relationships between them
Foundation for the other diagrams
Beverage
Multiplicity
Class Name *
Person
- Name: String - Age: Integer
+ getName() + getAge()
- Water: Integer
drinks
Class Attributes 1
+ Addwater()
Association
Generalization
Class Operations
Tea
Coffee
- Milk: Boolean - Sugar: Integer - Coffee: String
- Teabag: String
+ getTea()
+ getCoffee()

18. Classes Person Tea Coffee
Most important building block of any object-oriented system
Description of a set of objects
Abstraction of the entities
Existing in the problem/solution domain
Class Name
Person
- Name: String - Age: Integer
+ getName() + getAge()
Tea
- Teabag: String
+ getTea()
Coffee
- Milk: Boolean - Sugar: Integer - Coffee: String
+ getCoffee()

19. Attributes and Operations
Represent some property of the thing being modeled
Syntax: attributeName : Type
Operations
Implement of a service requested from any object of the class
Syntax: operationName(param1:type, param2:type, ...) : Result
Person
- Name: String - Age: Integer
+ getName() + getAge()
Coffee
- Milk: Boolean - Sugar: Integer - Coffee : String
+ getCoffee()
Class Attributes
Class Operations 27

20. Association and Multiplicity
Relationship between classes that specifies connections among their instances
Multiplicity
Number of instances of one class related to ONE instance of the other class
Association name (verb phrase)
Multiplicity
Person
- Name: String - Age: Integer
+ getName() + getAge()
Multiplicity
Coffee
- Milk: Boolean - Sugar: Integer - Coffee: String 1
drinks *
“One person drinks zero to many coffees”
+ getCoffee()

21. Aggregations and Compositions
Weak “whole-part” relationship
Mailitem ‘has a’ address
Composition
Strong “whole-part” relationship between elements
Window ‘contains a’ scrollbar
Mailitem
Address
Body 1
Window
DrawingArea
Scrollbar 1
..2
Aggregation
Composition

22. Inheritance Relationship between superclass and subclasses
All attributes and operations of the superclass are part of the subclasses
Tea
Coffee
- Milk: Boolean - Sugar: Integer - Coffee: String
Beverage
- Water: Integer
+ Addwater()
- Teabag: String
+ getTea()
+ getCoffee()
Generalization

23. Generalization/Specialization
Building a more general class from a set of specific classes
Specialization
Creating specialized classes base on a more general class
Generalization
Specialization
Tea
Coffee
- Milk: Boolean - Sugar: Integer - Coffee: String
+ getCoffee()
Beverage
- Water: Integer
+ Addwater()
- Teabag: String
+ getTea()

24. Active vs. Passive Class
Active class
Own a thread control and can initiate control activity
Used when asynchronous communication is necessary
Typically modeled with a statemachine of its behavior
Encapsulated with ports and interfaces
Passive class
Created as part of an action by another object
Own address space, but not thread of control
여기서 부터 Embedded특성.
왜 active class가 필요한지 active class로 부터 port, interface설명!
Game
Level :
Charstring
Player
Passive class
NumberOfPlayers :
Integer
Active class Id :
Integer
HighScore :
Integer
InitiateGame
StartNew ( ) ( )
GameOver ( )

25. Ports and Interfaces Ports Interfaces
Define an interaction point on a classifier
Interfaces
Declaration of a coherent set of public features and obligations
Contract between providers and consumers of services
Coffee Machine
Port symbol
Interface Definition
<<interface>> ToUser
signal CupOfCoffee() signal CupofWater() signal ReturnChange()
<<interface>> FromUser
signal Coin (Integer) signal Tea() signal Coffee()
Interface Name

26. Provided/ Required Interface
Provided interface
Class provides the services of the interface to outside callers
What the object can do
Provided interface accept incoming signal form outside callers
Required interface
Class uses to implement its internal behavior
What the object needs to do
Outgoing signal are sent via required interface
Provided Interface
Class
SubmitJob
Required Interface
PrintServer
CheckStatus
SetPrintProperties
Interface Name

27. Computer Device Example

28. Sequence Diagram
Emphasize on the sequence of communications between parts
Show sequences of messages (“interactions”) between instances in the system
Emphasize time ordering
Sequence Diagram Name
sd MakeCoffee
:Customer
:CoffeeMachine
Lifeline
Reference Frame
theMessage(“Insert Coins”)
ref
InsertCoins
처음에 여기다가 overall 한 그림 넣어주기.
Coffee()
Messages line
CupofCoffee()
Message name
ref
ReturnCoins

29. Lifelines Individual participant in the interaction over period time
Subsystem/ object/ class
Actor
External system roles in the interaction
Instance name (object) : Type name (class)
sd MakeCoffee
:Customer
:CoffeeMachine
theMessage(“Insert Coins”)
Lifeline
ref
InsertCoins
Coffee()
CupofCoffee()
ref
ReturnCoins

30. Messages One-way communication between two objects
May have parameters that convey values
sd MakeCoffee
:Customer
:CoffeeMachine
theMessage(“Insert Coins”)
Message name
ref
InsertCoins
Can be:
a signal
a call
a return
create
destroy
Messages line
Coffee()
CupofCoffee()
ref
ReturnCoins

31. Referencing Reuse already existing sequence diagrams
Avoid unnecessary duplication
sd MakeCoffee
:Customer
:CoffeeMachine
:Customer
:CoffeeMachine
sd InsertCoins
Coin()
OK()
theMessage(“Insert Coins”)
ref
InsertCoins
Coffee()
Reference
CupofCoffee()
ref
ReturnCoins

32. State Machine Diagram Specify the dynamic behavior of an element Show
The life history of a given class
Capture significant events that can act on an object
The event that cause a transition from one state to another
The actions that result from a state change
State
Event
Guard
receive order [amount >$25]
rejected
Confirm Credit
Cancel Order
Waiting
Action
Since the entire ”system” may be represented by a class or a set of systems it too may have its own statemachine diagram.
approved/ debit account()
receive order [amount <$25]
Initial State
Final State
Process Order
Transition

33. States State Condition or situation during the life of an object
Satisfies some condition, performs some activity or waits for some event
State
receive order [amount >$25]
Confirm Credit
rejected
Cancel Order
Waiting
approved/ debit account()
receive order [amount <$25]
Initial State
Final State
Process Order
State

34. Event and Action Event Action
Stimulus which causes the object to change state
Action
Output of a signal or an operation call
Event
Guard Condition
receive order [amount >$25]
Confirm Credit
rejected
Cancel Order
Waiting
approved/ debit account()
receive order [amount <$25]
Process Order
Action

35. Transition Change state from one to another triggered by an event
Occur only when guard condition is true
Syntax: event(arguments)[condition]/action
receive order [amount >$25]
Confirm Credit
rejected
Cancel Order
Waiting
approved/ debit account()
receive order [amount <$25]
Process Order
Transition

36. State or Transition-oriented Syntax
Transition line
Flowline
Off On
Input
Off On
Off on on / / ^ ^
activate;
off
off / / ^ ^
deactivate ;
Output
startBilling () ;
Action
activate
deactivate On
startBilling ( ) ;
Off
나중에 원본 class 43,45 page
Sequence 78 page
State 103 page
(그리는 순서 읽고 설명하기!) On
Transition line: transition details shown on line textually
Flowline: simple line; transition details shown in chained symbols

37. Q & A