OOAD 는 인간은 실수한다는 것을 전제하고  문제인식, 정보수집,  분석, 아키텍처, 설계, 구현, 테스트, 배포, 서비스, 

유지보수의 일련의 개발과정을 반복적으로 수행해나가며 점진적으로 개선해나가며 시스템을 구축하는 개발 방법론

이다.  

이 포스트에서는 각 단계에 대표되는 산출물들을 간략히 알아보도록 하겠다.   사실 각 단계가 무엇을 목표로 하는지가 

더 중요하지만 이에 관한 사항들은 추후에 포스팅 하도록 하겠다.  들어가기에 앞서,  "방법론은 산출물이 아니다" 라는

말만 명심해두자. 그 단계가 목표로 하는 것이 무엇이냐에 따라 도움이 되는 활동이라면 사실 어떠한 것도 산출물이 

될 수도 있다. 즉  OOAD는 각 단계에 필요한 산출물을 확정짓지 않는다는 것이다. 

소개될 산출물들은  Refinement(정제) 과정을 통해 끊임없이 수정되고 개선되어야 한다. 

고객이 정말로 무엇을 원하는지 요구사항을 수집하고  업무의 흐름을 파악하는 과정으로

고객과 최대한 자연스러운 대화를 이끌어내야 한다. 여러차례에 걸쳐 대화를 통해 문답서를 정련해 나간다. 

ex) 비디오 가게 회원관리 문답서

문답서를 바탕으로 시스템의 주체와 대상(액터), 그리고 업무의 핵심 서비스를 도출해 내는 과정이다.  

이 과정은 문답서에서 명사와 동사를 힌트로 하여 추출해 낼 수 있다.

문답서를 바탕으로, 서비스 항목(기능)에 따라 비지니스 영역에서 업무가 어떠한 순서에 따라 일어나는지 정리한 문서이다.

이 문서는 정보수집과정에서 필요로하며,  시스템화 이전의 비스니스 업무가 어떻게 이루어졌는지 파악하는데 목적이 있다.

(이 단계에서 시스템적인 용어를 사용않고, 실제 업무(domain)에서 사용하는 용어를 사용한다)

ex) 회원관리 절차서

기존 업무흐름에서 시스템이 대체할 영역을 반영하여 절차를 다시 기술한 문서로 시스템화의 첫 진입점이 된다. 

기존 업무가 시스템화 되었음을 가정하고, 그 절차를 기술하는 과정이다. 

ex) 분석 절차서

단어리스트에서 식별한 데이터와 그에 대한 처리를 관련있는 것들끼지 그룹화 하는 과정이다. 그 그룹들은 클래스의 후보들이

되며 이들 사이에  연관관계 또한 식별한다.  이 과정에서 각 그룹들을 카드화하여 서로 조합해보면서 각 기능을 수행할 최적의

그룹과 그 관계를  찾는 것이 좋은 방법이 된다.  이 방법을 개인적으로 해보지는 않았지만, 좀더 재사용성 좋고  견고한 SW가

되기 위해서 반드시 필요한 과정이라 생각한다. 

클래스들의 전체적인 관계에 초점을 맞추어 특정 플랫폼과 기술에 종속적이지 않게  도식화한 문서이다. 

도메인 모델의 클래스에는 범용타입의 데이터와 처리 메소드들도 표현된다. (메소드의 인자타입과 반환값도 표시됨) 

ex) 회원관리 단어리스트, CRC, Domain Model

 Domain Model 에 아키텍처(Architectur) 에서 결정된 플랫폼과 기술,  언어들이 적용되어  실제 구현언어의 클래스들로 관계를 

도식화한 문서이다. (아키텍처를 적용하면, 3-tier, 웹, 클라이언트 등과 같은 아키텍처에 수반되는 역할을 갖는 클래스들이 

추가(결합)가 된다. )

ex) 회원관리 Class Diagram

서비스 또는 기능별로 객체들의 상호작용(메소드 호출)을 시간순으로 도식화 한 문서이다. 

ex) Sequence Diagram

개인적으로   OOAD와 UML을 공부하면서, 항상 걸림돌이 되었던 부분이 절차와 데이터를 파악하고 나서, 객체지향 기술을

적용하는 부분이었다.   도출한 데이터와 절차를 바탕으로 절차지향적인 시스템으로 바꾸는 것은 어렵지 않은 일이다. 

반면  객체지향적으로 바꾼답시고 데이터를 그룹화하고 클래스에  Model, View, Controller 라는 이름을 붙히는 것이 늘 왠지 어색

하고 찝찝한 과정이었다.   지금 생각해 보면 단어리스트와 CRC 를 바탕으로 최적의 방법으로 그룹핑하여 Domain Model을 

도출하는 과정이 객체지향 프로그래밍 모델로의 첫번째 진입점이 된다고 생각한다.  두 번째는 웹 , 클라이언트/서버 아키텍처 

등이 결정되어  도메인 모델과 결합되는 부분이라 생각한다.  

 기존에는 아키텍처라는 과정을 간과했기 때문에  늘  부자연스움을 느꼈던  것 같다.  

이 포스트에서는 아키텍처와 UI 디자인 단계의 산출물에 대해서 간략하게 알아볼 것이다..

아키텍처가 결정됨과 동시에 Programming 설계와 더블어 UI 설계를 시작하게 된다. UI 설계 단계의 산출물에는 

 IA, 화면기준안, 스토리 보드가 존재한다.  이들 하나하나에 대해서만 알아볼 것이며, 이것들을 하나의 흐름으로 

연관지어 설명하지는 않겠다. 이런것들이 무언인지만 파악하고, 추후 포스트에서 전체적인 흐름을 설명하겠다. 

 stand alone : 단일 PC에서 동작하는 구성

 2-Tier : client와 데이터 및 그것을 처리하는 비지니스 로직을 갖는 DB, 2개 층으로 구성되는 시스템

 3-Tier : 비지니로직를 갖는 DB에 대한 부하를 분산하기 위해, 비지니스 로직을 WAS(Web Application Server)에 별도로                                 분리해 3개층으로 구성되는 시스템 형태. 여러 대의 WAS 를 마치 하나처럼  클러스터링하여 부하를 분담한다 

웹 아키텍쳐: 시스템의 접근이 웹으로 이루어지는 구성

애플리케이션 아키텍처: 시스템의 접근이 애플리케이션을 통해 이루어지는 구성

엔터프라이즈 아키텍처 : 시스템의 접근이 웹과 애플리케이션을 통해 이루어지는 구성

여러대의 병렬 DB들을 마치 하나의 DB인 것처럼 사용할 수 있는 오라클 DB 클러스터링 기법