2. 개발 process에서 analysis
• Analysis는 원하는 시스템(use case modelling 및 requirement 조사
단계를 통해 구체화된 시스템)이 가지는 필수적인 요구 사항 및 특징
들을 잡아서 이를 나타내는 model을 만드는 과정
• 본 단계를 거치면
– analysis classes: business domain의 주요 개념에 대한 model
– use case realization: use case를 달성하기 위해 class간 상호 작용하는 과정 기술
requirment 추출과
analysis 통한 모델 구축은
수시로 영향 주고 받는 단계
3. Analysis model is ...
• 가능한 대부분 참여자(디자이너, 개발자, 사용자)에게 의
미 있는 결과물이여야 한다.
• 항상 business 영역(실제 모델링하고자 하는 영역)의 언
어로 표현된다.
• 전반적인 큰 그림을 잡는다.
– problem domain에 대한 이야기만.
– 가령 전자 상거래에 대한 analysis model은 Customer, Order와 같
은 것으로 구성되어야지, 실제 db 접근 처리나 classes간 통신 프
로토콜등이 나와서는 안 된다.
• coupling이 최소화 되어 있어야 한다.
• 원하는 시스템에 대한 이야기를 담고 있게 된다. (use
case realization)
5. class
• 클래스는 추상화를 통해 어떤 대상을 모델링한 것.
– 동일한 유형에 속하는 모든 객체를 대표하는 개념.
대상이 가지는 데이터 및 속성과 동작을 한데 어울러서 표현.
– 절차지향 프로그래밍에서는 동작을 중심으로 처리가 되어가며,
데이터(속성)과는 분리된 형태
– 현실을 모델링하는 개념 중 하나로서, 기존 절치지향 개념에 의한
모델링 보다 현실 모델링에 적합한 특성을 지닌다.
• 객체 지향 모델링이 가지는 특성
– 추상화(abstaction)
– 상속성(inheritance)
– 캡슐화(encapsulation)
– 다양성(polymorphism)과 동적 바인딩(dynamic binding)
6. OO 특성이 가지는 혜택
• 추상화, 상속성
– 문제 도메인 공통 요소에 따른 동작을 중복 정의하지 않아도 된다.
– 추상화 레벨 정도에 따라서 그에 따른 동작을 정의함으로서, 중복적인 구현 및 이
로 인한 문제점을 사전 방지할 수 있으며, 문제 발견 및 조치에 대한 주의를 집중시
킬 수 있다.
• 데이터 은닉/캡슐화 (encapsulation)
– 데이터 자체에 대한 제어를 직접적으로 하지 않고 특정 동작을 통해서 수행함으로
서, 관련된 logic을 제어할 수 있다.
– 데이터 처리에 방식이 달라지는 경우, 접근 함수 자체는 동일하게 유지되면서, 해
당 함수 자체에서 logic만을 변경하게 된다. => 시스템이 변동성에 대해서 내성을
가짐
– 노출되는 범위를 제어하여 문제 발생 범위와 해결 범위를 제약할 수 있다.
– 예) 특정 문서 목록을 추출하는 함수. DB 직접 접근 vs. 함수 호출
• 다형성과 동적 바인딩
– 사용자는 동일한 동작에 대해서는 동일한 동작을 수행할 수 있다.
– 대상이 가지는 특성에 따른 동작에 대해서는 고민하지 않는다, 단지 output만 생각
할 뿐이다.
– 예) mydocs 문서 목록 가져오기 vs 일반 docs 문서 목록 가져오기: listItems()
7. Object and instance
• Every object is an instance of exactly one class.
• Object ...
– 관련 데이터(attribute)와 동작(operation, method,
function)을 한 묶음으로 구성
– 모든 object는 식별가능 해야 한다.
– 다른 object에게 message를 던져서 작동을 한다.
9. UML class notation
• visibility (접근 권한) - 신중신중!!
+ public
- private
# protected
~ package
10. analysis classes in dev. process
analysis classes는 problem domain을
모델링하는 데 필요한 개념들을 class
들로 구성해가는 과정.
[질문] 어떻게 class들을 추출해 내갈 것
인가?
[질문] 실제 use case는 어떻게 본 단계
와 연관되어지는 것일까?
11. Finding the classes
• class는 시스템을 바라보는 관점이며, 이는 개인적 경험에
따라 경험적인 측면에서 추출하는 경향이 크다.
• 일반적 방법
– 본 단계에서는 기존 요구 명세 및 use case가 활용될 수 있다.
– [방법 1.]요구 사항을 분석해서 명사와 동사를 정리해 가면서 동일
역할 부분을 한데 묶어 간다.
– [방법 2.] CRC (Class Name, Responsibilities, Collaborators)
– Patterns.
12. 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.
18. abstract relation and polymorphism
• abstract operations have no
implementation.
• abstract classes have one or more
abstract operations, and they can't be
instantiated.
20. exception for polymorphism
• 위 예에서 다형성을 적용하는데 있어서 특수한 경우에 대해서
override를 하고 있다.
• 위험성이 따른다. 가능한 피하도록 한다.
• 시스템 복잡도가 증가하는 경우 child가 개별적 정의를 하는 것은 시
스템 유지 보수에 문제 파악 속도를 낮춘다.
21. package and its notation
• The package is the UML mechanism for
grouping things.
22. package diagram 활용 ?!
• package diagram을
정리하게 되면 시스
템 상호 의존성 파
악에 용이 또한 옆
의 사례 경우와 같
이 논리적 해결에
용이.
• 또한 package 변경
에 있어서 연관성
참고 가능
23. 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이라고 이야기 합니다.
36. Analysis 단계 정리
• 대상 시스템에 대해서 요구 사항들을 추출해서 use case
diagram으로 정리하고, 각각에 대해서 use case spec을
작성합니다.
• 정리된 요구 사항을 반영할 수 있는 시스템을 만들기 위해
서 분석 단계에 접어들면서, analysis classes를 도출하고,
이들이 움직이는 동작을 use case 기준으로 각기
interaction diagram을 작성합니다.
• 분석 단계에서 필요에 따라서 analysis classes를 추가하
기도 하며, use case를 추가하기도 하는 등 작업 간 상호
비교 갱신해 나가도록 합니다.
