분산 데이터 처리 · 2016-12-06 · 학습 내용 introduction overview of the uml notation...
TRANSCRIPT
학습 내용
Introduction
Overview of the UML Notation
Software Life Cycle Models and Processes
Introduction
Reference : H. Gomma, “Software Modeling and Design (UML, Use Cases, Patterns, and Software Architectures)”,
Cambridge University Press, February 2011
Introduction
2
Introduction
3
■ 모델(Model) 정의 시스템을 대표(Representative)하여 표현할 수 있도록 추상화(Abstraction)하여 작게 보여지는 모습(Visualization) 모델링(Modeling) 정의 모델을 만드는 행위
Introduction
4
■ Modeling and Design
모델링은 시스템을 구현하기 전에 분석하고 만들어진다. “잘 모르는 것을 이해하는데 도움이 될 수 있도록 어떤 것을 사용한다.”
■ UML as a Standard
Overview of the UML Notation
5
• UML (Unified Modeling Language)
– 객체형태의 모델을 표현하는 언어
• UML 역사 (Three-Amigos)
Software Life Cycle Models and Processes
6
RUP Definition
A modern process model derived from the work on the UML and associated process.
History Created by the Rational Software Corporation,
a division of IBM since 2003
Three Principles Use Case Driven
Architecture Centric
Iterative and incremental development
UML UML Notation
use symbols
UML Diagram graphical depiction
RUP VS. UML RUP is a description of a
software development process
UML is a modeling notation
RUP can use UML, but the reverse is not true
■ (Rational) Unified Software Development Process
Software Life Cycle Models and Processes
7
학습 내용
UML Diagrams
Overview of Software Modeling And Design Method
Reference : H. Gomma, “Software Modeling and Design (UML, Use Cases, Patterns, and Software Architectures)”,
Cambridge University Press, February 2011
■ UML Diagram
Overview of the UML Notation
9
■ Class Diagrams
Overview of the UML Notation
10
Associations
■ Class Diagrams
Overview of the UML Notation
11
Generalization/Specialization Hierarchy
Aggregation and Composition Hierarchies
■ Sequence Diagrams
Overview of the UML Notation
12
■ Communication Diagrams (Figure 2.5)
Overview of the UML Notation
13
■ State Machine Diagrams
Overview of the UML Notation
14
해석?
■ Packages
Overview of the UML Notation
15
■ Concurrent Communication Diagrams
Overview of the UML Notation
16
Active object
A concurrent object, process, thread, or task
Own thread of control
executes concurrently with other objects
Passive object
No thread of control
Executes only when another object(active or passive) invokes one of its operations
■ Message Communication Concurrent Communication Diagrams
Overview of the UML Notation
17
학습 내용
Use Case Modeling
Actors, Use Cases
Documenting Use Cases
Use Case Relationships
Activity Diagrams
Use Case Modeling Reference : H. Gomma, “Software Modeling and Design
(UML, Use Cases, Patterns, and Software Architectures)”, Cambridge University Press, February 2011
■ Requirement Modeling
Use Case Modeling
- Define software functional requirement
in terms of use cases and actors
Requirement Modeling
■ Use Case Diagram
Overview of the UML Notation
20
Use Case
Describes sequence of interactions between user(actor)and system
Narrative description
■ Use Case Diagram
Use Case Modeling
Use case relationships
Include
Extend
21
22
■ Use Cases (Figure 6.1)
Use Case Modeling
23
■ A Simple Use Cases
Use Case Modeling
24
■ Actors
Use Case Modeling
Actor models external entities of system
Actor interact directly with system
Human user
External I/O device
External system
Timer
Actor initiates actions by system
May use I/O devices or external system to physically interact with system
Actor initiates use cases
25
■ Actors
Use Case Modeling
26
■ Actors
Use Case Modeling
Primary Actor
Starts the use case by providing input to the system
Secondary Actor
Participates in use case
Can be primary Actor of a different use case
Actor
Represents all users who use system in the same way
A user is an instance of an actor
Represents a role played by all users of the same type
Human user may play more than one role
27
■ Actors (Figure 6.5)
Use Case Modeling
해석?
28
■ Identifying Use Cases
Use Case Modeling
Actor가 수행해야 하는 주요 기능을 고려한다
(Consider each major function an actor needs to perform)
해당 기능은 Actor에게 가치를 준다.
(Provides value to an actor)
Actor와 System 사이의 상호 작용을 명시한다.
(Specifies interaction between actor and system)
유스케이스는 Actor가 시작한 이벤트의 일련의 처리 흐름이다.
(Use case is a complete sequence of events initiated by an actor)
유스케이스는 Actor의 입력으로 시작한다.
(Use case starts with input from an actor)
기본 흐름 (Basic path)
Most common sequence
대안 흐름 (Alternative branches)
Variants of basic path
E.g., for error handling
29
■ Documenting Use Cases
Use Case Modeling
Use Case Name
Summary
Short description of use case
Dependency ( on other use cases)
Actor – primary, secondary
Preconditions
Conditions that are true at start of use case
Description
Narrative description of main sequence
Alternatives
Narrative description of alternative sequences
Nonfunctional requirements
E.g., performance and security requirements
Post condition
Condition that is true at end of use case
30
■ Use Case Name : Make Order Request (Figure 6.8)
Use Case Modeling
31
■ Use Case Description : Make Order Request
Use Case Modeling
■ Analysis Modeling consist of
Analysis Modeling
32
정적 모델링 (Static Modeling)
- 분석 모델에서의 클래스 다이어그램은 문제 영역에서의 부류를 보인다.
(Class Diagrams show the classes of the problem domain(Analysis Model))
동적 모델링 (Dynamic Modeling)
- 상태 다이어그램을 사용하여 상태 머신 모델링을 한다.
(State Machine modeling using state charts)
- 객체 간의 상호 작용을 모델링을 한다.
(Object interaction modeling)
■ Analysis Modeling consist of
Analysis Modeling
33
정적 모델링 (Static Modeling)
- 분석 모델에서의 클래스 다이어그램은 문제 영역에서의 부류를 보인다.
(Class Diagrams show the classes of the problem domain(Analysis Model))
■ Analysis Modeling consist of
Analysis Modeling
34
동적 모델링 (Dynamic Modeling)
- 상태 다이어그램을 사용하여 상태 머신 모델링을 한다.
(State Machine modeling using state charts)
- 객체 간의 상호 작용을 모델링을 한다.
(Object interaction modeling)
학습 내용
Object and Classes
Associations
Composition / Aggregation
Generalization / Specialization
System Context Class Diagram
Static Modeling of Entity Classes
Static Modeling
Reference : H. Gomma, “Software Modeling and Design (UML, Use Cases, Patterns, and Software Architectures)”,
Cambridge University Press, February 2011
36
■ Design Concepts Objects and Classes
Static Modeling
Objects represent “things” in real world
Provide understanding of real world
Form basis for a computer solution
An Object (object instance) is a single “thing”
E.g., an account, an employee
A class (object class) is a collection of objects with the same characteristics
E.g., account, employee
Attribute
Data value held by object in class
E.g., account number, balance
■ Classes and Objects (figure 2.2)
Overview of the UML Notation
37
38
Software Design and Architecture Concepts
■ Class with attributes
39
Software Design and Architecture Concepts
■ Class with operations (Figure 4.3)
40
■ Static Modeling
Static Modeling
Define structural relationships between classis
Depict classes and their relationships on class diagrams
Relationships between classes
Associations
Composition / Aggregation
Generalization / Specialization
Static Modeling during Analysis
System Context Class Diagram
Depict external classes and system boundary
Static Modeling of Entity classes
Persistent classes that store data
41
■ Associations
Static Modeling
클래스 간의 정적, 구조적 관계
(Static, structural relationship between classes)
E.g, Employee works on Project
■ Associations
Static Modeling
Multiplicity of Associations
얼마나 많은 클래스의 인스턴스들이 또다른 클래스의 인스턴스와 어떻게 연결될지를 명시한다.
Specifies how many instances of one class may relate to a single
instance of another class
Examples
1 –to- 1 association
1 –to- many association
Optional association
(0 or 1)
Optional association
(0,1, or many)
42
43
■ One-to-many Association
Static Modeling
44
■ Associations on a class diagram
Static Modeling
해석?
45
■ Class attributes
Static Modeling
46
■ Generalization / Specialization Hierarchy
Static Modeling
Some classes are similar but not identical
Have some attributes in common, others different
Common attributes abstracted into generalized class (superclass)
E.g., Account (Account number, Balance)
Different attributes are properties of specialized class (subclass)
E.g., Savings Account (interest)
47
■ Composition Hierarchy
Static Modeling
Composition Hierarchy
Whole and part objects are created, live, die together
Association between instances
48
■ Constraints
Static Modeling
49
Static Modeling
■ Constraints
50
■ Static Modeling of Problem Domain
Static Modeling
분석 모델에서 (During Analysis Modeling)
개념적인 정적 모델을 만들 때
(Conceptual static model)
문제 영역의 실제 개체에 초점을 둔다.
(Emphasizes real-world classes in the problem domain)
실제 프로그램에서의 클래스를 나타내는 것은 아니다.
(Does not initially address software classes)
다음의 두 가지 클래스에 초점을 둔다
(Emphasis on)
물리적 클래스 (Physical classes)
물리적인 특성을 가진 것 (Have physical characteristics (can see, touch))
엔터티 클래스 (Entity classes)
데이터 중심 클래스 (Data intensive classes)
51
■ Conceptual static model (Figure 7.18)
Static Modeling
52
■ Static modeling of entity classes
Static Modeling
엔터티 클래스란 (Entity classes)
데이터 중심 클래스
(Data intensive classes)
지속적인 데이터 저장
(Store long-living (persistent) data)
데이터 베이스 중심
(Many are database intensive)
실시간 분산 시스템에 또한 중요
(Also important for many real-time and distributed applications)
분석 모델링에서는 (During analysis modeling)
문제 영역에서의 엔터티 클래스를 모델링
(Model entity classes in the problem domain)
속성 및 관계 명시
(Attributes/Relationships)
■ Conceptual static model for Banking system
Static Modeling
53
해석?
54
■ Modeling Class Attributes
Static Modeling
학습 내용
Object Structuring Criteria
Modeling and Class Structuring Categories
Classes and Objects
Object Structuring and Class Structuring
Reference : H. Gomma, “Software Modeling and Design (UML, Use Cases, Patterns, and Software Architectures)”,
Cambridge University Press, February 2011
56
■ Object Structuring Criteria
Object Structuring and Class Structuring
시스템의 모든 소프트웨어 객체를 다음과 같은 타입으로 결정할 수 있다.
Determine all software objects in system
다음의 스테레오 타입을 사용하여 구조화할 수 있다.
Structuring criteria depicted using stereotypes
Boundary objects
Entity objects
Long living objects that store information
Determined during static modeling
Control objects
Application Logic objects
57
■ Classification of application classes by stereotype
Modeling Application Classes and Objects
58
■ Object Structuring Criteria
Entity object
• A software object, which encapsulates information and provides access to the information it stores.
Boundary object
• User interaction object
• Proxy object
• Device I/O object
Control object
• Coordinator objects
• State dependent control objects
• Timer objects
Application logic object
• Business logic objects
• Algorithm objects
• Service objects
Object Structuring and Class Structuring
■ User interaction object
사용자와 상호작용을 하는 인터페이스
Interfaces to and interacts with a human user
표준 I/O 디바이스
Via standard I/O devices
Keyboard, visual display, mouse
단순하거나 복잡한 사용자 인터페이스
Support simple or complex user interfaces
Command line interface
Graphical user interface (GUI)
Boundary object
59
60
■ Device I/O boundary objects
Boundary object
기기 입력, 출력 인터페이스
Device I/O boundary object
Interfaces to I/O device
입력 인터페이스 (Input object)
E.g., Sensor Interface
출력 인터페이스 (Output object)
E.g., Actuator Interface
I/O(Input/Output) object
E.g., ATM Card Reader Interface
61
■ System external classes and software boundary classes
Depicting External Classes and Boundary Classes
62
■ Control classes and objects
Control Classes and Objects
객체 그룹의 실행에 있어 전반적인 코디네이션을 제공한다.
Provides overall coordination for execution of a group of objects
전반적인 결정을 내린다.
Makes overall decisions
객체들의 상호작용 흐름에서 언제, 어떤 순서로 객체들이 참여할지 결정한다.
Decides when, and in what order, other objects participate in interaction
sequence
Several kinds of Control objects
Coordinator object
State dependent control object
Timer object
63
■ Coordinator objects
Control Classes and Objects
64
■ State dependent control objects
Control Classes and Objects
상태 전이 테이블이나 상태 머신으로 정의
Is defined by finite state machine or state transition table
입력 이벤트를 받음
Receives incoming events
해석?
65
■ Timer objects
외부 타이머로 주기적으로 활성화된다.
Is activated periodically by an external timer
Control Classes and Objects
66
■ Application logic classes and objects
Application Logic Classes and Objects
Business Logic Object
고객의 요청을 처리하는 비즈니스에 특정한 어플리케이션 로직을 정의
Defines business specific application logic (rules)
for processing a client request
주로 하나 이상의 엔터티 개체에 접근
Usually accesses more than one entity object
Algorithm Object
Service object
67
Application Logic Classes and Objects
■ Business logic object
■ Algorithm Object
Application Logic Classes and Objects
해석?
69
■ Service object
다른 객체들에게 서비스를 제공한다.
Provides a service to other objects
고객 객체로부터의 요청에 반응한다.
Responds to requests from client objects
Application Logic Classes and Objects
학습 내용
Dynamic Modeling
Dynamic Analysis
State Dependent Analysis
Dynamic Interaction Modeling
Reference : H. Gomma, “Software Modeling and Design (UML, Use Cases, Patterns, and Software Architectures)”,
Cambridge University Press, February 2011
71
■ Dynamic Modeling
Dynamic Interaction Modeling
유스케이스에서 객체들이 어떻게 참가하는지 모델링
Determine how objects participate in use case
• 객체를 결정하는 구조적인 기준을 사용
Use object structuring criteria to determine objects
• Stereotype for each object structuring criteria
• 유스케이스에서의 객체 간의 상호 작용의 흐름을 보여준다
Shows sequence of object interactions in use case
• Depict on
– Communication diagram or
– Sequence diagram
72
■ Dynamic Modeling
Dynamic Interaction Modeling
유스케이스를 성취하기 위해 객체가 다른 객체와 어떻게 상호작용할지 결정
Determine how objects interact with each other to support use case
• 액터가 발생시킨 외부 이벤트로 시작한다
Start with external event from actor
• 유스케이스를 성취하기 위해 필요한 객체를 결정한다
Determine objects needed to support use case
• 외부 이벤트 다음에 오는 내부적인 이벤트의 순서를 결정한다
Determine sequence of internal events following external event
• 시퀀스 다이어그램/커뮤니케이션 다이어그램을 작성한다
Depict on communication diagram
73
■ Use case Diagram
Object Interaction Modeling
74
■ Stateless Dynamic Interaction Modeling
Dynamic Interaction Modeling
1. Develop use case model
-액터와 시스템 간의 각 상호작용을 고려한다
Consider each interaction between the primary actor and the system
- 외부 입력을 통해 사용자가 시스템과의 상호 작용을 시작했음을 기억한다
Remember that the actor starts the interaction with the system through an
external input
- 유스케이스의 주요 흐름에서의 객체의 소통 흐름을 개발한다
Start by developing the communication sequence for the scenario
described in the main path of the use case
- 액터와 사용자 간의 상호작용을 고려한다
Consider each interaction in sequence between the actor and the system
75
■ 1. Develop Use Case Model
View Alarms Example
76
■ Stateless Dynamic Interaction Modeling
Dynamic Interaction Modeling
2. 유스 케이스를 성취하기 위해 필요한 객체를 결정한다
Determine object needed to realize use case
- 소프트웨어 객체를 결정하기 위해 객체 구조화 기준을 적용한다.
applying the object structuring criteria to determine the software objects
(both boundary objects(2a) and internal software objects (2b below)
2a.바운더리 객체를 결정한다.
Determine boundary object(s)
- 유스케이스에 참가하는 액터를 고려한다
Consider the actor that participates in the use case
- 액터의 입력을 받는 시스템 객체 혹은 액터와 소통할 때의 외부 객체를 결정한다
Determine the external objects through which the actor communicates with
the system, and the system objects that receive the actor’s inputs
- 외부 객체로부터 시스템으로 들어오는 입력을 고려한다
Start by considering the inputs from the external object to the system
77
■ Stateless Dynamic Interaction Modeling
Dynamic Interaction Modeling
2b. 내부의 소프트웨어 객체들을 결정한다.
Determine internal software objects
- 유스케이스의 주요 흐름을 고려한다
Consider the main sequence of the use case
- 객체 구조화 기준을 사용한다
Using the object structuring criteria
- 컨트롤 객체 혹은 엔터티 객체 등 유스케이스에 참가하는 객체를 결정한다
Determine the internal software objects that participate in the use case,
such as control or entity objects.
78
■ 2. Determine Objects Needed to Realize Use Case
View Alarms Example
Two objects participate in the use case
79
■ Stateless Dynamic Interaction Modeling
Dynamic Interaction Modeling
3. 객체 간의 메시지 소통을 결정한다
Determine message communication sequence
- 바운더리 객체와 이를 대응하는 객체에 필요한 메시지를 고려한다.
Consider the communication required between the boundary object and
the subsequent objects
- 시퀀스 다이어그램 혹은 커뮤니케이션 다이어그램을 그린다.
Draw a communication diagram or sequence diagram
- 액터로부터 오는 외부 입력을 고려한다.
Starts with an external input from the actor
80
■ 3. Determine Message Communication Sequence
View Alarms Example
81
■ Stateless Dynamic Interaction Modeling
Dynamic Interaction Modeling
4. 대안 흐름을 결정한다.
Determine alternative sequences
- 에러 처리와 같은 대안 흐름을 고려한다.
Consider the different alternatives such as error handling
- 대안 흐름에 필요한 객체를 고려한다
Consider that objects need to participate in executing the alternative
branch
82
■ 1. Develop Use Case Model
Make Order Request Example
■ 1. Develop Use Case Model
83
Make Order Request Example
■ 1. Develop Use Case Model
84
Make Order Request Example
85
■ 2. Determine Objects needed to Realize Use Case
Make Order Request Example
고객 액터에 대해서, 사용자 인터랙션 객체가 필요하다.
Given the customer actor, there will need to be a user interaction object
유스케이스를 성취하기 위해 필요한 네 가지 서비스에 대한 서비스 객체가 필요하다.
Service objects are need for the four services needed to realize this use case,
Customer Account Service
Credit Card Service
Delivery Order Service
Email Service
코디네이터 객체가 하나의 사용자 인터랙션 객체와 네 개의 서비스 객체들을 코디네이션한다
A coordinator object (Customer Coordinator) to coordinate the interactions
between Customer Interaction and the four service objects
86
■ 3. Determine Message Communication Sequence
Make Order Request Example
Make Order Request Example
■ 3. Determine Message Communication Sequence
87
88
■ 3. Determine Message Communication Sequence
Make Order Request Example
89
■ 4. Determine Alternative Sequences
Make Order Request Example
90
■ 4. Determine Alternative Sequences
Make Order Request Example
■ 4. Determine Alternative Sequences
Make Order Request Example
91
92
■ 4. Determine Alternative Sequences
Make Order Request Example
93
■ 4. Determine Alternative Sequences
Make Order Request Example