검색결과 리스트
Domain Model에 해당되는 글 1건
- 2010.12.13 [OOAD] 요구사항 수집부터 분석까지
글
[OOAD] 요구사항 수집부터 분석까지
OOAD(Object Oriented Analysis Development)
OOAD 는 인간은 실수한다는 것을 전제하고 문제인식, 정보수집, 분석, 아키텍처, 설계, 구현, 테스트, 배포, 서비스,
유지보수의 일련의 개발과정을 반복적으로 수행해나가며 점진적으로 개선해나가며 시스템을 구축하는 개발 방법론
이다.
이 포스트에서는 각 단계에 대표되는 산출물들을 간략히 알아보도록 하겠다. 사실 각 단계가 무엇을 목표로 하는지가
더 중요하지만 이에 관한 사항들은 추후에 포스팅 하도록 하겠다. 들어가기에 앞서, "방법론은 산출물이 아니다" 라는
말만 명심해두자. 그 단계가 목표로 하는 것이 무엇이냐에 따라 도움이 되는 활동이라면 사실 어떠한 것도 산출물이
될 수도 있다. 즉 OOAD는 각 단계에 필요한 산출물을 확정짓지 않는다는 것이다.
소개될 산출물들은 Refinement(정제) 과정을 통해 끊임없이 수정되고 개선되어야 한다.
문답서 (인터뷰)
고객이 정말로 무엇을 원하는지 요구사항을 수집하고 업무의 흐름을 파악하는 과정으로
고객과 최대한 자연스러운 대화를 이끌어내야 한다. 여러차례에 걸쳐 대화를 통해 문답서를 정련해 나간다.
유스케이스
문답서를 바탕으로 시스템의 주체와 대상(액터), 그리고 업무의 핵심 서비스를 도출해 내는 과정이다.
이 과정은 문답서에서 명사와 동사를 힌트로 하여 추출해 낼 수 있다.
절차서
문답서를 바탕으로, 서비스 항목(기능)에 따라 비지니스 영역에서 업무가 어떠한 순서에 따라 일어나는지 정리한 문서이다.
이 문서는 정보수집과정에서 필요로하며, 시스템화 이전의 비스니스 업무가 어떻게 이루어졌는지 파악하는데 목적이 있다.
(이 단계에서 시스템적인 용어를 사용않고, 실제 업무(domain)에서 사용하는 용어를 사용한다)
분석절차서, 요구사항 기술서(Service Requirement Specification)
기존 업무흐름에서 시스템이 대체할 영역을 반영하여 절차를 다시 기술한 문서로 시스템화의 첫 진입점이 된다.
기존 업무가 시스템화 되었음을 가정하고, 그 절차를 기술하는 과정이다.
단어리스트
분석절차서를 바탕으로, 명사와 동사를 추출해서 나열하고, 그것들의 연관성과 책임을 식별하는 과정이다.
객체지향 개발을 위한 진입점이라 할 수 있다. 명사는 데이터가 되며, 동사는 데이터에 대한 조작/처리가 된다.
CRC (Class Relation Collaboration)
단어리스트에서 식별한 데이터와 그에 대한 처리를 관련있는 것들끼지 그룹화 하는 과정이다. 그 그룹들은 클래스의 후보들이
되며 이들 사이에 연관관계 또한 식별한다. 이 과정에서 각 그룹들을 카드화하여 서로 조합해보면서 각 기능을 수행할 최적의
그룹과 그 관계를 찾는 것이 좋은 방법이 된다. 이 방법을 개인적으로 해보지는 않았지만, 좀더 재사용성 좋고 견고한 SW가
되기 위해서 반드시 필요한 과정이라 생각한다.
Domain Model
클래스들의 전체적인 관계에 초점을 맞추어 특정 플랫폼과 기술에 종속적이지 않게 도식화한 문서이다.
도메인 모델의 클래스에는 범용타입의 데이터와 처리 메소드들도 표현된다. (메소드의 인자타입과 반환값도 표시됨)
Class Diagram
Domain Model 에 아키텍처(Architectur) 에서 결정된 플랫폼과 기술, 언어들이 적용되어 실제 구현언어의 클래스들로 관계를
도식화한 문서이다. (아키텍처를 적용하면, 3-tier, 웹, 클라이언트 등과 같은 아키텍처에 수반되는 역할을 갖는 클래스들이
추가(결합)가 된다. )
Sequence Diagram
서비스 또는 기능별로 객체들의 상호작용(메소드 호출)을 시간순으로 도식화 한 문서이다.
개인적으로 OOAD와 UML을 공부하면서, 항상 걸림돌이 되었던 부분이 절차와 데이터를 파악하고 나서, 객체지향 기술을
적용하는 부분이었다. 도출한 데이터와 절차를 바탕으로 절차지향적인 시스템으로 바꾸는 것은 어렵지 않은 일이다.
반면 객체지향적으로 바꾼답시고 데이터를 그룹화하고 클래스에 Model, View, Controller 라는 이름을 붙히는 것이 늘 왠지 어색
하고 찝찝한 과정이었다. 지금 생각해 보면 단어리스트와 CRC 를 바탕으로 최적의 방법으로 그룹핑하여 Domain Model을
도출하는 과정이 객체지향 프로그래밍 모델로의 첫번째 진입점이 된다고 생각한다. 두 번째는 웹 , 클라이언트/서버 아키텍처
등이 결정되어 도메인 모델과 결합되는 부분이라 생각한다.
기존에는 아키텍처라는 과정을 간과했기 때문에 늘 부자연스움을 느꼈던 것 같다.
'방법론로그 > OOAD' 카테고리의 다른 글
| 방법론(methodology) (0) | 2011.04.12 |
|---|---|
| 2011.03.08.Tues 아키텍처 발전역사 (0) | 2011.03.08 |
| [OOAD] 요구사항 수집부터 분석까지 (0) | 2010.12.13 |
| [OOAD] 아키텍처, IA , 화면기준안, 스토리보드 (1) | 2010.12.13 |