UML(Unified Modeling Language)는 시스템을 객체지향적(Object-Oriented)으로 분석(Analysis) 및 설계(Design)를 하기 위한 언어이다. 이 언어는 어떤 시스템의 상세(SPECIFICATION)를 만들고 시각화(VISUALIZATION)하고 문서화(DOCUMENTATION)하는데 도움이 된다.
Use case diagram
시스템이 무엇을(WHAT) 하느냐를 기술한다. 그러나 어떻게(HOW) 하느냐를 기술하는 것은 아니다.
액터(ACTOR)는 시스템과 상호작용(INTERACTION)하면서 이벤트를 발생시키는 주체이며, 액터는 사람(USER)일 수도 있고, 사물(THING)일 수도 있고 다른 시스템(OTHER SYSTEM)일 수도 있다. 유스케이스(USECASE)는 액터가 사용하는 시스템기능에 대한 서술이다. 액터와 유스케이스들 사이에는 관계(ASSOCIATION)가 맺어진다. 하나의 액터는 다수개의 유스케이스와 관계를 맺을 수 있으며, 하나의 유스케이스도 다수개의 액터와 관계를 맺을 수 있다.
유스케이스끼리도 관계를 맺을 수 있다. 첫째, 하나의 유스케이스는 다른 유스케이스의 일종일 수 있는데, 이들은 일반화관계(GENERALIZATION)로 표시되며 is a kind of의 관계가 있다. 둘째, 여러 개의 유스케이스들은 수학에서의 공약수처럼 공통된 하나의 유스케이스를 포함할 수 있는데, 이들은 포함관계(INCLUDE) 관계로 표시된다. 셋째, 하나의 유스케이스는 다른 유스케이스의 변종일 수가 있는데, 이들은 확장관계(EXTEND) 관계로 표시된다.
유스케이스가 많이 존재하는 그림에서는 복수개의 유스케이스를 하나의 시스템영역으로 묶을 수 있으며, 이때 시스템에는 고유한 이름이 붙여진다.
유스케이스 기술서(DESCRIPTION)를 통해서 한 유스케이스가 어떠한 이벤트들의 흐름을 가질 수 있으며, 하부흐름(SUBFLOW) 또는 다른 흐름(ALTERNATIVE FLOW) 등도 가질 수 있다는 것을 표현한다.
유스케이스는 요구사항(REQUIREMENT)을 기술하는데 도움이 되는 그림이며, 이 그림을 바탕으로 사용자, 설계자, 개발자, 테스트 팀 모두가 의사소통을 하는 도구가 된다.
Class diagram
시스템에서 발생할 수 있는 클래스들과 그 클래스들간의 관계를 표현하는 그림이다. 이는 유스케이스와 달리 시스템의 정적인 표현이다.
클래스는 클래스명(CLASS NAME), 속성들(ATTRIBUTES), 그리고 오퍼레이션들(OPERATIONS)을 가진다. 클래스의 속성과 오퍼레이션들은 그 보안레벨에 따라 PUBLIC, PRIVATE, PROTECTED 등으로 구분될 수 있다. 각 속성은 데이터타입(예, Date 등등)을 지정할 수도 있고 제약조건(CONSTRAINT)을 지정할 수도 있다. (예, {A,B,C}) 각 오퍼레이션들에는 시그니처(SIGNATURE)를 지정할 수 있는데, 시그니처란 INPUT PARAMETER, INPUT PARAMETER의 DATATYPE, 오퍼레이션의 RETURN DATATYPE을 의미한다.
클래스간의 관계(ASSOCIATION)는 관계명(ROLE NAME)과 방향성(NAVIGABILITY), 관계수(MULTIPLICITIES), 제약조건(CONSTRAINT)을 가진다.
관계수는 n..m (n>=0,n<m) 또는 그냥 n (n>=1)으로 표시될 수 있는데, n..m 관계는 n개에서 m개까지의 관계를 맺을 수 있다는 것을 의미하고 이때 m은 정해진 개수가 아니라 그냥 MANY를 의미하면 *(ASTERISK) 로 표현할 수 있다. 관계수가 n으로 표시되는 것은 정확히 n개의 관계를 맺어야 한다는 것을 의미한다.
제약조건은 그 조건을 만족하는 경우에만 관계가 의미가 있다는 뜻이다. 배타적(EXCLUSIVE) 관계도 제약조건을 이용하여 표시된다.
관계에는 크게 ASSOCIATION, AGGREGATION, GENERALIZATION, DEPENDENCY의 4가지 타입이 있다.
ASSOCIATION 관계는 클래스가 다른 클래스와 관계를 맺고 있다는 뜻인데, 이 관계는 인스턴스를 생성시켜서 이용하고 이용당하는 관계, 또는 메시지를 주고 받는 관계 등을 말한다.
ASSOCIATION 관계는 방향성(NAVIGABILITY)을 가질 수 있는데, 한 클래스와 다른 클래스의 관계가 쌍방향이 아닌 단방향인 경우에 NAVIGABLE한 ASSOCIATION 관계가 된다.
AGGREGATION 관계는 여러 클래스가 집합(COLLECTION)으로 모여서 하나의 클래스를 이루고 있다는 관계를 표현한다. 그래서 한 클래스는 다른 클래스의 is-a-part-of의 관계에 있다. 예를 들어 자동차라는 클래스는 핸들, 바퀴, 샤시, 윈도우 등의 클래스들과 AGGREGATION 관계를 맺을 수 있다. AGGREGATION 관계는 이미 “has” 또는 “contains” 의 의미를 가지므로 관계명(ROLE NAME)을 정의하지는 않는다. 그러나 관계수(MULTIPLICITIES)는 지정할 수 있다.
AGGREGATION과 유사한 집합관계로서 COMPOSITION 관계가 있는데, 이는 한 클래스는 다른 클래스에 속하는데 그 클래스 없이는 존재할 수 없는 밀접한(STRONG) 집합관계를 맺고 있음을 의미한다.
GENERALIZATION 관계는 한 클래스는 다른 클래스의 서브관계로서 상속을 받음을 의미한다. 그래서 한 클래스는 다른 클래스의 is-a-kind-of의 관계에 있다. 예를 들어 자동차라는 클래스는 승용차, 트럭, 버스 등의 클래스들과 GENERALIZATION 관계를 맺을 수 있다.
DEPENDENCY 관계는 한 클래스가 변경되면 다른 클래스도 따라서 변경될 가능성이 있는 관계를 의미한다. 대개는 한 클래스가 다른 클래스의 오퍼레이션의 파라메터로 사용되는 경우에 DEPENDENCY 관계가 맺어질 수 있다.
클래스와 다른 클래스간에 맺고있는 ASSOCIATION 관계 자체가 하나의 클래스를 형성할 수 있는데 이를 ASSOCIATION 클래스라고 한다. 대개 관계수가 양쪽 다 MANY에 해당되는 경우에 이 클래스가 나올 수 있다.
인터페이스(INTERFACE)는 클래스 또는 시스템을 외부에서 어떻게 사용할 수 있는가를 정의하기 위한 오퍼레이션들의 집합으로 정의한다. 이 오퍼레이션들을 클래스가 실제로 구현을 하게 되는데 인터페이스와 구현되는 클래스는 실체화(REALIZATION)관계를 맺는다. 인터페이스는 스테레오타입(STEREOTYPE)으로 표시되며, 그 이름은 I라는 대문자로 시작된다.
클래스 다이어그램은 시스템을 정적(STATIC)으로 표현해주는 그림이다.
Package diagram
서로 연관성이 있는 클래스들을 사각형으로 묶을 수 있는데 이를 패키지라 한다. 패키지는 패키지명을 가진다. 한 패키지에 속한 클래스는 다른 패키지에 속한 클래스와 DEPENDENCY 관계를 맺을 수도 있는데, 이러한 경우에는 패키지간의 DEPENDENCY 관계가 된다.
Object diagram
클래스간에 순환(RECURSIVE) 관계 등 복잡한 관계를 맺고 있을 때, 클래스 다이어그램의 이해를 돕기 위해서 클래스의 인스턴스(INSTANCE)를 그림으로 표현한다. 인스턴스명:클래스명이 밑줄쳐진(UNDERLINE) 상태로 이름이 표현되며, 인스턴스간에는 일반적인 ASSOCIATION 관계가 맺어진다.
따라서 클래스 다이어그램은 오브젝트 다이어그램의 추상화(ABSTRACTION)된 그림이라고 할 수 있다. 오브젝트 다이어그램도 클래스 다이어그램과 마찬가지로 시스템을 정적(STATIC)으로 표현하는 그림이다.
Sequence diagram
객체들간의 동적인 상호관계를 시간의 흐름순서에 따라 보여준다. 상호작용을 하는 객체는 액터일 수도 있고, 클래스의 인스턴스일 수도 있다. 각 객체들은 메시지를 주고 받으면서 호출하는데 객체는 자기 자신에게 메시지를 던져 호출할 수도 있다. 메시지들은 시간 순으로 정렬되어진다.
객체는 다른 객체들에게 비동기적(ASYNCHRONOUS) 메시지를 보낼 수 있으며 이는 반쪽 화살촉을 가지는 화살표로 그린다. 메시지들이 비동기적 관계에 있으면 그 메시지들은 시간에 관계없이 보내어지고 받을 수 있다는 것이다.
하나의 유스케이스의 복수개의 시나리오를 가질 수 있는데, 각 시나리오별로 시퀀스 다이어그램이 하나씩 그려질 수 있다. 시퀀스 다이어그램은 시스템을 동적으로 표현해주는 그림이다.
Collaboration diagram
상호협동 다이어그램은 시퀀스 다이어그램과 비슷한 의미를 제공하는 그림이다. 그러나 여기에서는 시간에 따른 정렬보다는 객체의 역할(ROLE)에 비중을 두어서 그리는 그림이다. 그리고 각 메시지에는 일련번호를 부여할 수 있다.
이 다이어그램도 시퀀스 다이어그램과 마찬가지로 시스템을 동적으로 표현하는 그림이다.
Statechart diagram
상태 다이어그램은 객체가 생성되어서 소멸되기까지 다른 객체와의 상호작용에 의해 그 객체의 상태가 변화되어가는 것을 표현한 그림이다. 한 순간에 어떤 상태에 머물러있는 객체에 특정 이벤트(EVENT)가 발생되면 다른 상태로 전이하는 것을 화살표로 표현하는데 상태가 전이되기 위한 조건(CONDITION)이 있을 수 있다.
각 상태(STATE)는 중복되지 않아야 한다. 즉, 한 객체는 한 순간에 하나의 상태에 머물러 있어야 한다. 그러나 여러 개의 연관성 있는 상태들을 모아서 하나의 복합상태(COMPOSITE STATE)를 만들 수는 있다.
Activity diagrams
액티비티 다이어그램은 상태 다이어그램과 유사한 기능을 하지만, 상태 다이어그램은 한 객체의 상태에 초점을 맞추는 것이고 액티비티 다이어그램은 객체가 수행하는 행동에 초점을 맞추는 것이다.
객체가 행동을 수행할 때에는 다른 객체에 메시지가 전달되어 그 객체의 행동을 유발시킬 수도 있다. 따라서 액티비티 다이어그램은 한 프로세스(PROCESS)의 시작부터 종료까지 여러 객체들이 어떤 행동들을 하는가를 표현하는 그림이다.
Component diagrams
컴포넌트란 클래스가 실제 구현되어져 나오는 결과물을 얘기하는 것으로 소스코드, 실행코드, 라이브러리 등을 말한다. 컴포넌트 다이어그램은 구현되어진 모듈들의 이름이나 의존관계 등을 표현한다.
Deployment diagrams
배치 다이어그램은 시스템의 하드웨어 또는 소프트웨어의 물리적인 구조를 보여준다.
ER Diagram vs. Class Diagram
* class와 method의 정의
class가 가질 수 있는 attribute 뿐만 아니라 method까지 동시에 정의할 수 있다.
* Relationship의 cardinality
UML모델링에서는 cardinality를 정확하게 지정할 수 있다.
예를 들어 각 회원은 인증문답을 3개까지만 지정할 수 있다는 biz rule이 있다고 가정하면,
이 rule을 UML에서는 명확하게 표현할 수 있지만 ERD에서는 단순히 one-to-many로만 표현한다.
[출처 : http://iclickyou.com/1340]