분산 데이터 처리 · 2016-12-06 · 학습 내용 introduction overview of the uml notation...

학습 내용

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


5

• UML (Unified Modeling Language)

– 객체형태의 모델을 표현하는 언어

• UML 역사 (Three-Amigos)

http://ko.wikipedia.org/wiki/%ED%8C%8C%EC%9D%BC:Grady_Booch,_CHM_2011_2_cropped.jpg


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


7

학습 내용

UML Diagrams

Overview of Software Modeling And Design Method



■ UML Diagram


9

■ Class Diagrams


10

Associations

■ Class Diagrams


11

Generalization/Specialization Hierarchy

Aggregation and Composition Hierarchies

■ Sequence Diagrams


12

■ Communication Diagrams (Figure 2.5)


13

■ State Machine Diagrams


14

해석?

■ Packages


15

■ Concurrent Communication Diagrams


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


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


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

33

정적 모델링 (Static Modeling)

- 분석 모델에서의 클래스 다이어그램은 문제 영역에서의 부류를 보인다.

(Class Diagrams show the classes of the problem domain(Analysis Model))


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



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)


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



56

■ Object Structuring Criteria


시스템의 모든 소프트웨어 객체를 다음과 같은 타입으로 결정할 수 있다.

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


■ 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


64

■ State dependent control objects


상태 전이 테이블이나 상태 머신으로 정의

Is defined by finite state machine or state transition table

입력 이벤트를 받음

Receives incoming events

해석?

65

■ Timer objects

외부 타이머로 주기적으로 활성화된다.

Is activated periodically by an external timer


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


■ Business logic object

■ Algorithm Object


해석?

69

■ Service object

다른 객체들에게 서비스를 제공한다.

Provides a service to other objects

고객 객체로부터의 요청에 반응한다.

Responds to requests from client objects


학습 내용

Dynamic Modeling

Dynamic Analysis

State Dependent Analysis

Dynamic Interaction Modeling



71

■ Dynamic 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


유스케이스를 성취하기 위해 객체가 다른 객체와 어떻게 상호작용할지 결정

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


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



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



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



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



4. 대안 흐름을 결정한다.

Determine alternative sequences

- 에러 처리와 같은 대안 흐름을 고려한다.

Consider the different alternatives such as error handling

- 대안 흐름에 필요한 객체를 고려한다

Consider that objects need to participate in executing the alternative

branch

82


Make Order Request Example


83



84


85

■ 2. Determine Objects needed to Realize Use Case


고객 액터에 대해서, 사용자 인터랙션 객체가 필요하다.

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





87

88



89

■ 4. Determine Alternative Sequences


90





91

92



93



분산 데이터 처리 · 2016-12-06 · 학습 내용 introduction overview of the uml notation...

Documents