UML 과 방법론의 차이

좋은 글을 읽으면 한번씩 정리해보는 것도 좋쿠나

http://blog.naver.com/PostView.nhn?blogId=bumwoo80&logNo=140843471

 

 

1.     UML 과 방법론의 차이

UML 의 구성을 알아보기에 앞서 먼저 UML과 방법론의 차이를 알아야 한다.
방법론이란 말 그대로 어떠한 작업을 할 때 이러저러한 절차를 가지고 작업을 하면 된다 라고 하는 것을 이론적으로 정립을 하여놓은 것이다.
소프트웨어 공학에서 많은 방법론이 있어왔고, 현재도 수많은 방법론이 존재한다.
사실 프로그램을 하는 모든 사람은 나름대로 방법론을 가지고 있다. 그러한 나름의 방법론이 작업을 얼마만큼 효과적으로 만드는지에 따라 좋은 방법론인지 아닌지 결정 날 것이다.
그럼 UML은 무엇인가? UML은 이러한 방법론을 적용할 때의 결과물을 나타내기 위한 도구이다.
예를 들면 모든 소프트웨어를 설계 할 때 어떠한 표준적인 규칙을 가지고 설계도를 그려야 한다.
이때 설계의 표준이 되는 것이 UML 이다.
건축도면에서 나오는 건물 내부의 여러 가지 표준적인 표기를 보면 될 것이다. 즉 각자 다양한 방법론을 자기의 프로젝트에 적용하더라도 UML을 공통적으로 적용할 수 있다.

 

2. UML의 구성

전체 UML은 8가지의 다이어그램으로 나타난다. 시스템의 정적인 면을 나타내는 클래스 다이어 그램, 동적인 면을 나타내는 콜레버레이션 다이어그램 , 시퀀스 다이어그램, 상태 다이어그램 , 액티비티 다이어그램, 디플로이먼트 다이어그램, 컴포넌트 다이어 그램 으로 구성되어 있다.
이외로 유스케이스 다이어 그램이 존재 한다.
유스케이스 다이어그램을 두 부류로 나누지 않은 이유는 다른 모든 다이어그램을 그리기 위해 기반이 되는 다이어 그램이기 때문이다.

 

A.     Usecase diagram

Usecase Diagram은 Usecase를 그려놓은 Diagram이다. 여기서 Usecase란 말 그대로 컴퓨터 시스템과 사용자가 상호작용을 하는 경우이다.
예를 들어 보험처리 프로그램의 경우 “고객이 보험증권에 싸인 한다.” , “보험 판매원이 판매통계량을 종합한다.” 등이 usecase 가 된다.
이러한 Usecase Diagram은 시스템 구축의 초기에 이 시스템이 어떤 일을 하는지에 대한 부분을 사용자 입장에서 이해할 수 있을 정도로 기술해야 한다.
이러한 Usecase Diagram은 사용자와의 대화수단으로 그리고 앞으로 구축해 나갈 때의 밑바탕이 되는 것이다.

B.      Class Diagram

Class Diagram의 경우 시스템 내부에 존재하는 Class들을 선별하여 나타내고, 각 Class들의 Attribute 와 behavior 를 기입한다. 여기서 Class들 사이에 여러 가지 relationship을 가질 수 있다.
예를 들어 연관관계(Association, 연관,연산,연합)은 Class와 Class가 어떠한 연관을 가지고 있음을 나타내고 여기서 세부적으로 복잡연관(Composition,구성) 과 집합 연관관계(Aggregation, 집합,응집) 등으로 나뉘어 질 수 있다. 이외에 상속관계(Generalization,일반화) , 의존관계(Dependency)가 나타날 수 있다.
Class Diagram을 그리고자 할 때 항상 추상화 단계를 고려하여서 그리도록 하여야 할 것이다. 추상화의 단계가 높은 경우 대충의 속성과 행위를 기입하고 대충의 관계를 기입하여도 충분할 것이다. 이 단계에서 너무 상세한 내용을 찾고 기입하다 보면 Class Diagram 내부에서 구현의 단계에서 이루어져야 할 일이 이루어지는 오류를 범하게 된다.
이러한 오류는 실제 구현 단계에서 커다란 위험의 요소를 내재하게 된다.

C.      Sequence Diagram (연속적인 사건들, 순서..)

Sequence Diagram 은 Collaboration Diagram 과 함께 시스템의 동적인 면을 나타내는 대표적인 Diagram이다. 시스템이 실행 시 생성되고 소멸되는 객체를 표기하고 객체들 사이에 주고 받는 메시지를 나타내게 된다. Collaboration Diagram 또한 메시지의 흐름을 나타내지만 Sequence Diagram만의 특징이라면 횡축을 시간 축으로 하여 시간의 흐름을 나타내어 메시지의 순서에 역점을 두고 있다.

D.     Collaboration Diagram

Collaboration Diagram 또한 Sequence Diagram 과 함께 메시지의 흐름을 나타낸다. 하지만 Collaboration Diagram은 객체와 객체들 사이의 관계 또한 표기하게 된다. 실제 UML에서 Class의 Instance인 객체를 표기하는 Diagram이 명시적으로 존재하지 않는다. 이러한 객체들 사이의 관계를 나타내기 위해 별도로 Object Diagram을 사용하여도 되지만 Object Diagram은 Class Diagram과 크게 차이점이 없는 관계로 UML의 표준에는 포함되어 있지 않다.
갑자기 이러한 Object Diagram을 여기서 언급하는 이유는 객체들 사이의 관계를 표기하기 위해 Class Diagram과 거의 동일한 Object Diagram을 그리기 보다는 특별히 Class Diagram과 차이점이 되는 부분을 여기 Collaboration Diagram 에 기입하는 것이 좋다.

E.      Statechart Diagram

StateChart Diagram은 한 객체의 상태 변화를 Diagram으로 나타낸 것이다.
시스템의 실행 시 객체의 상태는 메시지를 주고 받음으로써 또한 이러한 이벤트를 받음으로써 많은 변화가 있을 수 있다. 실제 시스템에서 실행 시 많은 객체가 생성되고 소멸된다.
이렇게 무수한 객체의 상태 전부를 모두 Diagram으로 나타내는 것은 불가능하다.
결국 StateChart Diagram 은 특별히 관심을 가져야 할 객체에 관하여 그리고 특정 조건에 만족하는 기간 동안의 상태를 표시하여야 한다.

F.      Activity Diagram

Activity Diagram은 Flow Chart가 UML에 접목되어 있다면 가장 이해가 빠를 것이다.
시스템 내부에 존재하는 여러 가지 행위를 그리고 각 행위의 분기, 분기되는 조건 등을 모두 포함하게 된다. 이러한 Activity Diagram에서 기존 Flow Chart와 다른 점은 어떠한 행위에 따라 객체의 상태를 표기할 수 있다는 것이다. 이러한 점을 제외하고 기존 Flow Chart 와 표기법과 의미가 약간 달라질 뿐 크게 다르지 않다고 보아도 좋다.




Activity Diagram

G. Deployment Diagram & Component Diagram

이 두 Diagram 은 시스템의 물리적인 부분의 구성을 나타낸다.
Deployment Diagram은 실제 하드웨어적인 배치와 연결상태를 나타낸다.
그리고 Component Diagram은 소프트웨어의 물리적 단위(Exe, Dll 등 기타 Library) 의 구성과 연결상태를 나타내게 된다.




Deployment Diagram

Component Diagram