* Design & implementation
- 실행 가능한 소프트웨어 System을 개발하는 것
- inter-leaved : design과 implementation은 동시에 발생한다.
- Build(구현) or Buy(구매)
> 구매 : Commercial off the shelf system(COTS)
> 사느냐, 구현하느냐에 따라 System이 달라진다.
* Object-Oriented Design Process
- 구조적 개발 방법론을 사용하기 때문에 Large-System 개발에 용이
- small system 개발에는 비용적 측면이 비효율 적일 수 있다.
* Process stage
- Define the context
- Design the System Architecture
- Identify the objects
- Develop design models(Using Diagram)
- Specify Object interface(Attribute, Method)
ⓐ System Context and interactions
- 시스템 구현의 Boundary를 설정
- 자신의 System에 포함된 것과 포함되지 않은 것을 정적, 동적으로 밝힌다.
- Output : A system context model(정적)
An interaction model(정적인 것의 동적인 연결 관계)
- 각각의 커다란 System들의 연결관계를 밝힌 후, activity를 세분화하여 usecase diagram을 그린다.
표를 추가하여 각 activity가 하는 일을 작성해준다.
ⓑ Architectural design
- 주요 컴포넌트와 컴포넌트간의 상호관계를 밝힌다.
- 주요 컴포넌트를 조직화하여 package로 나타낸 후, 그들의 연관 간계를 나타낸다.
또한, package 내부에서의 컴포넌트 간의 상호관계도 밝힌다.
ex)
ⓒ Object class identification
- 객체의 클래스를 정하는 것으로 정해진 형식이 없으며, 반복적인 작업으로 이루어진다.
- object를 알아보는 일반론
1) 문법적 접근 방법 : 명사 = class로 잡힐 가능성이 많다.
2) 눈에 보이는 것은 class로 될 가능성이 많다.
3) 사용사례, 시나리오를 통해서 1)과 2)를 실시한다.
4) class의 특징을 사용한다. > 모든 클래스는 책임을 갖고 있다.
> 각 클래스(명사)가 책입지는 것(하는 일)을 작성한다.
> 만약, 책임지는 것이 없다면 Attribute가 될 것이다.
ⓓ Design Models
- Package diagram or class diagram등으로 static model(정적 모델)을 작성한다.
(아마도 ⓒ단계에서 이일을 햇을 것이다.)
- Static model의 연결관계인 dynamic interaction을 그린다.
이때, Sequence diagram, component diagram, state diagram등을 사용한다.
(이는 ⓑ단계의 산출물을 이용하면 될 것이다.)
- Sub System model도 그려준다(Package의 계층적으로 접근)
ⓔ Interface specification
- Interface로써 사용할 만한 것은 interface로 뽑아낸다.
* Design Pattern
- 여기서 말하는 Design은 object, class를 밝히는 과정이다.
- Pattern을 가져와 Domain 요구사항을 추가한다.
- 각각의 pattern은 다음과 같은 요소로 표현된다.
ⓐ Name : Pattern Name
ⓑ Description : 목적
ⓒ Problem description : 풀고자하는 문제
ⓓ solution description : 해결법
ⓔ Consequence : 주의점, 부작용
ⓕ 필요하다면 UML을 추가로 그려준다
- Pattern들에 대해서는 다음에 소개하도록 하겠다.
- 대표적인 pattern으로는 observer, facade, iterator, decorator가 존재한다.