위키원
"다이어그램"의 두 판 사이의 차이
잔글 (→같이보기) |
|||
| 76번째 줄: | 76번째 줄: | ||
* Ogasawara Noriko, 〈[https://zdnet.co.kr/view/?no=00000039154123 UML은 무엇을 위해 있는 것일까?]〉, 《ZDNet Korea》, 2006-12-26 | * Ogasawara Noriko, 〈[https://zdnet.co.kr/view/?no=00000039154123 UML은 무엇을 위해 있는 것일까?]〉, 《ZDNet Korea》, 2006-12-26 | ||
| − | == | + | ==같이 보기== |
| − | + | * [[그래프]] | |
{{데이터|검토 필요}} | {{데이터|검토 필요}} | ||
2021년 8월 7일 (토) 03:02 기준 최신판
다이어그램은 정보를 조율, 묘사, 상징화 하여 2차원 기하학 모델로 시각화하는 기술이다. 때때로 2차원 표면에 그래픽적 투사 과정을 거쳐 3차원 공간에 시각화된다. 그래프(graph)와 다이어그램(diagram)의 용어를 혼용하기도 한다. [1]
목차
개요[편집]
다이어그램의 기능과 목적은 전달에 있으며, 강력한 전달력을 활용한 계몽적 측면과 의미를 빠르고 정확하게 알려야 하는 고지적 측면을 갖는 시각 언어이다. 다이어그램은 표현 내용에 따라 비교 통계 다이어그램(도표, 그래프, 통계도표 등), 기구 계통 다이어그램(조직도, 계보도, 계통도 등), 기능 및 해부 다이어그램(기상도, 구조도, 해부도 등), 행사 예정표 및 일람표(예정도표), 통계 지도 및 장식 지도(노선 안내도 등) 등이 있다.[2]
역사[편집]
1990년대까지의 OOD/Booch, OMT, OOAD, RDD, GOOD, HOOD, OOSD, OOJSD 등과 같은 많은 방법론들은 실제 시스템을 구축하는데 있어서 각각의 객체지향 기술들이 갖는 방법과 심벌이 서로 달랐다. 그리고 1994년 소프트웨어 방법론의 선구자인 그래디 부치, 제임스 럼바, 이바 야콥스에 의해서 UML이 연구되었고 1995년 부치의 방법론과 럼바의 OMT 방법론이 통합되었다. 1996년 야콥슨의 OOSE 방법론이 추가되면서 1997년 객체관리그룹에서 여러 표기법을 통합해 UML을 발표했다.[3]
특징[편집]
다이어그램의 종류는 많지만 보통 개발 업무에서는 9가지를 보고 있다.
클래스 다이어그램[편집]
클래스 다이어그램의 경우 시스템 내부에 존재하는 클래스들을 선별하여 나타내고 각 클래스의 속성(Attribute)과 행위(Behavior)를 기재한다. 여기서 클래스들 사이에 여러 가지 관계(Relationship)를 맺을 수 있다. 예를 들어 연관관계(Association)는 클래스와 클래스가 어떠한 연관이 있음을 나타내고 여기서 세부적으로 복합연관(Composition)과 집합 연관관계 (Aggregation) 등으로 나누어 질 수 있다. 이외에 상속관계(Generalization), 의존관계(Dependency)가 나타날 수 있다. 클래스 다이어그램을 그리고자 할 때 항상 추상화 단계를 고려하여서 그리도록 하여야 할 것이다. 추상화의 단계가 높은 경우 대충의 속성과 행위를 기재하고 대충의 관계를 기재하여도 충분할 것이다. 이 단계에서 너무 상세한 내용을 찾고 기재하다 보면 클래스 다이어그램 내부에서 구현의 단계에서 이루어져야 할 일이 이루어지는 오류를 범하게 된다. 이러한 오류는 실제 구현 단계에서 커다란 위험의 요소를 내재하게 된다.[4]
시퀸스 다이어그램[편집]
시퀸스 다이어그램은 콜라보레이션 다이어그램과 함께 시스템의 동적인 면을 나타내는 대표적인 다이어그램이다. 시스템이 실행 시 생성되고 소멸하는 객체를 표기하고 객체들 사이에 주고받는 메시지를 나타내게 된다. 콜라보레이션 다이어그램 또한 메시지의 흐름을 나타내지만 시퀸스 다이어그램만의 특징이라면 가로축을 시간 축으로 하여 시간의 흐름을 나타내어 메시지의 순서에 역점을 두고 있다.[4]
콜라보레이션 다이어그램[편집]
콜라보레이션 다이어그램 또한 시퀸스 다이어그램과 함께 메시지의 흐름을 나타낸다. 하지만 콜라보레이션 다어그램은 객체와 객체들 사이의 관계 또한 표기하게 된다. 실제 UML에서 클래스의 인스턴스인 객체를 표기하는 다이어그램이 명시적으로 존재하지 않는다. 이러한 객체들 사이의 관계를 나타내기 위해 별도로 오브젝트 다이어그램(Object Diagram)을 사용하여도 되지만 오브젝트 다이어그램은 클래스 다이어그램과 크게 차이점이 없는 관계로 UML의 표준에는 포함되어있지 않다. 갑자기 이러한 오브젝트 다이어그램을 여기서 언급하는 이유는 객체들 사이의 관계를 표기하기 위해 클래스 다이어그램과 거의 같은 오브젝트 다이어그램을 그리기보다는 특별히 클래스 다이어그램과 차이점이 되는 부분을 여기 콜라보레이션 다이어그램에 기재하는 것이 좋을 것이다.[4]
유스케이스 다이어그램[편집]
유스케이스 다이어그램은 유스케이스를 그려놓은 다이어그램이다. 여기서 유스케이스란 말 그대로 컴퓨터 시스템과 사용자가 상호작용을 하는 하나의 경우이다. 예를 들어 보험처리 프로그램의 경우에 "고객이 보험증권에 sign 한다. 판매원이 판매 통계량을 종합한다." 등이 use case가 된다. 이러한 유스케이스 다이어그램은 시스템 구축의 초기에 이 시스템이 어떠한 일을 하는지에 대한 부분을 사용자 관점에서 이해할 수 있을 정도로 기술하여야 한다. 이러한 유스케이스 다이어그램은 사용자와의 대화수단으로 그리고 앞으로 구축해 나갈 때의 밑바탕이 되는 것이다.[4]
상태 다이어그램[편집]
상태 다이어그램은 한 객체의 상태 변화를 다이어그램으로 나타낸 것이다. 시스템의 실행 시 객체의 상태는 메시지를 주고받음으로써 또한 어떠한 이벤트를 받음으로써 많은 변화가 있을 수 있다. 실제 시스템에서 실행 시 많은 객체가 생성되고 소멸한다. 이렇게 무수한 객체의 상태 전부를 모두 다이어그램으로 나타내는 것은 불가능하다. 결국 상태 다이어그램은 특별히 관심을 가져야 할 객체에 관하여 그리고 특정 조건에 만족하는 기간 동안의 상태를 표시하여야 한다.[4]
액티비티 다이어그램[편집]
액티비티 다이어그램은 플로우챠트가 UML에 접목되었다면 가장 이해가 빠를 것이다. 시스템 내부에 존재하는 여러 가지 행위들 그리고 각 행위의 분기, 분기되는 조건 등을 모두 포함 하게 된다. 이러한 액티비티 다이어그램에서 기존 플로우 챠트와 다른 점은 어떠한 행위에 따라 객체의 상태를 표기할 수 있다는 것이다. 이러한 점을 제외하고 기존 플로우챠트와 표기법과 의미가 약간씩 달라질 뿐 크게 다르지 않다고 보아도 좋다.[4]
컴포넌트 다이어그램[편집]
컴포넌트 다이어그램(Component Diagram)은 소프트웨어 컴포넌트 사이의 의존관계를 묘사한다. 소프트웨어 컴포넌트를 구성하는 요소들과 그것들을 구현하는 요소들도 모두 표현될 수 있다.[5] 컴포넌트는 기존의 함수, 클래스 등에 비하여 보다 큰 규모이므로 재사용을 하는 경우 재사용의 효과가 보다 크게 된다. 그리고 매우 강한 수준의 정보 은닉 개념을 지원한다. 기존 컴포넌트를 수정하는 대신에 아예 새로운 컴포넌트로 기존 컴포넌트를 대체하는 것도 가능하다.
배포 다이어그램[편집]
실행 상황에서 노드들의 구성을 보여주고 소프트웨어 요소들이 실제로 어떤 하드웨어에 배치되어 실행되는지를 보여준다.[6] 컴포넌트 다이어그램과 같이 실세계의 개체를 다루며 컴포넌트 다이어그램이 소프트웨어 컴포넌트였다면 배포 다이어그램은 하드웨어에 중점을 둔 다이어그램이다. 다시 말해 배포다이어그램은 컴퓨터를 기반으로 하는 시스템의 물리적 구조를 나타낸다. 컴퓨터와 부가장치, 그리고 각각의 연결 관계뿐만 아니라 각각의 기계에 설치된 소프트웨어까지 표시한다.[7]
객체 다이어그램[편집]
객체 다이어그램과 클래스 다이어그램을 서로 밀접한 관련이 있으며 거의 유사한 노테이션을 사용한다. 이 두 다이어그램 모두 시스템의 정적인 구조를 시각화하기 위해 사용된다. 클래스 다이어그램이 클래스를 보여주는 반면 객체 다이어그램은 클래스의 인스턴스를 표시한다. 객체 다이어그램은 클래스 다이어그램보다 더 구체적이다.[8]
활용[편집]
UML은 기법을 결정하고 있을 뿐 그 사용법까지는 정의하고 있지 않다. 즉 UML 사용방법은 이용자에게 맡고 있기 때문에 기술 방법만 지키면 자유롭게 UML을 사용할 수 있다. 그렇다고는 해도 실제의 시스템 개발의 현장에서는 주로 3가지의 용도로 쓰이는 경우가 많다. [9]
모델링[편집]
요건 정의 국면에서는, 현행 시스템을 이해하는 것이나 '무엇을 만들까?' 를 의식해 유저의 요건을 묻기 위해서 모델링이라고 하는 기법을 사용해 시스템의 전체상을 그리는 작업을 하는 일이 있다. 이 작업을 실시하는 사람을 모델러라고 부르고 모델링에 의해서 작성하는 그림을 개념 모델이라고 부른다. 개념 모델 자체는 어떠한 표현을 해도 상관없지만, 일반적으로는 UML의 클래스 다이어그램을 사용하는 것이 많은 듯하다. 그 이유 중 하나는 설계자가 이해하기 쉽기 때문이다. UML을 사용한 모델링에서는 유저의 머릿속에 있는 요건을 정보로 정리하고 그 정보끼리의 관계를 정의해 도식화하는 것으로 시스템의 요건을 전체상으로서 파악한다. 실제로 이 작업을 보고 있으면, 마치 최초부터 거기에 존재했나 싶을 정도로 클래스 다이어그램이 완성되어 가는 모습에 매우 놀란다. 또 클래스 다이어그램의 읽는 법이 몇 가지는 결정돼 있긴 하지만 기억할 것은 많지 않다. 직감적으로 판단할 수 있기 때문에 UML에 익숙하지 않은 유저도 이해하기 쉬어서 클래스 다이어그램에 대한 평가는 대체로 높다. 만약 클래스 다이어그램을 사용하지 않고 말만으로 유저의 요건을 정리하려고 하면, 부분적인 요건의 상세화는 할 수 있지만 전체를 파악하는 것이 어려워 주제가 희미해져 버리는 약점이 있다. 한편 클래스 다이어그램을 유저와 함께 만들어내 가는 모델링에서는 전체상을 시각적으로 이해할 수 있어 유저 자신이 깨닫지 못했던 과제도 발견할 수 있다는 장점이 있다. 단지 모델링의 단계에서 작성하는 클래스 다이어그램은 다음에 설명하는 설계 레벨의 클래스 다이어그램에 비해 매우 입도가 엉성하고 정보도 부족한 것이 많기 때문에 그대로는 프로그래밍할 수 없다. 그 대신 유저와 개발자의 사이에 '대체로 이런 느낌' 이라고 하는 시스템에 대한 요구를 합의할 수 있어 요건 정의 국면에서는 매우 유효하다. 이와 같이 모델링에서는 UML의 클래스 다이어그램을 사용하는 것이 일반적입니다만 추상도가 높은 클래스 다이어그램의 정보를 구체화해 보충하는 스테이트 머신 다이어그램나 오브젝트 다이어그램도 잘 사용된다.[9]
설계[편집]
요건 정의 국면에 UML을 사용해 작성한 그림은 설계에서 보다 구체화된다. 예를 들면, 클래스 다이어그램이나 스테이트 머신 다이어그램으로부터 데이터베이스의 논리 설계를 행하거나 실제 이미지에 접근하기 위해서 클래스의 상세화를 한다. 설계 국면에서는 '어떻게 만들까?'를 의식하지만, 자바 등의 객체 지향 언어로 개발하는 것이 전제가 되고 있는 경우 UML을 사용하고 설계도(클래스 다이어그램이나 순서도 등)를 쓰는 경우가 많다. 실제로 움직이는 물건을 만들기 위한 설계이므로, 모델링에 비해 보다 엄밀성이 요구되지만 이 때 표기 방법이 명확하게 정해져 있는 UML이 매우 도움이 된다. 설계에서 클래스 다이어그램을 사용하는 가장 큰 장점은 클래스 간 인터페이스를 빠른 단계에서 명확하게 할 수 있는 점이다. 설계에서 쓰는 클래스 다이어그램에는 클래스의 속성이나 관계뿐 아니라 조작도 나타내게 되어 있다. 예를 들면, 수주 클래스에 수주 등록이라는 조작을 하는 것으로 그 클래스를 사용해 수주 정보를 등록할 수 있는 것이다. 여기에서는 조작을 실행하기 위해서 필요한 입력 정보와 실행 결과의 출력 정보를 분명히 해 클래스의 인터페이스를 정의하지만, 그 조작 자체의 내용을 자세하게 나타내 보일 필요가 없기 때문에 필요한 정보를 최저한의 표기로 나타내 보일 수 있다. 덧붙여 설계 시에 클래스 다이어그램이나 순서도 등을 만드는 것은 필수가 아니고, 비교적 소규모의 시스템으로 개발 멤버 사이에 미리 설계 방법이 공유되어 있는 경우에는, 필요에 따라서 코딩제의 프로그램으로부터 리버스해 클래스 다이어그램 등을 작성해, 설계서를 나중에 작성하기도 한다. 리버스 기능은, 이후 설명하는 툴로 지원되고 있다.[9]
프로그래밍[편집]
실행 환경에 의존하지 않는 UML 모델로부터 툴을 사용해 실제로 움직이는 프로그램으로 변환하는 기술을 MDA(Model Driven Architecture)라고 부른다. MDA에 준거하면, 모델링→설계→프로그래밍에의 변환을 모두 UML만으로 할 수 있게 된다.[9]
각주[편집]
- ↑ 위키백과, 〈다이어그램〉, 《위키피디아》
- ↑ 한글글꼴용어사전, 〈다이어그램〉, 《네이버 지식백과》
- ↑ codedragon, 〈모델링 언어의 발전〉, 《개인블로그》
- ↑ 4.0 4.1 4.2 4.3 4.4 4.5 C1 SW, 〈다이어그램 종류와 개념에 대해 알아보자〉, 《개인블로그》, 2017-07-02
- ↑ Geunhee Zhang, 〈다이어그램(Diagram) 종류〉, 《개인블로그》, 2015-04-24
- ↑ Phang's IT Blog, 〈기타 다이어그램(컴포넌트.배포, 패키지 다이어그램〉, 《개인블로그》, 2019-05-19
- ↑ plandis, 〈배포 다이어그램〉, 《개인블로그》, 2010-07-22
- ↑ 위키백과, 〈객체 다이어그램〉, 《위키피디아》
- ↑ 9.0 9.1 9.2 9.3 Ogasawara Noriko, 〈UML은 무엇을 위해 있는 것일까?〉, 《ZDNet Korea》, 2006-12-26
참고자료[편집]
- 위키백과, 〈다이어그램〉, 《위키피디아》
- 한글글꼴용어사전, 〈다이어그램〉, 《네이버 지식백과》
- Geunhee Zhang, 〈다이어그램(Diagram) 종류〉, 《개인블로그》, 2015-04-24
- C1 SW, 〈다이어그램 종류와 개념에 대해 알아보자〉, 《개인블로그》, 2017-07-02
- Phang's IT Blog, 〈기타 다이어그램(컴포넌트.배포, 패키지 다이어그램〉, 《개인블로그》, 2019-05-19
- 위키백과, 〈객체 다이어그램〉, 《위키피디아》
- plandis, 〈배포 다이어그램〉, 《개인블로그》, 2010-07-22
- codedragon, 〈모델링 언어의 발전〉, 《개인블로그》
- Ogasawara Noriko, 〈UML은 무엇을 위해 있는 것일까?〉, 《ZDNet Korea》, 2006-12-26
같이 보기[편집]
