<Software Engineering>

Introduction to

OOAD Using UML Tools

Professor : 유준범 교수님

Team Member : 200711472 진교선

200711431 박성훈

200711460 이상열

200711465 이홍재

Outline

1. Introduction

A. What is OOAD?

2. OOAD Process

A. Basic Concepts in Object-Oriented

B. Benefits of OOAD

C. OOA & OOD

D. UML Tools for OOAD

E. OOAD Process

3. UML

A. Unified Approach to OOA

B. UML Notation

C. Introduction UML Tools

4. Introducing UML Tools

A. Star UML

B. UMLet

5. OOAD Application Using UML

A. Blackjack Game

6. Conclusion

1. Introduction

OOAD 는 Oriented – Object Analysis & Design 의 약자로 기존의 SOAD 와는

상반된 개념으로 Class 와 Object 를 기반으로 한 Software Design 을 일컫는다

.

A. What is OOAD?

OOAD 는 기본적으로 실제 세상을 Object 의 세상으로 규정하고, 주어진 문제를

Object 간의 관계로 보아 해결하는 것을 의미한다. OO Paradigm 은 C++, Java,

Smalltalk 등의 프로그래밍 언어에서 쉽게 이해 할 수 있다. 이러한 프로그래밍

언어들은 Class 를 통해 Object 를 specification 하고 그러한 Object 들의

Method 를 통해 Object 의 State 변화 혹은 Relationship 을 표시하게 된다.

2. OOAD Process

A. Basic Concepts of OOAD

i. Classes and class Hierarchies

가) Instances : 클래스의 instance 는 Class 가 Object 를 생성 하는 것을

말한다. 따라서 Abstraction 은 Instance 를 가지지 않는다.

나) Inheritance : Class 간의 상속관계이며 하위 클래스는 상위 클래스의

모든 Member 와 Method 를 상속받아 그대로 혹은 재구성 하여 사용

할 수 있다. Inheritance 자체가 Class 간의 Relationship 이기도 하다.

다) Abstraction and hiding : Abstraction 은 구현되어 있지 않은 Class 를

의미하며 하위 클래스들의 Behavior 를 specification 하게 된다.

Hiding 은 Member 를 Private 로 설정하여 특정 Method 이외에는

접근하지 못하게 하는 것으로 Encapsulation 의 핵심이 된다.

ii. Object

가) Attributes : Class 로부터 생성된 Object 가 가지는 데이터를 말한다.

나) Methods : Object 의 Method 는 Object 의 State 변화 혹은

Member 변수를 접근하는 역할을 하며, 다른 Object 와의

Relationship 을 구체화 해놓은 것이다.

다) Encapsulation : 한 Object 의 독립성을 보장하는 속성으로, Object 의

Member 를 Method 를 통해서만 접근이 가능하도록 하는 것이며,

이를 통해서 Object 는 독립적은 Module 로서 Software 에 존재하게

된다.

라) Polymorphism : Same Hierarchy 상에 존재하는 Method 간의

Overriding 을 말한다. 이러한 Overriding 을 통해 Abstraction 에서

정의한 behavior 를 구현하고, 상속받은 Method 를 상황에 맞는

형태로 재구성하여 사용할 수 있다.

iii. Messages

B. Benefits Of OOAD

이러한 OOAD 의 장점에는 무엇이 있는지 살펴보도록 하겠다. 기본적으로 이러한

OOAD 의 장점은 B. 에서 논한 OOAD 의 기본적인 특성에서 도출 되는 것이다.

A. Benefits of OOAD

가) OO approach 는 함수들의 관계가 아닌 실제 세상의 concept로 문제

에 접근하는 방식이다.

나) 사용자의 requirement에 맞춰 문제를 이해하고 개발할 수 있다.

다) 안정성 있는 디자인을 이끌어 낼 수 있다.

라) 디자인의 flexibility가 생긴다.

마) 시스템 분석의 일관성이 유지된다.

바) OO의 기본개념인 information hiding으로 독립적인 reusable 한 클래

스 구성이 가능하다.

사) Maintenance 가 쉬워진다.

B. 각각의 Benefit에 대한 분석

가) OO approach 는 실제 세상의 concept로 문제에 접근한다는 것은 기

존의 sequential 한 디자인 구조에서는 디자인의 주요 구성이 함수들

의 sequential한 호출 관계를 주요로 했다면 OO approach는 객체들이

메소드를 통해 상호관계를 하는 것이 뼈대를 이룬다. 이는 실제 세상

에서 객체 즉 사물끼리의 관계를 도식화 시킨 것이다. 이점에서 OO

approach 는 sequential approach 보다 실제 세상에 더 가깝다 할 수

있다.

나) 사용자의 requirement를 분석하기 편한 점이 OOAD의 장점 중 하나

이다. 이러한 분석의 편의성은 OOAD가 Encapsulation을 통하여 체계

인 Module화를 제공하기 때문이다. 또한 1번에서 논한 바와 같이 실

제 세상과 비슷한 구조를 띄는 것도 한가지 요인이다.

다) 좀 더 빠르고 robust 한 프로그램이 되려면, 구현의 합리성도 중요하

지만 설계 단계에서부터 중복된 멤버를 줄이고, 합리적인 프로세스 선

택이 중요하다. Sequential 한 디자인에서는 한가지 프로세스에 여러

함수끼리의 호출이 발생하고, 각 함수마다 불 필요한 변수들이 존재하

게 되어 프로그램의 안정성을 보장하지 못하는 경우가 발생한다. 하지

만 OOAD에서는 각각의 Object가 필요한 변수들 만을 가지고 있으며

이러한 변수들은 Class 라는 일정한 틀을 기준으로 생성된다

(Encapsulation). 또한 이 변수들을 미리 설계된 Method를 통해서만

접근하게 된다. 또한 Abstraction이 하위 Class 들의 Behavior를 제한

하고 있어 불필요한 method의 생성을 사전에 제한 할 수 있다. 이러

한 OOAD 의 특성으로 인해 더욱더 robust 한 설계가 도출 될 수 있

다.

라) OOAD에서의 design flexibility는 디자인을 변경하는 융통성을 의미하

는 것이 아니다. 여기서의 flexibility는 클래스간의 상호관계를 언제든

지 추가하고 변경 할 수 있다는 의미이다. 이러한 flexibility는 기능의

추가 혹은 변수의 추가에 용이하다. Sequential 한 디자인에서는 기능

의 추가를 위해 그 기능의 함수뿐만 아니라 다른 함수의 구조까지 변

경이 필요한 반면에 OOAD에서는 단순히 클래스의 Method추가 만으

로 기능의 구현이 가능해 진다.

마) 시스템 분석의 일관성은 모듈간의 상호작용이나 기능이 상호 모순적

이지 않다는 의미이다. 예를 들어 온도 유지를 위해 냉방과 난방을 동

시에 한다면 이는 모순적인 디자인이 되는 것이다. 따라서 시스템 분

석을 일관성 있게 하는 것이 효율적인 소프트웨어 디자인의 선결조건

이 된다. 이러한 일관성은 각각의 모듈의 상호작용이 모순되지 않는

것을 의미 하는데, 모듈화가 더욱 간단하게 되는 OOAD 가 이러한 분

석을 더욱 쉽게 만들어 준다는 것을 의미한다.

바) 각각의 Class 는 독립적인 module로 사용된다. Sequential한 디자인

에서도 함수가 그러한 역할을 수행 하지만 사용하는 변수나 타입에

따라 그 reuse가 용이하지 않은 부분이 있다. 함수의 경우 반환되는

값이 하나로 정해져 있기 때문에 한정된 경우가 아니라면 그 재사용

이 불가능하기 때문이다. 반면 OOAD의 Inheritance, Polymorphism의

개념을 도입한다면 하나의 클래스를 디자인의 경우에 맞춰 재구성하

고, 그에 맞는 Method 혹은 Member를 뽑아서 사용 할 수 있다.

사) Maintenance가 용이한 점은 Sequential 한 디자인의 경우 한가지 변

화에 대하여 그 함수 뿐만 아니라 다른 함수 혹은 다른 Module에 영

향을 끼치며, 변화를 하게되는 경우가 발생한다. OOAD는 이미

Encapsulation 되어있는 Module간의 relationship으로 이루어 져 있으

므로 한가지 Module의 변화가 다른 Module에 영향을 끼치지 않는

형태가 된다. 또한 Module간의 process에서 문제가 발생 하였을 경우

문제를 일으킨 Module을 찾아내어 수정 하는 것 또한 쉽다.

C. OOA & OOD

i. OOA Modeling Dimensions

OOA Modeling 의 8가지 방법를 말한다. 문제를 OO Approach로 분석하는

방법이며 이를 통해 OOD를 위한 모델을 설정하게 된다.

가) Identification/Classification of entities : Entity를 Class화 하고 그에

대한 Entity의 정의에 대해 설계한다.

나) General-to-Specific and Whole-to-Part entity relationships : Top –

down design의 형태로 이해 할 수 있는 방식이다. General 한 부

분에서부터 Specific 한 부분으로 설계하는 것이다. 이것은

Process 를 구체화 시켜 각각의 Class에 분배하는 것을 의미한다.

Whole-to-Part 는 전체적인 부분에서부터 각각 쪼개 나가는 것을

의미하는데, 이는 Entity를 Module화 시키고 이들의 관계에 대해

설계 하는 것을 말한다.

다) Description of attributes of entities : 설계된 Entity들의 데이터

flow 설계

라) Large-scale model partitioning : 전체적인 모델을 부분으로 쪼개어

그에 대한 세부 모델을 설정하는 것을 의미한다.

마) States and transitions between states : Object 간의 상태에 따라

데이터 Flow 의 형태가 어떻게 될 것인가에 대한 모델이다. State

Machine Model의 형태로 구성하게 될 것이다.

바) Detailed Specification for Functions : 위에서 설계한 Class와

instance된 Object들의 State변화와 Relationship을 표시해 줄

Method를 설정하는 단계이다.

사) Top-down Decomposition : 이러한 Entity들을 설정하였으면 큰 덩

어리부터 쪼개어 작은 Class 단위까지 분석하는 단계를 거친다. 이

를 통해 지금 까지의 분석이 타당한지를 검사하게 된다.

아) Identification of Exclusive services : Entity들이 제공할 서비스에 대

해서 정의한다.

자) Entity communications : 설계된 Entity간의 관계에 대해 설계한다.

이는 Entity 간의 Method 혹은 Event throwing 으로 이루어진다.

ii. Goals of OOA

가) 성공적인 OOA를 위해서는 다음과 같은 것들이 이루어 져야 한다..

ü 기본적인 Requirement들이 engineer와 customer 사이에서 정해져 있

어야한다.

ü Class가 정의 되어 있어야 한다.

ü Class Hierarchy 가 specify 되어 있어야 한다.

ü Object 간의 관계를 설명 할 수 있어야 한다.

ü Object의 Behavior가 modeling 되어 있어야 한다.

ü 이러한 과정들이 model이 완성될 때 까지 반복 되어야 한다.

iii. Generic Steps for OOA

가) Elicit customer Requirements for the system

ü Customer의 요구사항을 추출해 내는 과정

나) Identify scenarios for use-cases

ü 뽑아낸 요구사항들을 기반으로 사용자가 software을 사용하는 상황을

가정한다. 이러한 가정을 통해 실제 사용될 수 있는 software를 설계

하는데 도움이 된다.

다) Select classes and objects using basic requirements

ü 구성할 System에 적합한 Class를 선별하고 그 Class의 instance인

object를 선별한다.

라) Identify attributes and operations for each system object

ü 사용될 Object가 가지는 데이터를 설정한다.

마) Define structures and hierarchies that organize classes

ü Class 간의 relationship을 표현하는 Hierarchy를 작성한다.

바) Build an object-behavior Model

responsibilitiesdesign

messagedesign

class and objectdesign

subsystemdesign

ü Class로부터 Instance된 Object가 어떠한 프로세스를 수행 할 것인가

에 대한 모델을 설정한다.

사) Review the OO analysis model against use-cases

ü 초기에 설정해 놓은 use-case를 기반으로 분석되어 만들어진 모델이

use-case에서의 프로세스를 수행 하는지에 대해 살펴본다.

iv. Four important concepts in OOD

가) Abstraction : 하위 Class의 Behavior를 정해 놓은 클래스이다. 이

클래스를 상속받은 경우 Abstraction에서 지정한 Behavior를 구현

하지 않은 Class는 instance를 생성하지 못한다.

나) Information Hiding : Member를 클래스 외부에서 접근하거나 데이

터를 변경 하는 것을 막아 놓은 것을 의미한다. Encapsulation과

상통하는 개념이다.

다) Functional Independence : 한 Class 는 기능적으로 독립적인 존재

여야 한다. 이는 Class가 System의 Module로 활용된 다는 것을

의미한다.

라) Modularity : 모든 System의 구성은 독립적은 Module로 이루어

져 있어야 한다.

v. Layer Structure of OOD

가) Subsystem Layer : customer의 요구에

맞춰 software의 작동이 가능하게 해주

는 부분 Non-Functional Requirement 부

분

나) Class & Object Layer : Class Hierarchy

구조

다) Message Layer : entity 간의 relationship에 따른 상호 작용

라) Responsibilities Layer : 구현에 필요한 Data structure 와

Algorithmic design

vi. OOA to OOD

OOA Model OOD Model

Classes

Attributes

Methods

Relationships

behavior

Object

Data Structure

Algorithms

Messaging

Control

vii. Generic Components for OOD

가) Problem Domain Component

ü Customer의 requirements를 직접적으로 구현하는 subsystem

나) Human Interaction Component

ü User Interface 부분. 즉, 인간의 조작을 전제로 하는 Component

다) Task Management Component

ü Subsystem 간의 task 교환을 컨트롤 하는 Component

라) Data Management Component

ü Object 의 저장 및 검색을 담당하는 Component

D. OOAD Process

i. Requirement

가) What is SW Requirement?

ü Functional Requirement

- Statements of services which the systems should provide : 시스템이 제공 해

야 할 서비스에 대한 요구사항이다.

- 이는 System의 특정 input에 대한 reaction과 특정 situation 에 대한

behavior가 포함된다.

ü NFR(Non-Functional Requirement)

- Reliability : System의 robust함

- Response time : Real-time system의 경우 일정 시간 안에 응답 하지 못하는

경우 System 자체가 쓸모 없어지는 경우가 발생한다.

- Storage Requirements : Embeded System 같은 경우 한정된 system resource

를 사용해야 하므로 이러한 사항도 requirement에서 고려되어야 한다.

- 이러한 NFR은 기능적인 부분보다는 System이 활용될 환경에 제약을 받게

되며 이러한 경우 Functional Requirement보다 우선적으로 고려되어야 할

사항이다.

나) Customer Requirement Analysis

Dl 과정은 Customizing이라는 과정을 통해 고객의 요구사항을 빠짐없이 기록하

고 분석하는 업무를 장기간에 걸쳐 실행하여 requirements 를 specification 하는

작업이다.

ü Elicitation : requirement를 도출하는 과정

ü Analysis : requirement를 분석하여 분류하는 과정

ü Specification : 분류한 requirement에 대한 명세화

ü Validation : 만들어진 Requirement에 대한 적절성 판단 및 문서화

다) Benefits of Requirement Analysis

ü Functional Requirement 에 대한 기본지식 이해

ü Non Functional Requirement에 대한 주요 활동 및 필요 사항 이해

ü Requirement Analysis Process 의 이해

ü 실무 적용 시 고려사항에 대한 숙지

라) Skills for Requirement Elicitation

ü Interview : 고전적인 인터뷰 방법. 원하는 대답을 도출하기 위하여 미리

질문을 작성하여 일정한 질문에 대한 많은 표본을 얻는 것이 중요하다.

ü Scenario : use-case혹은 Task Diagram등을 활용하여 사용자의 행동 패턴

을 미리 예측하여 Scenario화 한다.

ü Prototype : Customer에게 미리 계획을 보여줄 때 사용하는 방법으로, 완

성되기 전에 모델을 작성하여 사용자의 요구에 부합하는지 확인하는 방

법이다. Evolutionary Design 에서 많이 활용한다.

ü Facilitated Meeting : 사회자의 진행 하에 회의 형식의 인터뷰 방법으로

여러 customer들의 requirement중 상충하는 부분을 찾아내고 그에 대한

절충 점을 찾는 방법이다. UX 분야에서 많이 활용한다.

마) Requirement Classification

ü FR Vs. NFR

ü Volatility Vs. Stability

- Project 진행 동안 바뀔 수 있는 Requirement와 기본적으로 요구되는 사항

을 분류한다.

- Volatility 한 Requirement일수록 추가기능인 경우가 많다.

ü Requirement의 Priority 도 Classification에 포함된다.

ii. Analysis

가) Why Analysis is required?

ü Use case model alone is not enough!!

- Standard component에 존재하는 부분이 있을 수도 있다.

- 필요 없이 중복되는 부분이 있을 수 있다.

ü So Analysis aims to

- 해결하고자 하는 문제의 실제 사용되는 환경을 분석한다.

- 문제를 해결하기 위해 Object 들이 상호작용하는 관계에 대해 분석한다.

- 이를 통해 correct, coherent 한 모델을 제시한다.

나) Major Analysis Activities

ü Class Modeling – static structure of the system

- 비슷한 역할을 속성을 가지는 Class를 분류한다.

- Class 간의 연계, attribute, operation을 추가하여 First Cut Class Diagram 을

제시한다. 이 First Cut Class Diagram은 중복된 클래스가 제거된 첫째 모델

이 될 것이다. 그러나 이 모델에는 아직 중복된 Method 혹은 Member가 존

재 할 수 있다. 이는 아직 Inheritance와 reusable class 의 선별이 안되어 있

기 때문이다.

- Inheritance relationship과 Reusable class 를 선별하여 Revise Class Diagram

을 작성한다. 이것이 최종 클래스 모델링이 될 것이다.

ü Interaction Modeling

- Sequential Diagram을 활용하여 Object의 Interaction에 따른 Software의

Task 수행 Timeline을 디자인 한다. 이는 Revise Class Diagram에 존재하는

Class 들간의 interaction이 될 것이다.

ü State Modeling

- State chart를 작성한다. State Machine Model의 형태로 작성하여 Module의

State에 따라 System이 어떠한 결과를 도출 할 것인가에 대해 Modeling 한

다.

ü Attributes and Operations Specification

- 도출된 Diagram들을 토대로 어떠한 Method가 필요할 것인지 선별하여 분

류한다.

다) Class Finding

ü Where are Classes from

- Language Supplier : 프로그래밍 언어가 제공하는 API

- Earlier Projects : 이전 프로젝트의 클래스를 Reuse

- Colleagues : 직장 동료의 클래스를 Reuse

- Open Source Movement : GNU, Android 등의 오픈소스 코드

ü Class 혹은 Concept(Abstraction)을 reuse 하는 경우에는 저작권의 문제도

생각해 봐야 할 것이다.

ü Reuse 된 Class가 System에서 적절한 instance를 생성하는데 도움이 되

는 지에 대해서도 검증이 필요하다.

라) Make Class Diagram and Use-case

ü Requirements 단계에서 제작한 Use-case 를 통해 찾아낸 Class 간의

Relationship을 알아 내는 것

ü 이러한 Class Diagram은 Use-case 를 specification 하는 의미가 있다.

ü 또한 이렇게 작성된 Class Diagram은 그 자체로 Analysis Model 로서 의

미가 있다.

마) Example of Use case diagram

바) Types of Specified Operations

ü Set or reveal attribute values

- Attribute value를 설정 혹은 수정하는 함수. State setting의 역할

ü Perform calculations

- Object 에서 Data Processing 을 담당

ü Send messages to other Modules

ü Module간의 Task 교환 등을 담당

사) Adding Attribute and Operations

ü Class Diagram을 통해 Object간의 상호 관계에 대해 Specification

이 되었다면 그를 토대로 Method를 추가하는 작업이 필요하다.

ü 가능하다면 각각의 Use-case에 대해 모두 적용이 될 수 있도록

Method와 Member를 추가하여 준다.

ü Attribute는 Class가 표현하는 만큼만 추가되어야 한다.

아) Look for Reuse Opportunities

ü 위에까지 완성된 클래스들은 순수하게 필요에 의해 만들어진 클래

스 이므로 이것이 Standard Libraries에 존재하거나, 다른 코드상에

구현이 되어 있는지는 알 수 없다. 또한 Inheritance 관계의 Class

들은 불필요하게 중복되는 Method나 Attribute를 가지고 있을 것

이다.

ü 이러한 중복되는 요소들은 Reuse를 통해 통합 함으로써 불필요한

System 구성 요소를 줄여줘야 한다.

iii. Design

가) Design은 Analysis에서 Specification 한 Model을 실제 구현 가능한

System Model로 구현하는 단계이다.

나) OOD Main Issues

ü Decompose : System의 Component들은 각각의 역할 혹은 구성에 따라

Module화 되어야 하며 이러한 Module 들은 상호관계를 통해 Main

Problem 을 해결하는데 도움을 주어야 한다.

ü Compose : Module들을 합하여 System을 구성하거나 그 일부분인

Component를 구성하게 되며, 한번 구성된 System의 Component는 다른

시스템에서 Reuse 될 수 있어야 한다.

ü Understand : 각 Component 가 다른 정보나 Module의 도움 없이 이해

가능 하여야 한다.

ü Continuity : 구현 단계에서의 작은 변화가 프로젝트 전체에 영향을 주지

않아야 한다. 즉, Class 간의 Encapsulation을 통해 각각의 모듈별로 수정

이 가능한 상태가 되어야 한다.

ü Protection : 다른 Module에서 발생된 error가 다른 Module 에 영향을

끼치지 않아야 한다.

다) OOD Process Flow

라) System Design Process

ü Analysis model 을 Subsystem으로 분할하여 해결한다. Divide –and

conquer

ü Subsystem에 process 와 Task 분배

ü User Interface 디자인

ü Data 관리를 위한 전략 수립

ü System 관리를 위한 적절한 control algorithm의 design

마) Object Design

ü Protocol description

- Entity 간의 상호 message 교환 형태를 확정하고 그에 대한 operation을 표

준화 하는 것

ü Implementation Description

- Information about object`s private part

- Internal details about data structures

- Operation`s procedural details

3. UML

A. Unified Approach to OOA

i. UML Concepts

가) Unified Modeling Language(UML)은 정형화된 Notation을 제공하여,

Natural Language보다 해석상 모순이 발생할 여지가 적다.

ii. UML Support

가) Use case Diagram

나) Class Diagram

다) State Diagram

라) Interaction Diagrams

마) Activity Diagram

바) Package Diagrams

사) etc.

B. UML Notation

i. Class Notation

가) Notation for Single Class

ü Example of Cabbie Class

ii. Class Relationship Notation

가) Inheritance Normal Class

ü 실선 화살표를 상위 클래스 방향으로 이어준다.

ü Example of Dog Hierarchy

나) Inheritance Abstraction

ü 점선 화살표를 Abstraction 방향으로 이어준다.

ü Dog Class hierarchy Cont.

다) Composition Relationship

ü 집합

- 다이아몬드가 있는 선으로 표시한다.

- Example of Dog

ü 연관

- 실선으로만 표기한다.

- Example of Dog

4. Introducing UML Tools

A. StarUML

i. starUML개요 가) StarUML™은 UML(Unified Modeling Language)을 지원하는 소프트웨어 모델링 플랫

폼입니다. UML 버전 1.4에 기반을 두고 있으며, UML 버전 2.0의 표기법을 적극적으

로 지원하고 있습니다. 총 11가지의 다양한 종류의 다이어그램을 제공할 뿐만 아니라

UML 프로파일 개념과 템플릿 기반의 문서 및 코드 생성을 지원하여 MDA(Model

Driven Architecture) 접근방법을 적극적으로 지원합니다. 또한 고객의 환경에 대한 맞

춤 능력이 우수하고 기능에 대한 확장성이 매우 뛰어난 것이 장점입니다. 가장 선도

적인 소프트웨어 모델링 도구 중의 하나인 StarUML™을 사용하면 소프트웨어 프로젝

트의 생산성(Productivity), 품질(Quality)이 획기적으로 높아진다는 것을 실감하실 수

있습니다.

ii. 기본개념

가) 모델, 뷰, 그리고 다이어그램 ü StarUML™에서는 모델과 뷰 그리고 다이어그램의 개념을 서로 분리해서 사용합니다. 우선, 모

델(Model)은 소프트웨어 모델에 관한 정보를 담고 있는 요소를 의미합니다. 뷰(View)는 모델

이 담고 있는 정보를 시각적으로 표현한 것을 의미하며, 다이어그램(Diagram)은 뷰 요소들의

집합으로써 사용자의 일정한 생각을 표현한 것을 의미합니다.

나) 프로젝트와 유닛

ü 프로젝트

- 프로젝트(Project)는 StarUML™에서 다루는 가장 기본이 되는 단위를 의미합니다. 프

로젝트는 하나 혹은 그 이상의 소프트웨어 모델들을 관리할 수 있으며 항상 존재하

는 최상위 패키지(Top-level Package)로도 이해될 수 있습니다. 하나의 프로젝트는

일반적으로 하나의 파일에 저장됩니다.

ü 프로젝트 구성

- 프로젝트 하위에는 다음의 요소들이 포함되며 관리될 수 있습니다.

ü 프로젝트 파일

- 프로젝트 파일은 XML 형태로 저장되며 확장명은 ".UML" 입니다. StarUML™에서 작

성된 모든 모델, 뷰, 다이어그램들은 하나의 프로젝트 파일에 저장됩니다. 프로젝트

를 여러 파일에 나누어 저장하려면 유닛을 사용할 수 있습니다. 프로젝트 파일에는

다음과 같은 정보들이 저장됩니다

- 프로젝트가 사용하는 UML 프로파일들

- 프로젝트가 참조하는 유닛 파일들

- 프로젝트에 포함된 모든 모델 정보

- 프로젝트에 포함된 모든 다이어그램 및 뷰 정보

ü 유닛

- 프로젝트는 기본적으로 하나의 파일에 저장되지만 프로젝트를 여러 명이 작업하거

나 하는 등의 이유로 여러 개의 파일로 나누어서 다루어야 할 경우가 있습니다. 이

러한 경우, 프로젝트를 여러 개의 유닛(Unit)으로 만들어서 다룰 수 있습니다. 유닛

은 계층적으로 구성될 수 있어서 유닛의 하부에 여러 개의 서브 유닛을 가질 수도

있습니다. 유닛은 .UNT 파일에 저장되며, 프로젝트 파일(.UML) 혹은 다른 유닛 파일

(.UNT)에서 참조됩니다

다) 모듈

ü 모듈은 StarUML™을 확장하여 새로운 기능들과 특징들을 제공하기 위한 하나의 패키

지입니다. 모듈은 아래의 <그림>과 같은 여러 확장 요소들의 조합으로 만들 수 있습

니다. 또한 목적에 따라 하나의 확장 요소만으로 독립적인 모듈을 구성하거나, 모듈

내에 같은 유형의 확장 요소들을 여러 개 만들 수도 있습니다.

ü 모듈의 추가

- 사용자가 개발하거나 써드 파티 벤더에 의해 배포되는 모듈을 추가적으로 설치하면

확장된 기능을 StarUML™ 내에서 사용할 수 있습니다. 시스템에 새로 추가되는 모

듈을 설치하는데 별도의 복잡한 등록과정이 필요치는 않습니다. 모듈을 설치하려면

해당 모듈을 <install-dir>\modules\ 하위 디렉토리에 서브 디렉토리를 만든 다음

모듈을 구성하는 파일들을 복사하면 됩니다

iii. 프로젝트 관리하기

가) 프로젝트 관리하기

ü 새프로젝트 만들기

- 새 프로젝트를 만드는 방법 1 - 새 프로젝트:

1. [File]->[New Project] 메뉴를 선택합니다.

2. 사용자가 기본 접근법으로 선택한 접근법으로 초기화된 프로젝트가 바로 만들어

집니다. 접근법의 종류에 따라 프로파일이 포함되고, 프레임워크가 로딩될 수 있습

니다.

- 새 프로젝트를 만드는 방법 2 - 새 프로젝트 선택 대화상자:

1. [File]->[New Project By Approach] 메뉴를 선택합니다.

2. 새 프로젝트 선택 대화상자의 접근법 선택 페이지에 사용 가능한 접근법들이 목록

에 나타납니다. 이 중에서 한가지를 선택하고 [OK] 버튼을 누릅니다.

3. 선택한 접근법에 따라 프로젝트가 생성되고 초기화됩니다. 접근법의 종류에 따라

프로파일이 포함되고, 프레임워크가 로딩될 수 있습니다.

ü 프로젝트 열기

- 파일에 저장된 프로젝트를 불러와서 작업을 하기 위해서는 프로젝트 파일을 열어야

합니다. 프로젝트가 하나 이상의 유닛들을 포함하고 있다면 그것들도 프로젝트을 열

때 함께 로드됩니다.

- 프로젝트를 여는 방법:

1. [File]->[Open] 메뉴를 선택합니다.

2. 프로젝트 열기 대화상자가 나오면 프로젝트 파일(.UML)을 하나 선택하고 [Open]

버튼을 누릅니다.

3. 선택된 프로젝트 파일이 열립니다.

ü 프로젝트 저장하기

- 프로젝트에서 사용자가 수행했던 작업의 내용들을 파일에 저장하기 위해서는 프로

젝트를 파일에 안전하게 저장해야 합니다. 프로젝트 파일에 바로 저장하거나 다른

이름으로 저장할 수 있으며, 포함된 유닛들의 정보도 한번에 저장할 수 있습니다

- 프로젝트를 저장하는 방법:

1. [File]->[Save] 메뉴를 선택합니다.

2. 프로젝트에 파일 이름이 지정되어 있지 않는 경우에는 프로젝트 저장 대화상자가

나타납니다. 여기서 파일 이름을 입력하고 [Save] 버튼을 누릅니다.

3. 프로젝트가 파일에 저장됩니다.

나) 유닛 관리하기

ü 유닛 관리하기

- 프로젝트의 내용을 하나의 파일에서 관리할 수도 있지만 여러 사람의 팀 작업을 위

해서는 여러 개의 유닛으로 나누어서 작업하는 것이 편리합니다. 이 장에서는 유닛을

만들고, 제거하는 등의 관리 방법을 설명합니다.

ü 유닛만들기

- 프로젝트 혹은 다른 유닛의 일부분을 별도의 파일로 저장하여 관리해야 할 경우가

있습니다. 예를 들어 하나의 프로젝트에 여러 명이 팀 작업을 해야 하는 경우, 프로젝

트를 여러 개의 유닛으로 분할하여 CVS, Microsoft Visual SourceSafe와 같은 도구로

팀작업을 할 수 있습니다. 패키지(Package), 모델(Model) 또는 서브시스템(Subsystem)

요소만이 별도의 유닛으로 만들어질 수 있습니다.

- 새 유닛을 만드는 방법:

1. 별도의 유닛으로 만들고자 하는 요소(패키지, 모델 또는 서브시스템)를 선택합니다.

2. 마우스 오른쪽 버튼을 눌러 [Unit]->[Control Unit] 메뉴를 선택합니다.

3. 저장 대화상자가 나오면 유닛의 파일 이름을 입력하고 [Save] 버튼을 누릅니다.

4. 선택한 요소가 유닛으로 만들어집니다.

ü 유닛 병합하기

- 유닛에 포함된 요소들을 별도의 유닛 파일로 다루지 않고 상위 유닛이나 프로젝트에

통합하여 더 이상 유닛 파일을 관리하고 싶지 않은 경우 유닛을 병합할 수 있습니다.

- 유닛을 병합하는 방법:

1. 병합할 유닛에 해당하는 요소(패키지, 모델 또는 서브시스템)를 모델 탐색기에서 선

택합니다.

2. 마우스 오른쪽 버튼을 누른 후 [Unit]->[Uncontrol Unit] 메뉴를 선택합니다.

3. 유닛이 프로젝트 혹은 상위 유닛으로 병합됩니다.

ü 유닛 저장하기

- 유닛의 정보들을 변경하였다면 유닛을 파일에 안전하게 저장하여야 합니다. 유닛에

지정된 파일에 바로 저장하거나 다른 이름으로 저장할 수 있습니다.

- 유닛을 저장하는 방법:

1. 저장할 유닛을 모델 탐색기에서 선택합니다.

2. 마우스 오른쪽 버튼을 누른 후 [Unit]->[Save Unit] 메뉴를 선택합니다.

3. 유닛이 파일에 저장됩니다.

- 유닛을 다른 이름으로 저장하는 방법:

1. 다른 이름으로 저장할 유닛을 모델 탐색기에서 선택합니다.

2. 마우스 오른쪽 버튼을 누른 후 [Unit]->[Save Unit As] 메뉴를 선택합니다.

3. 유닛 저장 대화상자가 나오면 새로운 유닛 파일 이름을 입력하고 [Save] 버튼을 누

릅니다.

4. 유닛이 새로운 파일에 저장됩니다.

ü 유닛 제거하기

- 프로젝트에 포함된 유닛이 더 이상 필요하지 않은 경우에는 유닛을 제거할 수 있습

니다. 유닛을 제거하면 유닛에 포함되는 모든 요소가 삭제되며 그 이후로 프로젝트를

불러올 때 유닛이 더 이상 로드되지 않습니다. 단지, 유닛의 내용을 프로젝트 혹은 상

위 유닛으로 통합하고 해당 유닛을 더 이상 관리하고 싶지 않는 경우에는 유닛 삭제

가 아닌 유닛 병합하기를 선택하십시오.

- 유닛을 제거하는 방법:

1. 유닛을 제거하려면 우선 모델 탐색기에서 유닛에 해당하는 요소(패키지, 모델 또는

서브시스템)를 선택합니다.

2. 마우스 오른쪽 버튼을 누른 후 [Unit]->[Delete Unit] 메뉴를 선택합니다.

3. 유닛을 제거할 것인지를 한번 더 확인하는 대화상자가 나옵니다. 여기서 [Yes]를 선

택합니다.

4. 유닛이 프로젝트로부터 완전히 제거됩니다.

다) 모델 조각으로 작업하기

ü 모델 조각 만들기

- 프로젝트의 일부 내용을 별도의 파일로 저장하여 다른 사람에 의해 사용되거나 차

후에 다시 사용될 것을 고려한다면 모델 조각(Model Fragment)을 만들 수 있습니다.

모델 조각은 유닛과 달리 다른 파일로부터 참조되거나 다른 파일을 참조하지 않으

로 그 자체로써 독립적인 단위입니다. 모델 조각은 언제든지 프로젝트에 불러와서

포함될 수 있습니다.

- 모델 조각을 만드는 방법:

1. 모델 조각(Model Fragment)으로 만들 패키지(Package), 서브시스템(Subsystem) 혹

은 모델(Model)을 모델 탐색기에서 선택합니다.

2. [File]->[Export]->[Model Fragment] 메뉴를 선택합니다.

3. 모델조각 저장 대화상자가 나오면 모델 조각 파일의 이름을 입력하고 [Save] 버튼

을 누릅니다.

ü 모델 조각 불러오기

- 별도의 모델 조각 파일(.MFG)에 저장되어 있는 요소들을 프로젝트 내부로 불러올

수 있습니다. 모델 조각을 프로젝트로 불러오면 모델 조각 파일에 저장된 요소들

이 복제되어 포함되므로 모델 조각 파일을 직접 참조하지는 않습니다.

- 모델 조각을 불러오는 방법:

1. [File]->[Import]->[Model Fragment] 메뉴를 선택합니다.

2. 모델 조각 열기 대화상자가 나오면 읽어올 모델 조각 파일(.MFG)을 선택하고

[Open] 버튼을 누릅니다.

3. 읽어올 모델 조각을 어떤 요소 하부에 둘 것인지를 결정하기 위해 요소 선택 대

화상자가 나옵니다. 여기서 모델 조각을 포함할 요소(패키지, 모델, 서브시스템

또는 프로젝트)를 선택하고 [OK] 버튼을 누릅니다.

4. 모델 조각이 선택한 요소 하위에 추가됩니다.

라) 프레임워크 불러오기

ü 프로젝트에서 특정 프레임워크를 사용하기 위해서는 먼저 프레임워크를 불러와야 합

니다. 프레임워크를 불러오면 프레임워크에 포함되어 있는 모든 요소들을 사용할 수

있는데, 프레임워크를 구성하는 유닛들은 일반적으로 읽기전용(readonly) 파일이므로

프레임워크 자체 요소들을 변경을 가할 수 없습니다.

ü 프레임워크를 불러오는 방법:

1. [File]->[Import]->[Framework] 메뉴를 선택합니다.

2. 프레임워크 가져오기 대화상자가 나타나면 가져올 프레임워크를 목록에서 선택하고

[OK] 버튼을 누릅니다.

3. 읽어올 프레임워크를 어떤 요소 하부에 둘 것인지를 결정하기 위해 요소 선택 대화

상자가 나옵니다. 여기서 프레임워크를 포함할 요소(패키지, 모델, 서브시스템 또는

프로젝트)를 선택하고 [OK] 버튼을 누릅니다.

4. 프레임워크가 선택한 요소 하위에 추가됩니다.

마) UML프로파일 사용하기

ü UML프로파일 포함하기

- 정의되어 있는 UML 프로파일들을 현재 프로젝트 내부로 포함시켜 사용할 수 있습

니다. UML 프로파일이 프로젝트에 포함되면 프로파일에서 정의된 스테레오타입

(Stereotype), 확장속성(TagDefinition) 및 데이터타입(DataType) 등을 프로젝트에서

사용할 수 있습니다.

- UML프로파일을 포함하는 방법:

1. [Model]->[Profiles] 메뉴를 선택합니다.

2. 프로파일 관리자 윈도우가 화면에 나타나면, 왼쪽의 사용 가능한 프로파일의 목록

에서 포함시킬 프로파일을 선택하고 [Include] 버튼을 누른 뒤 [Close] 버튼을 누

릅니다.

3. 선택한 프로파일이 현재 프로젝트에 포함됩니다.

ü UML프로파일 제거하기

- 현재 프로젝트에 포함되어 있는 UML 프로파일들을 제외시킬 수 있습니다. UML 프

로파일이 프로젝트에서 제외되면 프로파일에 정의된 스테레오타입(Stereotype), 확장

속성(TagDefinition) 및 데이터타입(DataType)을 프로젝트에서 사용할 수 없게 됩니

다.

- UML프로파일을 제거하는 방법:

1. [Model]->[Profiles] 메뉴를 선택합니다.

2. 프로파일 관리자 윈도우가 화면에 나타나면, 오른쪽의 포함된 프로파일의 목록에

서 제외시킬 프로파일을 선택하고 [Exclude] 버튼을 누른 뒤 [Close] 버튼을 누릅

니다.

3. 선택한 프로파일이 현재 프로젝트에서 제외됩니다.

5. OOAD Using UML Tools

A. Blackjack Game Example

i. Requirement 가) 이 소프트웨어 응용 프로그램의 목적은 블랙잭 게임을 구현하는 것이다. 블랙잭 게임

에서 한 명 이상의 플레이어가 딜러와 게임을 벌인다. 각 플레이어는 딜러만 상대하여

게임을 할 수 있으며, 다른 플레이어와는 게임을 할 수 없다. 나) 플레이어의 관점에서 게임의 목표는 모든 카드의 페이스 값을 합하여 21이 되거나 가

능한 21에 가까워지고 초과하지 않을 때까지 덱에서 카드를 가져오는 것이다. 모든 카

드 페이스 값의 합이 21을 넘으면 플레이어가 진다. 처음 두 카드 페이스 값이 21과

같으면 플레이어가 블랙잭을 가졌다고 한다. 딜러는 플레이어들과 함께 게임을 한다.

딜러는 카드를 딜하고 플레이어에게 추가 카드를 제시하고, 핸드의 전부 또는 일부를

보여주고, 핸드의 전부 또는 일부를 계산하고, 핸드의 카드의 수를 계산하고, 승자를 결

정하고, 새로운 핸드를 시작한다 다) 카드를 페이스 값이 무엇인지 알고 이 값을 보고할 수 있어야 한다. 모든 카드는 카드

덱에 속한 것이어야만 한다. 이 덱에는 다음 카드를 deal할 수 있는 기능과 아울러 덱

에 남아있는 카드의 수를 보고하는 기능이 있어야만 한다. 라) 카드마다 페이스 값을 가지고 있다. 에이스는 1 또는 11로 계산한다. 페이스카드(잭, 퀸,

킹)는 각각 10을 계산한다. 나머지 카드는 페이스 값을 나타낸다.

마) 게임의 규칙은 플레이어 카드의 페이스 값이 딜러 카드의 페이스 값의 합보다 21에 더

가까우면 플레이어가 베팅한 금액을 따는 것이다. 플레이어가 블랙잭으로 승리하면 베

팅 금액의 3:2배를 얻는다(딜러도 블랙잭을 갖지 않는다고 가정할 경우). 플레이어 카드

의 페이스 값의 합이 21을 넘으면 베팅을 잃는다. 블랙잭은 다른 조합으로 된 21을 이

긴다.

바) 플레이어와 딜러의 점수가 같고 최소 17점이면 비긴 것으로 간주하고 플레이어가 베팅

을 갖는다.

사) Identify scenarios for use-cases.

ü 딜러가 덱을 셔플한다.

ü 플레이어가 배팅한다.

ü 딜러가 처음 카드를 딜한다.

ü 플레이어가 플레이어 핸드에 카드를 추가한다.

ü 딜러가 딜러 핸드에 카드를 추가한다.

ü 핸드가 플레이어 핸드의 값을 플레이어에게 반환한다.

ü 핸드가 딜러 핸드의 값을 딜러에게 반환한다.

ü 딜러가 플레이어에게 다른 카드를 원하는지 묻는다.

ü 딜러가 플레이어에게 다른 카드를 딜한다.

ü 플레이어가 그 카드를 플레이어 핸드에 추가한다.

ü 핸드가 플레이어 핸드의 값을 플레이어에게 반환한다.

ü 딜러가 플레이어에게 다른 카드를 원하는지 묻는다.

ü 딜러가 플레이어 핸드의 값을 얻는다.

ü 딜러가 베팅 값을 보내거나 플레이어로부터 베팅 값을 요청한다.

ü 플레이어가 플레이어의 베팅 속성에 추가하거나 뺀다.

아) Graphical statement for use case.

ii. Analysis 가) Select classes and object using basic requirements as a guide.

ü Available class list.

■게임 ■카드 ■페이스 카드

■블랙잭 ■덱 ■킹

■딜러 ■핸드 ■퀸

■하우스 ■페이스 값 ■잭

■플레이어들 ■수트 ■게임

■플레이어 ■승자 ■배팅

■카드들 ■에이스

ü 게임 : 블랙잭은 게임의 이름이다. 그러므로 우리가 게임이라는 명사를 다루는 방

법과 동일하게 다룬다.

ü 블랙잭 : 이 경우 게임은 명사로 간주될 수 있지만 게임은 실제로는 시스템 자체

이므로 이것을 잠재 클래스로 제외한다.

ü 딜러 : 딜러가 없으면 안 되기 때문에 이것은 그대로 둔다.(참고로 일반적인 사람

에게 속한 것들은 추상화해 낼 수 있지만 이 예제에서는 그렇게 하지 않는다) 딜

러 클래스를 전부 피하고서 딜러가 플레이어 클래스의 인스턴스로만 할 수도 있다.

그러나 딜러의 추가 속성이 충분히 있기 때문에 이 클래스를 그대로 두어야 한다.

ü 하우스 : 이것은 딜러의 다른 이름이 뿐이기 때문에 쉽게 처리할 수 있다.

ü 플레이어들 및 플레이어 : 플레이어들이 필요하므로 이 클래스가 있어야한다. 그

러나 클래스가 플레이어 그룹이 아닌 단일 플레이어를 나타내야 하므로 플레이어

들은 취소하고 플레이어를 남겨둔다.

ü 카드들 및 카드 : 이것은 플레이어와 같은 논리로 처리한다. 게임에서는 카드들이

절대적으로 필요하지만 우리는 클래스가 단일 카드를 나타내야 하므로 카드들은

취소하고 카드는 남겨둔다.

ü 덱 : 덱에서 요구하는 활동이 많기 때문에 (셔플(Shuffling, 카드섞기) 및 드로윙

(Drawing, 카드받기)) 이것은 클래스로 선택하기 적합하다고 결정한다.

ü 핸드 : 플레이어마다 핸드를 갖는다. 이 게임에서 우리는 플레이어가 단일 핸드를

갖도록 규정할 것이다. 그러므로 플레이어가 핸드 객체를 갖지 않아도 카드를 추

적할 수 잇다. 그러나 이론적으로 플레이어가 다중 핸드를 가질 수 있고 다른 카

드 게임에서 핸드 개념을 사용할 수 있으므로 이 클래스를 남겨둔다.

ü 페이스 값 : 카드의 페이스 값은 카드 클래스의 속성으로 가장 잘 나타낼 수 있으

므로 취소한다.

ü 슈트(suit) : 블랙잭 게임에서 우리는 슈트(suit)를 추적할 필요가 없다. 그러나 슈트

(suit)를 추적해야 하는 카드게임들이 있다. 그러므로 이 클래스를 재사용할 수 있

도록 만들기 위해 추적해야 한다. 하지만 카드의 속성이 되어야 하므로 취소한다.

ü 에이스 : 이것은 카드 클래스의 속성으로 더 잘 표현할 수 있으므로 클래스에서

취소한다.

ü 페이스 카드, 킹, 퀸 : 에이스와 마찬가지로 카드 클래스의 속성으로 더 잘 표현할

수 있으므로 취소한다.

ü 배팅 : 이 클래스는 딜레마가 된다. 배팅 없이 블랙잭 게임을 할 수 있지만 요구

사항문에서 분명하게 배팅을 설명에 넣었다. 이 경우 배팅은 플레이어의 속성으로

간주할 수 있지만 플레이어가 배팅을 할 필요가 없는 게임도 많이 있다. 결국 배

팅은 플레이어의 논리적인 속성이 아니다. 또한 여러 사물에 배팅할 필요가 없는

게임도 많이 있다. 결국 배팅은 플레이어의 논리적인 속성이 아니다. 또한 여러 사

물에 배팅할 수 있기 때문에 배팅을 추상화하는 것이 좋다. 돈, 칩, 시계 말, 심지

어 집에 대한 권리까지도 배팅할 수 있다. 배팅을 클래스로 만들지 않아야 하는

여러가지 타당한 논증이 있겠지만 이 경우에서 우리는 클래스로 할 것이다.

ü 결과적으로 우리가 선택한 클래스는 카드, 덱, 핸드, 딜러, 플레이어, 배팅으로 총

6개에 해당한다.

나) Identify attributes and operations for each system object.

ü 카드

- 페이스 값을 안다.

- 슈트(suit)를 안다.

- 값을 안다.

- 조커, 에이스, 페이스 카드인지 안다.

ü 덱

- 셔플을 한다.

- 다음 카드를 딜한다.

- 덱에 남아있는 카드의 개수를 안다.

- 시작할 덱 전체가 있는지 안다.

ü 핸드

- 핸드에 얼마나 많은 카드가 있는지 안다.

- 핸드의 값을 안다.

- 핸드를 보여준다.

ü 딜러

- 카드를 딜한다.

- 덱을 셔플한다.

- 플레이어에게 카드를 준다.

- 딜러의 핸드를 보여준다.

- 딜러 핸드의 값을 계산한다.

- 딜러 핸드에 있는 카드의 개수를 안다.

- 카드를 요청한다(히트 or 홀드).

- 승자를 결정한다.

- 새 핸드를 시작한다.

ü 플레이어

- 카드를 요청한다(히트 or 홀드).

- 플레이어의 핸드를 보여준다.

- 플레이어 핸드의 값을 계산한다.

- 핸드에 얼마나 많은 카드가 있는지 안다.

- 핸드 값이 21을 넘는지, 같은지 또는 미만인지 안다.

ü 배팅

- 배팅의 종류를 안다.

- 현재 배팅의 값을 안다.

- 배팅할 수 있는 플레이어가 얼마나 남아있는지 안다.

- 배팅을 감당할 수 잇는지 안다.

iii. Design 가) 카드

ü 페이스 값을 안다.

- 카드는 분명히 이것을 알아야 한다. 내부적으로 이 클래스는 카드의 값을 추적해

야만 한다. 이것은 구현 문제이므로 이런 식으로 책임 역할을 표현하지 않는다.

인터페이스 측면에서 이것을 페이스 값 디스플레이라고 부르자.

ü 수트를 안다.

- 페이스 값의 경우와 같은 이유로 이 책임 역할을 남겨두고 이름 디스플레이(수트

를 확인)라고 이름을 변경한다. 그러나 블랙잭에는 이것이 필요하지 않다. 재사용

목적으로 남겨 둔다.

ü 페이스 카드인지 안다.

- 페이스 카드, 에이스, 조커에 대한 별도의 책임 역할이 있을 수 있지만 값을 보

고하는 책임 역할이 이것을 다룰 수 있으므로 이 역할은 카드의 역할에서 빼도

록 한다.

ü 에이스인지 안다.

- 이전 항목에 포함되므로 이 역할 역시 빼도록 한다.

ü 조커인지 안다.

- 이전과 동일하지만 요구사항문에서는 조커가 언급된 적이 없다는 점에 유의하자.

이것은 클래스가 보다 재사용될 수 있도록 책임 역할을 추가할 수 있는 상황이

다. 그러나 조커에 대한 책임 역할은 값 보고에 해당하는 것이므로 이 책임 역할

은 카드의 역할에서 빼도록 한다

ü UML Notation

나) 덱

ü 셔플한다.

- 분명히 덱을 셔플해야 할 필요가 있다.

ü 다음 카드를 딜한다

- 분명히 다음 카드를 딜해야 하므로 이것은 남겨두자.

ü 덱에 남아있는 가드의 개수를 안다

- 적어도 딜러는 남아있는 카드가 있는지는 알아야 하므로 이것은 남겨둔다.

ü 시작할 덱 전체가 있는지 안다.

- 덱은 모든 카드를 포함하고 있는지 알아야만 한다. 그러나 이것은 엄밀하게 내부

구현 문제일 수 있다. 어느 경우가 되도라도 일단 남겨두도록 한다.

ü UML Notation

다) 핸드

ü 핸드에 얼마나 많은 카드가 있는지 안다.

- 분명히 핸드에 얼마나 많은 카드가 있는지 알아야 하므로 이것은 남겨둔다. 그러

나 인터페이스 관점에서 이름을 변경하여 핸드에 있는 카드 개수 보고라고 하자.

ü 핸드의 값을 안다.

- 분명히 핸드의 값을 알아야 하므로 이것을 남겨둔다. 그러나 인터페이스 관점에

서 이름을 변경하여 핸드의 값 보고라고 한다.

ü 핸드를 보여준다.

- 핸드의 내용을 볼 수 있어야 한다.

ü UML Notation

라) 딜러

ü 카드를 딜한다.

- 딜러는 핸드를 달할 수 있어야 하므로 이것은 남겨두자.

ü 덱을 셔플한다.

- 딜러는 덱을 셔플할 수 있어야만 한다.

ü 플레이거에게 카드를 준다.

- 딜러는 플레이어의 핸드에 카드를 추가할 수 있어야만 하므로 이것은 남겨둔다.

ü 딜러의 핸드를 보여준다.

- 분명히 이 기능이 필요하지만 이것은 모든 플레이어를 위한 일반적인 기능이고

핸드가 스스로 보여주고 딜러가 이것을 요청해야 할 것이다.

ü 딜러 핸드의 값을 계산한다.

- 이 경우에는 계산을 구현해야 하므로, 딜러 핸드의 값 보여주기로 한다.

ü 딜러 핸드에 있는 카드의 개수를 안다.

- 딜러 핸드에 있는 카드의 개수가 나중에 필요해질지 아닐지 모르지만, 일단 딜러

핸드의 카드 개수로 이름지어 보여준다.

ü 카드를 요청한다.

- 딜러는 카드를 요청할 수 있어야만 한다. 그러나 딜러 또한 플레이어이므로 코드

를 공유 할 수 있는 방법이 있을까? 이렇게 하는 것이 가능하기는 하지만 지금

은 딜러와 플레이어를 별도로 취급하려고 한다. 설계를 하면서 반복할 때 상속을

사용하고 공통점을 요소로 뽑아낼 수 있을 것이다.

ü 승자를 결정한다.

- 이것은 우리가 딜러가 이것을 계산하도록 할 것인지 아니면 게임 객체가 하도록

할 것인지에 달려있다. 지금은 일단 남겨두자.

ü 새 핸드를 시작한다.

- 이전 항목과 동일한 이유로 이것을 남겨두자.

ü UML Notation

마) 플레이어

ü 카드를 요청한다.

- 플레이어는 카드를 요청할 수 있어야만 하므로 이것은 남겨두자.

ü 플레이어의 핸드를 보여준다.

- 분명히 이 기능이 필요하지만 이것은 모든 플레이어를 위한 일반적인 기능이고

핸드가 스스로 보여주고 일러가 이것을 요청해야 할 것이다.

ü 플레이어 핸드의 값을 계산한다.

- 이전과 동일한다. 그러나 이 경우에 계산은 구현 문제이다. 이름을 변경하여 플

레이어 핸드의 값 보여주기로 하자.

ü 핸드에 얼마나 많은 카드가 있는지 안다.

- 플레이어 핸드의 값을 보여주기와 동일하지 않을까? 지금은 남겨두지만 이름을

변경하여 플레이어 핸드의 카드 개수 보여주기로 하자.

ü 핸드 값이 21을 넘는지, 21과 같은지, 또는 21미만인지 안다.

- 누가 이런 결정을 해야 하는가? 이것은 게임의 특정 규칙을 근거로 한다. 플레이

어는 분명히 이것을 알아서 카드를 요청할 것인지 결정해야 한다. 사실 딜러도

이렇게 해야 한다. 이것은 핸드의 값 보고에서 처리할 수 있다.

ü UML Notation

-배팅

ü 배팅의 종류를 안다.

- 이 시점에서 우리는 나중에 재사용하기 위해 이것을 남겨두지만 이 게임에서는

배팅의 종류가 항상 돈이 되도록 한다.

ü 현재 배팅의 값을 안다

- 이것은 현재 배팅의 값을 추적하기 위해 필요하다. 플레이어와 딜러는 이것을 알

아야 한다. 우리는 질러가 무제한 금액을 배팅할 수 있다고 가정할 것이다

ü 배팅할 수 잇는 플레이어가 얼마나 남았는지 안다.

- 이 경우 배팅은 플레이어가 사용할 수 잇는 돈의 전체로서의 역할을 할 수 잇다.

이런 식으로 플레이어는 자신의 자원을 넘어서는 배팅을 할 수 없다.

ü 배팅을 감당할 수 있는지 안다

- 이것은 딜러가 플레이어가 배팅을 감당할 수 있는지 결정할 수 있도록 하는 간

단한 반응이다.

바) UML Presentation for Blackjack Game

iv. Implementation

v. Testing

6. Conclusion

A. Method for Design Software

소프트웨어 디자인으로서의 OOAD는 지금까지 알아본 여러가지 장점을

제공한다. OOAD의 최대 장점은 Module화에 있다. Module화가 잘된

Software는 디자인 단계에서부터 robust 함을 유지 할 수 있다. 또한 구현

단계에서의 변화에 대응하기가 용이하다. 그뿐만 아니라 유지보수 또한

Software전반이 아닌 Module 단위로 이루어 지므로 매우 편리한 면이 있

다.

B. UML for Design Tool

UML 툴은 OOAD에서 정형화된 표현방식을 제공하는 것에 의미가 있다. 즉

UML이 Requirement & Design Specification을 제공하는 것이다. 이러한 도식 표

현은 표현의 모순을 줄여주고 일관성을 유지하는데 도움이 된다. 또한 UML이 제

공하는 다이어그램 들을 통해서 여러 모델을 설정할 수 있다. 이러한 모델들을

정형화된 방식으로 코드화 시키는 것 또한 UML의 장점이다