Written by 심 원도.
1998년 12월 21일
플라스틱소프트웨어
www.plasticsoftware.com
1. UML 정의
1) UML이란?
Unified Modeling Language의 약자로 객체지향 분석(Analysis)과 설계(Design)를 위한 modeling Language이다. 이는 Booch, Rumbaugh(OMT), Jacobson등의 객체지향 방법론(methods)에 관한 석학들이 내어놓은 방법론의 통합으로 이러한 방법론의 명맥을 잇는다고 볼 수 있다. 또한 객체 기술에 관한 국제 표준화 기구인 OMG(Object Management Group)에서 이미 UML을 표준화로 인정했으며 현재 ver1.1까지 만들어져 있다.
v 방법론(methods)과 Modeling Language 차이
방법론은 생각과 행동을 구조화하는 방법을 명백히 제시한다. 예를 들어 사용자가 하나의 모델을 만들 때, 어떻게, 언제, 무엇을, 왜라는 모든 방법을 제시하는 것이 방법론인 반면에 이러한 모델을 단지 표현하는 것이 modeling language이다.
2) UML 표기와 의미
UML에서는 표기할려는 대상을 diagram을 사용하여 나타내고 그 대상에 의미를 부여한다.
Example.
2. Development Process
1) 개발 프로세스(Development Process)와 UML
우리는 UML의 전체구성과 세부내용을 언급 전에 개발 프로세스를 먼저 알아보아야 할 것이다. 먼저 개발 프로세스를 언급하는 이유는 UML이 위에서 언급했듯이 방법론이 아니고 방법론에 따르는 설계 시 사용되는 언어일 뿐이라는데 있다.. 그러므로 하나의 방법론을 적용하여 언제 어디에 사용되는지 알아봄으로써 UML의 이해를 도울 수 있을 것이다.
2) 구성
Requirement Analysis(요구분석) -> Analysis(분석) -> Design(설계) -> Implementation (구현)-> Test(테스트)
Development process의 구성은 대략 위와 같으며 이는 내용에 따라 구성된 것이다.
물론 여기에도 순서가 존재하고 순서에 맞게 진행되어야 한다.
3) 요구분석(Requirment Analysis)
요구분석은 말 그대로 사용자의 요구를 알아보는 것이다. 개발 초기에 용역을 맏기는 고객의 요구를 충분히 알기 위해 그리고 이러한 요구를 구축할 시스템에 충분히 반영하기 위하여 요구분석의 단계가 필요하고 이것의 문서화가 필요하다. 이 단계는 또한 고객과 공급자간의 마찰이 생길때 이를 해결하기 위한 자료로써도 사용되어진다. 이러한 요구분석의 결과물로는 시스템에 요구하는 기능을 적어놓은 일반적인 문서가 된다. UML에서의 Use Case Diagram과 간단한 Class Diagram 그리고 Activity Diagram으로 표현이 되어진다.
4) 분석(Analysis)
분석의 단계에서는 실제 풀어야 할 문제에 대한 분석을 필요로한다. 하지만 이러한 분석에서 세부적인 기술(implementation)이나 특정 기술(technic)은 배제하고 실세계의 존재물에 해당하는 모델들(classes, objects, interaction)에 관한 것이다.
분석단계에서 행하여지는 일들을 간단히 소개하면 다음과 같다.
n 해결 해야 될 문제의 영역에 대한 지식을 얻어야 한다. 이 지식은 기존 시스템의 기술(description), 사용자와의 대화, business process, term catalog, 같은 문제를 가지고 다른 팀. . 등등에서 가져올 수 있다.
n 적당한 클래스들의 후보(candidate)들을 찾아야 한다. 이 과정에서 brainstorming이 필요하며 이 과정이 끝난 후 모든 후보들에 대한 다시 한번 심각한 고찰이 필요하고 여기서 필요 없는 클래스가 생략되게 된다.
n 클래스들 사이의 정적인 관계가 모델링 되어진다. 예를 들어 association, aggregiation, generalization, dependencies등으로 관계들이 표현되어진다.
n 오브젝트들 사이의 행위(behavior)와 협력(collaboration)등을 state diagram, collaboration diagram, sequence diagram, activity diagram으로 표현되어진다.
n 모든 다이어그램이 완성되면 종이에 시스템을 실행시켜보는 방법으로써 다시 한번 검증하는 것이 필요하다.
n 기본적인 user interface의 프로토타입을 만들어야 한다.
결과적으로 분석의 단계에서 나오는 결과물로 UML에서는 class diagram, sequence diagram, collaboration diagram, state diagram, activity diagram이 나오게 된다.
5) 설계(Design)
설계 단계는 분석 단계의 결과물에 기술적인 부분을 첨가하여 확장하는 것이다. 기술적인 확장이란 시스템을 어떻게 구현(implement)할 것인지에 촛점을 두고 어떻게 동작하고 어떤 제약이 있어야 하는지에 관하여 생각하는 것이다. 이와 같이 설계 단계와 기술적인 하부구조를 분리하는 것은 분석 단계에서 만들어진 결과를 되도록이면 변화시키지 않고 유지하면서 하부구조를 좀 더 쉽게 변화시키거나 발전시킬 수 있도록 하기 위함이다.
설계단계에서 실제 일어나는 일은 다음과 같다.
n 분석단계에 나온 클래스들에서 기능적 패키지(functional package)들을 분리시킨다. 예를 들어 user interface, database handling, communication을 위한 패키지가 분석단계에서 나온 클래스들에 포함되어 있다면 기능적 패키지로 분리 시키고 없다면 첨가 시킨다.
n 동시성을 가진 행위의 경우 공유되는 자원에 대하여 acitive classes와 비동기적 메시지(asynchronous messages), 동기화 기술(synchronization technique)을 가지고 모델링되어야 한다.
n 시스템의 출력에 해당하는 형식이 정해져야 한다. 시스템의 출력은 user interface, 기록, 다 른 시스템과의 통신등과 같은 것이다
n 필요한 외부 클래스 라이브러리나 컴포넌트를 명시하여야 한다
n 시스템에서 예상되는 예외(exception)상황에서의 에러처리를 고려하여야 한다.
설계단계에서의 결과물로 UML에서는 class diagram, sequence diagram, collaboration diagram, state diagram, activity diagram, component diagram, deployment diagram이 나오게 된다.
6) 구현(Implementation)
구현의 단계는 실제로 소스코드로 생성하는 단계이다. 만약 설계를 완벽하게 마쳤다면 구현의 경우는 아주 쉬운 작업이 될 것이다. 이 단계에서는 다이어그램에서 특정언어의 구문으로 옮겨 적는 과정 그리고 컴파일하고 링킹하고 다시 디버깅하는 작업이 포함되어있다. 실제로 소스코드의 작성은 프로그래머에게 익숙한 작업이고 친근한 작업이다. 하지만 객체지향 분석과 설계에서는 코딩을 먼저 하는 것이 바람직하지 못하다. 분석과 설계의 과정을 충분히 거치지 않고 바로 코딩을 할 경우 분석하고 설계하는 단계를 다시 하는 경우가 빈번하며 이는 오히려 프로젝트를 망치거나 장기화 시킬 우려가 대단히 크다.
구현단계의 결과물로 어떤 다이어그램을 만드는 일은 드물다. 대신 설계 단계를 정정하는 것이 필요하다.
7) 테스트(Test)
마지막 단계로써 테스트의 목적은 코드에서의 에러를 발견하는 일이다. 여기서 에러의 발견은 프로그램에서의 실수가 아니고 성공이라고 보아도 좋다. 테스트 결과의 에러가 문서로 남게 되고 이것이 다음 버전에서 고쳐질 수 있기 때문이다.
2. UML 구성
1)
구성
2) Use Case Diagram
n 내용
말 그대로 컴퓨터 시스템과 사용자가 상호작용을 하는 하나의 경우이다. 예를들어 보험처리 프로그램의 경우에 “고객이 보험증권에 sign한다.”, “보험 판매원이 판매통계량을 종합한다.” 등이 use case가 된다.
이러한 use case diagram 은 위 development process에서 언급한 바와 같이 요구구분석의 단계에서 주로 사용자의 요구를 기술하는데 사용된다. 여기서 알아둘 것은 처음부터 완벽하게 use case diagram을 작성하려 하지 말라는 것이다. Use case의 작성이 필요할 때 마다 작성하는 것이 바람직하다.
Example.
3) Class Diagram
n 내용
Class diagram의 경우 여러가지 객체들의 타입, 즉 클래스들을 표현하고 그 클래스들의 정적인 관계(associated, dependent, specialized, packaged)를 표현한다. 이러한 정적인 요소는 시스템의 life cycle과 수명을 같이하며 하나의 시스템은 여러 개의 class diagram으로 표현이 가능하다.
4) Object Diagram
n 내용
Object diagram과 class diagram의 변형으로 class diagram과 거의 같은 표기법을 사용한다. 하지만 class diagram과의 차이점은 표현되는 것이 클래스 대신 실제 인스턴스화된 객체를 표현한다. 이것은 클래스 다이어그램의 실행시에 나타나는 하나의 예를 나타낸 것이다.
클래스 다이어그램과 오브젝트 다이어그램의 경우 다음 강의에 자세하게 실을 예정입니다. 여기서 예제는 생략하고 다음 강의에 더 자세한 설명과 예제를 보시기 바랍니다.
5) Sequence Diagarm
n 내용
Class diagram은 시스템의 정적인 구조를 보여준다. 하지만 여기 sequence diagram은 collaboration diagram과 함께 시스템의 동적구조, 즉 객체와 객체그룹사이, 객체와 객체사이, 객체그룹과 객체그룹사이의 동적인 행위를 기술하게 된다.
특히 sequence는 종좌표축으로 시간개념을 도입하고 횡좌표축으로 객체들을 나열하여 그 사이의 상호작용을 표시하였다.
n Example.
6) Collaboration Diagram
n 내용
Collaboration diagram의 경우 객체들 사이의 행위를 나타내는 것은 sequence diagram과 동일하다. 둘의 차이점은 sequence diagram이 시간에 따른 행위의 흐름에 역점을 두고 표현하지만 collaboration diagram의 경우 객체들 사이의 정적인 구조에 더 역점을 두고 있다.
Sequence diagram과 collaboration diagram이 모두 객체들 사이의 상호작용(interaction)을 나타내므로 interaction diagram이라 통칭하기도 한다. 이런 interaction diagram이 필요한 경우는 하나의 use case내부에 포함된 객체들 사이의 행위를 보일 때 필요하다. 하지만 객체 상호간의 관계에 역점을 두었기 때문에 객체 하나의 행위를 정확하게 표현하기에는 부적절한다.
n Example.
7) Package Diagram
n 내용
“거대한 소프트웨어를 어떻게 작게 나눌것인가?” 이 말은 소프트웨어 방법론에서 문제시하고 있는 가장 오래된 질문중 하나이다. 이 문제의 해결을 위해 초기 구조적 방법론에서는 기능적으로 분해(functional decomposition)하는 방법을 사용하였다. 시간이 지남에 따라 여기에 process와 data의 분리현상이 일어났고 이것이 기능적인 분해의 방법에도 적용이되었다. 하지만 클래스란 개념의 등장으로 이러한 방법을 대치하게 되었고 클래스들을 상위개념으로 묶는 것이 문제시되었다. UML에서는 이러한 상위 개념으로의 그룹화 방법으로 package란 방법을 제시하였다.
Package란 하나의 클래스가 아닌 system에서의 하나의 modeling element가 된다. 쉬운 예로 하나의 element를 modeling 하기위해 하나의 클래스 diagram을 작성하였다면 이 class diagram이 하나의 package가 된다. Package diagram은 이러한 package와 package들 사이의 의존관계(dependency)를 나타낸다.
n Example.
8) State Diagram
n 내용
State diagram은 오브젝트가 가질 수 있는 모든 상태와 어떠 한 event를 받았을때 결과로 어떠한 상태로 변화하는지를 나타낸다.
n Example.
9) Activity Diagram
n 내용
Activity diagram 은 기존의 다른 diagram처럼 기존의 전통을 가진 것이 아니다. Jim Odell의 event diagram, SDL state modeling techinques, Petri nets등의 여러가지 이론이 섞여서 만들어 진 것이다. 이런 다이어그램은 순서도나 병렬적인 처리를 요하는 행위를 표현할 때 사용하면 유용한 것이다.
Activity diagram은 순서에 따른 activity를 나타내는 것으로 모델링하고 있는 diagram에서의 activity의 의미를 파악하는 것이 중요하다. activity의 의미로 개념적인 다이어그램에서는 activity는 인간이나 컴퓨터에 의해 수행이 필요한 어떠한 업무(task)를 의미하고, 상세화(specification)하는 다이어그램이나 구현(implementation)을 위한 다이어그램의 경우 activity는 class의 method 가 된다.
n Example.
10) Deployment Diagram
n 내용
하드웨어 시스템들은 각각 고유의 특성을 가지고 있다. 이런 환경에서 분산환경에서의 시스템 구축은 시스템 마다의 고유 특성을 담고 시스템간의 관계를 표현한 diagram을 필요로 하게 된다. 이 때 필요한 것이 각 시스템 마다의 하드웨어, 소프트웨어 컴포넌트들의 관계를 나타낸 deployment diagram이다.
Deployment diagram은 node라는 notation으로 computationl unit(대부분 하드웨어적인 부분)을 나타낸다.
n Example.
v 여기서 UML에 대한 첫 강좌를 마칠까 합니다. 많은 부분이 부족하다고 필자 또한 느낍니다. 하지만 이러한 부족부분을 이 강좌를 읽고 공부하는 사람이 채워주리라 믿고 계속하도록 하겠습니다.
앞의 내용은 UML의 전반적 구성과 간단한 설명이었습니다. 원래 순서로는 Use Case Diagram을 하는 것이 옳지만 구성부분중 가장 많이 쓰이고 또 가장 중요한 부분을 차지하는 Class Diagram을 중점으로 두 세번의 강좌를 할 예정입니다.
그리고 이글을 인용하거나 Posting하실분은 저한테 메일주세요. 히….
글 중에 잘못된 내용이나 오타가 있으면 다음의 주소로 연락주세요.
wideeye@www.plasticsoftware.com
'SE' 카테고리의 다른 글
| UML[3/4] (0) | 2008.07.25 |
|---|---|
| UML[2/4] (0) | 2008.07.25 |
| Pattern[4/4] (0) | 2008.07.25 |
| Pattern[3/4] (0) | 2008.07.25 |
| Pattern[2/4] (0) | 2008.07.25 |
