|
1)
UML 개요
분석, 설계,
개발에 UML을 사용하게 되는데 UML은 Unified Modeling Language의 약어로 소프트웨어
시스템을 모든 수준(아키텍처 수준부터 구현 수준까지)에 거쳐 명세하고
구현하고 문서화하는데 사용되는 “심볼언어(Symbolic Language)” 라고
얘기할 수 있습니다.
먼저 모델링(Modeling)이란
말을 자주 사용하는데 이에 대한 정의부터 하겠습니다. 모델링이란 다른
말로 추상화(Abstraction)라고 이야기 할 수
있습니다. 그런데 추상화란 단어도 우리에게 금방 이해되지 않습니다. 그래서
좀 더 쉬운 말로 하자면 단순화(Simplification)라고
이야기 할 수 있습니다.
즉, 우리가 만들어야
할 시스템이 너무 복잡해 보이니까, 단순하게 만들자! 그렇게 중요한
부분이 아니라면 무시하고 중요한 부분에만 집중해서 단순하게 만들자! 하는 것이
모델링 입니다. “모델링 = 단순화”, 밑줄 쫙, 외우세요!
요즘 여기저기서
방법론(Methodology) 이야기를 많이 하는데 일반적으로 방법론이란 다음 세가지로
이루어 집니다.
|
방법론
= 표기법 + 프로세스 + 툴
표기법(Notation)
모델링을
할 때 모델을 만든 사람이나 그것을 보고 구현할 사람, 혹은 발주자가
같은 “말”을 하자는 취지에서 반드시 표준이 필요한 요소입니다. 만든
사람은 A를 생각하고 만들었는데 그것을 읽는 사람은 B를 생각하면 안
된다는 거지요. 다른 말로 “서로 같은 말을 쓰자”는 얘깁니다. 그래서
Language라는 말이 붙은 것이지요. 이 표기법에 대해 90년대 초에
많은 논쟁이 있다가 표준으로 통일되어 사용하게 된 것이 UML
입니다.
프로세스(Process)
일을
진행해 나갈 때 어떤 단계를 거쳐야 하며, 각각의 단계는 어떤 행위로
이루어 져야 하는가를 정의하는 것입니다. 다양한 프로세스가
있는데 많이 알려진 것 중의 하나가 RUP (Rational Unified Process)
입니다
툴(Tool)
꼭
필요한 것은 아닌데 Rational에서 UML과 RUP 시장을 장악하고 나서 자신의
툴이 이 모든 것을 제공해준다는 의미에서 집어넣었습니다. 유명한 예로는
Rational Rose가 있지요.
|
60~70년대 포트란이나
코볼로 만들어진 프로그램은 그리 복잡하지 않아서 소수 엔지니어 팀이 관리할 수
있었습니다. 그런데 C, 파스칼 같은 언어가 나오면서 “Modular” 프로그래밍
기법이 소개되고, 점점 큰 소프트웨어를 만들게 되었는데 이에 따라 더 많은 엔지니어가
개발에 참여하게 되고, 광범위한 문서(대부분 잘 안 만들지요!)가 필요하게 되었습니다.
이에 대한 대안으로 나온 것이 객체지향(OO: Object-Oriented) 프로그래밍이고,
95년 웹/자바의 폭발과 함께 각광 받게 되었습니다. OO 프로그래밍의
주요 개념은 데이터 캡슐화 (Encapsulation), 상속 (Inheritance),
코드 재사용 등이지요. OO의 사용으로 인해 점점 더 복잡한 소프트웨어
시스템을, 빠르고 적은 인원으로 만들 수 있게 되었습니다.
발주자가 요구사항
정의서를 주면 궁극적으로 소스코드로 된 소프트웨어 시스템을 만들지요? 그런데
요구사항정의서와 소스코드 간의 괴리가 너무 커서 이 중간을 매울 무엇인가가 필요하게
되었는데 그것이 바로 소프트웨어 모델입니다. 즉, 소스코드보다는
고수준이면서 요구사항정의서보다는 좀 더 구조화된 뭔가가 필요하게 된 것입니다.
마치 집을 짓기 전에 설계-청사진을 만드는 것과 유사하지요.
이에 90년대
초반에 많은 연구가 이루어졌는데, 다양한 기술과 제언들이 쏟아져 나왔지만 서로
호환성이 없어서 혼란이 심화되니까 업계표준이 필요하다는 인식이 퍼지게 되었습니다.
그 중 조금 유명한 기술 하나가 Grady Booch의 방법론이었고, James Rumbaugh의
OMT(Object Modeling Technique) 입니다. 그런데 Rational에 있던 Booch가
GE에 있던 Rumbaugh을 불러서 두 모델기술이 통합되었고, 그 이듬해에 Use-Case로
유명한 Ivar Jacobson (당시 스웨덴 Ericsson 근무)의 OOSE(Object-Oriented Software
Engineering) 까지 포섭하면서 Rational에 거두 3 인방이 모이게 되었습니다. 그래서
Three-Amigo 라는 애칭으로 불리곤 합니다. 사실 이 세 사람이
모여 통합하니까 업계에서 반박할 사람이 없었고 그리하여 OMG라는 단체를 내세워
UML을 발표한 것입니다.
참고로 UML은
관계 데이터베이스의 성공요소 중 하나인 ER(Entity-Relationship) 모델에서
많은 개념을 빌려왔습니다.
2)
UML 디자인 목표
UML은 다음과
같은 디자인 목표를 가지고 만들어졌습니다.
- Ready
to use “out of the box” - 즉시 사용할 수 있는 수준의 언어
- 가능한
모든 프로그래밍 언어 지원이 목표 (하지만 특정 언어에 독립적으로)
- 특별한
요구사항에 맞춰 고칠 수 있는 언어
- 이해를
돕는 수준에서 “formal”해야 하지만 수학적 이론이 너무 많이 포함되어서는
안됨
UML이 유명해진
이유는 앞서 설명한 대로 가장 유명한 대가들의 모델링 기술을 통합하기도 했지만
업계 유명 소프트웨어 벤더 (예: IBM, Microsoft, Oracle, Digital, HP, Unisys)
지원을 받는다는 것입니다. UML은 소프트웨어 엔지니어링 뿐만이
아니라 데이터베이스, 시스템 디자인 등의 학문에서 가장 좋은 아이디어를 발췌했다고
볼 수 있습니다. UML의 다른 장점은 특정 프로그래밍 언어에 종속되지 않으면서,
다양한 문제 도메인에 적용되고, 규모에 상관없이 적용할 수 있다는데 있습니다.
이렇듯 모델링
언어가 UML로 통합되면서 OOP 업계가 급성장할 수 있었고, 다양한 툴들이 벤더 종속적이지
않게 상호운용 될 수 있었습니다. 이 UML이 학계가 아닌 업계로부터 성장했다는 사실은
좋은 모델링 기술이 실제적으로 많은 비용을 절약하게 해준다는 사실을 보여줍니다. 또한
동일한 모델링 언어를 사용함으로 해서 개발자는 새로 교육받을 필요도 없고, 특정
프로세스나 도메인에 국한되지 않아서 활용범위가 넓다는 장점이 있습니다.
3)
UML 다이어그램
UML 다이어그램은
다음과 같이 4 가지 용도로 나눌 수 있습니다.
- 시스템
행동, 요구사항을 이해하기 위해 - Use-case diagram
- 클래스
정적 구조를 이해하기 위해 - Class diagram
- 클래스
동적 행동을 이해하기 위해 - Interaction diagram, Activity diagram, State
diagram
- 전체 아키텍처를
이해하기 위해 - Package diagram, Deployment diagram
각각의 다이어그램
용도를 정확하게 이해하는 것이 중요합니다.
- Use-case
diagram - 시스템이 어떻게 행동해야 하는지 스냅샷으로 보여줍니다.
- Class diagram
- 객체, 클래스를 서술하고 객체간의 정적인 관계를 보여줍니다.
- Interaction
diagram - 객체가 어떤 행동을 위해 어떻게 서로 협력하는가를 보여줍니다.
- Activity
diagram - 프로세스 흐름을 보여줍니다.
- State diagram
- 주어진 한 클래스의 행동을 자세히 기술합니다.
- Package
diagram - 클래스 사이의 의존성을 보여줍니다.
- Deployment
diagram - 소프트웨어 컴포넌트와 하드웨어 컴포넌트 간의 물리적 연관성을 보여줍니다.
4)
클래스 다이어그램
클래스 다이어그램은
시스템의 클래스 생김새와 클래스들 간의 정적 구조를 이해하기 위해 그립니다. 클래스가
가진 속성(attribute)과 동작(operation)이 무엇인지 기술해야 하고 (OO에서 이야기하는
state + behavior 라고 이해하시면 됩니다), 클래스 간의 관계를 보여주어야 하는데,
관계에는 Association과 Generalization이라는 두 가지 유형이 존재합니다. UML은
시스템 모델링을 위해 그림을 그립니다. 일반 자연어로, 텍스트로 기술하는
경우 기술한 사람의 의도와는 다르게 이해하는 경우가 종종 있지요. 그래서
그런 오해를 피하기 위해 일정한 구문(syntax)을 정의했는데, 그 구문이 그림이라는
것입니다. 그래서 UML을 배운다는 것은 “그림 그리기 구문”을 배우게
되는 것입니다. 구문이 있기 때문에 Language라는 단어가 뒤에 붙어 있는 것이지요.
개략적으로 구문을
살펴보고 하나 하나 자세히 배우도록 합시다.
- 클래스
다이어그램은 서로 연결된 노드(node)로 이루어진 그래프 입니다.
- 노드는
사각형으로 그리고 위치와 크기는 그리 중요하지 않습니다.
- 하나의
노드는 하나의 클래스를 기술합니다.
- 모든
그림은 2 차원으로 그립니다.
- 특별한
의미를 가진 icon 들이 있습니다.
- 노드를
연결하는 선이 있습니다.
- 필요한
경우 텍스트를 삽입할 수 있는데 특별한 구문이 있는 것은 아니고 { } 사이에
삽입합니다.
① 클래스
 클래스를 보여주는 UML 예제 그림 두 개입니다.
3 개의 방으로
이루어진 사각형으로 그립니다. 외곽은 실선으로 그립니다.
- 상단:
클래스 이름을 기술합니다.
- 중단:
클래스의 속성을 기술합니다.
- 하단:
클래스의 동작을 기술합니다.
- 필요에 따라
중단과 하단을 생략하고 클래스 이름만 기술하기도 합니다.
- 클래스 이름은
중간에 굵은 글씨체로 씁니다.
- 클래스 이름은
반드시 대문자로 시작합니다.
- 속성과 동작은
소문자로 시작합니다.
- Abstract 클래스나
인터페이스는 누여서(italic체) 씁니다.
동작은 클래스가
제공하는 메소드인데 구문은 다음과 같습니다.
visibility
name (parameter-list): return-type-expression {property-string}
 - 가시성(visibility)은 + (public),- (private), # (protected)
글자를 사용합니다.
- Parameter-list
구문은 다음과 같습니다.
kind
name:type-expression=default-value
- 종류(kind)는
in, out, 혹은 inout 셋 중 하나입니다.
- Abstract operation
에는 {abstract} 를 기술합니다.
- 클래스 동작
(static method), 클래스 속성에는 밑줄을 긋습니다.
② 코멘트(노트)
모델의 일부이기는
하지만 사람이 읽어서 이해하는데 도움을 주도록 노트 혹은 코멘트를 붙일 수 있습니다.
그림에서처럼 우상귀가 접힌 모양의 사각형을 사용합니다. 제한사항,
코멘트, 알고리즘 등을 적어 넣습니다. 관련된 부분에 연결을 시킬 때는 반드시
점선을 사용합니다.
③ Association
 클래스 간의 관계를 나타내기 위해 association을 사용합니다.
일반 사양서
수준에서는 클래스의 책임과 운항성(navigability)을 기술해야 하고, 구현 수준에서는 자료구조를
기술합니다.
Association은
ER 다이어그램에서 relationship에 해당한다고 보시면 되고요, 그냥 두 개의 클래스를
실선으로 연결하는 것입니다. 썰렁하지요 ^^
그럼, ER 다이어그램과
UML 다이어그램의 차이점은 무엇이냐 하면, ER에서는 자료구조에 중점을 두지만,
UML에서는 객체의 책임/역할(role)에 중점을 두는 것입니다.
한쪽 끝에 그
클래스가 association에 참여하면서 하는 역할을 기술합니다. 역할을 기술하지
않는 경우 그 클래스 이름이 역할 이름이 됩니다. 될 수 있으면 기술해 주는
것이좋습니다.
역할은 다중성(multiplicity)을
가집니다. ER에서 얘기하는 mapping cardinality 라고 이해하시면 되겠습니다.
일반적으로 min..max 구문을 사용하면 min, max가 같으면 하나의 숫자만 사용합니다.
* 는 0 혹은 그 이상, + 는 1 혹은 그 이상을 의미합니다.
그림은 하나의
주문(Order)이 0 혹은 그 이상의 주문행(OrderLine)으로 이루어져 있음을 나타내고
OrderLine은 Line items 라는 역할을 한다는 것입니다.
④ Generalization
클래스 간에
상하 구조를 그릴 때는 Generalization 구문을 사용합니다.
일반적인 상속(inheritance)
구조를 그릴 때 사용하며 서브-타입에서 수퍼-타입으로 향하는 화살표(비어 있는
세모 화살표)를 그립니다.
관계 측면에서는
“is-a” 관계가 형성됩니다.
예제 그림에서
“Corporate Customer is-a Customer” 그리고 “Personal Customer is-a Customer”를
읽을 수 있고, 모든 Customer는 name, address 라는 속성을 물려받고, 모든 Customer에
대해 creditRating( ) 메소드를 부를 수 있습니다.
⑤ 제약사항
(Constraint)
클래스나 association에
특정한 제약을 가하기 위해서는 그림과 같이 제약사항을 { } 사이에 넣어서 텍스트
형태로 기술합니다.
일반적으로 association,
generalization으로 많은 제약사항을 표현할 수 있지만 이것으로 표현 할 수 없는
경우, 오해를 피하기 위해 코멘트 형식으로 더 기술해 주는 것입니다.
한 회사에서
주문을 처리하는데 관여하는 클래스 관계를 그린 클래스 다이어그램 전체 그림 예입니다.
5)
시퀀스 다이어그램
 클래스 다이어그램이 정적 측면에서 시스템을 바라본 것이라면
동적 측면에서 바라본 것이 교류도(Interaction Diagram)
입니다. 일반적으로 하나의 쓰임새 (use-case)를 더 잘 이해하기 위해, 그 쓰임새
내에 있는 여러 객체가 어떻게 움직이는지 들여다보고 싶을 때 그립니다.
교류도에는 시퀀스(Sequence)
다이어그램과 협력(Collaboration) 다이어그램 두 가지가 있는데 약간 다르지만 유사합니다.
그래서 둘 다
그리는 경우는 거의 없고 취향에 따라 한 가지를 그립니다.
일반적으로 시퀀스
다이어그램을 그립니다.
그런데 대부분의
UML 툴이 이 둘 사이의 자동으로 변환 해주기 때문에 하나의 다이어그램만을 그리고 툴을
사용해서 다른 다이어그램을 얻을 수 있습니다.
여기서는 많이
그리는 시퀀스 다이어그램에 대해 배웁니다.
교류도를 그리는
첫번째는 순서는 참여하게 될 객체를 구분하고 그리는 것입니다. 객체는 사각형으로
그리고 가운데에 객체 ID 이름을 굵은 글씨체로 씁니다.
그리고 객체
아래로
점선을 그어서 생명선(lifeline)을표시합니다.
객체간 통신은
메시지를 통해서 하는데 보통 메시지는 화살표 위에 메소드 이름을 기술하고, 객체
자신의 메소드를 부를 때는 self-delegation 구문을 사용합니다.
그리고 리턴을 명시할 필요가 있을 때는 점선으로 화살표를 그립니다. (아래 첫번째
그림)
하지만 리턴을
반드시 명시할 필요는 없습니다. 이해하는데 도움이 되면 명시하세요.
프로그램 제어에
필요한 구문이 있는데 하나는 조건을 명시하는 것이고 (즉, 어떤 조건이 참이나 거짓이
될 때만 메시지를 보내도록), 다수의 객체에게 메시지를 동시에 보낸다는 것을 나타내는
iteration marker * 를 사용하는 것입니다.
주문을 처리하는데
관여하는 클래스와 그 들간의 메시지 전달 관계를 그린 시퀀스 다이어그램 전체 그림
예 입니다
- http://agora.plasticsoftware.com/UMLKorea/
한글로 된 UML
사이트 중에서는 가장 영양가 있는 곳이 아닌가 싶습니다. “UML에 관련된
각종 지식과 정보를 공유하여 많은 사람들이 UML을 사용하고 좀 더 쉽게 접근하여
실제 필요에 따라 응용할 수 있도록 하는 것이 목적입니다”라고 홈 페이지에 나와
있네요. 영문 사이트로는 http://www.uml-forum.com 이 있는데 여기도 좋은 정보가
많이 있습니다. 특히 UML 2.0 에 대한 정보는 가장 빠른 것 같습니다.
- http://dognet.chonbuk.ac.kr
전북대의 “생각하는
사람들”이라는 그룹에서 만든 사이트 입니다. State diagram, Activity diagram,
Use-case diagram 등에 대해 간략한 튜토리얼을 원하시면 이 사이트를 방문해 보세요.
- http://mindview.net/Weblog/log-0041
Bruce Eckel
홈 페이지 (http://www.bruceeckel.com/)에 있는 WebLog에 가시면 유용한 Q&A가
있는데, “어떤 UML 툴이 좋은가요?”에 대한 대답이 있는 링크입니다. 다양한
툴과 다양한 사용자 피드백이 있으니까 읽어보시고 적절한 것을 골라서 사용하시면
되겠습니다.
|
