- 요구분석(Requirment Analysis)
고객의 요구를 충분히 알기 위해 그리고 이러한 요구를 구축할 시스템에 충분히 반영하기 위하여 요구분석의 단계가 필요하고 이것의 문서화가 필요하다. 이 단계는 또한 고객과 공급자간의 마찰이 생길때 이를 해결하기 위한 자료로써도 사용되어진다. 이러한 요구분석의 결과물로는 시스템에 요구하는 기능을 적어놓은 일반적인 문서가 된다. UML에서의 Use Case Diagram과 간단한 Class Diagram 그리고 Activity Diagram으로 표현이 되어진다.
- 분석(Analysis)
분석의 단계에서는 실제 풀어야 할 문제에 대한 분석을 필요로한다. 하지만 이러한 분석에서 세부적인 기술(implementation)이나 특정 기술(technic)은 배제하고 실세계의 존재물에 해당하는 모델들(classes, objects, interaction)에 관한 것이다.
- 해결 해야 될 문제의 영역에 대한 지식을 얻어야 한다. 이 지식은 기존 시스템의 기술(description), 사용자와의 대화, business process, term catalog, 같은 문제를 가지고 다른 팀. . 등등에서 가져올 수 있다.
- 적당한 클래스들의 후보(candidate)들을 찾아야 한다. 이 과정에서 brainstorming이 필요하며 이 과정이 끝난 후 모든 후보들에 대한 다시 한번 심각한 고찰이 필요하고 여기서 필요 없는 클래스가 생략되게 된다.
- 클래스들 사이의 정적인 관계가 모델링 되어진다. 예를 들어 association, aggregiation, generalization, dependencies등으로 관계들이 표현되어진다.
- 오브젝트들 사이의 행위(behavior)와 협력(collaboration)등을 state diagram, collaboration diagram, sequence diagram, activity diagram으로 표현되어진다.
- 모든 다이어그램이 완성되면 종이에 시스템을 실행시켜보는 방법으로써 다시 한번 검증하는 것이 필요하다.
-기본적인 user interface의 프로토타입을 만들어야 한다.
결과적으로 분석의 단계에서 나오는 결과물로 UML에서는 class diagram, sequence diagram, collaboration diagram, state diagram, activity diagram이 나오게 된다.
- 설계(Design)
설계 단계는 분석 단계의 결과물에 기술적인 부분을 첨가하여 확장하는 것이다. 기술적인 확장이란 시스템을 어떻게 구현(implement)할 것인지에 촛점을 두고 어떻게 동작하고 어떤 제약이 있어야 하는지에 관하여 생각하는 것이다. 이와 같이 설계 단계와 기술적인 하부구조를 분리하는 것은 분석 단계에서 만들어진 결과를 되도록이면 변화시키지 않고 유지하면서 하부구조를 좀 더 쉽게 변화시키거나 발전시킬 수 있도록 하기 위함이다.
- 분석단계에 나온 클래스들에서 기능적 패키지(functional package)들을 분리시킨다. 예를 들어 user interface, database handling, communication을 위한 패키지가 분석단계에서 나온 클래스들에 포함되어 있다면 기능적 패키지로 분리 시키고 없다면 첨가 시킨다.
- 동시성을 가진 행위의 경우 공유되는 자원에 대하여 acitive classes와 비동기적 메시지(asynchronous messages), 동기화 기술(synchronization technique)을 가지고 모델링되어야 한다.
- 시스템의 출력에 해당하는 형식이 정해져야 한다. 시스템의 출력은 user interface, 기록, 다 른 시스템과의 통신등과 같은 것이다.
- 필요한 외부 클래스 라이브러리나 컴포넌트를 명시하여야 한다
- 시스템에서 예상되는 예외(exception)상황에서의 에러처리를 고려하여야 한다.
설계단계에서의 결과물로 UML에서는 class diagram, sequence diagram, collaboration diagram, state diagram, activity diagram, component diagram, deployment diagram이 나오게 된다. - 구현(Implementation)
구현의 단계는 실제로 소스코드로 생성하는 단계이다. 만약 설계를 완벽하게 마쳤다면 구현의 경우는 아주 쉬운 작업이 될 것이다. 이 단계에서는 다이어그램에서 특정언어의 구문으로 옮겨 적는 과정 그리고 컴파일하고 링킹하고 다시 디버깅하는 작업이 포함되어있다. 실제로 소스코드의 작성은 프로그래머에게 익숙한 작업이고 친근한 작업이다. 하지만 객체지향 분석과 설계에서는 코딩을 먼저 하는 것이 바람직하지 못하다. 분석과 설계의 과정을 충분히 거치지 않고 바로 코딩을 할 경우 분석하고 설계하는 단계를 다시 하는 경우가 빈번하며 이는 오히려 프로젝트를 망치거나 장기화 시킬 우려가 대단히 크다.
- 테스트(Test)
마지막 단계로써 테스트의 목적은 코드에서의 에러를 발견하는 일이다. 여기서 에러의 발견은 프로그램에서의 실수가 아니고 성공이라고 보아도 좋다. 테스트 결과의 에러가 문서로 남게 되고 이것이 다음 버전에서 고쳐질 수 있기 때문이다.
Bookmark this on Delicious
댓글을 달아 주세요