1. UML
•
UML이란 Unified Modeling Language의 약자로 1997년 OMG(Object Management Group)에서 표준으로 채택한 통합모델링언어
•
즉, 모델을 만드는 표준언어
•
모델이란 것은 어떤 것을 실제로 만들 때 이렇게 만들면 잘 작동할지 미리 검증해 보는 것
2. UML을 사용하는 유형
1.
다른 사람들과의 의사소통 또는 설계 논의
2.
전체 시스템의 구조 및 클래스의 의존성 파악
3.
유지보수를 위한 설계의 back-end 문서
•
UML을 그리는데 가장 좋은 도구는 종이와 펜이라는 말이 있듯이 습관적으로 만드는 게 아니라 필요에 의해 만드는 것이 가장 좋은 것 같습니다.
3. Class Diagram (클래스 다이어그램)
•
UML은 구조 다이어그램 7개, 행위 다이어그램 7개로 총 14종류의 다이어그램이 있습니다.
•
구조 다이어그램은 시스템의 개념, 관계 등의 측면에서 요소들을 나타내고 각 요소들의 정적인 면을 보기 위한 것이고 행위 다이어그램은 각 요소들 혹은 요소들간의 변화나 흐름, 주고받는 데이터 등의 동작을 보기 위한 것으로, 클래스 다이어그램은 구조 다이어그램에 해당합니다.
•
클래스 다이어그램은 클래스 내부의 정적인 내용이나 클래스 사이의 관계를 표기하는 다이어그램으로 시스템의 일부 또는 전체의 구조를 나타낼 수 있습니다.
•
클래스 다이어그램은 의존 관계를 명확히 보게 해주며, 순환 의존이 발생하는 지점을 찾아내서 어떻게 이 순환 고리를 깨는 것이 가장 좋은지 결정할 수 있게 해줍니다.
4. 클래스 다이어그램의 요소(Element)
클래스 Class
•
클래스는 보통 3개의 compartment(구획)으로 나누어 클래스의 이름, 속성, 기능을 표기합니다.
•
속성과 기능은 옵션으로 생략이 가능하지만 이름은 필수로 명시해야 합니다.
•
클래스의 세부사항들을 상세하게 적는 것이 유용할 때도 있지만, UML 다이어그램은 필드나 메서드를 모두 선언하는 곳이 아니기 때문에 다이어그램을 그리는 목적에 필요한 것만 사용하는 것이 좋습니다.
Stereo Type (스테레오 타입)
•
스테레오 타입이란 UML에서 제공하는 기본 요소 외에 추가적인 확장요소를 나타내는 것으로 쌍 꺾쇠와 비슷하게 생긴 길러멧(guillemet, « ») 사이에 적습니다.
•
이 길러멧이란 기호는 쌍 꺾쇠와는 좀 다른 것으로 폰트 크기보다 작습니다. 종이나 화이트보드에 그릴 때는 상관없지만 공식적인 문서라면 이 기호를 구분해서 사용하는 것이 좋을 것 같습니다.
Abstract Class/Method (추상 클래스 / 메서드)
•
추상클래스란 1개 이상의 메서드가 구현체가 없고 명세만 존재하는 클래스를 말합니다.
•
추상 클래스의 이름과 메서드는 italic체나, {abstract} 프로퍼티를 사용하여 표기합니다.
•
UML 툴에서는 italic체로 표기하는 것이 많지만 종이나 칠판에 그릴 때는 힘들게 italic체로 기울여서 적는 것 보다는 {abstract} 프로퍼티로 표기하는 것이 쉽고 명확할 것 같습니다.
•
또한 공식적인 것은 아니지만 스테레오타입을 사용하여 추상 클래스를 표기하기도 합니다.
5. 클래스간의 관계
•
클래스 다이어그램의 주 목적은 클래스간의 관계를 한눈에 쉽게 보고 의존 관계를 파악하는 것에 있습니다.
•
그렇기 때문에 클래스 다이어그램에서 가장 중요한 것이 클래스간의 관계입니다.
01. 상속 (Inheritance) / 일반화라고도 합니다. (Generalization)
•
Generalization은 슈퍼(부모)클래스와 서브(자식)클래스간의 Inheritance(상속) 관계를 나타냅니다.
•
여기서 Generalization이란 서브 클래스가 주체가 되어 서브 클래스를 슈퍼 클래스로 Generalize 하는 것을 말하고 반대의 개념은 슈퍼 클래스를 서브 클래스로 Specialize(구체화) 하는 것입니다.
•
상속은 슈퍼 클래스의 필드 및 메서드를 사용하며 구체화 하여 필드 및 메서드를 추가 하거나 필요에 따라 메서드를 overriding(오버라이딩) 하여 재정의 합니다.
•
또는 슈퍼 클래스가 추상 클래스인 경우에는 인터페이스의 메서드 구현과 같이 추상 메서드를 반드시 오버라이딩 하여 구현하여야 합니다. (Java에서는 extends로 상속)
02. 인터페이스 구현 (Interface Implimentation) / 실체화라고도 합니다. Realization (실체화)
•
Realization은 interface의 spec(명세, 정의)만 있는 메서드를 오버라이딩 하여 실제 기능으로 구현 하는 것을 말합니다.
•
Realization을 나타내는 표기법은 2가지가 있습니다.
•
첫 번째는 인터페이스를 클래스처럼 표기하고 스테레오 타입 «interface»를 추가합니다.
•
그리고 인터페이스와 클래스 사이의 Realize 관계는 점선과 인터페이스 쪽의 비어있는 삼각형으로 연결합니다. 두 번째는 인터페이스를 원으로 표기하고 인터페이스의 이름을 명시합니다.
•
그리고 인터페이스와 클래스 사이의 관계는 실선으로 연결합니다.자바에서는 위와 같이 implements 키워드를 사용하여 인터페이스를 구현합니다.
03. 연관 (Association)
•
연관 관계(Association)는 서로 상대를 알고 명령할 수 있는 관계
•
한 클래스가 다른 클래스를 사용한다.
•
각각 독립적으로 생성되고 연결이 될 수도, 연결이 되지 않을 수도 있다.
•
그래서 프로그램에서 위험한 관계이며 다른 안전한 관계로 바꿀 것은 권합니다.
ex)
class Car --------- class Person
class Car {
private:
Person person;
public:
setPerson(Person _p){
this.person = _p;
// setPerson 메소드를 호출해서 사용
}
}
C++
복사
04. 집합 (Aggregation)
•
Aggregation은 Shared Aggregation이라고도 하며 Composition(Composite Aggregation)과 함께 Association 관계를 조금 더 특수하게 나타낸 것으로 whole(전체)와 part(부분)의 관계를 나타냅니다. Association은 집합이라는 의미를 내포하고 있지 않지만 Aggregation은 집합이라는 의미를 가지고 있습니다.
•
Aggregation은 Shared Aggregation이라고도 하며 Composition(Composite Aggregation)과 함께 Association 관계를 조금 더 특수하게 나타낸 것으로 whole(전체)와 part(부분)의 관계를 나타냅니다.
•
Association은 집합이라는 의미를 내포하고 있지 않지만 Aggregation은 집합이라는 의미를 가지고 있습니다.
•
Aggregation 관계로 표현되는 전체 객체의 생성 시기가 꼭 동일할 필요는 없다. 소멸시에도 Aggregatin 관계의 클래스들이 다른 객체에 의해 공유될 수도 있다.
•
컬렉션과 원소 사이의 관계입니다. “필통은 연필과 지우개 등을 가지고 있다.” 처럼 “가지고 있다.” 혹은 “가질 수 있다.”로 표현할 수 있는 형식 사이의 관계입니다.
class Car <>------------ class Engine
class Car{
private:
Engine engine;
public:
Car(Engine _e){
this.engine = _e;
// 생성자의 매개 변수로 들어온 놈이
// 꼭 Car과 같이 생성될 필요는 없으며
// 외부에서 생성된 Engine은 다른 객체에서도
// 사용되고 있을 수도 있다.
}
};
C++
복사
05. 구성 (Composition)
객체의 생성과 소멸 시기가 동일하다.
즉 Car 클래스 생성자 내에서 Engine 클래스를 생성한다.
class Car <<>>------------- class Engine
class Car{
private:
Engine engine;
public:
Car(...){
this.engine = new Engine( ... );
}
};
C++
복사
06. 의존 (Dependency)
•
Dependency는 클래스 다이어그램에서 일반적으로 제일 많이 사용되는 관계로서, 어떤 클래스가 다른 클래스를 참조하는 것을 말합니다.
•
위의 그림은 자바에서 참조하는 형태에 대해 코드를 보여주고 있습니다.
•
참조의 형태는 메서드 내에서 대상 클래스의 객체 생성, 객체 사용, 메서드 호출, 객체 리턴, 매개변수로 해당 객체를 받는 것 등을 말하며 해당 객체의 참조를 계속 유지하지는 않습니다.
•
원본 개체의 변화에 따라 의존 개체도 변화하는 형식 사이의 관계
•
회원 정보가 바뀌면 회원 컨트롤에 표시한 정보를 변경한다.
•
그리고 어떠한 형식 개체를 생성하는 책임을 갖고 있을 때도 의존 관계로 표시합니다.
Car - - - - - - - - - > Aircon
class Car{
...
public:
void Air( Aircon con){
con.turnOn();
// Aircon 클래스를 인자로 받아 메소드를 내부적으로 호출한다.
// Aircon 의 turnOn 의 정의가 바뀌면
// Car 에 영향을 주게 되므로 의존 관계에 있다고 말한다.
}
};
C++
복사