Structural Models

구조적 모델은 "무엇이 상호작용하는가"에 초점을 맞춰서 시스템의 정적인 구조와 뼈대를 모델링하는 것이 주의 핵심이다.

구조적 모델의 목적

객체는 Application Domain에서 핵심이 되는 사물, 아이디어, 개념 등을 나타내는 것이다. 클래스 다이어그램, 오브젝트 다이어그램을 작성하기 위한 규칙이나 스타일 지침 그리고 구조 모델간의 관계를 이해하는 것을 목적으로 한다.

Structural 모델의 가장 주요한 목표는 문제 영역에 포함된 핵심 데이터를 발견하고 객체의 구조적 모델을 구축하는 것이다.

구조적 ViewPoint

ViewPoint를 표현하기 위해서 다양한 다이어그램을 제공하고, 컴포넌트 다이어그램부터 클래스 다이어그램, 객체 다이어그램 등이 대표적으로 활용된다.

Class Diagram

클래스 다이어그램에서는 시스템의 정적인 구조를 구성하는 핵심 단위인 클래스는 사각형 박스로 그려지고, 내부적으로 크게 3가지의 엘리먼트로 나누어 표현된다.

Class Name

말 그대로 클래스의 이름을 보이며, 가장 위칸에 위치하고 문제 도메인에서 식별된 해당 객체의 이름을 나타낸다.

Attributes

이름 다음에 오는 중간 칸을 이용하며, 클래스가 내부적으로 관리하고 유지하는 데이터를 의미한다.

표기법은 아래와 같다.
[visible] name : type-expression [=initial-value]

가시성(Visibility)

이 때, Visibility는 총 3가지로 표기할 수 있는데, 우선 +는 public을 의미하며 외부의 누구나 접근 가능하고, -는 반대로 private를 의미해 해당 클래스 내부에서만 접근 가능하다. 마지막으로 #은 protected를 의미해 자식 클래스에게만 접근을 허용한다.

정적 인스턴스

속성 밑에 밑줄이 그어서 표기하며, 클래스 차원에서 메모리에 유일하게 하나만 존재하여 공유되는 정적(Static) 변수를 의미한다.

Operation

가장 아랫쪽 칸을 차지하며, 클래스가 외부 클라이언트에게 제공하는 서비스를 정의한다.

표기법은 아래와 같다.
[visibility] name([parameter-list]) [: return-type]

속성과 마찬가지로 오퍼레이션에 밑줄이 그어져 있으면 Static Method를 뜻한다.

클래스 간의 주요 관계

Generalization(Inheritance)

is-a가 성립하는 부모-자식 간의 관계를 나타낸다. 여러 클래스를 분석하다 공통적인 부분(Attribute or Operation)이 발견되면, 이를 부모 클래스로 뽑아 올려 중복을 없애고 코드를 재사용하기 위해 사용되는 관계이다. 속이 빈 삼각형 화살표와 실선으로 표기한다.

Aggregation(Composition)

전체와 부분을 나타내는 part-of 관계를 가진다. 두 클래스의 결합 강도에 따라서 다음의 두 관계로 세분화할 수 있다.

Strong Aggregation(Composition)

전체와 부분의 생명주기가 동일한 매우 강한 결합의 형태이다. 전체 객체가 소멸하거나 생성될 때, 부품 component도 동시에 생성되고 소멸한다. 표기법으로는 속이 찬 다이아몬드로 표현된다.

Weak Aggregation

부품이 하나의 전체에만 전담되지 않고 여러 다른 객체에서 공유될 수 있는 결합으로 속이 빈 다이아몬드로 표기한다.

Association

상속이나 전체-부분 관계에 속하지 않는 클래스 간의 일반적인 연결 및 사용 관계를 의미한다. 선으로 연결해 표현하고, 관계를 명확히 하기 위해 방향성 화살표나 역할 이름을 덧붙일 수 있다.

가장 중요한 특징은 선 끝에 다중성을 명시해 하나의 객체가 상대방 객체와 몇 개의 관계를 맺는지를 나타낸다.

Dependency

Associate보다 훨씬 약한 연결로 한 클래스의 변경이 다른 클래스에 영향을 미치는 관계이다. 특정 메서드를 실행할 때, 파라미터로 전달받거나 리턴 타입으로 일시적으로만 사용할 때 주로 형성된다.

일반 실선이 아닌 점선 화살표로 표기하여 적용한다.

인터페이스와 스테레오 타입

인터페이스(interface)

실제 동작하는 구현 부분 없이 외부에 제공할 Operation의 시그니처만 모아둔 집합이다.
<<interface>>

클래스들이 직접 통신하면 서로 떼어낼 수 없는 Strong Coupling이 발생한다. 인터페이스를 둠으로서 결합의 강도가 줄어들어 Weak Coupling을 유도할 수 있다.

스테레오 타입(Stereotype)

기존에 존재하는 UML의 기본 구성 요소를 확장해 새로운 의미나 종류의 모델 요소를 만들어내는 표기법이다.

아래와 같은 표기법으로 나타낸다.
<<>>
다이어그램을 보는 사람이 해당 요소의 용도와 성격을 명확히 이해할 수 있도록 돕는 역할을 한다.

클래스 다이어그램 vs 객체 다이어그램

같은 내용을 정리해도 다이어그램의 종류에 따라서 서로 다른 형태를 띈다. 아래와 같이 클래스 다이어그램과 객체 다이어그램은 서로 다른 모습을 보인다.

객체 식별 및 모델링 프로세스

Object Identification

문제 도메인에 있는 어떤 아이디어나 개념을 소프트웨어 내의 클래스로 뽑아낼 것인가"를 결정하는 단계이다. 총 3가지의 기법으로 클래스 후보군을 추린다.

텍스트 분석

기계적으로 분석하는 방법으로, 문장에서 명사는 클래스나 속성의 후보로, 동사는 오퍼레이션 후보로 추출한다.

브레인 스토밍

팀원들이 한자리에 앉아 시스템에 필요할 듯한 클래스나 속성 등을 토론하며 식별하는 방식이다.

Common object list

비즈니스 도메인에서 보편적으로 클래스로 추출되는 대표적 유형리스트를 참고해 누락된 객체를 찾아내는 방법이다.

역할, 물리적 사물, 사건, 상호작용을 중심으로 알아보게 된다.

CRC 카드

CRC 카드는 다이어그램을 그리기 전, 설계의 결함을 조기에 찾아내고자 작성된다. 주로 Object Identification을 수행하고 작성된다.

Use Case 기반으로 분석을 통해서 초안을 작성하고 브레인 스토밍을 통해 토의한 이후 롤플레잉을 통해서 검증한다. 그리고 이에 대한 결함을 보완하면서 CRC 카드를 기반으로 클래스 다이어그램을 그린다.

CRC카드 앞	CRC 카드 뒤

클래스 유형

Unified Process는 3가지로 클래스를 유형을 나눠 분류한다.

이 전체는 stereotype이며, UML을 정의하면 시스템을 정확히 모델링하는 데 필요한 추가 구성요소를 정의할 수 있다.

Entity Class

영구적으로 DB에 저장되고 유지되어야 하는 데이터 정보들을 기록한다. 예를 들어 계좌나, 학생, 강좌 등 프로젝트에서 중심을 가지는 데이터들 다루는 Class를 말한다.

Boundary Class

시스템과 외부 Actor 간의 상호 작용 및 입출력을 담당한다. 위의 설명처럼 주로 input과 output과 연관된 작동을 주로 이 클래스에 분류한다.

Control Class

복잡한 비즈니스 로직을 연산하거나 알고리즘을 제어하는 것을 주로 담당하는 클래스로 무언가 계산을 해야하는 로직의 경우 이 클래스로 분류된다.

Case Study

Osbert Oglesby 미술품 시스템을 중심으로 앞서 정리한 내용들을 돌아보는 과정을 거친다.

1. System Request & Use Case

Osbert가 그림을 구매할 때 최대 지불 가능 가격을 산정하고, 미술 시장의 새로운 트렌드를 파악해 세금 계산 등을 위해 모든 판매/구매 기록을 유지하고 보고서를 출력하는 시스템을 개발하고자 한다.

이때, Use Case는 아래와같이 4개의 주요 Use Case로 구성된다.

정보 시스템을 한 단락으로 묘사해보면, "예술 작품 구매 의사 결정 과정의 효과를 향상시키기 위해 보고서를 생성할 것이다. 보고서에는 걸작, 명작 및 기타 그림으로 분류되는 그림에 대한 매매 정보가 포함되어있다."로 표현할 수 있다.

2. 엔티티 식별 및 구조 고도화

엔티티를 명사를 추출함으로서 식별하고, 구조를 개선하여 클래스 다이어그램을 명확하게 만들어낸다.

명사 추출

1) 위의 단락에서 명사만을 표기한다.
"예술 작품 구매 의사 결정 과정의 효과를 향상시키기 위해 보고서를 생성할 것이다. 보고서에는 걸작, 명작 및 기타 그림으로 분류되는 그림에 대한 매매 정보가 포함되어있다."

2) 추출 결과물을 보면 아래와 같다.
{ 예술 작품, 구매, 과정, 효과, 보고서, 걸작, 명작, 기타 그림, 그림, 정보 }

3) Entity Class를 추출한다.
추상명사와 동명사 등을 제외하고, 오래 지속되지 않는 것들도 제외한 뒤, 동의어를 제거하면 아래만 남는다.
{ 걸작, 명작, 기타 그림, 그림 }

고로 이렇게 4개가 Entity Class로 선택된다.

1차 Diagram 구조 개선

우선 각 엔티티 클래스 후보군들을 두고, 클래스 간의 상호관계를 고려한다. 관계를 보면 그림을 기준으로 나머지 클래스들과 포함 관계를 가진다. 따라서 그림(painting) 클래스를 Base Class로, 나머지를 Sub Class로 한다.

2차 Diagram 구조 개선

지금까지의 클래스 다이어그램을 기준으로 Pricing Algorithm을 반영하지 않았기에 이제 이 부분을 고려해야한다.

걸작(masterwork)을 다룰 때, 정보 시스템은 우선 같은 화가의 명작(masterpiece)인 것처럼 최대 지불 금액을 계산한다. 고로 걸작(masterwork)은 명작(masterpiece)의 모든 attribute를 가져야한다. 또한 자신의 속성도 가져야한다.

3차 Diagram 구조 개선

위의 클래스에서 고려하지 못한 pricing algorithm은 경매 기록이 있는 그림과 구매를 고려중인 그림 사이의 유사도 계수를 계산한다는 것이다.

그렇게 되면 경매 기록이 있는 그림 클래스가 필요하다. 이는 Painting class의subclass여야 하며, 현재 전시된 그림과는 관련성이 없어서 표현하면 아래와 같이 표현한다.

4차 Diagram 구조 개선

3번째까지도 fashionability 모델링이 아직이며 F*A 공식으로 상품의 최대 지불가격을 정해야한다. (F = 작가 유명도 상수, A = 그림 크기) 또한 Fashionability Class가 필요하다. 이러한 고려사항을 적용하면 아래와 같아진다.

상세 클래스 다이어그램

클래스 다이어그램에 필요한 요소를 상세히 다 넣으면 아래와 같은 그림으로 그릴 수 있다.

3. 바운더리 클래스 식별

시스템과 유저간의 입력/출력을 담당하는 UI 요소를 도출한다. 4개의 Use Case 스크린을 포괄적으로 처리할 클래스를 둔다. 이후 보고서들의 내용은 각기 다르므로 3개의 독립적 보고서 클래스를 분리해 바운더리 클래스를 도출한다.

Purchase Report, Sales Report, Future Trends Report, User Interface Class

4. 컨트롤 클래스 식별 및 최종 완성

데이터를 가공하고 계산하는 복잡한 로직을 별도의 클래스로 도출한다. 가격을 계산하는 알고리즘을 처리하기 위해 클래스를 만들고 새로운 트렌드를 분석하는 Compute Future Trends 클래스를 추가해 4개의 컨트롤 클래스를 식별한다.