4. 클래스 모델링

728x90

01 클래스 다이어그램의 기초

• 클래스 다이어그램의 구성 요소

– 클래스: 자료 타입 그 자체를 나타냄
– 연관관계: 클래스 인스턴스 사이의 관계를 나타냄
– 속성: 클래스와 그 인스턴스 안에서 발견될 단순 자료
– 오퍼레이션: 클래스와 그 인스턴스에 의하여 수행될 함수를 나타냄
– 일반화: 클래스를 상속 구조로 그루핑

02 클래스와 가시성

2.1) 클래스

• 클래스는 박스로 표현하며 그 안에 이름을 적는다
– 다이어그램은 속성과 오퍼레이션을 나타낼 수 있다.
– 오퍼레이션의 원형은 다음과 같이 표시한다.
operationName(parameterName parameterType, …): returnType

2.2) 속 성

• 객체의 상태 또는 성질을 나타냄
– 객체에 대한 정보를 나타냄
– 속성은 변수와 동의어는 아님. 추상적으로 정의한 성질
– 객체 외부에서 값을 가져갈 수도 있고 변경할 수도 있음
– 읽기 전용도 있음

2.3) 오퍼레이션

• 박스 맨 아래 오퍼레이션의 원형으로 표현
– 대부분 속성에 대한 get,() set()
– 읽기 전용은 get() 오퍼레이션만
– 일부 오퍼레이션은 매개변수 필요
– 일부 오퍼레이션은 다른 객체에 메시지 호출할 필요가 있음

2.4) 가시성

• 속성과 오퍼레이션 앞에 visibility 표시
– Public : ‘+’
– Protected : ‘#’
– Private : ‘-’

2.5) 추상 클래스

• 추상 오퍼레이션
– 구현이 없는 오퍼레이션
• 추상 클래스
– 인스턴스가 없는 클래스

03 연관관계와 다중도

• 두 클래스가 서로 어떻게 관련이 있는지를 나타냄
– 연관관계의 양 끝에는 다중도를 표시
– 연관관계 특성을 드러내기 위해 이름을 붙임

• One-to-one
– 한 회사에 오직 한 개의 책임자 위원회가 있음
– 책임자 위원회는 한 회사를 위한 위원회임
– 회사는 항상 위원회를 가지고 있어야 함
– 위원회는 어떤 회사의 소속임

• Many-to-many
– 비서 일인이 여러 명의 관리자를 위하여 일함
– 관리자 한 사람이 여러 명의 비사를 둘 수 있음
– 비서는 풀에서 일함
– 관리자들은 비서의 그룹을 가질 수 있음
– 어떤 관리자는 비서가 없을 수도 있음
– 관리자가 없는 비서는 일시적으로 가능한가?

• 불필요한 1대1 관계는 피함

복잡한 예

• 예약은 항상 단 하나의 탑승객에 대한 것
– 탑승객이 없는 예약은 없음
– 예약에 탑승객이 여러 명인 경우는 없음
• 탑승객이 다수의 예약을 할 수 있음
– 탑승객이 예약이 하나도 없을 수 있음
– 탑승객에 다수의 예약이 있을 수도 있음

• 두 개의 연관 클래스에 관한 속성을 어느 한쪽에 위치시킬 수 없을 때
• 다음과 같은 경우

재귀 연관관계
• 클래스 자신과 연관관계를 맺음

04 일반화 관계와 전체/부분 관계

• 일반화 관계

– 두 가지 이상의 서브클래스로 구체화 시키는 것
– Discriminator: 상세화 할 때 기준을 나타내는 레이블

불필요한 상속 피하기

• 인스턴스가 되어야 할 것을 무리하게 클래스
구조로 상속한 경우
• 개선 후 클래스 다이어그램

구별자

• 그루핑하는 기준
– 동력의 위치에 따른 구별 – 내연, 외연
– 운송 매체 – 육상, 해상

전체부분 관계 - Aggregation

• Aggregation : 전체부분 관계를 나타내는 특수한 형태

– 전체에 해당되는 클래스는 aggregate 또는 assembly라 부름
– 다이어몬드 심볼은 isPartOf 라는 관계로 생각할 수 있음

Aggregate를 사용하는 경우

• 일반적인 경우 다음의 관계가 성립하면 aggregate를 사용
– ‘is a part of’ 관계가 성립할 때
– ‘is composed of’ 관계가 성립할 때
• 집합 개념을 관리하거나 소유하고 있으면 부분 개념도 소유

합성은 aggregation이 강한 관계
– 집합이 소멸되면 부분도 따라서 소멸

– 주소를 표현하는 두 가지 방법

05 고급 표현

• 인터페이스는 객체집합이 가지는 행위의 일부를 가시화 한 것
– 인터페이스는 클래스와 유사, 인스턴스 변수와 구현된 메소드만 없다.

OCL (Object Constraint Language)

• 소프트웨어 모듈에 제약사항을 정형적으로 나타내도록 설계된 명세 언어

– OCL은 시스템에 대한 논리적인 사실만 나타냄

– 제약 사항에 대한 side-effect는 없음
• 참이나 거짓이 아닌 결과를 낼 수 없으며 변수 값을 조작하지도 않음

– 클래스 다이어그램에 표현된 OCL 문장은 속성값이 무엇이며 연관관계에 대하여 나타낼 필요가 없음

06클래스 다이어그램 개발 과정

• 반복, 점증적 방법
– 초벌로 작성 후 계속 추가, 삭제

클래스 파악

• 도메인 모델을 개발할 때 클래스를 찾아내려고 노력

• 사용자 인터페이스나 시스템 구조에 대한 작업할 때 필요한 클래스를 고안
– 특정 설계 문제를 해결할 때 필요
– 도메인 모델을 생성할 때 고안할 수도 있음

• 재사용에 관심을 두어야
– 프레임워크
– 시스템 확장
– 유사 시스템

연관관계 파악

• 가장 중요한 중심 되는 클래스부터 시작
• 분명하고 확실한 데이터를 포함할 수 있는 것이어야 함
• 덜 중요한 클래스로 작업을 이동
• 클래스에 많은 속성과 연관관계를 추가하는 것은 피해야 함
– 더 적은 자료를 다룬다면 시스템은 단순해짐

연관관계 파악 비결

• 다음과 같은 관계가 클래스에 성립되는지 판단해 본다.
– possesses
– controls
– is connected to
– is related to
– is a part of
– has as parts
– is a member of, or
– has as members
– 양 끝에 다중도를 표시하고
– 레이블을 정확히 붙임

속성 파악

• 각 클래스에서 보관하여야 할 데이터를 찾음
• 클래스 후보에서 탈락한 명사는 대부분 속성임
• 속성은 단순한 원자적 값을 가져야 함
– 스트링, 문자, 정수 등의 타입

일반화 관계

• 일반화를 파악하는 두 가지 방법
– 상향식
• 유사 클래스를 그루핑 하여 슈퍼클래스를 생성
– 하향식
• 먼저 일반적인 클래스를 찾고 필요하면 상세화

클래스에 임무부여

• 임무(responsibility)란 시스템이 수행하도록 요구된 사항
– 주어진 클래스의 모든 요구는 명확히 서로 연관됨
– 한 클래스에 너무 많은 임무가 주어지면 다른 클래스로 분산
– 임무가 부여되지 않은 클래스는 필요 없는 것임
– 어떤 임무가 현재 존재하는 클래스에 할당되지 않았다면 새 클래스를 생성

• 임무를 결정하기 위하여
– 사용사례 분석
– 시스템 명세에 액션을 기술하고 있는 동사와 명사를 찾음

임무의 종류

• 속성값을 저장하고 읽음
• 새 인스턴스를 생성하고 초기화
• 데이터베이스에서 불러오기, 저장하기
• 인스턴스를 소멸
• 연관관계 링크를 추가 및 삭제
• 복사, 변환, 출력 등 다른 형태로 정보를 변경
• 수식 결과를 계산
• 탐색, 위치 추적
• 다른 특수 임무

오퍼레이션 파악

• 각 클래스에 부여된 임무를 실현시키기 위하여 필요
– 임무 하나에 여러 개의 오퍼레이션이 필요할 수도 있음
– 임무를 구현한 메인 오퍼레이션은 public으로
선언되어야
– 임무를 실행하기 위하여 협동하는 다른 메소드는
가능하면 private으로 선언

07 코드 매핑

• 속성은 인스턴스 변수로 구현
• 일반화는 extends로 구현
• 인터페이스는 implements로 구현
• 연관관계는 인스턴스 변수로 구현
– 양방향 연관관계는 단방향의 두 개의 연관관계로 구현
• 각 관련 클래스가 인스턴스 변수를 가지도록 구현
– 단방향 연관관계에서 다중도 표시가 ‘1’ 또는 선택인
쪽
• 클래스의 변수를 선언
– 단방향 연관관계에서 다중도 표시가 many 인 쪽
• 벡터를 이용하여 객체의 집합으로 구현