이전 글에서 객체지향 분석설계(OOAD-Object Oriented Analysis and Design)의 개요와 그 의의에 대해 간단히 정리해보았다.
이번 글에서는 OOAD의 주요 산출물을 간결하게 정리하고자 한다.
각 산출물들은 따로따로 노는 것이 아니라, 유기적으로 연결되어야 하며, 논리적이며, 모순이 없어야 한다.
예를 들어, Use Case Diagram에는 표현되어있지만 Domain Diagram에는 빠져있다던가, Sequence Diagram에는 들어있지만 Requirements에는 빠져있다던가 ..
이런 내용 누락과 모순이 발생하게 되면, 결국 설계에 빈틈이 생기게 되고, 요구사항이 누락되게 된다.
Requirements(FR/NFR) :
기능적 요구사항(Functional Requirements), 비 기능적 요구사항(Non Functional Requirements) 를 테이블 형식으로 적는다.
이 요구사항들은 각각 FR-Use case, NFR-QA로 연결된다.
Use Case Diagram :
Use case들이 정리된 뒤, 각 Use case의 Actor와 System 중 어떤 모듈과 상호작용을 하는지를 UML로 표현한다.
Actor는 Use case의 이해관계자에 해당하며, 둘 이상이 될 수 있다.
Fully Dressed-up Form :
Use case들을 도출한 뒤, Use case들의 세부 명세를 작성한다.
Use case의 범위와 Actor, 이해관계자와 Pre condition, Basic Flow, Alternative Flow, Include/Exclude Relationship, 기타 등등 … Use case들에 대해 모두 작성한다.
Domain Model :
Use case들과 FDF(Fully Dressed-up Form) 산출물을 통해, 해당 시스템의 도메인(Domain)을 정의한다.
Use case에서 등장한 개념들과 관계들이 보통 도메인 대상이 될 수 있으며, Use case에서 서술된 술어나 형용사 등이 각 도메인의 Property나 각 도메인 간 관계로 표현될 수 있다.
이 단계까지는 Implements Specific한 내용을 담지 않도록 주의한다. (DBMS를 뭘로 쓸 것인가, 프레임워크를 뭘 도입할 것인가 등)
최대한 현실 세계의 문제를 해결하기 위해, 시스템의 도메인을 Use case의 세계에 매핑되도록 작성하는 것이 중요하다.
도메인은 표로 정리하고, UML을 이용하여 다이어그램으로도 같이 표현해주면 도움이 된다.
System Sequence Diagram :
각 Use case 안에서, Actor와 System이 어떻게 상호작용을 하는지 나타내는 다이어그램이다.
Use case diagram, Domain diagram과 마찬가지로 표준 UML로 그려진다.
세부 도메인들은 System에 가려져있으며, 보통 System Sequence Diagram을 도출하는 것 까지가 객체지향 분석(OOA-Object Oriented Analysis)에 해당한다.
Sequence Diagram :
Sequence Diagram부터는 객체지향 분석 디자인(OOD-Object Oriented Design)의 산출물로 간주된다.
SSD(System Sequence Diagram)에서 블랙박스로 감추어진 System을 정의한 Domain 간 상호작용으로 표현한다.
UCD(Use Case Diagram), DD(Domain Diagram), SSD와 마찬가지로, 표준 UML을 활용하여 작성한다.
Class Diagram :
SD(Sequence Diagram)을 정의한 뒤, Domain에 해당하는 모듈들을 class level로 도출한다.
역시 표준 UML로 작성하며, 각 class간 관계를 드러낸다.
Class Diagram의 Notation은 Direction, Association, Aggregation, Composition, Inheritance 등이 있는데..
이 부분은 Domain들이 어떻게 유기적으로 관계를 맺는지에 따라 취사선택하면 된다.
CD의 Notation에 대해서는 따로 다룰 수 있는 기회가 있으면 좋겠다.
Traceability :
각 산출물 간 추적이 가능하도록 주기를 매겨두는 것 이라고 생각하면 좋을것 같다.
별도의 양식이나 규칙은 없고, 팀 내부에서 산출물 간 추적이 가능하도록 식별자를 붙여두면 좋을 것이다.
예를 들면, Requirements는 R-03, Use case는 U-03, Domain은 D-03, … 이런식으로 말이다.
Glossary :
요구사항과 도메인 내 모르는 용어나 개념들을 정리하기 위한 사전 역할을 한다.
팀원들이 읽고 잘 소통할 수 있도록, 팀원들이 잘 아는 단어 및 용어로 기술한다.
이렇게 매우 간단하게 OOAD에서 다루는 산출물을 정리해보았다.
현업에서도 OOAD 활동을 게을리해서 막판에 피눈물을 흘리는 경우들이 많았던 것 같아서 ..
강의안을 보는 내내 반성하게 되었다.
요구공학과 OOAD를 FM대로 수행하기는 어려울 수 있지만, 핵심 가치들을 잃어버리지 않도록..
정신을 잘 차려야겠다.