Analysis

classes and objects

use case realization

개발 process에서 analysis

• Analysis는 원하는 시스템(use case modelling 및 requirement 조사

단계를 통해 구체화된 시스템)이 가지는 필수적인 요구 사항 및 특징들을 잡아서 이를 나타내는 model을 만드는 과정

• 본 단계를 거치면

– analysis classes: business domain의 주요 개념에 대한 model

– use case realization: use case를 달성하기 위해 class간 상호 작용하는 과정 기술

requirment 추출과

analysis 통한 모델 구축은

수시로 영향 주고 받는 단계

Analysis model is ...

• 가능한 대부분 참여자(디자이너, 개발자, 사용자)에게 의미 있는 결과물이여야 한다.

• 항상 business 영역(실제 모델링하고자 하는 영역)의 언어로 표현된다.

• 전반적인 큰 그림을 잡는다.

– problem domain에 대한 이야기만.

– 가령 전자 상거래에 대한 analysis model은 Customer, Order와 같은 것으로 구성되어야지, 실제 db 접근 처리나 classes간 통신 프로토콜등이 나와서는 안 된다.

• coupling이 최소화 되어 있어야 한다.

• 원하는 시스템에 대한 이야기를 담고 있게 된다. (use

case realization)

Analysis

Part 1. Classes and Objects

class

• 클래스는 추상화를 통해 어떤 대상을 모델링한 것.

– 동일한 유형에 속하는 모든 객체를 대표하는 개념.

대상이 가지는 데이터 및 속성과 동작을 한데 어울러서 표현.

– 절차지향 프로그래밍에서는 동작을 중심으로 처리가 되어가며,

데이터(속성)과는 분리된 형태

– 현실을 모델링하는 개념 중 하나로서, 기존 절치지향 개념에 의한

모델링 보다 현실 모델링에 적합한 특성을 지닌다.

• 객체 지향 모델링이 가지는 특성

– 추상화(abstaction)

– 상속성(inheritance)

– 캡슐화(encapsulation)

– 다양성(polymorphism)과 동적 바인딩(dynamic binding)

OO 특성이 가지는 혜택 • 추상화, 상속성

– 문제 도메인 공통 요소에 따른 동작을 중복 정의하지 않아도 된다.

– 추상화 레벨 정도에 따라서 그에 따른 동작을 정의함으로서, 중복적인 구현 및 이로 인한 문제점을 사전 방지할 수 있으며, 문제 발견 및 조치에 대한 주의를 집중시킬 수 있다.

• 데이터 은닉/캡슐화 (encapsulation)

– 데이터 자체에 대한 제어를 직접적으로 하지 않고 특정 동작을 통해서 수행함으로서, 관련된 logic을 제어할 수 있다.

– 데이터 처리에 방식이 달라지는 경우, 접근 함수 자체는 동일하게 유지되면서, 해당 함수 자체에서 logic만을 변경하게 된다. => 시스템이 변동성에 대해서 내성을

가짐

– 노출되는 범위를 제어하여 문제 발생 범위와 해결 범위를 제약할 수 있다.

– 예) 특정 문서 목록을 추출하는 함수. DB 직접 접근 vs. 함수 호출

• 다형성과 동적 바인딩

– 사용자는 동일한 동작에 대해서는 동일한 동작을 수행할 수 있다.

– 대상이 가지는 특성에 따른 동작에 대해서는 고민하지 않는다, 단지 output만 생각할 뿐이다.

– 예) mydocs 문서 목록 가져오기 vs 일반 docs 문서 목록 가져오기: listItems()

Object and instance

• Every object is an instance of exactly one class.

• Object ...

– 관련 데이터(attribute)와 동작(operation, method,

function)을 한 묶음으로 구성

– 모든 object는 식별가능 해야 한다.

– 다른 object에게 message를 던져서 작동을 한다.

object and class

UML class notation

• visibility (접근 권한) - 신중신중!!

+ public

- private

# protected

~ package

analysis classes in dev. process

analysis classes는 problem domain을

모델링하는 데 필요한 개념들을 class

들로 구성해가는 과정.

[질문] 어떻게 class들을 추출해 내갈 것인가?

[질문] 실제 use case는 어떻게 본 단계와 연관되어지는 것일까?

Finding the classes

• class는 시스템을 바라보는 관점이며, 이는 개인적 경험에

따라 경험적인 측면에서 추출하는 경향이 크다.

• 일반적 방법

– 본 단계에서는 기존 요구 명세 및 use case가 활용될 수 있다.

– [방법 1.]요구 사항을 분석해서 명사와 동사를 정리해 가면서 동일

역할 부분을 한데 묶어 간다.

– [방법 2.] CRC (Class Name, Responsibilities, Collaborators)

– Patterns.

object diagram & associations

object diagrams are snapshots of an

excuting OO system.

Objects are instances of classes, and

links are instances of associations.

associations are connections between

classes.

class diagram vs. object diagram

special relations

associations

• 클래스는 다른 클래스들과 관계를 가진다. 이러한

관계를 나타내는 것이 바로 association.

example and stereotypes ...

• stereotypes ...

– use, call, parameter, send, instantiate

– trace, refine, derive

– access, import, friend

generalization concept

• Generalization is a relationship between a more

general thing and a more specific thing.

abstract relation and polymorphism

• abstract operations have no

implementation.

• abstract classes have one or more

abstract operations, and they can't be

instantiated.

example of gen. and poly.

exception for polymorphism

• 위 예에서 다형성을 적용하는데 있어서 특수한 경우에 대해서

override를 하고 있다.

• 위험성이 따른다. 가능한 피하도록 한다.

• 시스템 복잡도가 증가하는 경우 child가 개별적 정의를 하는 것은 시스템 유지 보수에 문제 파악 속도를 낮춘다.

package and its notation

• The package is the UML mechanism for

grouping things.

package diagram 활용 ?!

• package diagram을

정리하게 되면 시스템 상호 의존성 파악에 용이 또한 옆의 사례 경우와 같이 논리적 해결에

용이.

• 또한 package 변경에 있어서 연관성

참고 가능

Use case realization

• 지금까지 단계를 통해서 시스템을 class 기준으로 모델링하기 위한

구성 요소인 anaylsis classes들을 추출하였습니다. 이제는 use case

를 기준으로 realization을 하게 됩니다. 이 두 과정은 상호 영향을 미치는 작업으로 2개 과정이 동시에 일어날 수도 있습니다.

• anlaysis 관점

– anaylsis classes는 시스템에 대한 구성 요소 분석 측면

– use case realization은 시스템 동작에 대한 동적 상태 분석 측면

• use case realization은 collaboration diagram 또는

sequence diagrame으로 표현됩니다.

– 이 두 개의 diagram은 동전의 양면과 같음

– CASE 툴에서는 둘 중 하나를 그리면 다른 하나가 자동 생성

– 2개 diagram을 interaction diagram이라고 이야기 합니다.

interaction diagram

• 클래스/객체 간 상호 교류를 하면서 특정 목적을

달성하는 과정을 diagram으로 표시

(collaboration diag. and sequence diag.)

class diagram vs. collaboration diagram

descriptor

form

collaboration diagram

instance

form

동기 호출

비동기 호출

결과 반환

multiobject, iteration case

multi-object case

iteration case

branch and self-delegation case

concurrency - active objects

object status

use case & seq. diagram

• seq. diag.는 시간 순에 따른 시스템 흐름

표시에 용이. 직관적인 면 때문에 자주 사용하는 diagram.

seq. diag. details (1) - life, iter.

life cycle notation

iteration notation

seq. diag. details (2) - branch, self-delegation

seq. diag. details (3) - concurrency

seq. diag. details (4) - status

Analysis 단계 정리

• 대상 시스템에 대해서 요구 사항들을 추출해서 use case

diagram으로 정리하고, 각각에 대해서 use case spec을

작성합니다.

• 정리된 요구 사항을 반영할 수 있는 시스템을 만들기 위해서 분석 단계에 접어들면서, analysis classes를 도출하고,

이들이 움직이는 동작을 use case 기준으로 각기

interaction diagram을 작성합니다.

• 분석 단계에서 필요에 따라서 analysis classes를 추가하기도 하며, use case를 추가하기도 하는 등 작업 간 상호

비교 갱신해 나가도록 합니다.

[참조] activity diagram

OO flowcharts

activity diag. - decision

activity diag. - fork, join, object, swinlanes

activity diag. - signals

Design

design classes

refining analysis relationships

interfaces and subsystems

use case realization - design

state charts