소프트웨어에서, 모델링을 시작하는 일반적인 방법은 알고리즘 관점과 객체지향관점이라고 할 수 있다. 알고리즘 관점에서는 모든 소프트웨어를 이루는 주요 기본요소가 프로시저 또는 함수인데 이는 요구사항이 변하고 시스템이 커지면 유지보수가 용이하지 않다고 볼 수 있고, 객체지향 관점에서는 객체 또는 클래스가 주요 기본요소로 사용되어 개발하는데 있어 컴포넌트로 시스템을 바라볼 수 있도록 하여 용이한 유지보수와 신속한 개발을 유도한다.
이러한 객체지향시스템을 가시화하고, 명세화하고, 구축하고, 문서화하는데 UML(Unified Modeling Language)이 사용된다
Unified Modeling Language의 약자로 객체지향 분석(Analysis)과 설계(Design)를 위한 modeling Language이다. 이는 Booch, Rumbaugh(OMT), Jacobson등의 객체지향 방법론(methods)에 관한 석학들이 내어놓은 방법론의 통합으로 이러한 방법론의 명맥을 잇는다고 볼 수 있다. 또한 객체 기술에 관한 국제 표준화 기구인 OMG(Object Management Group)에서 이미 UML을 표준화로 인정했으며 현재 ver1.4까지 릴리스되어 있다.
- Things(사물)
- Structural things(구조사물)
- class : 동일한 속성, 오퍼레이션, 관계, 의미를 공유하는 객체들을 기술
- interface : 클래스 또는 컴포넌트의 서비스를 명세화하는 오퍼레이션의 집합
- collaboration : interaction(교류)를 정의하며 서로 다른 요소와 역할들이 모여 있다.
- use case : 시스템이 수행하는 순차적 활동들을 기술하며 특정 행위자(Actor)에게 주목할 만한 결과치를 준다.
- active class : 객체가 하나 또는 그 이상의 프로세스나 스레드를 갖는 클래스이며 객체들의 행동이 다른 요소들과 함께 동시적으로 이루어진다.
- component : 시스템의 물리적이고 대체 가능한 부분이며 인터페이스를 준수,구현한다. 클래스, 인터페이스, 협력과 같은 서로 다른 논리요소를 물리적으로 패키지화 한 것을 나타낸다.
- node : 실행시에 존재하는 물리적요소이며 전산자원을 나타낸다.
- Behavioral things(행동사물)
- interaction : 지정된 목적을 완수하기 위해서 특정 문맥을 속한 객체들 간에 주고 받는 메시지들로 구성
- state machine : 상태의 순서를 지정하는 행동이며, 하나의 객체 혹은 하나의 interaction은 그들의 생명주기 중에 각종 event에 대한 응답과 함께 이들 state를 거쳐간다.
- Grouping things(그룹사물)
- package : 요소를 그룹으로 묶는 다목적 메커니즘. Structural things, Behavioral things, 다른 Grouping things까지도 하나의 패키지 내에 둘 수 있다.
- Annotational things(주해사물)
- note : 하나의 요소 또는 요소들로 된 공동체에 첨부되는 제약과 주석을 나타내는 기호이다.
- RelationShips(관계)
- dependency : 두 사물간의 의미적 관계로서, 한쪽 사물(독립 사물)의 변화가 다른 사물(종속 사물)에 영향을 줄 수 있는 관계이다.
- association : 구조적 관계로서, 링크(link)의 집합을 나타낸다.aggregation 은 전체와 부분간의 구조적 관계를 나타낸다.
- generalization : specialization/generalization 관계로서 일반화된 요소 (부모:parent)의 객체를 특수화된 요소 (자식:child)의 객체로 치환할 수 있는 관계이다.
- realization : classifier간의 의미적 관계인데 인터페이스와 이를 실현하는 클래스나 컴포넌트 사이에서 use case와 그것을 실현하는 collaboration사이에서 볼 수 있다.
- Diagrams(도해)
- Use Case Diagram : Use Case, Actor와 그들간의 관계들을 나타낸다. 시스템의 정적 Use Case View를 다룬다.
- Class Diagram : class, interface, collaboration 간의 관계들을 나타내며 객체지향 시스템 모델링에서 가장 공통적으로 쓰이는 Diagram이다. Class diagram의 경우 여러가지 객체들의 타입, 즉 클래스들을 표현하고 그 클래스들의 정적인 관계(associated, dependent, specialized, packaged)를 표현한다. 이러한 정적인 요소는 시스템의 life cycle과 수명을 같이하며 하나의 시스템은 여러 개의 class diagram으로 표현이 가능하다.
- Object Diagram : 객체와 그들간의 관계들을 나타낸다. Class Diagram에 있는 사물들의 인스턴스에 대한 정적 스냅 샷을 나타낸다. Class Diagram과 같은 표기법을 사용한다.
- Interaction Diagram : 객체와 그들의 관계, 그리고 그들간에 보낼 수 있는 메시지들로 구성되는 interaction을 나타낸다. Interaction Diagram은 시스템의 동적View를 다룬다. Interaction Diagram은 Sequence Diagram과 Collaboration Diagram으로 구성되는데 Sequence Diagram은 메시지의 시간적 순서를 강조하며 Collaboration Diagram은 메시지를 주고 받는 객체의 구조적 구성을 강조한다.
- StateChart Diagram : StateMachine을 나타내며, StateMachine은 State, Transition, Event, Activity로 구성된다. 시스템의 동적View를 다룬다. 인터페이스, 클래스 또는 협력의 행동을 모델링하는데 중요하며 사건에 따라 순차적으로 일어나는 객체 행동에 중점을 두기 때문에 빠른 반응이 필요한 시스템을 모델링할 때 중요하다.
- Activity Diagram : 특별한 종류의 상태도로서 시스템 내부에 있는 활동간의 흐름을 나타낸다. 시스템의 동적 View를 다루며, 시스템 기능 모델링시 중요하고, 객체간의 제어 흐름에 중점을 둔다.
- Component Diagram : 컴포넌트간의 구성과 의존 관계를 나타내며, 시스템의 정적 구현 View를 다룬다. 클래스도와 관련이 있는데, 일반적으로 하난의 컴포넌트는 클래스도에 있는 하나 또는 그 이상의 클래스, 인터페이스, 협력들과 대응된다.
- Deployment Diagram : 실행시 처리하는 노드와 그 노드에 있는 컴포넌트들의 구성을 나타내며, 아키텍쳐의 정적 배치 View를 다룬다. Deployment Diagram은 Component Diagram과 관련이 있는데 일반적으로 하나의 노드는 컴포넌트도에 있는 하나 또는 그 이상의 컴포넌트를 수용하기 때문이다.
|
UML 개요