지난 글에서는 요구사항을 추출하고 분석한 뒤, 유스케이스 다이어그램을 통해 기능 간의 관계를 표현하고, 이를 바탕으로 요구사항 명세서를 작성하는 과정까지 정리했다.
이번 글에서느 이러한 결과물을 기반으로, 시스템의 요구사항을 구조적으로 표현하는 요구 모델링 방벙에 대해서 정리해 보려고 한다.
1. 모델링 기초
우선, 모델링을 하는 목적과 이유에 대해서 정리해보자.
모델링의 가장 큰 목적은 복잡한 시스템을 효과적으로 다루기 위함이다. 실제 소프트웨어 시스템은 전체를 한 번에 이해하기 어렵기 때문에 중요한 요소만을 남기고 불필요한 부분은 제거하는 추상화와 단순화 과정이 필요하다.
이렇게 시스템을 단순화하거나 추상화하는 이유는 다음과 같다.
- 복잡성을 효과적으로 관리하기 위해
- 형체가 없는 소프트웨어 구조를 시각화하기 위해
- 이해관계자 간 원활한 커뮤니케이션을 위해
- 문제 도메인 및 제품 요구 사항을 이해하기 위해
- 개발 중인 시스템 구조를 파악하기 위해
- 구현하기 전에 해결 방안을 검토하기 위해
- 기존 시스템을 체계적으로 문서화하기 위해
모델링은 어떤 관점에서 바라보는지, 그리고 어느 수준까지 추상화할 것인지에 따라 달라진다. 다라서 모델링을 수행할 때는 목적에 맞는 관점과 추상화 수준을 적절히 선택하는 것이 중요하다.
또한, 모델링 작업의 결과물은 서로 독립적이지 않고 영향을 주고 받는다.
예를 들어, 요구 분석 단계에서 작성한 유스케이스 명세를 통해 시스템의 주요 용어, 개념, 속성, 관계 등을 도출할 수 있으며, 이는 도메일 모델을 구서하는 기반이 된다.
다음 그림을 통해 모델 간의 관계를 살펴보면
그림에서 살펴보면 알 수 있듯이,
- 도메인 모델이 용어집에 영향을 줄 수 있으며
- 유스케이스 명세서는 도메인 모델에 필요한 용어, 개념, 속성 및 관계를 제공한다.
이처럼 각 모델은 서로 유기적으로 연결되어 있으며, 전체 시스템을 이해하는 데 중요한 역할을 한다.
2. UML(Unified Modeling Language)
소프트웨어 모델을 표현하기 위한 표기법이 존재하지만, 현재 가장 널리 쓰이는 것은 UML(Unified Modeling Language)이다. UML은 소프트웨어 시스템을 시각적으로 표현하기 위한 표준 모델링 언어로, 실무와 학계에서 모두 널리 활용되고 있다.
객체지향 개발 방식이 확산되면서 UML은 객체지향 소프트웨어를 모델링하기 위한 대표적인 그래픽 언어로 자리 잡았다. 또한 UML은 특정 프로그래밍 언어에 종속되지 않기 때문에, 다양한 개발 환경에서 공통된 모델링 언어로 사용될 수 있다는 장점이 있다.
2.1. UML의 역사
UML은 다음 세 가지 주요 객체 지향 방법론의 표기법이 결합된 것이다.
- Grady Booch의 방법론
- James Rumbaugh의Object-Modeling Technique(OMT)
- Ivar Jacobson의 Object-Oriented Software Engineering(OOSE)
그렇기 때문에 UML은 원래 객체 지향 스타일의 모델링, 설계, 프로그래밍을 지원한다. 즉, UML은 객체 지향 방식에서 진화한 것이며, 객체 지향 프로그래밍 스타일을 지원한다.
UML 버전의 진화는 다음 그림을 참고하면 된다.
3. UML 다이어그램
UML은 다양한 다이어그램을 통해 소프트웨어 시스템을 시각적으로 표현할 수 있다. 이러한 UML 다이어그램은 시스템을 여러 관점에서 이해할 수 있도록 도와준다.
UML은 소프트웨어 개발을 위한 구체적인 프로세스를 정의하지는 않지만 유스케이스 중심(Use Case Driven), 아키텍처 중심(Architecture-Centric), 반복적이고 점진적인 개발(Iterative, Incremental)을 지향하는 특징을 가진다.
UML 다이어그램은 크게 정적 모델과 동적 모델로 구분할 수 있으며, 각 종류는 다음과 같다.
- 정적 다이어그램
- 클래스 다이어그램
- 객체 다이어그램
- 컴포넌트 다이어그램
- 배치 다이어그램
- 패키지 다이어그램
- 컴포지트 구조 다이어그램
- 동적 다이어그램
- 유스 케이스
- 액티비티 다이어그램
- 상태 다이어그램
- 시퀀스 다이어그램
- 커뮤니케이션 다이어그램
- 인터랙션 오버뷰 다이어그램
- 타이밍 다이어그램
이처럼 다양한 UML 다이어그램이 존재하며, 하나의 다이어그램만 사용하는 것이 아니라 정적 다이어그램과 동적 다이어그램을 적절히 조합하여 활용하는 것이 중요하다. 이를 통해 구현 전에 시스템 구조와 동작을 보다 명확하게 설계할 수 있다.
한편, 프로그래밍 언어는 정해진 문법을 따르지 않으면 컴파일 오류가 발생하거나 실행이 불가능하다.
반면 UML은 비교적 유연하게 표현이 가능하지만 그렇다고 임의로 작성하는 것은 바람직하지 않다. 따라서 정의된 UML 표기법을 기반으로 일관성 있게 모델링하는 것이 중요하다.
4. UML 모델링 과정
UML 모델링의 근본적인 목표는 시스템을 구성하는 클래스와 클래스 간의 관계를 도출하는 것이다. 이러한 구조는 주로 클래스 다이어그램을 통해 표현된다.
하지만 클래스 다이어그램만으로는 시스템의 모든 측면을 충분히 표현할 수 없기 때문에, 다양한 관점에서의 모델링이 분석 및 설계 단계에서 함께 이루어져야 한다.
UML 모델링 과정은 일반적으로 다음과 같은 순서로 진행된다.
- 요구사항을 유스케이스로 정리하고 유스케이스 다이어그램을 작성한다.
- 시스템에서 필요한 클래스 후보를 도출하고 개념적인 도메인 모델을 작성한다.
- 유스케이스 흐름을 기반으로 시퀀스 다이어그램을 작성한다.
- 클래스의 속성, 오퍼레이션(메서드) 및 클래스 사이의 관계를 찾아 도메인 모델을 구체화한다.
- 상태 다이어그램, 액티비티 다이어그램 등 필요한 다른 다이어그램을 추가하여 UML 모델을 보완한다.
- 서브시스템을 식별하고 전체 시스템 구조를 설계한다.
- 적당한 객체를 찾고 필요에 따라 새로운 객체를 설계하여 시스템을 구체화한다.
이러한 과정을 통해 다양한 관점에서 점진적으로 구체화하며, 최종적으로 일관된 UML 모델을 완성할 수 있다.
다음 그림을 한 번 살펴보자.
UML 모델 과정을 그림으로 나타낸 것인데, 이를 설명하면 다음과 같다.
- 유스케이스 다이어그램을 통해 클래스 후보를 도출하고 개념적 클래스 다이어그램을 먼저 작성한다.
- 이후 상태 다이어그램이나 액티비티 다이어그램, 순서 다이어그램 등 필요한 UML 다이어그램을 작성하며 시스템을 다양한 관점에서 모델링한다.
- 마지막으로 이러한 결과를 반영하여 클래스 다이어그램을 구체화하고 완성한다.
이처럼 클래스 다이어그램은 초기에 개념적으로 설계한 후, 다른 다이어그램들과의 상호작용을 통해 점진적으로 구체화하는 것이 UML 모델링 과정의 특징이다.
4. 정적 모델링
UML에서 정적 모델링의 대표적인 예시는 클래스 다이어그램이다. 클래스 다이어그램은 시스템의 도메인 개념과 객체 간의 구조적인 관계를 표현할 때 사용된다.
정적 모델링은 객체들의 공통된 구조와 동작을 추상화하는 과정이므로, 객체지향의 기본 개념에 대한 이해가 필요하다. 이에 객체지향의 핵심 개념을 UML에서 다시 정리해보려고 한다.
먼저, 객체와 클래스에 대해서 간단하게 짚고 넘어가면 다음과 같다.
- 객체(Object): 상태 동작, 고유 식별자를 가진 모든 실체
- 클래스(Class): 공통 속성을 공유하는 객체 집합에 대한 정의
4.1. 캡슐화(Encapsulation)
먼저 객체지향의 가장 기본적인 특징 중 하나는 캡슐화이다.
캡슐화란 객체의 속성(데이터)과 오퍼레이션(메서드)을 하나로 묶어 하나의 단위로 만드는 것이다. 이를 통해 객체 내부의 정보를 외부로부터 숨기고, 필요한 기능만을 외부에 제공할 수 있다.
이러한 캡슐화는 설계 및 분석 단계에서 복잡한 문제를 단순화하는 데 도움을 줌, UML을 활용한 모델링 과정에서도 중요한 역할을 한다.
+) 캡슐화된 정보는 항상 온전히 은닉되는 것이 아니라, public, private, protected와 같은 접근 제어를 통해 외부에 공개 범위를 선택적으로 설정할 수 있다.
4.2. 연관
객체는 일반적으로 단독으로 동작하지 않고, 다른 객체와 관계를 맺으며 상호작용한다. 객체지향 시스템에서 한 객체는 다른 객체에게 메시지를 보내 서비스를 요청하고, 이를 통해 협력 관계를 형성한다.
메시지를 받은 객체는 요청된 서비스를 수행한 후 그 결과를 반환한다. 이때 서비스를 제공하는 객체를 서버(Server), 서비스를 요청하는 객체를 클라이언트(Client)라고 한다.
이처럼 한 객체가 다른 객체의 서비스를 호출하는 경우, 두 객체가 속한 클래스 사이에는 연관 관계(Association)가 존재한다고 할 수 있다. 따라서 설계 단계에서는 어떤 객체들이 서로 상호작용해야 하는지를 식별하는 것이 중요하다.
또한 객체 간의 연관과 함께 고려해야 할 개념이 가시성(Visibility)이다. 가시성이란 객체에 대한 접근 가능성을 의미하며, 객체 A가 객체 B와 연관 관계에 있다면 A는 B를 알고 있으며 접근할 수 있어야 한다.
즉, 연관 관계는 단순한 연결을 의미하는 것이 아니라 객체 간의 상호작용과 접근 가능성까지 포함하는 개념이라고 볼 수 있다.
4.3. 상속
상속은 상위 개념의 일반화된 클래스가 가지는 속성과 연산을 하위 개념의 구체화된 클래스가 물려받는 것을 의미한다.
다음 그림을 통해 살펴보자.
위 그림에서 Manager 클래스 Employee 클래스를 상속받는 관계이며, 이러한 관계는 속이 빈 삼각형 화살표(일반화 관계)로 표현된다.
이를 정리하면 다음과 같다.
- Manager 클래스는 Employee 클래스의 하위 클래스(서브클래스)이다.
- Employee 클래스는 Manager 클래스의 상위 클래스(슈퍼클래스)이다.
- Manager 클래스는 Employee 클래스에 정의된 속성과 메서드를 모두 상속받는다.
- 또한 Manager 클래스는 자신만의 속성(Manage(who))과 메서드(managed())를 추가로 가질 수 있다.
즉, 상속은 단순히 기능을 사용하는 것이 아니라, 기존 클래스를 확장하여 재사용하는 관계라고 볼 수 있다.
4.4. 다형성
다형성이란 동일한 이름의 메서드가 서로 다른 클래스에서 다르게 동작할 수 있는 특징을 의미한다.
즉, 같은 메시지를 보내더라도 객체의 실제 타입에 따라 다른 결과가 수행되는 것이 다형성이다. 다음 그림을 통해 한 번 알아보자.
위 그림에 대해서 설명하면 다음과 같다.
- Polygon이라는 객체의 getArea()라는 메서드가 존재한다.
- 그리고 Circle과 Rectangle 클래스는 Polygon을 상속받는 서브클래스이다.
- Polygon 클래스에 정의된 getArea() 메서드를 Circle과 Rectangle이 각각 자신의 방식으로 재정의(오버라이딩)한다.
- 동일하게 getArea()를 호출하더라도 어떤 객체인지에 따라 실행되는 내용이 달라진다.
- Circle 객체의 getArea(): 원의 넓이 계산
- Rectangle 객체의 getArea(): 사각형 넓이 계산
이처럼 같은 메서드 호출이 서로 다른 동작으로 이어지는 것이 다형성이다.
4.5. 클래스 다이어그램
클래스 다이어그램은 UML 다이어그램 중에서 가장 대표적인 다이어그램으로, 시스템의 정적 구조를 모델링하는 데 사용된다.
정적 구조란 클래스, 속성, 클래스 간의 관계와 같이 시간에 따라 크게 변하지 않는 요소를 의미한다.
반면, 객체 간의 상호작용과 같은 동적인 측면은 시퀀스 다이어그램과 같은 다른 UML 다이어그램을 통해 표현한다.
4.5.1. 클래스
UML에서 클래스는 다음 그림과 같이 표현된다.
위 그림에 대해서 설명하면 다음과 같다.
- 클래스는 총 3가지 영역으로 구성된다.
- 상단: 클래스 이름
- 중간: 클래스의 속성(객체가 가지는 모든 필드)
- 하단: 오퍼레이션(메서드)으로, 아주 흔한 메서드(get/set 등)는 생략하기도 함.
또한 위 그림은 BankAccount 클래스가 점진적으로 구체화되는 과정을 나타낸다. 초기에는 단순히 클래스 이름만 정의되지만, 이후 속성과 메서드가 추가되면서 점차 완전한 형태의 클래스 다이어그램으로 발전하게 된다.
4.5.2. 클래스 다이어그램의 관계의 표현
클래스 다이어그램은 클래스 요소와 클래스 간의 관계를 표현하며, 대표적으로 다음과 같이 총 4가지가 존재한다.
- 연관 (Association)
- 상속 (Generalization)
- 의존 (Dependency)
- 구현 (Realization)
각 관계는 다음 그림을 통해 알아보자.
그림을 통해서 4가지 관계를 설명하면 다음과 같다.
- 연관
- Harbor(항구)에는 Boat(보트)는 서로 관계를 가지며, 보트가 항구에 정박할 수 있기 때문에 연관 관계가 존재한다.
- 연관 관계는 두 클래스가 서로 관련되어 있음을 나타내며, 객체 간의 연결 관계를 표현한다.
- 연관의 또 다른 예시로, 연관은 실선으로 표현하며 두 번째 그림과 같이 화살표 표시가 존재할 수 있는데, 단방향 탐색만이 가능하다는 뜻이다.
- 상속(일반화)
- SailBoat는 Boat의 하위 클래스라고 볼 수 있다.
- SailBoat가 Boat의 속성과 메서드를 상속받으며, 이를 기반으로 기능을 확장하거나 재정의할 수 있다.
- 의존
- Boat 클래스의 load() 메서드에서 Trailer 객체를 매개변수로 사용하기 때문에 Boat는 Trailer에 의존한다.
- 이 경우, Trailer의 인터페이스나 구조가 변경되면 Boat의 load() 메서드에도 영향을 줄 수 있다.
- 구현
- Boat는 Washable 인터페이스를 구현하는 관계에 있다. 즉, Washable 인터페이스에 정의된 wash() 메서드를 Boat 클래스에서 구현한다.
- 구현 관계는 인터페이스와 클래스 간의 관계로 상속과 유사하지만 인터페이스를 따르는 계약 관계(반드시 지켜야 하는 규칙)라는 점에서 차이가 있다.
다음 수강 신청 시스템의 예시를 통해 클래스 간의 관계에 대해서 이해해보자.
위 그림에 대해서 주요 관계를 설명하면 다음과 같다.
- Student와 Professor은 Person이라는 클래스의 서브 클래스이며, 상속(일반화) 관계이다.
- Transcript는 여러 개의 Registration을 포함하는 집합관계(Aggregation)를 가진다.
- Transcript가 Registration을 포함하지만, Registartion이 독립적으로 존재할 수 있음을 의미한다.
- ScheduleOfClasses 또한 여러 개의 CourseSection을 포함하는 집합관계를 가지며, ScheduleOfClasses가 CourseSection들을 관리하는 구조이다.
5. 동적 모델링
소프트웨어의 동적 측면은 정적 측면과 달리 시스템이 실행되는 동안의 변화와 동작을 나타낸다.
소프트웨어의 동적 측면은 시간의 흐름에 따라 이해할 수 있다. 객체 간의 상호작용은 프로그램이 실행되는 동안 특정 시간 동안 발생하기 때문이다.
이러한 동적 다이어그램은 정적인 클래스 다이어그램을 보완하는 역할을 한다. 클래스 다이어그램이 시스템의 구조를 표현한다면, 상호작용 다이어그램은 시스템의 동작을 표현한다.
UML은 다음과 같은 두 가지 유형의 상호작용 다이어그램을 제공한다.
- 시퀀스 다이어그램
- 협동 다이어그램
5.1. 시퀀스 다이어그램
시퀀스 다이어그램은 객체 간의 메시지 교환을 시간의 흐름에 따라 시각적으로 표현한 다이어그램이다. 다음 그림을 통해 한 번 시퀀스 다이어그램에 대해서 알아보자.
위 그림에 대해서 설명하면 다음과 같다.
- 상호작용에 참여하는 객체는 각각 네모 박스 안에 표현되며, 그림에서는 Library, p1(Patron), b1(Book)에 해당한다.
- 객체 아래 점선은 생명선(Lifeline)이며, 객체가 존재하는 시간을 나타낸다.
- 특정 메시지가 Library 객체로 전달되면, Library는 hasOverdueBooks() 메시지를 통해 p1 객체를 호출한다.
- 해당 메서드는 false 값을 반환할 수 있으며, 반환 메시지는 생략되거나 점선 화살표로 표현한다.
- addToHoldings(b1), assignToPatron(p1)과 같이 메시지에서는 매개변수가 포함될 수 있다.
- 조건문(if), 반복(loop)과 같은 흐름은 프레임(frame)을 사용하여 표현할 수 있다.
시퀀스 다이어그램의 요소는 다음 표를 확인해보면 된다.
시퀀스 다이어그램을 작성하는 순서는 다음과 같다.
- 참여하는 객체 파악
- 파악한 객체를 X축에 나열 후 라이프라인 긋기
- 유스케이스에 기술된 이벤트 순서에 따라 객체의 메시지 호출을 화살표로 나타냄
다음 그림은 수강신청 유스케이스를 통해 만든 시퀀스 다이어그램을 나타낸 것이다.
5.2. 협동 다이어그램
협동 다이어그램은 시퀀스 다이어그램과 동일하지만, 상호작용에 참여하는 객체들의 정적인 구조를 더 잘 보여주는 특징이 있다.
왼쪽이 시퀀스 다이어그램, 오른쪽이 협동 다이어그램이다. 협동 다이어그램은 다음 두 가지 요소를 결합한 형태다.
- 상호작용에 참여하는 객체들 간의 링크를 포함한 객체 다이어그램
- 객체 간에 주고받는 메시지
시퀀스 다이어그램에서는 메시지의 순서가 시간 흐름에 따른 위치로 표현되었다. 반면 협동 다이어그램에서는 각 메시지 앞에 번호를 붙여 순서를 표현한다.
예를 들어 위 그림에서 checkOutDuration()의 2.2.1은 2번 메시지 내부의 2.2. 메시지에서 발생한 첫 번째 하위 메시지임을 의미한다.
이러한 협동 다이어그램은 객체 간의 연결 관계를 중심으로 표현하기 때문에 시스템의 구조적인 관계를 이해하는 데에 더 유리하다.
5.3. 상태 다이어그램
상태 다이어그램은 시스템 또는 객체의 동적 동작을 모델링하는 UML 다이어그램이다. 객체가 특정 상태에 있다가 이벤트에 의해 다른 상태로 전이되는 과정을 표현한다.
즉, 상태 다이어그램은 이벤트에 따른 상태 변화를 중심으로 시스템의 동작을 설명한다.
도서관 시스템에서의 상태 다이어그램 예시를 통해 한 번 알아보자.
위 상태 다이어그램에 대해서 설명하면 다음과 같다.
- 시작 부분의 파란색 원은 초기 상태(Initial State)로, 객체의 생명주기가 시작되는 지점을 의미한다.
- 둥근 사각형(Book Available, Book Return, Search Book, Issue Book)은 객체의 상태를 나타내며 특정 조건에서 수행되는 동작을 포함한다.
- entry: 해당 상태에 진입할 때 수행되는 동작
- do: 상태가 유지되는 동안 수행되는 동작
- exit: 상태를 벗어날 때 수행되는 동작
- 화살표는 상태 간의 전이(Transition)을 의미하며, 특정 이벤트에 의해 발생한다.
- 전이는 일반적으로 이벤트 / 동작 또는 이벤트 [조건] / 동작 형태로 표현된다.
- 이중 원은 종료 상태를 나타내며, 객체의 생명주기가 끝났음을 의미한다.
6. 제어 모델링
UML에서는 정적 관점과 동적 관점 외에도 흐름도를 기반으로 제어 흐름을 모델링하는 다이어그램을 제공하는데 이를 액티비티 다이어그램이라고 한다.
액티비티 다이어그램은 알고리즘이나 프로세스에서 작업 절차를 모델링하며 예외 처리를 포함한 흐름도를 표현하는 데 적합하다.
액티비티 다이어그램은 상호작용 다이어그램을 보완한다. 상호작용 다이어그램은 객체 간의 메시지 흐름을 표현했다면, 액티비티 다이어그램은 작업 간의 흐름을 표현한다.
액티비티 다이어그램에서 사용하는 주요 요소는 다음과 같다.
- Activity(액티비티): 계산 또는 프로세스
- Transition(전환): 액티비티에서 다른 액티비티로 제어가 넘어가는 현상
- Branch(분기), Merge(합병): true로 계산된 조건의 분기
다음 그림 예시를 한 번 확인해보자.
그림에 대해서 설명하면 다음과 같다.
- 파란색 원이 액티비티 다이어그램의 시작 노드로, 프로세스의 시작을 의미한다.
- 마름모는 조건에 따라 분기되는 노드를 나타낸다.
- [Checkout Limit Not Reached / Checkout Limit Reached]와 같은 조건에 따라 서로 다른 경로로 흐름이 나뉜다.
- Checkout Limit Not Reached인 경우, Increment Book count for Patron이 실행되며, 이후 Record Patron as Borrower of Book 액티비티로 이어진다.
- Checkout Limit Reached인 경우 Inform Patron of Limi이 실행된다.
- 분기된 흐름은 이후 하나로 합쳐지며, 이는 Merge 노드를 통해 표현된다.
- 마지막의 이중 원은 종료 노드로 프로세스가 종료되었음을 의미한다.
- 오른쪽 코드와 1:1로 대응됨을 보여준다.
즉, 액티비티 다이어그램은 코드의 흐름을 시각화한 것이다.
7. 모델 검증
UML 모델을 생성한 이후에는 모델이 요구사항을 올바르게 반영하고 있는지 검증하는 과정이 필요하다.
모델 검증을 수행하는 방법에는 다음과 같은 것들이 있따.
- 리뷰: 사람이 눈으로 확인하는 방법으로 체크리스트를 활용하여 오류나 누락된 부분을 점검
- 테스팅: 모델 자체는 실행 불가능하기 때문에 모델을 기반으로 구현된 시스템이나 시뮬레이션을 통해 검증
- 정형적 방법: 요구사항과 모델의 일관성을 수학적으로 증명
- ex) 다이어그램 안 각 상태와 전이 조건을 수식으로 표현하여 논리적 오류가 없는지 검증
- 프로토타이핑: 모델을 기반으로 간단한 프로토타입을 구현하여 실제 예상대로 동작하는지 확인
- 요구 추적: 모델이 요구사항을 제대로 반영하고 있는지 확인하기 위해 모델로부터 요구를 거꾸로 추적하는 방법
7.1. 일관성 체크
모델 검증 방법에서 가장 중요한 것은 일관성 체크이다. 만약 UML 다이어그램 간에 표현된 내용이 서로 모순된다면, 이후 설계 및 구현 단계에서 큰 차질이 발생할 수 있다.
따라서 서로 다른 UML 다이어그램 간에 불일치하는 부분이 없는지 교차하여 검토하고 확인해야 한다.
7.1.1. 유스케이스 다이어그램 - 시퀀스 다이어그램 일관성 체크
우선 유스케이스 다이어그램과 시퀀스 다이어그램에 대하여 유스케이스 명세가 기술되어 있고 매칭되는 시퀀스 다이어그램이 있는지 체크해야 한다. 다음 사항들을 확인한다.
- 각 유스케이스를 수행하는 액터가 존재하는가?
- 각 액터는 최소 하나 이상의 유스케이스와 연결되는가?
- 각 유스케이스에 대해 명세가 기술되었나?
- 각 유스케이스에 대응되는 시퀀스 다이어그램이 존재하는가?
그림으로 나타낸 결과는 다음과 같다.
7.1.2. 시퀀스 다이어그램 - 클래스 다이어그램 일관성 체크
시퀀스 다이어그램에서 사용된 클래스와 메시지가 클래스 다이어그램에 정확히 반영되었는지 확인해야 한다.
- 시퀀스 다이어그램에 등장하는 모든 클래스가 클래스 다이어그램에 포함되어 있는가?
- 시퀀스 다이어그램에 표현된 각 메서드에 대해
- 메시지를 보내는 클래스와 받는 클래스가 클래스 다이어그램에서 연결되어 있는가?
- 메시지를 보내는 클래스에 해당 메서드 호출이 존재하는가?
- 메시지를 받는 클래스에 해당 메서드가 정의되어 있는가?
그림으로 나타내면 다음과 같다.
7.1.3. 클래스 다이어그램 - 상태 다이어그램 일관성 체크
클래스 다이어그램과 상태 다이어그램 간에도 일관성을 확인해야 한다.
상태 다이어그램에서 객체의 상태 전이는 특정 이벤트 또는 메서드 호출에 의해 발생한다. 따라서 클래스 다이어그램에는 이러한 상태 전이를 유발하는 메서드가 반드시 정의되어 있어야 한다.
즉, 상태 변화와 관련된 메서드가 클래스에 누락되지 않았는지 확인하는 것이 중요하다.
그림으로 나타내면 다음과 같다.
'학교공부 > [소프트웨어공학]' 카테고리의 다른 글
| [소프트웨어공학] - 설계 원리 (1) | 2026.04.21 |
|---|---|
| [소프트웨어공학] - 요구 분석 (0) | 2026.04.21 |
| [소프트웨어공학] - 프로젝트 관리와 계획 (0) | 2026.04.21 |
| [소프트웨어공학] - 프로세스와 방법론 (1) | 2026.04.21 |
