– 1980년대 말과 1990년대 초반에 객체지향 개발 프로세스 등장함 – 방법론과 표기법의 확산은 상당한 혼란을 초래함 – Rumbaugh와 Booch는 1994년에 그들의 방법을 통합하기로 결정함 • 그들은 Rational Software Corporation에서 함께 일함 – 1995년에는 다른 방법론자인 Jacobson이 팀에 합류 • 그의 방법론은 유스케이스에 중점 – 1997년에 OMG (Object Management Group)는 UML 표준화 프로세스를 시작
📁 UML 다이어그램
1. 클래스 다이어그램(Class diagrams) : 클래스들과 그들의 관계를 기술
2. 상호 작용 다이어그램(Interaction diagrams) : 객체들이 서로 어떻게 상호작용하는지에 대한 시스템의 동작을 표현한다.
3. 상태 다이어그램(State diagrams) 및 활동 다이어그램(Activity diagrams) : 시스템이 내부적으로 어떻게 행동하는지 보여준다.
4. 컴포넌트(Component diagrams) 및 배치 다이어그램(Deployment diagrams) : 시스템의 다양한 구성 요소가 논리적 및 물리적으로 어떻게 배치되는지 보여준다.
📁 UML features
상세한 의미론(semantics)과 확장 매커니즘(extension mechanism)을 가지고 잇따.
관련 텍스트 언어 OCL(Object Constraint Language)가 있다.
UML의 목적은 소프트웨어 개발을 돕는 것으로, 방법론이 아니다.
📁 좋은 모델
• 모델은 – 표준 표기법을 사용해야 함 – 고객과 사용자가 이해할 수 있어야 함 – 소프트웨어 엔지니어가 시스템에 대한 통찰력을 가질 수 있게 유도해야 함 – 추상화를 제공해야 함 • 모델은 다음과 같은 경우에 사용됨 – 설계 작성 – 이러한 설계에 대한 분석 및 검토 – 시스템을 설명하는 핵심 문서
📁 클래스 다이어그램(Class diagrams)
클래스 다이어그램은 클래스, 연관관계, 속성, 오퍼레이션, 일반화와 같은 요소로 구성된다.
1. 클래스 : 자료 타입 그 자체를 나타낸다. 속성과 오퍼레이션의 집합체이다.
클래스는 박스(사각형)으로 표현하고, 내부에 클래스 이름을 명시한다.
이름, 속성, 오퍼레이션 세 부분으로 구성되며, 속성과 오퍼레이션은 생략될 수 있다.
2. 연관관계 : 클래스와 인스턴스 사이의 연계 관계를 나타낸다.
두 클래스가 서로 어떻게 관련되어있는지를 표현한다.
연관관계의 특성을 표현하는 연관관계 장식 요소는 다음과 같다.
- 관계 이름(association name) : 동사나 동사구로 표현한다.
- 다중성(multiplicity) : 관계 사이에 개입하는 인스턴스의 개수를 의미한다.
- 역할 이름(role name) : 클래스에 의해 수행되는 역할이다. 링크의 양 끝에 표시한다.
- 방향성(directionality 또는 navigability)
🌱 연관관계의 다중성
– 다중성을 표시하지 않으면 1로 간주 – 다수일 때는 *로 표시, 0을 포함한 다수 • 0..1 : 선택적(optional) 관계 • 1..* : 1개 또는 그 이상 • 3..5 : 3개에서 5개까지
- One-to-one
예를 들면 다음과 같은 관계가 있다.
– 한 회사에 오직 하나의 이사회가 있음 – 이사회는 한 회사를 위한 위원회임 – 회사는 항상 이사회를 가지고 있어야 함 – 이사회는 어떤 회사에 소속됨
- Many-to-many
예를 들면 다음과 같은 관계가 있다.
– 비서 한 명은 여러 명의 관리자를 위하여 일함 – 관리자 한 사람은 여러 명의 비서를 둘 수 있음 – 비서는 pool에서 일함 – 관리자들은 비서의 그룹을 가질 수 있음 – 어떤 관리자는 비서가 없을 수도 있음
불필요한 1대1 관계 또는 부적절한 연관관계는 피해야 한다.
예를 들면 다음과 같다.
복잡한 연관관계 예시는 다음과 같다.
– 예약은 항상 단 하나의 탑승객에 대한 것 • 탑승객이 없는 예약은 없음 • 하나의 예약에 여러 탑승객이 관련되지 않음 – 탑승객이 다수의 예약을 할 수 있음 • 탑승객이 예약을 하나도 갖지 않을 수 있음 • 탑승객이 다수의 예약을 가질 수도 있음
🌱 연관 클래스(Association classes)
두 개의 관련 클래스에 관한 속성을 어느 한 쪽에 위치 시킬 수 없을 경우에 필요한 클래스를 말한다.
예를 들어, 아래 두 표현은 동일한 표현이다.
🌱 재귀 연관관계(Reflexive associations)
클래스 자신과 연관관계를 맺는것을 말한다.
🌱 연관관계의 방향성(Directionality)
연관관계는 기본적으로 양방향성(bi-directional)이다.
하지만 연관관계의 한 쪽 끝에 화살표를 추가함으로써 연관관계의 방향성을 제한할 수 있다.
예를 들면 아래와 같다.
• 클래스 인스턴스 Day는 그날에 연관된 Note 인스턴스를 알 필요 있음 • 그러나 메모 내용을 가지고 해당되는 날짜를 찾아내는 기능이 필요 없음
🌱 전체/부분 관계(Aggregation)
전체/부분(whole-part) 관계를 나타내는 특수한 연관관계가 존재한다.
전체에 해당하는 클래스는 aggregate 또는 assembly라고 부르며, 다이아몬드 심볼은 PartOf 관계를 나타낸다.
1) 'is a part of' 관계가 성립할 때 - 어떤 요소는 전체의 부품이다.
2) 'is composed of' 관계가 성립할 때 - 전체 요소는 a, b, c 요소로 구성된다.
위 두 경우 aggregate를 사용한다.
어떤 것이 전체(aggregate)를 제어하거나 소유하고 있으면 그것은 부분(parts)도 제어하거나 소유한다.
즉 집합관계(aggregation)은 전체/부분 관계에서 부분 스스로도 존재할 수 있는 관계를 말하며, 흰색 다이아몬드로 표시한다.
예를 들면 자동차와 엔진, 동호회와 동호회 회원의 관계를 말한다.
Aggregation의 계층 구조는 다른 일반적인 연관관계와 달리 계층 구조로 표현할 수 있다.
🌱 Composition 관계
aggregation이 강한 관계를 말한다.
전체가 소멸되면 부품도 소멸된다.
– 내포된 의미 • Room의 한 인스턴스를 두 Building이 동시에 소유하지 못한다 • Building은 Room의 수명 전체에 책임을 진다 (Building 소멸 시 동시에 소멸됨. 복사 시 같이 복사됨.)
3. 속성 : 클래스와 그 인스턴스 안에서 정의되는 데이터를 말한다.
객체의 상태 또는 성질을 나타내는 자료값이다.
객체에 대한 정보를 나타낸다.
객체 외부에서 값을 읽어갈수도 있고(get), 변경할 수도 있다(set).
읽기 전용도 가능하다.
4. 오퍼레이션 : 클래스와 그 인스턴스에 의해 수행될 함수
박스 내에 오퍼레이션 시그니처를 사용하여 표현한다.
속성에 대한 getter(), setter(). 읽기 전용은 getter() 오퍼레이션만 존재한다.
계산을 수행하기 위한 함수이다.
오퍼레이션 signature의 표현은 위와 같다.
🌱 가시성(visibility) 속성과 오퍼레이션 앞에 가시성을 표시해야한다. 속성과 오퍼레이션 앞에 가시성(visibility) 표시 – public: ‘+’ – protected: ‘#’ – private: ‘-’
5. 일반화 : 클래스 상속 구조를 표현한다.
일반화 관계(Generalization)
일반화 : 두 가지 이상의 클래스의 공통 요소를 일반화
상세화(specialization) : 수퍼클래스의 요소를 서브클래스로 구체화
🌱 인스턴스 다이어그램
클래스의 인스턴스들 간의 관계를 표현한다.
link는 연관관계의 인스턴스.
🌱 불필요한 상속 피하기
인스턴스가 되어야 할 것을 무리하게 클래스 구조로 상속한 경우, 상속 관계 안에 있는 여러 클래스가 서로 다른 오퍼레이션을 어느정도 가지고 있어야 하나 이를 간과한 경우이다.
개선 후 클래스 다이어그램
개선 후 인스턴스 다이어그램
인스턴스는 클래스를 변경하면 안된다.
예를 들어보자.
– 문제점: 학생 인스턴스가 두 클래스 사이를 오가게 됨 (상태와 상속 이 혼동된 경우) – 해결책: 별도의 클래스 두 개를 만드는 것보다 하나의 속성을 클래스 Student에 두고 현재 상태를 표시함
📁 추상클래스
추상 오퍼레이션이란 구현이 없는 오퍼레이션을 말한다. 기능의 정의만 있고, 실제 코드로 구현된 메소드가 없다.
추상 클래스란 인스턴스가 없는 클래스를 말한다.
📁 인터페이스
인터페이스란 객체 집합이 가지는 가시적인 행위를 표현한 것이다.
클래스와 유사하지만, 인스턴스 변수와 구현된 메소드만 없다.
예를 들면 다음과 같다.
– [사례] 은행 창구 직원과 ATM • 공통 오퍼레이션을 포함, 슈퍼클래스가 다름 • 같은 상속 구조에 위치시킬 수 없음. Cashier라는 인터페이스 특징 가짐
📁 OCL(Object Constraint Language)
소프트웨어 모듈의 제약사항을 정형적으로 나타내도록 설계된 명세 언어를 말한다.
OCL은 시스템에 대한 논리적인 사실, 즉 참 값을 갖는 사실만을 나타낸다.
제약 사항에 대한 side-effect는 없다. 참이나 거짓이 아닌 결과를 낼 수 없으며, 어떤 데이터도 수정하지 않는다.
클래스 다이어그램에 표현된 OCL 문장은 속성값이 무엇인지, 연관관계가 존재해야 하는지 등에 대해 명세할 수 있다.
🌱 OCL 문장의 구성요소
– 역할 이름, 연관관계 이름, 속성, 오퍼레이션의 결과에 대한 레퍼런 스 – 논리 진위 값: true, false – 논리적 연산자: and, or, =, <, >, <>(not equal) – 문자 스트링: ‘a string’ – 정수와 실수 – 산술 연산자: +, -, *, /
🌱 OCL 사용 예시
위 예시는 다각형과 점을 나타낸 OCL이다.
📁 Notes 노트란 UML 다이어그램에 포함된 작은 텍스트블록을 말한다. 프로그래밍 언어의 주석과 같다.
