건물을 짓기 전에, 어떠한 선행 작업이 필요할까? 가장 먼저 떠오르는 것이 바로 설계도일 것이다. 물론 설계도 이외에도 다른 것이 생각날 수 있지만, 설계도가 있어야지 건물의 구체적인 생김새하고 구조를 미리 볼 수 있다. 건축가가 건물을 설계하고 건축 도면을 그리는 것 처럼, 프로그래머는 UML을 사용하여 시스템의 구조와 동작을 시각적으로 표현한다.
UML(Unified Modeling Language)
UML은 앞에 간략히 설명한 것 처럼 설계도, 우리 쪽으로 변형해서 말하면 시스템 개발을 위한 시각적인 설계 표기를 제공하는 객체지향 모델링 언어다.
UML은 객체 지향 시스템을 개발할 때 산출물을 명세화, 시각화, 문서화하는 데 사용되고, 그 산출물은 다양한 참여자가 쉽게 이해할 수 있는 의사소통 도구로 활용된다.
UML은 시각화 언어다
- UML은 소프트웨어의 개념 모델을 시각적인 형태로 표현하며 명확히 정의된 표준화된 다이어그램을 제공한다. 이를 이용해 오류 없는 원할한 의사소통이 이루어질 수 있다.
UML은 명세화 언어다
- UML은 소프트웨어 개발 과정인 분석, 설계 단계의 각 과정에서 필요한 모델을 정확하고 완전하게 명세화하여 만들 수 있다. 명세화에서 각 다이어그램의 기호는 의미를 담고 있으며 추상적이지만 고유의 특성을 갖고 있다.
UML은 구축 언어다
- UML은 자바, C++, 비주얼 베이직,C#같은 다양한 프로그래밍 언어로 표현할 수 있다. 즉, UML로 설게된 모델을 프로그램 코드로 자동 변환할 수 있다. 이미 구축된 소스 코드를 UML로 역변환하여 분석하는 역공학도 가능하다.
UML은 문서화 언어다
- UML은 StarUML, 투게더 등 케이스 툴을 이용하여 설계한 내용을 자동으로 문서화할 수 있다.
정보 시스템을 다양한 시각화로 모델링 할 수 있도록 다음과 같이 표준화된 다이어그램을 제공한다.
구조 다이어그램(Structural Diagram)
- 클래스 다이어그램(Class Diagram)
- 시스템의 클래스와 그들의 관계를 보여준다
- 객체 다이어그램(Object Diagram)
- 특정 시점의 객체와 그들 관의 관계를 나타낸다
- 컴포넌트 다이어그램(Component Diagram)
- 시스템의 물리적 컴포넌트와 그들 간의 의존성을 표현한다
- 배포 다이어그램(Deployment Diagram)
- 하드웨어와 소프트웨어의 물리적 배치를 나타낸다
- 패키지 다이어그램(Package Diagram)
- 시스템의 논리적 그룹화와 패키지 간의 의존성을 보여준다
- 복합 구조 다이어그램(COmpostie Structure Diagram)
- 클래스의 내부 구조와 그들 간의 상호작용을 나타낸다
- 프로파일 다이어그램(Profile Diagram)
- UML 모델에 사용자 정의 스테레오타입과 태그 값을 적용한다
행위 다이어그램(Behavioral Diagrams)- 유스케이스 다이어그램(Use Case Diaram)
- 시스템의 기능적 요구사항을 사용자 관점에서 보여준다
- 시퀀스 다이어그램(Sequence Diagram)
- 객체들 간의 상효작용을 시간 순서에 따라 나타낸다
- 커뮤니케이션 다이어그램(Communication Diagram)
- 객체간의 메세지 교환을 보여준다
- 상태 다이어그램(State Diagram)
- 객체의 상태 변화와 이벤트에 따른 상태 전이를 나타낸다
- 활동 다이어그램(Activity Diagram)
- 시스템의 동작 흐름이나 비즈니스 프로세스를 나타낸다
- 타이밍 다이어그램(Timing Diagram)
- 객체 상태의 시간적 변화를 보여준다
- 상호작용 개요 다이어그램(Interaction Overview Diagram)
- 상호작용 다이어그램의 흐름을 개략적으로 나타낸다
다이어그램의 종류는 총 14가지가 있다. 하지만 어떠한 것을 만들 때 이 14가지를 전부 만들진 않는다. 상황마다 다르며, 만들지 않는 다이어그램도 있다. 하지만 여기서 웬만해선 만드는 메이저한 다이어그램 5가지가 있다. 클래스 다이어그램, 유스케이스 다이어그램, 시퀀스 다이어그램, 활동 다이어그램, 상태 다이어그램이 있다.
이 다섯 가지 다이어그램은 시스템의 구조와 동작을 명확히 정의하고 시각화하는 데 핵심적인 역할은 한다. 각 다이어그램은 시스템의 다른 측면을 집중적으로 다루며, 개발자, 비즈니스 분석가, 고객 등 다양한 이해관계자가 시스템을 명확히 이해하고 설계하는 데 필수적인 도구로 사용된다.
시스템의 어떤 기능을 제공해야 하는지, 사용자 인터페이스는 어떻게 만들어야 하는지, 어떤 클래스들이 필요한지 등은 개발자가 소스 코드를 작성하기 전에 미리 결정해야 하는 사항들이다. 시스템을 구축할 때 개발자가 고민하고 결정하는 모든 활동을 모델링이라 한다.
시스템을 구축할 때 개발자는 시스템 요구자의 요구사항 정의, 분석, 설계를 통하여 구현의 과정을 거친다. 이 때 소스코드 작성을 구현이라하고, 구현 단계 이전의 요구 사항 정의, 분석, 설계에서 수행하는 활동들은 모두 모델링이라 한다.
| 구분 | 모델링 | 프로그래밍 |
|---|---|---|
| 목적 | 구축할 시스템의 모습 정의 | 시스템의 실제 구현 |
| 세부 수행 활동 | 요구 사항 정의, 분석, 설계 | 소스 코드 편집, 컴파일, 시험, 디버깅 |
| 결과물 | 모델 | 소스 코드를 포함한 구현된 시스템 |
| 표기법 | 모델링 언어(UML) | 프로그래밍 언어(Java, Python) |
| 지원 툴 | CASE 툴(StarUML, 로즈, 투게더) | 개발 툴(Visual Studio) |
사물
사물은 모델에서 가장 중요한 추상적인 개념으로, 사물의 종류는 구조를 표현하는 정적 사물, 동작을 표현하는 동적 사물, 부가적으로 설명하는 주해 사물이 있다.
정적 사물
정적 사물은 모델의 구조, 즉 개념적, 물리적 요소를 표현하는 명사다. 정적 사물에는 클래스, 인터페이스, 커포넌트, 노드 등이 있다.
-
클래스
클래스는 동일한 속성, 오퍼레이션, 관계, 의미를 공유하는 객체를 기술한 것이다.
-
인터페이스
인터페이스는 클래스 또는 컴포넌트를 추상화한 오퍼레이션을 모아놓은 것이다. 인터페이스는 특정 클래스나 컴포넌트의 전체 또는 일부 동작을 나타낼 수 있다.
-
통신
통신에서는 서로 다른 요소와 역할이 모여 교류를 정의한다. 통신은 동작과 구조에서 중요하며 클래스 하나가 다수의 통신에 참여할 수 있다.
-
컴포넌트
컴포넌트는 전체 시스템을 구성하는 단위로 독립적으로 개발되고 배포되며 조립, 교환이 가능한 응집도가 높은 소프트웨어 산출물이다.- 시스템에서 물리적이고 대체 가능한 부분이다
- 사용자 업무 단위를 중심으로 만드는 사용자 지향 설계라고도 부른다
- 플러그앤플레이 조립 방식을 활용해 인터페이스 지향 설계라고도 부른다
- 기존 컴포넌트를 재사용해 생산성 향상을 기대할 수 있다
- 아키텍처 지향의 개발에 사용된다
- 모듈이 아닌 아키텍처를 기초로 컴포넌트를 조립한다
- 우선순위가 높은 모듈을 개발하면서 점차 확장시키는 점진적 개발 방식에 이용한다
- 대표적인 컴포넌트는 J2EE 플랫폼의 JAR 파일과 DLL파일, HTML파일이다
-
패키지
패키지는 요소를 그룹으로 묶는다. 정적 사물이나 동적 사물도 패키지 하나에 들어갈 수 있다. 컴포넌트가 물리적인 데 반해 패키지는 순전히 개념적이다.
-
노드
노드는 실행할 때 존재하는 물리적 요소다. 전산 자원을 나타내고 약간의 메모리와 처리 능역을 갖는다. 컴포넌트가 노드에 존재하며, 노드에서 노드로 이동할 수 있다.
동적 사물
-
교류
교류는 동작이며, 목적을 달성하기 위해 특정 문맥에 속한 객체들 간에 주고받는 메세지로 구성된다. 객체 간 메세지, 활동 순서, 객체 간의 연결 등을 표현하는 데 사용된다.
-
유스케이스
유스케이스는 시스템이 수행하는 활동들을 순차적으로 기술하며, 액터에게 의미 있는 결과 값을 제공해준다. 유스케이스는 모델에서 동적 사물을 통신으로 실현한다.
-
상태 머신
상태 머신은 외부 이벤트에 대한 객체의 상태와 상태의 변화 순서를 기술한다. 상태 머신에는 서로 다른 요소가 많이 들어 있는데, 상태 전이, 사건, 활동이 있다.
주해사물
주해 사물은 모델링에 참여하지는 않지만 모델링에 참여하는 다른 사물 뿐만 아니라 모델링을 이해하는 데 필요한 정보 등 필요한 모든 설명을 표시하기 위해 사용한다. 주해 사물에는 노트가 있다. 노트는 첨부되는 주석 또는 제약을 기술한다.
- 사물
관계
UML에는 의존, 연관, 일반화, 실체화라는 네 가지 관계가 있다.
- 의존 관계
의존 관계는 두 사물 간의 의미적 관계로, 한 사물의 명세가 바뀌면 다른 사물에 영향을 준다. 그러나 그 반대가 반드시 성립하는 것은 아니다. 의존은 한 클래스가 다른 클래스를 오퍼레이션의 매개변수로 사용하는 경우에 주로 나타난다.
- 연관 관계
연관 관계에는 객체 사이의 연결 관계로, 지속적으로 유지되는 관계다. 두 클래스가 연관 관계가 되면 한쪽 객체로 옮겨갈 수 있으며 그 반대도 가능하다. 연관의 양쪽 끝이 같은 클래스를 향하는 순환도 가능하다. 이는 한 클래스의 객체가 같은 클래스의 다른 객체에 연결할 수 있다는 의미다. 두 클래스를 연결하는 연관 관계를 쌍방 연관관계라 한다. 흔한 경우는 아니지만 둘 이상의 클래스를 연결하는 연관도 있는데, 이를 다수 연관이라 한다. 연관 관계는 클래스들을 연결하는 실선으로 표현하고 이름, 역할, 다중성, 집합 연관 등을 추가할 수 있다. A라는 객체가 B라는 객체와 연관 관계가 있다면 A 객체 안에서 B의 객체 생성이 이루어진다고 생각하면 이해하기 쉽다.- 이름
연관 관계는 의미를 설명하기위해 이름을 사용할 수 있다.
- 역할
클래스가 연관에 참여하면 그 클래스가 수행해야 하는 특별한 역할이 생긴다. 클래스가 수행하는 역할에 명시적으로 이름을 지을 수 있다.
- 다중성
모델링을 하다보면 한 연관에 참여하는 객체 하나에 객체가 몇 개 연결되어 있는지 밝히는 것이 중요한 때가 있는데, 이 몇 개를 일컬어 연관 역할에 대한 다중성이라 한다.
- 이름
| 표현 | 설명 |
|---|---|
| 1 | 한 객체와 연관된다. 표시하지 않아도 되는 기본 값이다. |
| 0..1 | 0개 또는 1개의 객체와 연관된다. |
| 0..* | 0개 또는 많은 수의 객체와 연관된다. |
| * | 많은 수의 객체와 연관된다. |
| 1..* | 1개 이상의 객체와 연관된다. |
| 1..12 | 1개에서 12개까지의 객체와 연관된다. |
| 1..2,4,8 | 1개에서 2개까지, 또는 4개 또는 8개의 객체와 연관된다. |
- 일반화 관계
일반화 관계는 일반화된 사물과 좀 더 특수화된 사물 사이의 관계로, 한 가지 종류를 의미하여 kind-of 관계라고도 한다.
일반화 관계에서 일반화는 부모 객체가 사용되는 곳 어디서나 자식 개체가 사용될 수 있음을 의미한다. 즉, 자식 객체는 부모 객체를 대신할 수 있다. 그러나 그 반대는 성립되지 않는다.
자식은 부모의 속성과 오퍼레이션을 상속하고 부모에게 없는 속성이나 오퍼레이션을 가지기도 한다. 동일한 용법을 가진 자식 객체 오퍼레이션은 부모 오퍼레이션을 대체한다.
- 실체화 관계
실체화 관계는 한 객체가 다른 객체에게 오퍼레이션을 수행하도록 지정하는 의미적 관계다. 대표적인 예가 인터페이스와 그것을 구현하는 클래스 사이의 관계다. 실체화 관계는 대개 인터페이스와 인터페이스에 오퍼레이션이나 서비스를 제공하는 클래스나 컴포넌트 사이의 관계를 지정하기 위해 사용한다.
결론
UML(Unified Modeling Language)은 소프트웨어 시스템의 설계 및 개발 과정을 시각적으로 모델링하기 위한 강력하고 표준화된 도구다. 다양한 유형의 다이어그램을 통해 시스템의 구조와 행동을 명확하게 표현하고 이해할 수 있게 한다.
결론적으로 UML은 소프트웨어 개발의 다양한 단계에서 필수적인 역할을 하며, 시스템을 더 체계적이고 효율적으로 설계하고 구현하는 데 기여한다. UML을 활용하면 시스템의 복잡성을 줄이고, 이해관계자들 간의 커뮤니케이션을 개선하며, 궁극적으로 더 나은 품질의 소프트웨어를 개발할 수 있다. UML은 소프트웨어 개발뿐만 아니라 비즈니스 프로세스 모델링, 시스템 엔지니어링 등 다양한 분야에서도 그 가치를 인정받고 있다.
