UML v1.1 개념-UML의 기본-Diagrams
|
|
그림 49 Diagram 구성도
n Diagram의 분류
그림 50 Diagram 구성도
• Structural diagrams
: 구성요소의 구조적인 형태를 보여주는 Diagram
- Class diagram
- Object diagram
- Component diagram
- Deployment diagram
그림 51 Structural diagrams
• Behaviour diagrams
: 구성요소의 행위에 대해 보여주는 Diagram
- Use Case diagram
- Activity diagram
- Statechart(State Machine) diagram
그림 52 Behaviour diagrams
• Interaction diagrams
: 구성요소간의 상호작용에 대해 보여주는 Diagram
- Sequence diagram
- Collaboration(Communication) diagram
그림 53 Interaction diagrams
: Use Case Diagram은 시스템 구축 초기에 이 시스템이 어떤 일을 하는지에 대해 사용자 입장에서 이해할 수 있을 정도로 기술하는 것이다. 이러한 Use Case Diagram은 사용자와의 대화수단으로써 앞으로 구축해 나갈 때 밑바탕이 되는 것이다.
n Use Case Diagram 구성요소
• Actor
- 시스템을 사용하는 사용자, 역할, 타 시스템 등을 표현.
• Use Case
- 시스템이 제공하는 기능.
• Relationships
- Association
• 서로 관련이 있는 Actor와 Use Case를 연결한다.
• Actor가 사용할 수 있는 Use Case를 표현한다.
• 표기법
그림 54 Use Case Association
- Generalization
• 추상적인 Actor를 구체화 하여 표현한다.
• 추상적인 Use Case를 구체화하여 표현한다.
• 표기법
그림 55 Use Case Generalization
- Include (포함관계)
• 두 개 이상의 Use Case가 공통으로 필요한 부분을 분리하여 표현한다.
• 하나의 기능을 하기 위해서는 다른 기능을 반드시 해야 하는 경우를 표현한다.
• 표기법
그림 56 Use Case Include
- Extend(포함관계)
• 기능 수행의 절차 중에서 선택적으로 수행되는 부분을 분리하여 표현한다.
• 조건에 따라 해당 기능이 수행 될 수도 있음을 의미한다.
• 표기법
그림 57 Use Case Extend
그림 58 Use Case Diagram
: 시스템 내부에 존재하는 클래스들을 선별하여 나타내고 각 클래스들의 속성과 행위를 기입한다. 클래스들 사이에 여러 가지 관계(Relationship)를 표현한다.
n Class Diagram의 용도
• Class Diagram은 시스템을 구성하는 클래스와 인터페이스의 구조, 관계를 통합하여 시스템의 정적인 부분을 모델링 한다.
그림 59 Class Diagram
: Object diagram과 Class diagram의 변형으로 class diagram과 거의 같은 표기법을 사용한다. 하지만 Class diagram과의 차이점은 표현되는 것이 클래스 대신 실제 인스턴스화 된 객체를 표현한다. 이것은 Class 다이어그램의 실행 시에 나타나는 하나의 예를 나타낸 것이다.
n Object Diagram의 용도
• Object Diagram은 어느 특정 시각에 시스템에 존재하는 객체들과 그들 사이의 관계를 표현한다.
• 특정 시각에 시스템에서
n Object Diagram의 구성요소
• 객체 (Object)
- 객체의 이름과 클래스명을 표기한다.
- 객체의 이름은 생략될 수 있으나 동일한 클래스로부터 인스턴스된 객체가 두 개 이상인 경우에는 이름을 표기하는 것이 좋다.
- 특정 시각에 객체가 갖는 속성 값을 같이 표현한다.
• 연결 (Link)
- 관련이 있는 객체를 연결 한다.
그림 60 Object Diagram
Collaboration Diagram과 함께 시스템의 동적인 면을 나타내는 대표적인 Diagram System 이다. 객체들 사이에 주고 받는 메시지를 나타내게 된다.
n Interaction Diagram
• Interaction diagram은 객체간에 연결 관계와 주고 받는 메시지를 표현한다.
• Interaction diagram의 종료로 Sequence Diagram, Collaboration Diagram이 있다.
n Sequence Diagram의 용도
• Sequence Diagram은 객체간에 주고 받는 메시지를 순서에 따라 표현한 것이다.
• 시간에 따른 메시지의 순서를 강조하여 표현 한다.
• 가로 방향으로 객체를 나열하고 세로 방향으로 메시지를 나열한다.
• 기능에 대한 흐름을 상세하게 표현하기 위해 사용된다.
n Sequence Diagram의 구성 요소
• 객체 (Object)
- Sequence에 관여하는 객체를 표현한다.
- 객체는 객체명과 클래스 명을 표기하며 둘 중 하나는 생략될 수 있다.
- 같은 클래스로부터 인스턴스된 객체가 있는 경우에는 객체명을 입력하여 구분하는 것이 좋다.
• 메시지 (Message)
- 객체간에 주고 받는 메시지와 방향을 표현한다.
- 메시지가 발생하는 순서에 따라 위에서 아래로 정렬하여 표시한다.
- 화살표로 표현하며 동기화 형태에 따라 다양한 형태로 표현된다.
• 생명선 (Life Line)
- Life Line은 객체가 살아 있는 기간을 표현한다.
- 해당 객체 밑에 수직 점선으로 표시한다.
- 도중에 객체가 Destroy될 경우 X로 표시한다.
• 제어초점 (Focus of Control) 또는 Activation
- Focus of control은 어떤 객체가 활성화 된 상태인지 표현한다.
- Life Line 위에 활성화 상태인 부분을 사각형으로 표시한다.
n Sequence Diagram 메시지종류는 동기화 형태에 따라 나눌 수 있다.
• Procedure call
- 함수 호출을 표현한다.
- 호출된 함수가 종료될 때까지 다음 메시지로 넘어가지 않음을 의미한다.
• Procedure return
- 함수의 리턴을 표현한다.
• Synchronous
- 메시지를 보내는 객체는 메시지를 받는 객체가 답변을 할 때까지 기다려야 함을 의미한다.
• Asynchronous
- 메시지를 보내는 객체는 메시지를 받는 객체의 응답을 기다리지 않고 바로 다음 메시지를 보낼 수 있음을 의미한다.
그림 61 Sequence Diagram
2.1.5. Collaboration(Communication) Diagram
: Sequence Diagram과 함께 메시지의 흐름을 나타내지만 객체와 객체들 사이의 관계 또한 표기한다.
n Collaboration Diagram의 용도
• 객체간의 관계와 주고 받는 메시지를 표현한다.
• 메시지의 순서보다는 객체간의 연결 관계와 어떤 메시지를 주고 받는가를 강조하여 표현한다.
n Collaboration Diagram의 구성요소
• 객체 (Object)
- Sequence Diagram과 같다.
• 연결 (Link)
- 메시지를 주고 받는 객체간을 실선으로 연결한다.
• 메시지 (Message)
- 객체간의 연결에 방향을 화살표로 표시하고 두 객체간에 주고 받는 메시지를 기술한다.
- 메시지의 순서는 메시지명 앞에 번호를 붙이며 번호는 단계별로 붙일 수 있다.
그림 62 Collaboration Diagram
2.1.6. Statechart(State Machine) Diagram
: 한 객체의 상태 변화를 다이어그램으로 나타낸다.
시스템 실행 시 무수한 객체의 상태 전부를 모아 다이어그램으로 나타내는 것은 불가능하므로, 특별히 관심을 가져야 할 객체에 관한, 특정 조건에 만족하는 기간 동안의 상태를 표시 한다.
n Statechart Diagram의 용도
• 이벤트에 따른 객체의 상태 변화를 나타낸다.
• 클래스, Use Case 또는 전체 시스템을 대상으로 개별 객체의 동적 측면을 모델링 한다.
n Statechart Diagram의 구성요소
• 상태 (State)
- 상태는 객체가 살아있는 동안에 가질 수 있는 어떤 조건 즉 상황이다.
- 객체는 현재의 상황에 따른 어떤 조건이 만족된 상태에 한하여 필요한 활동을 수행하게 된다.
- 시작상태(Start State)는 객체의 생성된 상태를 표현하며 객체가 처음으로 가지게 되는 상태로 자동 전이된다.
- 종료상태(End State)는 객체가 소멸된 상태를 표현한다.
• 전이 (,Transition)
- 전이는 두 상태간의 관계이다.
- 어떤 객체가 한 상태에서 다른 상태로 전환하기 위해 필요한 동작, 조건, 이벤트 등을 표현한다.
그림 63 StateChart Diagram
2.1.6.1. State
n State에는 다음과 같은 내용을 표현한다.
n name
• 상태를 구별하기 위해 이름을 부여한다.
• 이름이 없는 상태도 있을 수 있다.
n entry
• 상태에 들어올 때 수행되는 동작을 표현한다.
n exit
• 상태에 나갈 때 수행되는 동작을 표현한다.
n Internal Transition
• 현 상태에서 처리 할 수 있는 event가 발생할 경우 상태를 떠나지 않고 해당 사건을 처리하는 경우이다.
• 재귀전이인 경우에는 탈출 동작과 진입동작이 수행되지만 내부 전이는 상태를 떠나지 않으므로 이 동작을 수행하지 않는다.
n do
• 현 상태에서 수행할 동작을 표현한다.
n 하위상태
• 특정 상태에서 활동하는 작업이 또 다시 여러 상태를 가지고 있을 때 이를 표현한다.
그림 64 State
2.1.6.2. Transition
n 원래 상태
• 전이에 의해 바뀔 상태로서 전이 화살표의 시작점에 연결된 상태이다.
n Event
• 원래 상태에 있을 때 해당 전이를 유발시키는 사건.
• 필요에 따라 인자를 넘길 수 있다.
n Transition condition
• 사건이 발생 되었을 때 검토 되는 조건.
• 사건이 발생되더라도 전이조건을 만족해야 전이가 가능하다.
n Do/Action
• 전이를 할 때 수행하는 동작.
n 목표상태
• 전이가 완료된 후의 상태
: Flow Chart가 UML에 접목되어 시스템 내부에 존재하는 여러 가지 행위들, 각 행위의 분기, 분기되는 조건 등을 포함한다.
기존 Flow Chart와 다른 점은 어떤 행위에 따라 객체의 상태를 표기할 수 있다는 것인데 이것을 제외하곤 기존 Flow Chart와 표기법과 의미만 약간 다를 뿐이다.
n Activity Diagram의 용도
• Activity Diagram은 시스템의 동적인 측면을 모델링 하는 것으로 어느 문맥에서든지 사용이 가능하다.
• 대체로 전체 시스템이나, 서브 시스템, 함수, 클래스 등에서 사용한다.
• Use Case나 Collaboration Diagram에 첨부하여 동적 측면을 표현 할 수도 있다.
• Activity Diagram은 대체로 다음과 같은 구 가지 방법으로 이용한다.
- 업무흐름 모델링
• 시스템을 사용하는 행위자 관점에서 보이는 활동에 초점을 맞춘다.
• 시스템에 있는 업무 공정을 가시화, 명세화 하는 용도로 사용하여, 이런 용도로 사용할 경우에는 객체흐름(Object flow)을 표현 하는 것이 특히 중요하다.
- 자료흐름 모델링
• DFD(Data Flow Diagram)처럼 사용하여 자료 흐름을 모델링 한다.
그림 66 Data Flow Diagram(DFD)
• 이런 용도로 사용할 경우네는 프로세스를 Action state로 표현하고, 자료 흐름을 객체 흐름(object flow)으로 표현한다.
- 함수 모델링
• Activity Diagram을 Flowchart 처럼 사용하여 상세한 연산을 모델링 한다.
• 이런 용도로 사용할 경우네는 분기(branch), 분할(fork), 합류(join)를 표현하는 것이 중요하며, 함수에 전달되는 매개변수와 지역 객체들을 객체(object)로 표현하여 객체흐름을 기술한다.
n Activity Diagram의 구성 요소
• 상태 (State)
- 시작상태(Start state)
- 종료상태(End state)
- 동작상태(Action state)
- 활동상태(Activity state)
• 상태전이 (State Transition)
- Action이 완료되면 자동적으로 상태가 전이된다.
- 분할 또는 분기의 경우에는 조건이 표기된다.
• 객체 (Object)와 객체흐름 (Object Flow)
- 상태(state)간에 전달되는 자료를 객체로 표현하고, 전달 방향을 객체흐름으로 표현한다.
• 분할(for)와 합류(Join) 동기화(Synchronization)
- 동시에 진행이 가능한 상태인 경우 상태 전이를 분할하여 표시하며 분할된 상태 전이는 반드시 합류가 되어야 한다.
- 동기화는 입력 대 출력이 1:n 또는 n:1이 되어야 하며 아래의 왼쪽 그림과 같은 m:n 형태는 있을 수 없다. 이런 경우에는 우선 합류를 한 후 다시 분할을 하도록 한다.
그림 67 Synchronization
• 분기 (Branch)
- 조건에 따라 여러 가지의 흐름 중 하나를 실행 하는 것을 표현한다.
- 분기된 각 흐름에는 조건을 표시한다.
- 분기된 흐름은 다시 분기 기호를 사용하여 합치도록 표현한다.
• 구획선 (Swimlane)
- Activity Diagram의 각 Activity를 실행하는 주체를 표현한다.
- Swimlane을 사용하여 화면을 분할한다. 이렇게 나누어진 것을 구획면이라 한다.
- 각 구획면에 이름을 붙이고 Activity를 해당 구획 면에 배치한다.
- Activity는 하나의 구획면에만 속할 수 있다.
- 구획면은 해당 구획면에 있는 각 Activity를 수행하는 주체가 된다.
- 구획면의 이름은 Actor 또는 Class가 될 수 있고, 궁극적으로는 클래스로 구현된다.
그림 68 Activity Diagram
: Component Diagram은 소프트웨어의 물리적 단위(exe, dll등 library)의 구성과 연결상태를 표현한다.
n Component의 종류
• Component란 시스템을 구성하는 물리적인 단위를 의미하며 다음과 같이 세 종류로 분류 할 수 있다.
• 배치 컴포넌트 ( Deployment Component)
- DLL, 실행파일 등과 같이 실행 가능한 시스템 구성 요소
- 동적 웹 페이지, DB 테이블 등도 포함됨
• 작업 결과물 컴포넌트 (Work Product component)
- 시스템의 실행에 직접적으로 참여하지는 않지만, 개발 작업에서 만들어지는 결과물들이며 실행 시스템을 생성하는데 사용됨
- 분석/설계 문서, 소스코드 파일, 데이터 파일
• 실행 컴포넌트 (Execution component)
- 실행 시스템의 수행결과로 생성되는 컴포넌트
- 메모리상에 존재하는 객체, 실행 결과로 생성된 DB 레코드 또는 파일 등
n Component Diagram의 구성요소
• 컴퍼넌트 ( Component )
- 시스템을 구성하는 물리적 구성 단위를 표현한다.
• 의존 ( Dependency )
- 컴포넌트들 간의 의존관계 또는 컴포넌트와 클래스 간의 의존 관계를 표현한다.
- EXE 파일이 실행할 때 DLL 파일을 필요로 할 경우에 이들간에 의존 관계를 표현한다.
- EXE 또는 DLL을 구현 할 때 사용된 클래스와 의존 관계를 표현한다.
• 클래스 ( Class )
- EXE 또는 DLL을 구현한 클래스를 표현할 때 사용한다.
• 인터페이스 ( Interface )
- 컴포넌트가 구현하는 인터페이스를 표현할 때 사용한다.
• 실체화 ( Realization )
- 컴포넌트와 인터페이스의 관계를 표현한다.
n Component와 Class
• Component Diagram은 시스템의 물리적 구성 요소를 여러 관점으로 표현하며 관점에 따라 구성 요소가 달라진다.
• Component Diagram ( Component 와 class )
그림 69 Component 와 Class
n Component와 Interface
• Component가 실체화(realize) 하고 있는 인터페이스를 Realization으로 표현한다.
• Component가 사용하는 Interface를 dependency로 표현한다.
• 인터페이스를 표현하는 방법은 아이콘 형태로 표현하는 방법과 확장 형태로 표현하는 방법이 있다.
• Component가 어떤 Interface를 제공하는가 또는 어떤 인터페이스를 필요로 하는가를 표현하기 위한 방법으로 사용한다.
그림 70 Component 와 Interface
n 실행파일과 관련자료
• 시스템이 다수의 실행파일과 이에 연관된 라이브러리, 도움말, init파일, 테이블 등으로 구성되는 경우 Component Diagram을 통하여 물리적인 시스템을 모델링 한다.
• Component Diagram은 버전관리와 형상관리를 하는데도 유용하게 사용된다.
그림 71 실행파일과 관련자료
그림 72 Component Diagram
n 소스코드
• 소스코드 간의 컴파일 의존성을 표시하고, 형상관리를 위한 버전 표시한다.
• 소스코드가 디렉토리로 나누어져 저장되어 있을 경우 Package로 표현한다.
그림 73 소스코드
: Deployment Diagram은 실제 하드웨어적인 배치와 연결상태를 나타낸다.
n Deployment Diagram 구성 요소
• 노드 (Node)
- 노드는 물리적인 요소로서 시스템이 실행 될 때 존재하며 어느 정도의 메모리와 처리 능력을 갖는 전산 자원을 의미한다.
- 노드는 육면체로 표현하며 이름을 표기하고 필요에 따라 탑재되는 컴포넌트를 표기한다.
- 노드의 성격을 잘 표현할 수 있는 이미지를 사용하여 표현할 수도 있다.
• 연결 (Link)
- 물리적으로 연결되어 있는 두 노드의 연결 관계를 표현한다.
- 연결의 특성을 stereotype으로 표현한다.
• 컴포넌트 (Component)
- 노드에 탑재되는 컴포넌트를 표현하기 위해 사용한다.
• 의존 (Dependency)
- 노드와 컴포넌트는 의존 관계로 연결한다.
그림 74 Deployment Diagram
|
|
'UML' 카테고리의 다른 글
| 소프트웨어 아키텍처가 되는 길 (0) | 2016.09.13 |
|---|---|
| UML v1.1 개념-Development Process (0) | 2013.05.19 |
| UML v1.1 개념-UML의 기본-Extensibility mechanism (0) | 2013.05.19 |
| UML v1.1 개념-UML의 기본-관계(Relationships) (0) | 2013.05.19 |
| UML v1.1 개념-UML의 기본-Things (0) | 2013.05.19 |
