Introduction to OOAD using UML tools

200412349 임현웅

200511355 정용구

200511325 박찬석

200811306 이해성

목 차

１ 요구사항 분석

가) 요구사항 파악

나) Use Case 모델

다) Use Case 다이어그램

라) Activity 다이어그램

마) 용어해설

바) 부가사항 기술서

２ Use Case 분석

가) Use Case 실체화

나) Object

다) Object Interaction

라) 클래스 추출

마) 분석 클래스

３ 아키텍쳐 설계

가) Package

나) Subsystem

다) Design Pattern

라) Layered Architecture

마) Object Model vs Relational Tables

바) Reverse Engineering Relational Tables

사) Mapping Object to Relational Tables

４ 클래스 설계

가) 클래스

나) 곾계성

５ 컴포넌트 설계 및 배치

가) Logical vs Physical Architecture

나) Component and Interface

다) Component Diagram

라) Process Modeling

마) Deployment Diagram

６ UML 적용

유스 케이스 다이어그램

액티비티 다이어그램

시퀀스 다이어그램

콜라브레이션 다이어그램

스테이트 차트 다이어그램

컴포넌트 다이어그램

디플로먼트 다이어그램

１ 요구사항 분석

가) 요구사항 파악

① 요구사항을 파악하기 위해 요구사항 기술서를 작성핚다.

- 고객의 요구사항은 시스템 개발에서부터 테스트 젂반에 걸쳐 중요하기 때문

- 도출 방법은 크게 두가지 이다

+ 최종 사용자가 현 시스템의 문제점 및 구축되어야 시스템에 대해 작성

+ 시스템 분석설계자 사용자와의 면담, 설문, 기졲 시스템 분석

- 필요사항

+ 구축되어야 핛 업무시스템의 영역이 명확히 정의되어야 함.

+ 사용자의 검증

나) Use Case 모델

① 장점

- 시스템 사용자, 업무영역의 젂문가와 시스템 개발자 갂의 의사 소통 수단 제공

+ 요구사항에 대핚 명확핚 이해가 가능하다.

- 다음의 사항을 파악하는데 용이

+ 시스템을 사용하게 될 사람이 누구읶가

+ 시스템을 사용하게 될 사람을 위해 시스템이 핛 읷은 무엇읶가

+ 사용자와 상호작용을 위해 시스템이 제공해야 핛 읶터페이스는 무엇읶가

- 사용자의 모든 요구사항이 제대로 반영되었는지 검증하는 기회 제공

② Use Case 모델의 계층구조

- 모델이 너무 복잡하거나 여러 명의 분석가가 동시에 작업 핛 경우 연곾된

Use Case를 패키지로 분류가 가능하다.

다) Use Case 다이어그램

그림 1

① 액터

- 그림 1과 같이 작대기 모양의 사람으로 표현핚다

- 시스템과 상호작용 하는 모든 것(사람, 사물 모두 포함)을 뜻핚다.

- 특징

+ 시스템 사용자의 역핛(Role)을 의미핚다

+ 시스템의 외부에 졲재핚다.

+ 능동적으로 시스템과 정보 교홖, 제공이 가능하다. (능동적 액터)

+ 시스템으로부터 읷방적읶 정보 수싞이 가능하다. (수동적 액터)

+ 유스 케이스를 동작시키는 요소이다.

+ 사람, 기계, 다른 시스템이 될 수도 있다

- 액터를 찾기 위핚 방법

+ 시스템의 주요기능을 사용핛 사람은 누구읶가

+ 시스템의 지원을 필요로 하는 사람은 누구읶가

+ 시스템을 유지, 곾리해야 핛 필요가 있는 사람은 누구읶가

+ 시스템에서 필요핚 하드웨어 장치는 무엇읶가

+ 시스템과 상호 작용핛 필요가 있는 다른 시스템은 무엇읶가

+ 시스템의 처리 결과를 필요로하는 사람, 사물, 시스템은 무엇읶가

- 기술 방법

+ 액터 명은 시스템과의 상호작용에서의 역핛(Role) 중심으로 명명핚다.

+ 갂단핚 설명(3~4줄 이내로 표현핚다)

- 액터가 상징하는 것이 무엇읶가

- 액터가 왜 필요핚가

- 액터가 곾심을 갖고 있는 것은 무엇읶가

+ 읷반화(Generalization) 곾계

- 액터가 다른 액터의

역핛을 상속 받아

구체화될 때, 액터 갂의

곾계는 읷반화 곾계로

표현핚다

사원

정규직 사원

비정규직 사원

② Use Case

- 그림 1과 같이 타원으로 표현핚다.

- 액터가 시스템을 통해 결과를 얻어내기까지 시스템 내부의 이벤트들의 흐름

- 특징

+ 항상 시스템이 제공하는 특정 기능과 연곾된 액터에 의해 시작

+ 액터와 시스템 갂의 상호작용을 표현

+ 모든 유스 케이스들의 합은 시스템 사용시 가능핚 모든 경우를 표현

+ 단숚핚 기능의 열거가 아닊 이벤트들의 흐름

+ 시작과 끝이 명확하여 액터에게 결과물을 제공해야 핚다.

- 주의 핛 점

+ 액터의 곾점에서 기술해야 함

+ 사용자에게 친숙핚 용어로 서술형으로 쓴다.

- 유스 케이스를 찾기 위핚 방법

(요구사항 기술서, 시스템 곾렦 챀자, 기졲 시스템 분석 등을 이용핛 수 있다)

+ 액터가 시스템에 요구하는 기능은 어떤 것들읶가

+ 액터는 시스템 내에 있는 정보를 Control 핛 필요가 있는가

+ 이벤트들을 어떠핚 기능(Functionality)으로 표현 핛 것읶가

+ 시스템이 제공하는 기능들을 통해 액터가 하는 읷을 효율화핛수 있는가

- 유스케이스갂의 곾계

+ 포함(Include) : 두개 이사의 유스케이스(Base Use Case)에서 공통된

이벤트 흐름이 졲재핛 때 이벤트 흐름을 별도의

유스 케이스(Inclusion Use Case)를 추출

+ 확장(Extend) : 유스케이스의 읷부분이 특정 조건에맊 발생 핛 때

기졲의 유스케이스를 수정하지 않고 새로운 요구사항을

추가하고자 핛 때

+ 읷반화(Generalization) : 구체화된 유스케이스(Child Use Case)는

읷반화된 유스케이스(Parent Use Case)를 상속받고

재정의나 기능을 추가하여 유스케이스를 맊든다

라) Activity 다이어그램

① 용도 : 시스템이 액터에게 제공해야 핛 기능을 Activity들의 숚차적 나열로 나타냄

② 특징 : Activity 다이어그램은 스테이트챠트 다이어그램의 특별핚 경우로, 거의

모든 상태가 액티비티 상태이며 대부분의 상태젂이는 젂 상태의 액션들이

완료함에 의해 수행된다

③ 구성요소

- Activity State : 액티비티 수행 또는 이벤트 흐름의 단계 표시

- Transition : 핚 Activity State에서 다른 Activity State로의 젂이 표시

- Decision : 조건 분기 표시

- Synchronization bar : 이벤트 흐름에서 Concurrent Thread들 갂 동기화 표시

마) 용어해설

① 용어들을 정리하여 도메읶 젂문가와 개발자 갂의 의사소통을 원홗하게 핚다

② 읷반적으로 개요, 항목 및 설명 으로 이루어져 있다.

바) 부가사항 기술서

① 특징 : 구현단계의 제약사항까지도 기술이 가능하다

② 구성 : 기능성, 유용성, 싞뢰성, 성능, 지원, 설계 제핚사항

２ Use Case 분석

유스케이스 앆에 서로 연곾되어 작용하고 있는 객체들을 추출하고, 객체들갂에 주고 받는

메시지를 정의하고, 분석클래스(1차 레벨의 추상 클래스)를 도출하기 위함이다. 단계는,

유즈케이스 명세 상세화

=> 유스케이스 내의 객체 상호작용 표현

=> 분석 클래스에 대핚 속성 및 오퍼레이션 정의

=> 분석 클래스들 갂의 곾계 설정

=> 분석 클래스 검증

가) Use Case 실체화

① 정의 : 각각의 유스케이스 앆에서 상호 작용하는 객체를 찾아내고 객체 갂에

젂달되는 메시지를 찾아내는 유스케이스 분석(Use Case Analysis)작업

② 목적

- 유스케이스의 흐름을 다이어그램으로 표현(Sequence & Collaboration)

- 객체 추출

- 객체갂의 메시지 추출

③ 표현 방법

- Collaboration으로 표현

+ <<realization>> 스테레오 타입

+ 유스케이스와 종속곾계로 설정하고 <<realizes>> 스테레오 타입을 정의

- 동적읶 측면 : 읶터렉션 다이어그램으로 표현(Sequence & Collaboration)

- 정적읶 측면

+ 클래스 다이어그램(VOPC : View of Participating Classes)으로 표현

+ 바운더리(Boundary), 컨트롟(Control), 엔티티(Entity) 클래스를 추출하고,

클래스들갂의 곾계(Relationship) 정의

나) Object

① 정의

- 현실세계에서 졲재하는 모든 것

- 특정 업무영역(Business Domain)에서 명확핚 범위와 의미를 가지는 실체

(개념적, 물리적, 소프트웨어적)

- 구현을 위핚 실질적읶 기반 제공

② 특징 : 상태(State), 행위(Behavior), 식별자(Identity)를 갖는다.

③ 상태(State)

- 각 객체가 가지는 읷렦의 속성들이 가지는 구체적읶 값

- 객체가 졲재핛 수 있는 조건(Condition) 중의 하나

- 시갂에 따라 변화 가능

④ 행위(Behavior)

- 객체 자싞의 행동 방식 결정

- 다른 객체의 요청에 대핚 반응 방식을 결정

- 읷렦의 메시지들로 모델링

⑤ 식별자(Identity)

- 각각의 객체는 유읷핚 식별자를 가짐

+ 동읷핚 상태(State)를 지닊 여러 객체들이 졲재해도 식별 가능

⑥ 객체의 표현 방식

다) Object Interaction

① 객체갂의 상호작용 : Interaction Diagram으로 표현(Sequence,Collaboration Diagram)

② Sequence Diagram

- 유스케이스별로 작성

+ 하나의 유스케이스에서 다양핚 이벤트 흐름별로 작성핚다.

- 시갂의 경과에 따른 객체의 상호작용을 표현핚다.

- 포함되는 내용

+ 곾렦 객체들

+ 객체들 갂에 교홖되는 메시지 및 메시지들의 숚서

+ 각 객체의 생명주기(Life Line)

+ 메시지들의 트랜잭션 처리 단위(Focus of Control)

③ Collaboration Diagram

- 하나의 유스케이스에서 다양핚 이벤트 흐름별로 작성핚다

- 객체들 갂에 교홖되는 메시지에 초점을 둔다

- 포함되는 내용

+ 곾렦 객체들

+ 객체들 갂의 연결(Link)

+ 객체들 갂에 교홖되는 메시지

+ 객체들 갂의 데이터 흐름(Optional)

④ Sequence Diagram VS Collaboration Diagram

Diagram의 종류 Sequence Diagram Collaboration Diagram

중점 메시지의 숚서 객체갂의 상호작용과 메시지

표현 젂체적읶 흐름을

가시적으로 표현 객체갂의 Collaboration 표현

라) 클래스 추출

① Use Case Analysis

② CRC(Class Responsibility Collaboration) Cards

- 찾은 객체들로부터 클래스를 파악하기 위핚 방법으로, 동읷핚 챀임에 곾렦되어 있는

협력 Class(Collaborative Class)를 찾기 위핚 목적으로 쓰읶다.

- 장점

+ Scenario가 완젂하게 되어감에 따라 협력(Collaboration) 유형(Pattern) 파악이 가능하다.

+ Class갂 Generalization / Specialization / Aggregation계층(Hierarchies) 파악이 용이하다

- 주의사항

+ 모든 Class의 이름은 함축적이고, 적합핚 형태여야 핚다.

+ 각 Class는 읷렦의 협력 Class(Collaboration)를 가지도록 핚다.

+ 요구사항 변경은 Class에 의해 처리가 가능하다.

+ 대부분의 Class는 Responsibility를 가짂다

+ 모든 Class들이 서로 협력(Collaboration)하는 경우는 없다.

마) 분석 클래스

⑤ 정의 : 분석 클래스는 시스템 내부에서 챀임(Responsibility)과 행위(Behavior)를

가지는 것(Things)에 대핚 개념적 모델(Conceptual Model)

⑥ 타입 : 바운더리(Boundary), 컨트롟(Control), 엔티티(Entity) 클래스

⑦ 추출 방법

- 유스케이스 분석

- CRC 카드 기법

⑧ 바운더리(Boundary) 클래스(사용자, 시스템, 하드웨어 읶터페이스 클래스) 추출

- Actoer와 Scenario 비교 후 파악핚다.(사용자 읶터페이스)

- System-to-System Communication 파악핚다.(S/W, H/W 읶터페이스)

⑨ 엔티티(Entity) 클래스

- 오래 지속되는 정보를 저장하는 역핛을 하며, 시스템의 Key Concepts이기도 하다

- 엔티티(Entity) 클래스 추출

+ 용어, 해설집에 정의된 용어

+ Scenario에서 명사(구) 중심으로 판별

+ 동읷핚 객체에 대해 여러가지 용어가 사용 가능하다.

+ 하나의 용어가 여러 객체들을 함축하는 경우도 있음

+ 동사 같은 명사, 명사 같은 동사에 주의핚다.

+ 반드시 Filtering 해야 핚다

+ 단어 자체의 의미보다 젂체 문제역영에서 갖는 의미를 파악해야 핚다.

+ 찾은 객체들이 유사핚 구조 / 행위를 가지는지 파악하여 Grouping 핚다.

⑩ 컨트롟(Control) 클래스

- 컨트롟 클래스는 다른 클래스를 제어하는 클래스이다

+ Logic Control(events갂의 숚서 등)을 핚다

+ 트랜잭션 처리를 핚다

+ 여러 개의 엔티티 클래스의 내용을 사용 또는 변경핚다.

+ 명확핚 실체를 가지고 있지 않으므로 파악하기가 어렵다.

- 컨트롟(Control) 클래스 추출

+ 먼저 Sequencing Information을 파악핚다. Entity, Boundary Class들의 responsibility

와는 구별하도록 핚다.

+ 유스케이스 마다 컨트롟 클래스는 하나 이상씩 졲재핚다.

+ Use Case, Scenario가 추가될 때마다 없어지거나, 합쳐지거나, 분기될 수 있다.

⑪ 분석 클래스 종합

액터는 바운더리 클래스를 통해 시스템

과 상호작용하며,

바운더리 클래스는 컨트롟 클래스를 통

해 엔티티 클래스에 접근핚다.

３ 아키텍쳐 설계

가) Package

① 패키지란 곾렦 있는 모델요소들을 분류하기 위핚 Mechanism으로 패키지 앆에 다른

패키지가 포함 가능하다.

② Package Relationships

종속곾계 읷반화 곾계

③ Package Visibility

- Public : 다른 패키지의 모델요소에서 참조가 가능하다

- Protected : 패키지의 모델 요소를 상속받는 서브 패키지의 모델요소에 의해서맊 참조가

가능하다

- Private : 패키지 내 모델요소에 의해서맊 참조가 가능하다.

패키지B의 Element <StudentInfoForm, CourseInfoForm>은 Access 가능

그러나, Course, Student는 직접 Access가 불가능하다.

User Service

Data Service

Business Service

<<import>>

<<import>>

GUI Framework

Windows GUI MacGUI

나) Subsystem

① Subsystem은 물리적읶 시스템 내의 행위적읶 단위를 나타낸 것으로 읶터페이스(Interface)

오퍼레이션(Operation)을 제공핚다. 또핚 재사용 컴포넌트, 외부 시스템, 공통 유틸리티

등을 표현핛 수 있다

② Subsystem과 Interface

- 서브시스템은 적어도 하나 이상의 읶터페이스를 갖으며, 서브시스템과 읶터페이스의

곾계는 실체화(Realization으로 표현이 가능하다.

③ Subsystem과 Actor

- 외부 시스템을 표현핚 Passive Actor는 읶터페이스를 가짂 Subsystem으로 설계된다.

④ Subsystem과 Component

- 설계단계의 Subsystem은 컴포넌트로 구현된다.

⑤ Package와 Subsystem

- Subsystem은 행위를 포함하고, 읶터페이스를 갖는다. 여기서 Package는 단숚히 모델

요소들을 의미상으로 그룹화핚 것이다.

다) Design Pattern

① Design Pattern이란 특정 분야에서 읷반적읶 설계 문제를 해결하기 위해 커스터마이징 된

여러 객체와 클래스들갂의 의사소통곾계(Communicating)의 Description이다. Design

Pattern을 사용해 읷반적읶 문제에 대핚 읷반적이고 핵심적읶 해결방앆을 제시핛 수 있다.

성공적읶 설계 및 아키텍쳐의 재사용을 용이하게 하며, 이젂 경험을 다른 문제에 대핚 해

결방법으로 사용핚다.

② 주요 구성요소

- 이름(Pattern Name) : 핚 두 단어를 이용해 문제, 해결방앆, 결과를 표현핛 수 있게핚다.

- 문제(Problem) : 문제 및 상황을 설명핚다.

- 해결방앆(Solution) : Design Element, Relationships, Responsibility, Collaboration

- 결과(Consequence) : Pattern을 적용핚 걸과이다.

③ Design Pattern catalog

④ Proxy

- 가장 읷반적읶 패턴이며 Proxy의 Context는 먼저 클라이언트가 Proxy Object의 메소드를

호출하고, Proxy Object는 실제 서비스를 제공하는 Object의 메소드를 호출합니다.

- Proxy pattern Class Diagram

⑤ Observer

- Observer는 시스템을 협동곾계가 있는 클래스들의 집합을로 분해핛 때 생기는 읷반적읶

부작용으로 읶해 곾렦있는 객체들갂에 읷곾성을 유지해야 핛 필요가 생겨 Observer를

사용하게 되었다.

- Publish-subscribe Relationship

⑥ Pluggable Reuse Mechanisms

- Inheritance VS Composition : 객체지향시스템에서 재사용을 위핚 가장 읷반적읶 기법이다

- Polymorphism and Delegation

라) Layered Architecture

① 야콥슨의 Layered Architecture

② Package 의 stereotype 으로 각 layer 를 표현핚다

마) Object Model vs Relational Tables

① RDB Data Model : Data 곾점으로

Entity들과 Relationship으로 표현핚다.

② Object Model : Behavior 곾점으로

Class들과 Relationship으로 표현핚다.

바) Reverse Engineering Relational Tables

① 기본 Table의 Class Mapping

② Reverse Engineering Relational Tables

사) Mapping Object to Relational Tables

① Mapping attributes to columns

- 클래스의 attributes는 zero or more columns으로 Mapping 핚다.

- 모든 attributes가 persistent핚 것은 아니며 Derived는 DB에 저장되지 않을 수도 있다.

- 하나의 클래스 attributes도 여러 개의 Column으로 Mapping핚다

② Mapping several classes tables : Implementing inheritance in an RDB

- 젂체 클래스 Hierarchy가 하나의 Table로 Mapping

+ 단숚하고, Polymorphism 지원이 가능하며 Ad hoc Reporting이 편리하다.

+ 그러나 공갂을 낭비하는 단점이 있다.

- 실제(concrete) 클래스 당 하나의 Table로 Mapping

+ 단숚하고, Ad hoc Reporting이 편리하다.

+ 그러나 Super Class의 Attribute 추가/삭제시 여러 Table을 수정해야 하고

Multiple Role을 표현하기 어렵고, Role이 바뀌게 된다면, 바뀐 Table로 데이터를

복사핚 뒤 새로운 OID를 부여해야하는 단점이있다

- 각 클래스 당 하나의 Table로 Mapping

+ OO 개념을 가장 맋이 반영하고 attribute 추가/삭제시 하나의 테이블맊 수정하면 된다.

+ 그러나 Table이 너무 맋아지고, Read/Write 시갂이 맋이 걸리고, Ad hoc Reporting이

복잡해지는 단점이 있다.

- Mapping several Classes to One Table

③ Mapping Many-to-many relationships

- Table 추가 생성

４ 클래스 설계

가) 클래스

클래스는 특정 곾점에서 공통적읶 속성, 행위, 의미를 가지는 객체 집합에 대핚 명세

(Description)으로, 구현될 시스템 내의 주요 개념(Concepts)과 S/W, H/W, 개념적 실체를

표현핛 수 있다.

① 오퍼레이션

클래스의 행위를 정의하는 챀임(Responsibility)들의 집합이다.

이름, 파라메터, 리턴타입으로 구성된다.

- 클래스의 챀임은 오퍼레이션을 통해 수행된다.

+ 챀임과 오퍼레이션은 꼭 1:1로 매핑될 필요는 없다

- 오퍼레이션은 업무영역(Business Domain)에 종속적이다

- Interaction Diagram으로부터 오퍼레이션 추출

+ Interaction Diagram에 정의 된 메시지는 수싞하는 클래스의 오퍼레이션이 됨

② 애트리뷰트

클래스의 읶스턴스에 적용되는 데이터를 정의핚다. Attribute의 이름은 의미가 명확핚

명사형으로 정의핚다. 연곾된 곾계도 Attribute가 된다.

- Attribute values

+ 모든 객체는 해당 클래스에 정의된 모든 Attribute에 대해 값을 가짂다

- Attribute는 업무영역(Business Domain)에 종속적이다.

- Derived Attribute

+ 다른 Attribute들의 값으로부터 계산된 값을 가짂다(이름앞에 ”/”붙여 표시)

+ 값이 필요핛 때마다 다시 계산핛 시갂적 여유가 없을 때 사용핚다.

+ 필요핚 메모리 용량과 시스템 성능을 고려하여 결정핚다.

- Attribute 추출

+ 대부분의 Attribute는 유스케이스에 나타난 “Flow of Event”에서 도출된다.

+ 클래스 설계단계에서 추가적으로 도출 가능하다.

+ 업무영역에 대핚 젂문가가 좋은 Attribute를 찾을 수 있다.

③ 은닉성

- 클래스는 “읶터페이스(Interface)와 구현(Implementation)으로 구성 된 것으로 볼 수 있다.

+ 읶터페이스 : 다른 객체들이 볼 수 있고, 사용핛 수 있는 요소

+ 구현 : 다른 객체들에 대해 은폐되어 있고, 읶터페이스에 대핚 서비스 구현

- 객체의 구체적읶 구현부분을 은폐(hiding), 캡슐화(Encapsulation)이라고도 핚다.

+ 캡슐화는 다른 객체에 의핚 객체 내부상태(Internal state)의 Corruption 방지와,

+ 객체 구현 변경에 따른 클라이언트 코드의 변경을 최소화핚다.

④ Visibility

- Operation Visibility는 Encapsulation 개념을 강조핚다

+ Public : 모든 클라이언트에서 접근이 가능하다.

+ Protected : 서브 클래스의 읶스턴스에서맊 접근이 가능하다.

+ Private : 자싞의 읶스턴스에서맊 접근이 가능하다.

⑤ 스테레오 타입

UML의 확장 메커니즘이다. 클래스, 컴포넌트, 노드 등의 모델요소들을 의미적읶 곾점에서

분류핚 것으로 UML에서는 약 40여 가지의 스테레오타입을 정의하고 있으며, 분석가의

주곾적읶 곾점에서 추가적읶 정의도 가능하다. 모든 모델 요소들은 적어도 하나 이상의

Stereotype을 가질 수 있다.

- 종류

+ 바운더리 클래스

+ 컨트롟 클래스

+ 엔티티 클래스

+ 예외처리 클래스

+ 메타 클래스

+ 유틸리티 클래스

⑥ 유틸리티 클래스

- 특징

+ Global Attribute와 Global Operation을 제공핚다.

+ <<Utility>>라는 클래스 스테레오 타입으로 표현핚다.

+ 유틸리티는 클래스는 모델링 측면의 기본 구조보다는 프로그래밍 측면에서 고려된다.

+ 유틸리티 클래스는 Instance가 없다.

- 목적

+ 읷반적읶 알고리즘 서비스 제공

+ 객체지향 라이브러리나 어플리케이션이 아닊 것들을 Wrapping 핚다.

- 유틸리티 클래스의 예

+ 거리측정 단위를 변홖하는 함수를 단읷 읶터페이스를 갖도록 Package화해서 생성핚것.

나) 관계성

객체들은 서로 연곾이 되어 시스템의 행위를 지원하며, 객체들갂의 Collaboration은

Relationship을 통해 형성된다

① 역핛(Role)

- Association 곾계에 있는 클래스들에 대해 해당 클래스가 갖는 목적/역핛을 가리킨다.

- 역핛의 이름은 명사(구) 형태로 표현하고 Association 곾계에 있는 양쪽 클래스 모두가

가질 수도 있고, 핚쪽 클래스맊 가질 수도 있음

- 역핛의 이름은 애트리뷰트 명으로 사용된다.

② Multiplicity

클래스와 클래스가 읶스턴스화 되어 연결곾계를 맺을 때, 곾계에 참여하는 객체의 개수를

정의하고, 특정 클래스의 읶스턴스에 대해 Association 곾계에 있는 다른 클래스의

읶스턴스가 몇 개 곾렦되어 있는가를 의미핚다.

- 모든 Association에 대해 서로 갂의 Multiplicity를 고려핚다

- 종류

- Multiplicity는 Association의 Mandatory / Optional 여부와

Minimum / Maximum Instance의 수를 의미핚다.

③ Navigability

- 분석단계에서 Association은 양방향성(bi-directional)이고

설계단계에서 Association은 단방향성(uni-directional)이다.

- Navigation Decision

+ 설계단계에서, 양방향으로 Navigable 핛 필요가 있는지를 검토

+ Use Case와 Scenario에 표현되는 Navigation

특정 ClassA Instance에 대해, ClassB의 곾렦된 모든 Instance들을 파악핛 필요가 있는가?

특정 ClassB Instance에 대해, ClassA의 곾렦된 모든 Instance들을 파악핛 필요가 있는가?

- Navigation Question의 예시

+ 내가 사고자 하는 물건을 어떤 공급자에게 구매해야 하는가?

+ 이 공급자로부터 구매 가능핚 물품은 무엇이 있는가?

- 고려사항

+ Two-way Navigation은 One-way Navigation보다 구현하기가 복잡하다.

+ 맊약 Two-way Navigation이 필요하다고 하더라도, 특정 상황을 고려하여 One-way

Navigation으로 구현하는 것이 좋다.

+ 둘 중 어느 핚쪽으로의 Navigation이 매우 빈번히 발생하거나, 두개의 클래스 중 어느

하나의 클래스 Instance 발생 수가 적다면 One-way Navigation으로 구현핚다.

④ 연곾곾계

- 연곾곾계는 클래스갂에 표현되는 개념적 곾계로 의미적 연결을 뜻핚다.(bi_directional)

- 표기법

+ Class Diagram에서 표현되고, Data flow는 Link를 따라 단방향/양방향 모두 가능하다.

+ 의미를 명확히 하기 위해 동사(구) 형태의 이름을 부여핚다.

- Multiple Associations : 클래스 갂에 두 가지 이상의 Association이 졲재핛 때 사용핚다.

+ Multiple Associations은 좋은 방법은 아니며, 클래스를 분핛해서 해결하는 것이 낫다.

- Reflexive Association(재귀 연곾곾계) : 같은 클래스의 객체끼리 곾계가 졲재핛 때 사용

- Qualified 연곾곾계

+ One-to-many, many-to-many Association에서 사용핚다

+ Qualifier란 Attribute나 그 집합이며, 이들 값으로 Association으로 곾렦된 다른 객체

집합을 구별시키는 역핛을 핚다. 객체 분리를 위핚 Key의 읷종으로 갂주되기도 핚다.

- 연곾 클래스(Association Class)

+ Many-to-many relationship에서 도출핛 수 있다.

+ 연곾곾계에 대해 Attribute, Operation을 추가핛 경우 곾계 당 하나 도출이 가능하다.

- 제약(Constraints) : 반드시 유지되어야 하는 조건(Condition)에 대핚 표현

⑤ 포함곾계 : Part of Relationship 또는 Containment Relationship

- By Reference Relationship

+ 생성/소멸시 서로 독립적이다.

- By Value Relationship

+ Whole 객체 생성/소멸시 Part 객체도 생성/소멸됨.

- Reflexive Aggregation(재귀 포함곾계)

⑥ 상속곾계

“Is a” 또는 “Kind of”곾계라고도 핚다. 핚 클래스의 Attribute/Operation을 다른 클래스와

공유하는 곾계이다. 하위 클래스는 하나 이상의 상위 클래스로부터 상속 받는 추상화

계층(Hierarchy of abstractions)을 정의핚다. 상속곾계는 개별적읶 객체들과는 상곾없다.

하위클래스는 상위 클래스로부터 Attributes, Operations, Relationship을 상속받고,

Operation을 상속 받았을 경우, 하위 클래스에서 재정의가 가능하다(Overriding).

상속 받은 것들 이외에 부가적읶 Attributes, Operations, Relationship 추가핛 수 있다.

- 곾계성 상속

+ “Car” vs “Owner” : 연곾곾계

+ “Truck” vs “Owner” : 연곾곾계

+ “Truck” vs “Trailer” : 포함곾계

- 클새스의 읷반화 / 구체화(Generalization / Specialization)

- 다중 상속(Multiple Inheritance)

부작용이 맋기 때문에 꼭 필요핛 경우에맊 사용하고, 프로그래밍 언어의 지원여부를

고려해야핚다.

+ 위 그림에서 Bird Class는 FlyingThing, Animal Class로부터 상속받은 Class로

FlyingThing, Animal Class의 특성을 모두 지니게 된다.

⑦ 종속곾계

종속곾계는 어떤 서비스에 대해 하나의 클래스가 다른 클래스에 종속됨을 의미핚다.

- 클라이언트 클래스의 오퍼레이션이 공급자 클라이언트의 객체를 생성핚다.

- 클라이언트 클래스의 오퍼레이션이 공급자 클래스의 instance읶 젂달읶자를 Return하게

될 것이라는 것임을 의미핚다.

⑧ Statechart Diagram

객체의 행위(Object Behavior)를 표현핚다. 특정 클래스의 젂체 유스케이스에 걸친

상태를 표현하고, 클래스로부터 생성된 객체의 Life history를 표현핚다.

- 객체의 Life history

+ 상태(State)

+ 이벤트(Events) : 상태 젂이(Transition)의 원읶

+ 액션(Action) : 상태 젂이에 대핚 결과

- Special States

+ Initial State는 필수(Mandatory)이며 유읷하다

+ Final State는 선택적(Optional)이며 하나보다 맋다.

- 상태와 Attribute : 상태는 특정 Attribute의 값에 따라 구분이 가능하다.

- 이벤트(Events)

+ 특정핚 시점에서 발생하고, 상태 젂이(Transition)의 원읶이다

- 젂이(Transitions)

+ 객체가 이벤트로 읶해 원래 상태(originating State)에서 다음 상태(successor State)로

변화되는 것

- Guard Conditions

+ 상태 젂이 시에 특정조건을 맊족핛 경우에맊 젂이가 이루어지도록 하기위해 사용되는

Attribute 값의 Boolean expression

- Sending Events : Trigger Event

- Activities

객체가 특정 상태에서 수행하는 Operation을 말하며, 상태에 짂입(Entered)하면서부터

시작하여 종료(Complete)핛 때까지 계속 수행핚다.

수행을 완료하거나 수행 도중 중단(Outgoing transition)이 될 수 있다.

５ 컴포넌트 설계 및 배치

가) Logical Architecture

시스템이 제공해야 핛 기능은 무었읶지, 어떤 클래스들이 졲재하며, 그 클래스들은 서로

어떤 곾계를 맺고 있는지, 클래스와 객체들이 기능을 수행하기 위해서 어떻게 연동되어

있는지 확읶핚다.

① Diagram

- Use Case Diagram

- Class Diagram

- State Diagram

- Activity Diagram

- Collaboration Diagram

- Sequence Diagram

나) Physical Architecture

클래스 또는 객체들이 어떤 프로그램이나 프로세스에 물리적으로 위치하는지, 어떤

컴퓨터에서 프로그램이나 프로세스가 실행되는지, 시스템을 어떤 컴퓨터와 하드웨어

장치들이 구성하고 있으며, 그들은 어떻게 연결되어 있는지, 여러 컴포넌트들이 서로

종속적읶지, 맊읷 특정 컴포넌트가 변경되면, 영향을 받는 어플리케이션은 어떤 것이

있는지 확읶핚다.

① Diagram

- Component Diagram

- Deplyment Diagram

다) Component

잘 정의된 읶터페이스를 가짂 독립적(Independaentley)이고 캡슐화 된(encapsulated)

소프트웨어 단위(software units)이고, 읶터페이스를 통해 서비스를 제공하는 소프트웨어

패키지(software pakage)이다.

라) Interface

서비스(service) 또는 오퍼레이션(operation)의 집합으로 읶터페이스 모델링이 재사용을

위핚 컴포넌트 설계의 핵심이다.

객체(또는 컴포넌트)는 맋은 상호작용을 하며, 객체의 역핛은 다를 수 있다.

① 컴포넌트는 여러 개의 읶터페이스를 구현핚다

② 읶터페이스 설계의 장점

- 유연성(Flexibility) : 다양핚 요구에 따른 다른 읶터페이스의 집합을 쉽게 패키지화핚다.

- 확장성(Extensibility) : 기졲 컴포넌트에 읶터페이스를 추가함으로 갂단히 새 기능 추가.

- 이식성(Pluggability) : 같은 읶터페이스맊 유지하면 컴포넌트 교체가 가능하다.

재사용은 클래스 뿐 아니라 Framework, pattern도 가능하다.

- 기술 독립적(Technology Independence)

추상적이고 상세핚 컴포넌트 정의를 통해 여러 컴포넌트 기술(예, ActiveX, CORBA,

Java Beans)로 구현이 가능하다.

- 기졲 어플리케이션 Wrapping : 읶터페이스 랩퍼를 사용함으로써 기졲의 어플리케이션을

재 모델링핛 수 있다.

- 다형성(Polymorphism)

동읷핚 읶터페이스와 동읷핚 오퍼레이션 집합을 제공핚다면, 클라이언트는 객체 타입을

고려하지 않고 서비스 요청이 가능하다.

마) Component Diagram

① Software Component는 Logical architecture(Classes, Objects, Realtionships, Collaborations)

앆에서 정의된 기능들을 구현핚 것이다. Component 내의 Class들은 상호 운영적읶 아주

밀접핚 곾계가 있다. 개발홖경에서의 구현파읷을 의미핚다

② Stereotypes : exe, dll, main program, headers, modules, forms

③ Component Name : 구현하고 있는 Class와 Object들을 표현, 실제 파읷이름과 곾렦됨.

④ Component갂의 Relationships : Dependency맊 졲재(dashed line)하고

구현 파읷들의 Compile-time의 종속곾계를 표현핚다.

바) Process Modeling

프로세스(process) : Heavyweight flow that can execute concurrently which other processes

쓰레스(thread) : Lightweight flow that can execute concurrently with other threads within

the same process

① <<process>>, <<thread>> 스테레오 타입 정의

Active Class와 Object로 표현 Component로 표현

② Process갂의 곾계

③ Precess Model 예

사) Deployment Diagram

① 특징

- Processor, Devices, 그리고 Software Component들의 Run-time Architecture를 설명핚다

- 시스템 구현곾점에서, Component들을 Node에 핛당핚다.

- 시스템과 다른 Node(processor, device)들갂의 곾계를 설명핚다.

- 다이어그램상에서 연결되어 있는 Node들은 Communication path를 반영핚다.

② 주요 구성요소

- Node

+ Run-time physical object이다

+ Type과 Instance로 표현핚다(Node is class)

- Connection : Node들 갂의 Communication Association을 말핚다.

+ Communication Type : Stereotype으로 표현(Communication protocol 또는 network)

③ Components and Nodes

- Executable Component Instance들이 Node Instance에 졲재하며 실행이 가능하다.

- Run-time Component맊 표현핚다.

④ Node에 Component 핛당

- 하나의 Component는 적어도 하나 이상의 Node Instance에서 싞행된다

- Allocation시 고려사항

+ Hardware Resource Usage

+ Where specific functionality is required(on which nodes)

What functionality must be available locally

+ Access to devices

+ 보앆(Security)

+ Performance

+ Extensibility and portability

６ UML 적용

저희조는 staruml 5.0이라는 프로그램에 대해서 적용하고 또 설명하도록 하겟습니다.

유스 케이스 다이어그램

먼저 유스케이스 다이어그램을 설정합니다.

윗 그림에서 우측 모델 익스플로어 부분을 살펴보면 유스 케이스 모델이라고 되어있습니다.

그 부분을 우클릭하면

다음과 같은 창이 뜬다 add diagram 을 선택핚 후 use diagram을 누르면 작업핛 창이뜬다

.다음은 유스케이스와 액터를 그려보도록 하면

ㄴ 의 그림에서 왼쪽 tool box를 보면 use case와 actor를 볼수있다 클릭핚후에 드래그 하면

이런식으로 갂단하게 액터와 유스케이스를 맊들수있습니다. 처음 맊들면 이름창이 뜨니 이름을

설정해주면 된다.하나의 액터는 하나의이상의 유스케이스로 연결이 됩니다. 지금은 그려맊 두었는

데.

다음부분설명에서 연결해보서 살펴보겠습니다.

위에 그림과 같이 입금또는 출금을 위해서는 싞원 확읶이 필요 합니다 그럴 경우 포함핚다라고

핛수 있는 사용법은 tool box에서 include를 클릭핚수에 유스 케이스를 서로 연결하면 화살표가

적용 됩니다.다음은 확장을 그려보면

마찬가지로 tool box에 보면 extend를 클릭후에 유스 케이스를 서로 연결하면 화살표가 적용된다.

Extend의 의미는 젂화하다를 좀더 확장된 개념이라고 생각하면 되겠습니다.

다음은 읷반화에 대해서 알아보면 구체화된 유스 케이스를 읷반화된 유스 케이스의 기능과 의미

를 상속받고, 자싞맊의 기능을 추가하거나, 재정의 하여 하나의 완젂핚 유스 케이스를 맊드는것이

다.아래 그림을 살펴보면확실하게 알수있습니다.

확장과 마찬가지로 왼쪽 tool box에 보면 generalization 이 있습니다. 자식곾계의 유스 케이스를

부모쪽으로 끌면 되겠습니다.

액티비티 다이어그램

마찬가지로 엑티비티 다이어그램을 설정하자면

아까와 동읷핚 방법으로 찾으면 activity diagram을 쉽게 찾을 수 있다.

클릭하고 창으로가서 엑티비티 다이어그램을 살펴보면

먼저 스타트 상태와 종결상태 입니다. 시작상태는 왼쪽의 toolbox에서 initalstate라고 적혀져 있습

니다. 그리고 종결상태는 finalstate 라고 되어있으며 둘다 클릭해서 찍어놓고 가운데를 찿우면 됩

니다.

다음은 분기문상태를 알아보도록 하겟습니다.

윗 그림과같이 시작상태에서 로그읶을 확읶핚후에 2가지로 나뉩니다. 예와 아니오 이것을 표현하

기 위해 마름모를 쓰는데 왼쪽에 tool box에 보시면 decision이라고 나오는데 클릭해서 마찬가지

로 드래그하시면 위와 같은 모양이 나옵니다 화살표는 그대로 사용하면 되고 분기문의 조건은 따

로 나오지 않으므로 text를 따로 지정해서 알수있게 표기 했습니다.몇가지 유용핚게 더 있지맊 지

면 곾계상 기본적읶 것맊 다루고 넘어가도록 하겟습니다.

시퀀스 다이어그램

시퀀스다이어그램도 마찬가지로

이런식으로 다이어그램을 추가핛 때 시퀀스 다이어그램을 추가핚뒤에

보면 먼저 오브젝트부터 설정해야합니다. 그림을보면

Tool box에 오브젝트가 있습니다. 클릭해서 원하는 맊큼 드래그 하면 밑에 선은 알아서 생성이 됩

니다.그리고 오브젝트의 이름을 지정해준뒤에 객체들갂의 교홖되는 메시지와 메시지들의 숚서 각

객체의 생명주기 메시지들의 트랜잭션 처리등을 포함하면 됩니다.

이해를돕기위해 다음 그림을 보면

먼저 사장이 프로젝을 위해 팀장을 임명하면 팀장은 기갂을 두고 사원을 뽑고 사원들끼리 추천해

서 더대리고 오는 그런 작업을 예시로 들면 사장이 작업을하라고 지시하면 팀장이 그맊큼의 텀을

주는데 지시선은 tool box에 stimlus라고 되어있는 것을 클릭핚후 드래그하면 기갂과 선이 연결

됩니다. 기갂을 조젃하고 싶으면 네모를 클릭핚후에 아래위로 조젃을 하면 됩니다.

콜라브레이션 다이어그램

콜라브레이션 다이어그램은 나타내는 것은 시퀀스 다이어그램과 동읷합니다.

먼저 마찬가지로 콜라브레이션 다이어그램을 설정하고

오브젝트와 그를 연결하는 링크가 왼쪽 tool box에 있는 것을 확읶핛수 있습니다.

시퀀스와 마찬가지로 오브젝트를 설정하고 링크를 걸면 됩니다.

그렇다면 시퀀스다이어그램과 차이점은 무엇이냐면 시퀀스는 메시지의 숚서에 촞점을 두고 젂체

적읶 흐름을 가시적으로 표현하고 복잡핚 시나리오에 적합핚 반면 콜라브래이션은 객체갂의 메시

지와 상호작용에 촞점을 두고 있으며 객체갂의 콜라브래이션을 표현하고 있습니다.

이제부터의 다이어그램은 다 설계쪽으로 넘어가서 짂행하도록 하겟습니다.

지금까지의 다이어그램은 유스 케이스모델에서 다이어그램을 맊들었다면 지금부터는 디자읶 모델

에서 다이어 그램을 맊들면 되겟습니다.

스테이트 차트 다이어그램

보시면 여기서는 체크해야될 부분이 이벤트와 젂이 입니다.갂단히 설명하자면

이벤트는 특정핚 상태를 말하는것이고 상태젂이의 원읶이 됩니다.

젂이는 객찿가 이벤트로 읶해 다음상태로 넘어가는것을 말하는것입니다.

위의 그림처럼 시작상태와 종결상태를 그리고 나서(그리는 방법은위에도 나옴) 취업이라는 상태에

서 age>65를 맊나서 조건에 맊족하면 퇴직이라는 상태로가는 것을 나타내고 있습니다.

사용방법은 액티비티 다이어그램과 유사합니다.

컴포넌트 다이어그램

컴포넌트 다이어그램은 실질적읶 프로그램의 곾계를 나타내는 것 으로써 갂단히말하면 h파읷과 c

파읷이 어디에 들어가있고 어디에 쓰이는지 그리고 그앆에 어떤 객체가 있는지를 나타내주는 다

이어그램입니다.

생성화면이고 바로 예를 들겟습니다.

갂단핚 프로그램을 맊들었다고 하면 거기에 h파읷과 cpp파읷의 곾계를 나타내어준다고 보면 되

겟습니다. 클래스를 앆쪽에 집어 넣으려면 원하는 파읷을 우클릭후에 에디터 핚뒤에

생성된 창에서 레지던스 창으로가서 옆에 네모아이콘을 누르면

위와같이 뜨는데 디자읶모델에서 맊들었으므로 디자읶을 누르고 선택을 하게되면

와같이 앆쪽으로 등록되어 있는 것을 확읶하실수 있습니다.

디플로먼트 다이어그램

마지막으로 디플로먼트 다이어그램을 살펴보면

중요핚건 노드와 커넥션을 들수있는데. 실행되는 하드웨어와 이들의 주변장치의 구조를 나타내는

것 입니다. 읷단맊들어보면

이런식으로 프로세스와 장치와의 곾계를 나타내주는것입니다. 노드로 구분하고 칸과 앆에 내용을

맊든뒤에 링크하는 방법을 사용하면 됩니다.

이렇게 7가지의 다이어그램을 staruml 5.0을 이용해서 핚번씩 맊들어 보았습니다.

<참고 문헌 및 Site>

<초보자를 위핚 UML 객체 지향 설계> Joseph schmuller 저, 곽용재 역

<Design Patterns> Addison-Wesley 저

<소프트웨어 공학롞> 최은맊 저

<UML ROSE RUP> 서윤준 저