Lecture 10: 설계 - 3

경희대학교 김정욱 교수님의 소프트웨어 공학 수업을 기반으로 정리한 글입니다.

정적 모델링

정적 모델링 - 구조적 다이어그램

• 클래스 다이어그램: 클래스와 클래스가 가지는 속성, 클래스 사이의 관계 표현
• 오브젝트 다이어그램: 클래스에 속한 사물(객체)들, 즉 인스턴스(Instance)를 특정 시점의 객체와 객체 사이의 관계로 표현
• 컴포넌트 다이어그램: 컴포넌트 간의 관계나 컴포넌트 간의 인터페이스를 표현 (파일들 끼리의 연결)

▶ 정적 모델링 - 구조적 다이어그램

클래스 다이어그램

클래스 다이어그램

시스템 입장에서 클래스들 간의 관계를 나타낸 것으로, 클래스의 정적인 정의와 관계를 표현한다.

이때, 객체가 아닌 클래스는 본질적으로 정적(Static)이다. (시간과 조이 개임되지 않기 때문)

 

Use case diagram을 설계 관점으로 가져온 것이라고 할 수 있다.

 

▶ 클래스 다이어그램

 

※ 클래스로부터 파생된 객체(Object)는 그 자체가 동적이다.

 

클래스 다이어그램 그리는 과정

• 클래스 및 속성(변수, 함) 찾기 (Use case diagram 기반으로 찾기)
• 관계 찾기
• 클래스 다이어그램 그리기

▶ 클래스 다이어그램 그리는 과정

 

클래스 다이어그램은 객체 지향 관점이며, Use case diagram을 기반으로 그린다.

▶ 클래스 다이어그램 그리는 방법

• 사각형 그리기
• 사각형을 3등분 하여, 맨 위에 클래스 이름 써주기
• 속성 써주기
• 오퍼레이션/메서드 써주기 (클래스가 할 수 있는 행위, 즉 기능 정의)

속성/메서드 표기법

• + public, # protected, - private, ~ package (디폴트), / derived
• Underline(밑줄): 정적 변수 (클래스 내에서 사용)

※ '- width: int': width라는 변수를 int형 자료형으로 private(-)하게 받겠다.

 

※ / derived: 다른 속성에 의해 유추될 수 있는 것이다.

 

메서드 부분 작성법

• 메서드 이름(name: type): 리턴 타입

이때, 입력받는 argument가 없으면 생략하고, 리턴 타입이 void이면 리턴 타입을 생략한다.

▶ 정보은닉 표기법 (Java, C++, UML)

• 공개(+, public): 같은 시스템에 있는 모든 클래스가 접근할 수 있음
• 은닉(-, private): 같은 시스템 내의 다른 클래스가 직접 접근할 수 없고, 해당 클래스의 메서드를 통해서만 접근할 수 있음
• 부분공개(#, protected): 다른 클래스가 접근할 수 없고, 해당 클래스의 메서드, 클래스를 상속받은 하위 클래스만 접근 가능

※ protected도 private처럼 메서드를 통해 다른 클래스가 접근 가능하다.

▶ 클래스 이름, 속성, 오퍼레이션/메서드 (예시)

 

※ 함수의 입력 정의시, name 없이 type만 준 것은 이름은 구현 때 마음대로 할 수 있는 자유도를 준 것이다.

 

클래스 다이어그램 장점

• 유스케이스 다이어그램보다 설계 관점에서 더욱 구체적임
• 설계에서 클래스 다이어그램을 사용하는 가장 큰 장점은 클래스 간 인터페이스를 빠르고 명확하게 알 수 있기 때문임
• 클래스, 인터페이스, 관계 등이 표시가 되어있어 향후 개발 단계서 중요한 도구로 사용됨

▶ 유스케이스 다이어그램 vs 클래스 다이어그램

 

※ 위 클래스 다이어그램 예시에서 팀이 없어지면 야구선수도 없어진다.

 

클래스 다이어그램 단점

• 너무 상세한 내용을 기입하면 구현 단계에서 할 일이 미리 이루어지는 오류를 범하게 되어 실제 구현 단계에서 커다란 위험의 요소가 내재됨 (설계 내용을 실제 구현해야 하기 때문)
• 동적인 관점에 대한 해석이 불가

클래스 사이의 관계

1. 상속

한 클래스가 다른 클래스를 포함하는 상위 개념인 경우를 말하며,

부모를 향한 화살표로 표시되는 하향 계층 관계이다.

▶ 상속

• 클래스: 실선 (일반화 관계)
• 인터페이스: 점선 (실체화 관계)

부모 클래스: 추상적인 개념, 삼각형 표시가 있는 쪽 (자식 클래스의 공통적인 속성을 제공)

자식 클래스: 추상적인 개념을 물려받은 구체적인 개념

 

1) 일반화 관계

▶ 일반화 관계

 

2) 실체화 관계 (Realization)

▶ 실체화 관계

 

※ 실제 구현은 디테일한 내용이 들어가지만, 설계는 핵심만 넣는다.

2. 연관 관계 (Association)

클래스들끼리 서로 관련이 있는 관계를 말한다.

▶ 연관 관계

• 양방향(실선): 서로가 참조
• 단방향(화살표): 한 쪽이 다른 쪽을 참조

3. 집합 관계 (Aggregation)

연관 관계를 조금 더 특수하게 나타낸다. (전체와 부분의 관계)

이때 전체 객체가 사라져도 부분 객체는 남아있다. (한 객체의 생성과 소멸이 다른 객체에 영향 미치지 X)

 

※ 연관 관계의 한 종류이다.

▶ 집합 관계

4. 합성 관계 (Composition)

전체 객체가 사라지면 부분 객체도 사라진다. (의존적 - 생성, 소멸)

▶ 집합 관계

 

※ 내부에서 정의를 하기 때문에, 전체가 사라지면 부분도 사라진다.

▶ 집합 관계 vs. 합성 관계

 

라이프 타임 차이: 독립적(집합) vs. 의존적(합성)

 

※ 이러한 관계는 정해진 것이 없고, 개발하고자 하는 소프트웨어에 맞게 설계하면 된다.

관계의 숫자 표현

숫자 표현

• 1: 1개
• 0..1: 0 또는 1개
• *: 0 ~ n개
• 1..*: 1 ~ n개
• n..m: n ~ m

이러한 숫자는 클래스를 인스턴스화할 때, 인스턴스화 하는 개수를 뜻한다.

또한, 몇 개와 관계를 맺을 건지 나타낸다.

▶ 참조 가능한 인스턴스의 수

 

여기서 1..*에 의해 교수 클래스의 오브젝트 하나는 한 명 이상의 학생과 관련있음을 알 수 있다.

반대로 한 학생은 한명의 교수와 연관이 있음을 알 수 있다.

클래스 다이어그램 (예시)

예시 1

▶ 클래스 다이어그램 예시 1

• 후보선수는 0개 이상의 경기에 뛴다.
• 주전선수와 후보선수는 하나의 팀에 속한다.

예시 2

▶ 클래스 다이어그램 예시 2

예시 3

▶ 클래스 다이어그램 예시 3 (정답: 4번)

객체 다이어그램 (오브젝트 다이어그램)

객체 다이어그램

클래스 다이어그램과 유사하며, 클래스 다이어그램의 모델 요소를 인스턴스화하여 시스템의 동작을 탐색한다.

때문에 객체 간 상호작용(객체 간 메시지 전송, 반환)을 이해하고 설계하는 데에 매우 유용한 다이어그램이다.

▶ 객체 다이어그램

▶ 객체 다이어그램 표기

 

오브젝트: 클래스를 인스턴스화한 것

 

※ 화살표같은 거 없이 실선으로만 표현한다. 위의 연결 화살표들은 클래스 다이어그램 그릴 때 사용하는 것이다.

 

장점

• 특정 시점에 대한 오브젝트 간 관계를 보여주기 때문에 이해하기 쉬움
• 런타임시 클래스의 특정 인스턴스와 해당 상호 작용을 캡처하는 데 중점을 두기 때문에 실제 시나리오를 테스트하고 디버깅하는 것이 쉬움

단점

• 주로 클래스 다이어그램을 미리 그려야 객체 다이어그램을 그릴 수 있음
• 정적인 구조인 객체 다이어그램만으로 실제 시스템의 동적인 동작을 이해할 수 없

객체 다이어그램 (예시)

▶ 객체 다이어그램 예시

 

※ 기능(함수)는 생략하였다.

 

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

1. 관계 정의

• 클래스 다이어그램: 클래스와 클래스 간의 관계
• 객체 다이어그램: 객체와 객체 간의 관계

2. 추상화 vs. 구체적

• 클래스 다이어그램: 클래스의 관계로 구성된 추상 모델 (인스턴스에 대한 디테일은 제공 X)
• 객체 다이어그램: 특정 시점에 대한 클래스의 인스턴스를 나타내기에 보다 구체적

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