문서요약 - 객체 지향 설계 인스펙션을 위한 리딩 기법 by Travassos

제목: 객체 지향 설계 인스펙션을 위한 리딩 기법(Reading Techniques for OO Design Inspections)

저자: Guilherme H. Travassos 외 3인, 브라질

문서유형: 기술 문서(총 56페이지), 2002년

 

UML 기반 객체 지향 설계 산출물을 인스펙션 하는데 도움이 되는 리딩 기법을 제안한 자료

---

인스펙션

• 특정 소프트웨어 산출물(a software artifact)이 완전하고, 일관성 있고, 모호하지 않으며, 정확함을 보장하는 것을 목적으로 함
• 통상적으로 인스펙션은 1) 먼저 개인이 특정 산출물을 검토하고, 2) 팀으로 만나 발견한 결함을 토론 및 기록하고, 3) 이것을 해당 산출물의 작성자에게 알려 수정토록 함
• 상위 수준 설계가 완성되면 설계 문서들을 인스펙션하여 서로 일관성이 있는지 그리고 소프트웨어 요구사항이 설계에서 정확하고 완전하게 캡쳐되었는지 검증할 수 있음. 본 논문은 상위 수준 객체 지향 설계 문서를 인스펙션하기 위한 리딩 기법에 대하여 기술함

리딩 기법(reading techniques)

• 개별 검토자가 주어진 소프트웨어 산출물을 조사(판독)하고 결함을 식별하는데 사용될 수 있는 절차적 지침(리딩 기법)을 제공함으로써 인스펙션의 효과성을 증가시키고자 함
• 본 연구는 UML(Unified Modeling Language)을 사용해 표현한 상위 수준 객체 지향 설계 다이어그램에서의 결함 발견을 위한 소프트웨어 리딩 기법을 제안함
• 시스템의 정적 뷰와 동적 뷰를 캡쳐한 상위 수준 설계 산출물을 인스펙션 하는데 사용되는 이 리딩 기법을 ‘OORTs(The Object-Oriented Reading Techniques)’라 부름

소프트웨어 결함 타입

제안된 리딩 기법이 중점을 둔 결함 타입이 아래와 같다.

• 누락(Omission): 요구사항 문서로부터의 어떤 개념을 포함해야 하는 하나(또는 하나 이상)의 설계 다이어그램이 해당 개념을 위한 묘사를 포함하지 않고 있다.
• 부정확한 사실(Incorrect Fact): 설계 다이어그램이 요구사항 문서에 기술된 어떤 개념의 잘못된 묘사(a misrepresentation)를 포함하고 있다.
• 일관성 없음(Inconsistency): 한 설계 다이어그램에서의 어떤 개념의 묘사가 같은 설계 다이어그램에서(또는 다른 설계 다이어그램에서)의 동일한 개념의 묘사와 불일치 한다.
• 모호성(Ambiguity): 설계에서 어떤 개념의 묘사가 불명확하여 문서의 독자(개발자, 하위 수준 설계자 등)가 해당 개념의 의미를 잘못 해석하거나 오해하게 만들 수 있다.
• 관련 없는 정보(Extraneous Information): 맞는 사실일지는 몰라도 해당 도메인에 적용되지 않는(그래서 설계에 포함되어서는 안 되는) 정보를 설계가 포함하고 있다.

제안된 리딩 기법의 집합(OORT 3.0)

• 서로 유용하게 비교될 수 있는 다이어그램의 각 쌍을 위해 하나의 리딩 기법을 정의함. 제안된 OORT 3.0이 아래와 같은 7개의 리딩 기법으로 구성됨
  - OORT-1: 시퀀스 다이어그램 vs. 클래스 다이어그램
  - OORT-2: 상태 다이어그램 vs. 클래스 기술서
  - OORT-3: 시퀀스 다이어그램 vs. 상태 다이어그램
  - OORT-4: 클래스 다이어그램 vs. 클래스 기술서
  - OORT-5: 클래스 기술서 vs. 요구사항 기술서
  - OORT-6: 시퀀스 다이어그램 vs. 유스케이스
  - OORT-7: 상태 다이어그램 vs. (요구사항 기술서/유스케이스)
• 리딩 기법 1~4는 수평적 리딩(horizontal reading)이고, 5~7은 수직적 리딩(vertical reading)이다. 수평적 리딩은 하나의 생명 주기 단계 내의 문서들이 비교되고, 수직적 리딩은 다른 생명 주기 단계에 있는 문서 간의 비교가 수행된다.
• 수평적 리딩은 모든 설계 산출물이 동일한 시스템을 서술하고 있는지 식별하는 것이 목적이고, 수직적 리딩은 설계 산출물이 요구사항과 유스케이스에 의해 기술된 시스템을 올바르게 묘사하는지 검증하는 것이 목적이다.
• 수평적 기법이 수직적 기법에 앞서서 수행되는 것이 일반적이지만, 검토할 설계의 중요 속성에 따라 기법들의 일부분만 선택되거나 또는 순서가 바뀔 수도 있음

[객체 지향 리딩 기법]

OORT-1: 시퀀스 다이어그램 vs. 클래스 다이어그램

목표: 클래스 다이어그램이 시퀀스 다이어그램이 명세한 동작을 정확하게 실현하도록 클래스와 클래스 간의 관계를 기술하는지 확인

프로세스 입력:

1. 시스템의 클래스와 이것들이 어떻게 연관되어 있는지를 기술한 클래스 다이어그램

2. 시스템의 클래스/오브젝트/액터를 기술하고 또한 이들이 시스템의 서비스를 실현하기 위해 어떻게 협력하는지를 기술한 시퀀스 다이어그램

 

I. 시퀀스 다이어그램을 선정하고, 기술된 시스템 서비스를 이해하기 위해 그리고 어떻게 시스템이 이 서비스들을 구현해야 하는지 이해하기 위해 시퀀스 다이어그램을 읽는다.

A. 각 시퀀스 다이어그램에서 오브젝트, 클래스, 액터를 파란 펜으로 밑줄 친다.

B. 오브젝트 간에 교환되는 정보(메시지 또는 서비스)를 녹색 펜으로 밑줄 친다.

C 메시지와 서비스 상의 제약을 노란 펜으로 동그라미 친다. 또한 메시지 전송이 이루어지는 상황을 결정하는 조건(conditions)도 동그라미를 그어 표시한다.

II. 상응하는 시스템 오브젝트가 정확하게 기술되었는지 확인하기 위해 관련 클래스 다이어그램을 식별해 인스펙션 한다.

A. 시퀀스 다이어그램에 있는 모든 객체/클래스/액터가 클래스 다이어그램의 구체적인 클래스에 의해 표현되었는지 확인한다. 클래스와 액터의 경우 단순히 클래스 다이어그램 상의 이름을 찾고, 오브젝트의 경우 해당 오브젝트가 인스턴스화된 클래스의 이름을 찾음. 아래를 체크해 불일치가 발견되면 불일치보고서(the discrepancy report form)에 기록한다.

• 클래스/오브젝트가 클래스 다이어그램 상에서 발견되지 않으면 양 문서 간의 정보가 비일관적임을 의미
• 액터가 발견되지 않은 경우 필수 동작을 제공하기 위하여 이 액터가 시스템에서 하나의 클래스로써 표현될 필요가 있는지 판단한다. 만일 그렇다면 시퀀스 다이어그램에 등장하는 정보가 클래스 다이어그램에서는 누락된 것을 의미

B. 시퀀스 다이어그램의 녹색으로 표시된 모든 서비스/메시지에 대해 상응하는 동작이 클래스 다이어그램 상에 등장하는지 확인한다. 아래를 체크해 불일치가 있으면 불일치보고서에 기록함

• 시퀀스 다이어그램의 각 메시지에 대해 이를 수신하는 클래스가 클래스 다이어그램 상에서 적절한 동작을 포함하는지 확인. 그렇지 않은 경우는 다이어그램 간의 불일치를 의미(즉, 시퀀스 다이어그램에 존재하는 어떤 동작이 클래스 다이어그램에서는 누락)
• 시스템 서비스를 위한 적절한 동작이 있는지 확인. 그렇지 못한 경우는 시퀀스 다이어그램 상에 존재하는 어떤 서비스가 클래스 다이어그램 상에서는 표현되지 않았음을 의미
• 메시지가 전송되는 두 클래스 간의 어떤 연관성(association)이 클래스 다이어그램 상에 존재하는지 확인. 그렇지 못한 경우는 시퀀스 다이어그램에서는 메시지 교환 때문에 어떤 연관성이 존재하지만 이것이 클래스 다이어그램에서는 나타나지 않음을 의미
• 서비스가 달성되는 것을 막는 누락된 동작이 없음을 확인한다. 만약 이런 것이 있다면 시퀀스 다이어그램에서 뭔가가 누락되었음을 의미

C. 시퀀스 다이어그램에서 식별된 제약을 클래스 다이어그램이 충족시킬 수 있는지 확인. 아래를 체크해 불일치가 있으면 불일치보고서에 기록함

• 시퀀스 다이어그램이 메시지를 수신할 수 있는 오브젝트 수에 제한을 가하면 이 제약이 클래스 다이어그램에서 적절한 연관성의 카디널리티(cardinality) 정보로 등장하는지 확인한다.
• 시퀀스 다이어그램이 데이터의 허용가능한 값들의 범위를 명세하면 이 제약이 클래스 다이어그램에서 애트리뷰트 상의 값 범위로써 등장하는지 확인한다.
• 시퀀스 다이어그램이 데이터/오브젝트 간의 의존성에 관한 정보를 포함하면(예, 최소한 하나의 ‘구매’ 오브젝트가 존재하지 않는 한 ‘청구서’ 오브젝트가 존재할 수 없음) 이 정보가 클래스 다이어그램에서 클래스/관계 상의 제약으로써 포함되는지 확인한다.
• 시퀀스 다이어그램이 오브젝트 상태에 영향을 줄 수 있는 타이밍 제약을 포함하면(예, 5분 내에 입력이 수신되지 않으면 원도우가 닫힌다) 이 정보가 클래스 다이어그램에서 클래스/관계 상의 제약으로써 포함되는지 확인한다. 

D. 식별된 각 클래스, 메시지, 데이터에 대해 (검토자의 과거 경험에 비추어) 타당한 설계가 나왔는지 고민한다(예, 응집력, 결합력 같은 설계의 품질 속성을 고려). 아래 사항을 체크한다.

• 클래스가 이 데이터를 가진 이 메시지를 수신하는 것이 논리적인가?
• 제약이 타당한지를 검증할 수 있는가?
• 모든 필수 애트리뷰트가 정의되었는가?
• 시퀀스 다이어그램에 명세된 클래스에 대해 클래스 다이어그램에서 이 클래스를 위해 명세된 동작과 애트리뷰트가 말이 되는가?
• 클래스 명이 그 도메인, 애트리뷰트, 그리고 동작에 적합한가?
• 타 클래스와의 관계(relationships)가 적절한가?
• 관계가 올바른 타입인가(예, association이 적절한 곳에서 composition 관계가 사용되지는 않았는가)?

OORT-2: 상태 다이어그램 vs. 클래스 기술서

목표: 클래스가 상태 다이어그램이 명세한 기능을 실현할 수 있도록 정의되었는지 확인

프로세스 입력:

1. 시스템의 클래스를 그 애트리뷰트 및 동작과 함께 나열한 클래스 기술서 들의 집합

2. 오브젝트가 존재할 수도 있는 내적 상태(states)와 이 상태들 간의 가능한 전이(transitions)를 기술한 상태 다이어그램

 

I. 오브젝트의 가능한 상태와 상태 간의 전이를 트리거하는 액션을 이해하기 위해 상태 다이어그램을 읽는다.

A. 상태 다이어그램이 어떤 클래스를 모델링하고 있는지 식별한다. 식별이 불가능하면 뭔가가 누락되었거나 모호하다는 의미이므로 불일치보고서에 기록한다.

B. 상태 다이어그램에서 상태 시퀀스와 상태 전이 액션을 추적한다. 초기 상태부터 시작해서 최종 상태에 도달할 때까지 전이를 따라감(모든 전이가 커버되었는지 확인)

C. 따라 가는 중에 상태가 나타나면 파란 펜으로 상태의 이름에 밑줄 친다.

D. 따라 가는 중에 전이 액션(화살표)이 나타나면 녹색 펜으로 표시한다.

E. 방금 식별한 상태와 액션들이 어떻게 맞아 떨어지는지 생각해 본다.

• 검토자가 상태 머신을 읽는 것만으로 오브젝트에 어떤 일이 일어나는지 이해하고 기술할 수 있어야 함. 그렇지 못하면 상태 머신이 모호한 것이므로 불일치보고서에 기록한다.

II. 상태 다이어그램 상의 개념에 상응하는 클래스(또는 클래스 계층)/애트리뷰트/동작을 클래스 기술서 상에서 찾는다.

A. 클래스 기술서에서 상태 다이어그램에 상응하는 클래스(또는 클래스 계층)을 찾는다. 상응하는 클래스를 찾을 수 없으면 상태 머신이 클래스 기술서 상에 기술되지 않은 클래스를 기술하고 있으므로 불일치보고서에 기록한다.

 

B. 클래스가 상태 다이어그램의 파란 밑줄이 쳐진 상태들을 어떻게 인캡슐레이션 하는지 파악한다. 상응하는 클래스뿐만 아니라 상속 계층에 있는 부모 클래스를 모두 체크해야 함. 각 파란 밑줄 쳐진 상태가 발견될 때마다 별표로(*) 표시한다.

• 별표가 없는 상태가 있다면 클래스 기술서에서 뭔가가 누락되었음을 의미. 도메인 지식에 기반해 이 추가적인 상태가 말이 안 된다고 판단되면 이를 불일치보고서에 기록하고, 판단 못하면 단순히 두 다이어그램이 일관적이지 않다고 기록한다.

 

C. 상태 다이어그램에서 녹색으로 표시된 각 전이 액션에 대해 해당 전이를 달성할 수 있는 클래스 동작이 있음을 확인한다(현재 선정된 클래스 외에도 상속 계층의 상위에 위치한 클래스도 검토). 전이 액션이 이벤트(뭔가가 일어날 때 전이가 발생)이면 해당 이벤트를 달성시키는 동작을 찾는다. 전이 액션이 제약이면(즉, 표현식이 참 또는 거짓이 되면 전이 발생) 제약 표현식의 값을 변경시킬 수 있는 동작을 찾는다. 아래를 체크해 불일치를 발견하면 불일치보고서에 기록한다.

• 모든 액션이 클래스 기술서에 포함되었는지 확인한다. 그렇지 못하면 상태 다이어그램에서 표현된 것이 클래스 기술서에서는 표현되지 않았음을 의미
• 모든 제약이 클래스 기술서에 포함되었는지 확인한다. 그렇지 못하면 상태 다이어그램 상에 표현된 뭔가가 클래스 기술서에는 있지 않음을 의미
• 제약을 검증하는데 필요한 모든 데이터가 클래스 기술서에 존재함을 확인한다. 그렇지 못한 경우는 상태 다이어그램에 있는 정보가 클래스 기술서에는 없음을 의미 

III. 클래스가 기술된 대로 적절한 기능(functionality)을 실현할 수 있음을 확인하기 위해 클래스 기술서를 상태 다이어그램과 비교한다.

A. 클래스가 참여하는 시스템 기능(클래스 기술서에 기술됨)과 이 기능이 존재하는 상태(상태 다이어그램에 기술됨)를 고려한다.

• 클래스와 클래스가 인캡술레이션하는 동작에 대한 검토자의 시맨틱 지식에 기반하여 모든 상태가 기술되었는지를 확인한다. 그렇지 못한 경우는 뭔가가 누락되었고 클래스가 의도대로 동작할 수 없음을 의미하므로 이를 불일치보고서에 기술한다.

OORT-3: 시퀀스 다이어그램 vs. 상태 다이어그램

목표: 오브젝트의 모든 상태 전이가 해당 오브젝트가 송신 및 수신한 메시지에 의해 달성될 수 있음을 확인

프로세스 입력:

1. 시스템의 클래스, 오브젝트, 액터를 기술하고 또한 이것들이 시스템의 서비스를 실현하기 위해 어떻게 협업하는지 기술한 시퀀스 다이어그램

2. 오브젝트가 존재할 수도 있는 내적 상태와 상태 간 가능한 전이를 기술한 상태 다이어그램

I. 오브젝트의 가능한 상태와 상태 간 전이를 트리거하는 액션을 이해하기 위해 상태 다이어그램을 읽는다.

A. 어떤 클래스가 이 상태 다이어그램에 의해 모델링 되는지 결정한다. 이를 결정할 수 없다면 뭔가가 누락 되었거나 모호하다는 의미이므로 이를 불일치보고서에 기록한다.

B. 상태 다이어그램에서 상태 시퀀스와 전이 액션을 추적한다. 초기 상태부터 시작해서 최종 상태에 도달할 때까지 전이를 따라간다(모든 전이가 커버되었는지 확인)

C. 따라가면서 전이 액션(화살표)이 나타나면 녹색 펜으로 표시한다.

D. 방금 식별한 상태와 액션들이 어떻게 맞아 떨어지는지 생각한다.

• 검토자가 단지 상태 머신을 읽음으로써 오브젝트에 어떤 일이 일어나는지 이해하고 기술할 수 있다. 그렇지 못하면 상태 머신이 모호한 것이므로 불일치보고서에 기록한다.

II. 어떻게 전이 액션이 관련 오브젝트가 송신 및 수신한 메시지에 의해 달성되는지를 이해하기 위해 시퀀스 다이어그램을 읽는다.

A. 상태 다이어그램에 의해 모델링된 오브젝트를 사용하는 시퀀스 다이어그램을 선택한다.

• 해당 클래스를 포함하는 시퀀스 다이어그램이 없다면 상태 다이어그램에 있는 정보가 시퀀스 다이어그램 상에 등장하지 않는 것이므로 불일치보고서에 기록한다.

 

B. 기술되고 있는 시스템 서비스와 해당 오브젝트가 수신하는 메시지를 식별하기 위해 선택된 시퀀스 다이어그램을 읽는다.

 

C. 상태 다이어그램 상의 어떤 오브젝트 상태가 의미상으로(semantically) 시스템 서비스와 관련 있는지 생각한다. 이 상태들에 진입 또는 진출하는 상태 전이를 표시한다.

 

D. 시퀀스 다이어그램 상의 오브젝트 메시지를 상태 다이어그램 상의 상태 전이로 매핑한다. 각 전이 액션이 하나의 메시지(또는 메시지 시퀀스)로 매핑될 수 있음. 매핑 수행 시 관련 메시지와 전이 액션을 별표(*)로 표시하며, 상태 다이어그램 상의 연관 액션에게 주어진 레이블과 동일하게 메시지에 레이블을 단다.

• 의미상으로 이 매핑을 할 수 있음을 확인한다. 그럴 수 없다면 상태 전이에 필요한 메시지가 시퀀스 다이어그램에 포함되지 않았음을 의미하므로 불일치보고서에 기록한다.

 

E. 방금 상태 전이로 매핑한 메시지의 제약/조건을 찾는다. 발견된 제약/조건이 상태 다이어그램 상에서 어떤 식으로든 캡쳐되었는지 확인한다. 아래를 체크해 불일치보고서에 기록함

• 상태 다이어그램과 시퀀스 다이어그램상의 조건/제약 간의 일치성(correspondence)을 찾을 수 있음을 확인한다. 그렇지 못하면 한 다이어그램이 다른 다이어그램에는 없는 정보를 가지고 있음을 의미
• 양 다이어그램 모두에 등장하는 정보가 일관적임을 확인한다. 그렇지 못하면 동일한 정보가 두 개의 다이어그램 상에 일관성 없이 표현되었음을 의미

III. 모든 전이 액션이 고려되었음을 확인하기 위해 표식이 된 다이어그램을 검토한다.

A. 상태 다이어그램을 검토하여 별표 표시가 없는(오브젝트 메시지와 연관 될 수 없는) 전이 액션을 찾는다.

• 전이 액션에 제약이 레이블로 달렸다면 이 제약을 충족시킬 수 있는 메시지(또는 메시지 시퀀스)를 찾을 수 있는지 확인한다. 그럴 수 없다면 상태 다이어그램이 어떤 시퀀스 다이어그램에서도 기술되지 않은 시스템 서비스를 요구한다는 의미이므로 이를 불일치 보고서에 기록한다.
• 전이 액션에 이벤트가 레이블로 달렸다면 이 전이 액션을 달성할 수 있는 메시지(또는 메시지 시퀀스)나 이벤트(액터에 의해 수행됨)를 찾을 수 있는지 확인한다. 그렇지 못하면 상태 다이어그램이 어떤 시퀀스 다이어그램 상에도 기술되지 않은 시스템 서비스를 요구한다는 의미이므로 이를 불일치 보고서에 기록한다.

 

B. 별표 표시된 메시지와 전이 액션이 동일 시퀀스 다이어그램 상에 등장하면 이것들이 논리적 순서로 등장하는지 확인한다. 예를 들어, 하나의 시퀀스 다이어그램 상에서 액션 A1을 달성하는 메시지가 액션 A2를 달성하는 메시지 전에 등장하면, A1이 반드시 A2에 앞서야 함을 의미. 따라서 상태 다이어그램 상에서도 A1이 A2 전에 도달될 수 있는지를 확인해야 함

• 이 순서가 매치되지 않으면 정보가 두 개 다이어그램 상에 표현되기는 했어도 비일관적이므로 이를 불일치보고서에 기록한다.

OORT-4: 클래스 다이어그램 vs. 클래스 기술서

목표: 클래스의 상세 기술이 클래스 다이어그램에 따른 모든 필수 정보를 포함하는지 그리고 클래스의 기술이 의미론적으로 말이 되는지를 확인

프로세스 입력:

1. 시스템의 클래스와 이들이 어떻게 연관되어 있는지를 기술한 클래스 다이어그램

2. 시스템의 클래스를 그 애트리뷰트 및 동작과 함께 나열한 클래스 기술서의 집합

 

I. 클래스의 필수 속성(properties)을 이해하기 위해 클래스 다이어그램을 읽는다. 클래스 다이어그램 상의 각 클래스에 대해 아래 단계들을 수행함

A. 관련된 클래스 기술을 찾는다. 찾으면 클래스 기술 상의 클래스를 파란색 별표(*)로 표시

• 이를 찾을 수 없으면 클래스 다이어그램 상에 존재하는 클래스가 클래스 기술서에는 존재하지 않음을 의미하므로 불일치보고서에 기록한다.

 

B. 현재 고려 중인 클래스의 의미 있는 기술이 제공되는지 확인하기 위해 클래스의 이름과 텍스트 서술을 체크한다. 또한 이 기술이 적절한 추상화 수준을 사용 중인지 체크한다.

• 검토자가 상위 수준 기술서로부터 해당 클래스의 목적을 이해할 수 있는지 확인한다. 그렇지 못하면 이 기술이 설계 모델로 사용되기에 너무 모호하다는 의미이므로 불일치보고서에 기록한다.

 

C. 모든 애트리뷰트가 기본 타입과 함께 기술되었는지 확인한다.

• 클래스 기술서와 클래스 다이어그램 양쪽에 동일한 애트리뷰트 집합이 존재함을 확인한다. 그렇지 않으면 정보가 한 문서에는 있고 다른 문서에는 존재하지 않는 것이므로 불일치보고서에 기록한다.
• 클래스가 모든 애트리뷰트를 의미 있게 포함할 수 있는지(즉, 이 애트리뷰트들이 클래스 기술에 포함되는 것이 말이 됨), 그리고 애트리뷰트로 할당된 기본 타입이 애트리뷰트의 기술에 따르면 타당한지를 확인한다. 그렇지 않으면 불일치보고서에 기록한다.

 

D. 모든 동작(behaviors)과 제약(constraints)이 기술되었는지 확인한다.

• 클래스 기술서와 클래스 다이어그램 양쪽에 동일한 동작과 제약의 집합이 존재하며, 동작을 기술하는데 있어 동일한 스타일이나 정교성 수준(예, 수도 코드)을 사용함을 확인한다. 그렇지 않으면 한 다이어그램에 있는 정보가 다른 문서에는 없거나 또는 서로 일관적이지 못하다.
• 클래스가 모든 동작을 의미 있게 포함하는지 확인한다. 이 클래스에 대한 제약이 말이 되는지 확인한다. 동작이 (이 클래스 또는 다른 클래스에서) 정의된 애트리뷰트를 사용하여 그 임무를 달성할 수 있는지 확인한다. 그렇지 못하면 불일치보고서에 기록
• 제약이 정의된 애트리뷰트와 동작을 사용해 충족가능한지 확인하고, 그렇지 못하면 불일치보고서에 기록한다.
• 이 클래스의 동작이 기능 실현을 위해 다른 클래스의 애트리뷰트에 지나치게 의존적인지 확인한다(‘지나친 의존’에 대한 검토자의 판단이 요구됨). 이 클래스가 타 클래스를 참조하는 수를 시스템의 나머지 경우와 비교하고, 다루어지는 기능의 타입을 고려해 이런 의존이 불가피한지 판단한다. 만일 정말로 그렇다면 설계가 좋지 못한 상황이므로 이를 불일치보고서에 작성한다.

 

E. 클래스 다이어그램이 이 클래스를 위한 상속 메커니즘을 명세하는 경우 이것이 정확하게 기술되었는지 확인한다.

• 상속 관계가 클래스 기술서 상에 포함되었는지 확인하고, 그렇지 못하면(즉, 클래스 다이어그램 상의 정보가 클래스 기술서 상에는 없음) 불일치보고서에 기록한다.
• 이 클래스의 부모 클래스를 찾기 위해 클래스 계층도를 사용한다. 의미상으로 <클래스명>이 <부모명>의 한 타입이며, 계층도의 이 지점에서 이 클래스가 나오는 것이 말이 되는지 확인한다. 만약 그렇지 못하면 잠재적인 스타일 이슈가 있으므로 이를 불일치보고서에 기록한다.

 

F. 다수(multiplicity)에 대한 모든 클래스 관계(association, aggregation, composition)가 정확하게 기술되었는지 확인한다.

• 오브젝트 역할이 클래스 기술서 상에서 캡쳐되었는지 그리고 정확한 그래픽 표기법이 클래스 다이어그램 상에서 사용되었는지 확인한다. 만약 문제(한 다이어그램에서 정보가 누락됨, 표기법이 부정확함)가 발견되면 불일치보고서에 기록한다.
• 이 관계가 관련 역할과 오브젝트를 봤을 때 의미상으로 말이 되는지 확인한다. 예를 들어, composition 관계가 있을 때 연관된 오브젝트들이 정말로 “전체-부분(whole-part)” 관계인 것처럼 보이는가? 정의된 관계가 말이 안 되면 불일치보고서에 기록한다.
• 카디널리티가 중요하다면 이것이 클래스 기술서에 기술되었는지 확인한다. 관계에 대한 이해에 기반하여 사용된 오브젝트의 수량이 충분한지 확인한다.
• 관계를 나타내는 애트리뷰트가 있음을 확인한다. 그렇지 못하면 한 다이어그램에 있는 정보가 다른 곳에는 존재하지 않음을 의미하므로 불일치보고서에 기록한다.
• 관계가 타당한 기본 타입(또는 기본 타입의 구조)를 사용하는지 확인한다.

II. 무관한 정보가 존재하는지 확인하기 위해 클래스 기술서를 검토한다.

A. 기술된 모든 클래스가 클래스 다이어그램에 실제 등장하는지 확인하기 위해 클래스 기술서를 검토한다.

• 클래스 기술서 상에 별표 표시가 안된 클래스가 없음을 확인한다. 만약 이런 것이 있다면 클래스 기술서 상의 클래스가 클래스 다이어그램 상에는 존재하지 않으므로 불일치보고서에 기록한다. 

[수평적 리딩을 위한 불일치보고서 양식]

OORT-5: 클래스 기술서 vs. 요구사항 기술서

목표: 클래스 기술서가 기능 요구사항에 의해 기술된 개념과 서비스를 적절히 캡쳐하는지 확인

프로세스 입력:

1. 최종 시스템의 필수적인 개념과 서비스를 기술한 기능 요구사항의 집합

2. 시스템의 클래스를 그 애트리뷰트 및 동작과 함께 나열한 클래스 기술서의 집합

 

I. 기술된 기능을 이해하기 위해 요구사항 기술서를 읽는다.

A. 기술하고 있는 기능을 이해하기 위해 각 기능 요구사항을 꼼꼼히 읽는다.

B. 요구사항에서 명사(시스템 설계에서 클래스/오브젝트/애트리뷰트 후보)를 찾아 파란 펜으로 밑줄 친다.

C. 시스템에서 서비스/동작의 후보가 되는 동사(또는 액션에 대한 기술)을 찾아 녹색 펜으로 밑줄 친다.

D. 앞에서 식별한 명사와 동사 상의 제약/조건에 대한 기술을 찾아 노란 펜으로 밑줄 친다. 통상적으로 시스템 기능에 대한 제약/조건을 포함하는 비기능 요구사항에 특히 주의를 기울인다.

 

II. 요구사항이 적절히 캡쳐되었는지 확인하기 위해 클래스 기술서를 요구사항과 비교한다.

A. 기능 요구사항의 녹색 밑줄 쳐진 액션 기술 각각에 대해 클래스 기술서에서 연관 동작(또는 동작들의 조합)을 찾고, 클래스 기술서에서의 동작 이름과 요구사항에서의 액션 기술 양쪽 모두를 녹색 별표(*)로 표시한다. 이 검색을 돕기 위해 구문론적 단서를 활용할 수 있지만(예, 액션 기술과 유사하거나 동일한 동작 이름) 의미상으로도 요구사항과 상위 수준 설계에서의 기능이 동일한 것인지 확인해야 함

• 클래스가 요구 동작을 완수하기 위한 올바른 정보를 수신하는지 확인하고, 타당한 결과가 생성되는지 확인함. 그렇지 못하면 클래스가 기능을 적절히 구현할 수 없음을 의미하므로 그 이유를(기능 누락, 부정확하거나 모호한 정보) 불일치보고서에 기록한다.

 

B. 기능 요구사항에서 파란 밑줄 쳐진 명사 각각에 대해 클래스 기술서에서 연관 클래스를 찾는다. 연관 클래스가 요구사항의 개념 명을 따라 이름 지어졌거나, 해당 개념이 특정 인스턴스(즉, 오브젝트)인 general 클래스가 기술되거나, 또는 해당 개념이 애트리뷰트로써 포함될 수도 있음. 검색을 돕기 위해 구문론적 단서를 활용할 수 있지만(예, 개념 명과 유사한 클래스 명) 요구사항에서와 설계에서의 개념이 의미상으로도 동일한지 확인해야 함

 

C. 기능 요구사항에 있는 개념이 클래스 기술서에 있는 클래스 명에 상응하면 클래스 기술서에 있는 클래스 명과 요구사항 기술서에 있는 개념 양쪽 모두를 파란색 별표(*)로 표시한다.

• 클래스 기술서가 기능에 어떤 역할을 하는 개념에 대한 충분한 정보를 포함하는지 그리고 클래스 명이 밑줄 표시를 한 명사와 연관성이 있는지 확인한다. 그렇지 않거나 또는 클래스가 개념을 기술하는데 모호한 정보를 사용하고 있으면 이를 불일치보고서에 기록한다.
• 클래스가 표시를 한 명사에 대한 애트리뷰트(파란색)와 표시를 한 동사/액션 기술에 대한 동작(녹색)을 포함하는지 확인한다. 또한 이 클래스에 대해 식별된 제약/조건이 모두 기술되었는지 확인한다. 그렇지 못하면 요구사항에 있는 중요 정보가 설계에서 누락되었으므로 이를 불일치보고서에 기록한다.

 

D. 만일 기능 요구사항의 개념이 클래스 기술서의 애트리뷰트에 상응하면 클래스 기술서에서의 애트리뷰트 명과 요구사항 기술서에서의 개념 양쪽 모두를 파란 별표(*)로 표시한다.

• 요구사항 기술서와 애트리뷰트 상의 노란 밑줄의 제약/조건을 고려했을 때 클래스 기술서가 정보를 표현하는데 적당한 타입을 사용하는지 확인한다. 그렇지 못하면 설계에 부정확한 정보가 있는 것이므로 불일치보고서에 기록한다.

III. 모든 적절한 개념들이 문서 간에 서로 상응하는지 확인하기 위해 클래스 기술서와 기능 요구사항을 검토한다.

A. 요구사항의 기능 기술이 설계로부터 누락된 경우를 찾는다.

• 요구사항에 별표가 안된 명사 또는 동사가 없음을 확인한다. 만약 있다면 이것이 단순 설명용이 아닌 설계에 포함되어야 하는 건지를 확인한다. 만일 설계에 포함되어야 하는 거라면 해당 정보가 설계에서 누락된 것이므로 불일치보고서에 기록한다.

OORT-6: 시퀀스 다이어그램 vs. 유스케이스

목표: 시퀀스 다이어그램이 유스케이스에 의해 기술된 기능을 캡쳐하기 위한 적절한 오브젝트 및 메시지 조합을 기술하는지 확인

프로세스 입력:

1. 시스템의 중요 개념(궁극적으로 오브젝트, 클래스, 애트리뷰트로써 표현됨)과 시스템이 제공하는 서비스를 기술한 유스케이스

2. 시스템의 오브젝트와 시스템이 제공하는 서비스를 기술한 하나 또는 여러 개의 시퀀스 다이어그램(하나의 유스케이스에 대해 다수의 상응하는 시퀀스 다이어그램이 있을 수 있음)

3. 시퀀스 다이어그램에 있는 모든 클래스에 대한 클래스 기술서

 

I. 유스케이스에 의해 기술된 기능을 식별하고 이 기능을 달성하는데 필수적인 시스템의 중요 개념을 찾아낸다.

A. 기술하고 있는 기능을 이해하기 위해 유스케이스를 꼼꼼히 읽는다.

B. 유스케이스에 포함되어 있는 명사(시스템의 개념을 기술하고 있음)를 찾아 파란 펜으로 밑줄 긋고 고유 번호를 매긴다(특정 명사가 여러 번 나타나면 같은 번호를 줌).

C. 각 명사에 대해 이 명사에 적용되는(또는 이 명사에 의해 적용되는) 액션을 기술한 동사를 식별하여 녹색 펜으로 밑줄 긋고 번호 매긴다(서비스 수행 순서대로 번호를 매김). 이 액션이 수행되는데 필수적인 제약/조건을 찾는다.

D. 또한 이 액션을 수행하기 위해 전송되거나 수신되어야 하는 정보/데이터를 식별하고 노란색으로 “D_i,_j”라고 레이블을 단다(i와 j는 해당 정보를 교환하는 명사들에게 매겨진 식별 번호).

 

II. 상응하는 기능이 정확히 기술되었는지 그리고 동작 및 데이터가 올바른 순서로 표현되었는지 확인하기 위해 관련 시퀀스 다이어그램을 식별하고 인스펙션한다.

A. 각 시퀀스 다이어그램에 대해 시스템 오브젝트를 파란 펜으로 밑줄 치고 유스케이스의 상응하는 번호를 그 번호로 준다.

B. 시퀀스 다이어그램에 의해 기술된 서비스를 식별한다. 이를 위해 시퀀스 다이어그램 상의 오브젝트/클래스 간에 교환되는 정보(수평 화살표)를 검토한다. 만일 교환되는 정보가 매우 상세하면(메시지 수준) 제공하려는 서비스를 이해하기 위해 여러 메시지를 묶어 추상화 할 필요가 있을 수도 있다. 식별된 서비스에 녹색 펜으로 밑줄을 치고 (다이어그램에 나타나는 순서대로) 번호를 매긴다. 이 액션을 활성화시키는 조건을 찾는다.

C. 시스템 클래스 간에 교환되는 정보/데이터를 식별하고 노란색으로 “D_i,_j”라고 레이블을 단다(아래 첨자 i와 j는 해당 정보를 교환하는 오브젝트들에게 주어진 식별 번호).

III. 동일한 도메인 개념을 표현하고 있는지 확인하기 위해 표시를 한 다이어그램을 비교한다.

A. 유스케이스 상의 파란 밑줄 쳐진 명사 각각에 대해 동일한 명사가 표현되었는지 시퀀스 다이어그램을 검색한다. 만약 이것이 시퀀스 다이어그램 상에서 발견되면 유스케이스와 시퀀스다이어그램 상의 명사를 파란 별표(*)로 표시한다.

• 만일 유스케이스 상에 별표가 안된 명사가 있다면, 어떤 개념이 유스케이스 상에서 기능을 기술하기 위해 사용되었지만 시퀀스 다이어그램 상에서는 표현되지 않았음을 의미. 시퀀스 다이어그램 상의 명사 각각에 대해서 클래스 기술서 상의 상응하는 클래스를 찾고 별표 안된 명사가 애트리뷰트인지를 체크한다. 별표 안된 명사가 클래스의 애트리뷰트가 아니면 유스케이스 상에 기술된 개념이 시스템 설계에는 등장하지 않았음을 의미하므로 이를 불일치보고서에 기록한다.
• 시퀀스 다이어그램 상에 별표가 안된 명사가 있으면 시퀀스 다이어그램 상에 무관계한 명사가 있거나 또는 더 하위 수준 개념을 기술한 명사가 있음을 의미. 이 개념이 상위 수준 설계에 필수적인지 그리고 현 시점에 적정한 상세화 수준을 표현하고 있는지 생각해본다. 그렇지 못하면 무관한 정보가 존재함을 불일치보고서에 기록한다.

 

B. 시퀀스 다이어그램에 의해 기술된 서비스를 식별하고 이를 유스케이스 상에 사용된 기술과 비교한다.

• 클래스/오브젝트가 유스케이스 상에 명세된 것과 같은 순서로 메시지를 교환하는지 확인하고 그렇지 못하면 이것이 결함인지 생각해본다. 대개 메시지 순서의 전환이 기능에 영향을 미치지만, 때때로 결과에 영향을 주지 않으면서 메시지가 전환되거나, 병행되거나, 조건에 따라 선택적으로 수행 될 수 있다. 만약 순서의 변경이 기능을 변경시키면 설계 상의 정보가 부정확한 것이므로 불일치보고서에 표기한다.
• 시퀀스 다이어그램의 메시지 상에 등장하는 데이터가 유스케이스 상에서 정확하게 기술되었는가? 교환된 데이터가 모두 정확한 메시지이고, 해당 메시지가 정확한 클래스 간을 오가는지 확인한다(즉, 데이터의 레이블 “Di,j”가 다이어그램 간에 매치되는가). 메시지가 그것을 송신 및 수신하는 오브젝트에게 말이 되는지 그리고 관련 서비스를 달성할 수 있는지 확인한다. 그렇지 못하면 시퀀스 다이어그램이 정보를 부정확하게 사용 중인 것을 의미하므로 불일치보고서에 기록한다.

 

C. 유스케이스로부터의 모든 제약과 조건이 시퀀스 다이어그램에서 관측되는가? 유스케이스에 있는 몇몇 상세 사항이 시퀀스 다이어그램에서 누락되지는 않았는가?

• 제약이 관측되는지 확인하고, 시퀀스 다이어그램 상의 모든 동작 및 데이터가 유스케이스와 직접적으로 관련되는지 확인한다. 그렇지 못하면 시퀀스 다이어그램이 정보를 부정확하게 사용 중임을 의미하므로 불일치보고서에 기록한다.

OORT-7: 상태 다이어그램 vs. 요구사항 기술서와 유스케이스

목표: 상태 다이어그램이 요구사항과 유스케이스에 의해 기술된 것처럼 적절한 오브젝트 상태와 이벤트를 기술하는지 확인

프로세스 입력:

1. 각각이 시스템의 오브젝트를 기술하고 있는 상태 다이어그램들의 집합

2. 최종 시스템에 필수적인 개념과 서비스를 기술하고 있는 기능 요구사항들의 집합

3. 시스템의 중요 개념을 기술하고 있는 유스케이스들의 집합

 

I. 상태 다이어그램이 모델링하고 있는 오브젝트를 이해하기 위해 상태 다이어그램을 읽는다.

 

II. 오브젝트의 가능한 상태(어떤 상태가 서로 인접해 있는지)와 상태 변경을 야기하는 이벤트를 식별하기 위해 요구사항 기술서를 읽는다.

A. 요구사항을 읽고 개념이 기술된 위치(또는 개념이 참여하고 있거나 영향을 받는 기능 요구사항)를 찾아서 별표(*) 표시를 한다.

B. 이 오브젝트의 모든 다른 상태에 대한 기술을 찾는다. 상태를 찾기 위해 오브젝트가 다른 방식으로 동작하도록 만드는 애트리뷰트 값(또는 애트리뷰트 값의 조합)을 찾는다. 상태를 찾아내면 파란 펜으로 밑줄 치고 번호를 매긴다.

C. 번호가 매겨진 상태 중 어떤 것이 초기 상태인지 식별하여 파란 펜으로 “I” 표시를 한다. 마찬가지로 최종 상태는 “E”로 표시한다.

D. 모든 상태를 찾게 되면 별도의 종이에 상단의 1..N과 좌측 하단으로 1..N을 가진 인접 매트릭스(adjacency matrix)를 생성한다(1..N은 앞 단계에서 식별된 상태에 매긴 번호를 나타냄).

E. 각 상태 쌍에 대해 만약 오브젝트가 좌측 번호로 표현된 상태로부터 상단 행 번호로 표현된 상태로 변경될 수 있다면 행과 열의 교차점에 있는 박스에 표시를 한다. 이 상태 변경을 야기하는 이벤트를 결정할 수 있다면 그것을 해당 박스에 기입하고, 그렇지 못하면 단순히 체크 표시를 한다(이벤트가 나중 단계에서 결정될 것임). 이 전이가 발생하지 않는다고 결정되면 해당 박스에 X 표시를 하고, 확실한 결정을 할 수 없으면 박스를 공백으로 놔둔다.

F. 위에서 식별한 이벤트 각각에 대해 만일 요구사항에 기술된 어떤 제약이 있다면 이것을 매트릭스의 해당 이벤트 옆에 작성한다.

 

III. 유스케이스를 읽고 상태 변경을 야기할 수 있는 이벤트를 결정한다.

A. 유스케이스들을 읽고 해당 오브젝트가 참여하고 있는 유스케이스를 찾아 낸다.

B. 체크 표시가 된 인접 매트릭스의 각 박스에 대해 유스케이스를 검토하고 어떤 이벤트가 해당 전이를 야기할 수 있는지 결정한다. 체크 표시를 지우고 그 자리에 이 이벤트를 기입한다.

C. 인접 매트릭스에서 공백인 각 박스에 대해 해당 전이를 야기할 수 있는 이벤트를 유스케이스가 기술하고 있는지 확인한다. 만일 그렇다면 이 이벤트를 박스에 기입하고, 그렇지 않다면 박스에 X 표시를 한다.

IV. 기술된 상태가 요구사항과 일관적인지, 그리고 전이가 요구사항 및 유스케이스와 일관적인지를 결정하기 위해 상태 다이어그램을 읽는다.

A. 요구사항 기술서에서 표시되고 번호가 매겨진 각 상태에 대해 상태 다이어그램에서 상응하는 상태를 찾아 요구사항에서 사용된 것과 같은 번호를 파란 펜으로 표시한다(동일한 상태가 요구사항 기술서와 상태 다이어그램에서 각기 다른 이름을 가질 수도 있음에 유의).

• 모든 상태를 찾을 수 있는지 확인한다. 만일 어떤 상태가 누락되었다면 요구사항에서 표시한 두 개 또는 그 이상의 상태들이 상태 다이어그램 상에서 하나의 상태로 통합되었는지 확인한다. 만일 그렇다면 이 통합이 말이 되는지 확인하고, 그렇지 않다면 정보가 설계에서 누락된 것을 의미하므로 불일치보고서에 기록한다.
• 상태 다이어그램에 추가적인 상태가 없음을 확인한다. 요구사항에서 표시한 어떤 하나의 상태가 상태 다이어그램에서 둘 또는 그 이상의 상태로 쪼개졌는지 확인한다. 만일 그렇다면 이 분할이 말이 되는지 확인하고, 그렇지 않다면 설계에 관계 없는 정보가 포함되어 있음을 의미

 

B. 일단 모든 상태에 번호를 매기고, 인접 매트릭스 상에 표시된 전이 이벤트를 상태 다이어그램 상의 그것과 비교한다. 이벤트가 표시된 인접 매트릭스 상의 박스에 대해 상태 다이어그램 상의 상응하는 상태를 체크하여 이 상태들이 상태 간 전이를 하는 이벤트를 가지고 있는지 그리고 이 이벤트가 동일한 것인지를 확인한다.

• 인접 매트릭스 상의 모든 이벤트가 상태 다이어그램 상에 등장하는지 확인한다. 그렇지 않으면 정보가 설계에서 누락된 것이다. 만일 상태 다이어그램 상에 추가적 이벤트가 있으면 설계가 무관한 정보를 포함하고 있는 것이다.

 

C. 인접 매트릭스 상에 표시된 제약 각각에 대해 이것을 상태 다이어그램 상에서 찾는다.

• 인접 매트릭스 상에 있는 모든 제약을 찾을 수 있는지 확인한다. 만일 그럴 수 없다면 설계에서 정보가 누락된 것이다. 만일 상태 다이어그램 상에 추가적인 제약이 있다면 설계가 관계 없는 정보를 포함하고 있는 것이다.

[수직적 리딩을 위한 불일치 보고서 양식]