UML(Unified Modeling Language)

UML(Unified Modeling Language)

UML이란 소프트웨어 개발 과정에서 산출되는 산출물들을 명시, 개발, 문서화하기 위한 모델링 언어이다. UML은 Rational 사의 Grady Booch, James Rumbaugh에 의해 1994년 10월에 처음 개발에 착수되었다. 이후 1995년 10월에 Unified Method 0.8의 명칭으로 OOPSLA '95에서 발표되었으며, 이후 Ivar Jacobson이 UML 개발에 함께 협력하면서 1996년에 버전 0.9를 발표하였고, 1997년 11월에는 UML 1.1 이 OMG에 의해 표준으로 채택되었다.

UML은 모델링 언어일뿐 메쏘드(또는 방법론)는 아니다. 메쏘드는 프로세스에 대한 정의와 각각의 업무들에 대한 지침과, 업무들 간의 순서들을 명시해야 하는 반면, 모델링 언어는 표기법(또는 다이어그램)들만을 제시하는 것이다. 따라서 UML은 소프트웨어 개발에 사용하기 위한 여러 다이어그램들을 정의하고 있으며, 또 다이어그램들의 의미들에 대해 정의하고 있다.

UML은 여러가지 다이어그램들을 제시함으로써 소프트웨어 개발과정의 산출물들을 비주얼하게 제공하고, 개발자들과 고객 또는 개발자들 간의 의사소통을 원활하게 할 수 있도록 하고 있다. UML은 시스템을 모델링 할 수 있는 다양한 도구들을 제공하기 때문에, 도메인을 모델링하기가 훨씬 용이할 뿐만 아니라 모델링한 결과를 쉽게 파악할 수 있게 된다. 또한 산업계 표준으로 채택되었기 때문에 UML을 적용한 시스템은 신뢰성 있는 시스템으로 평가받을 수 있다.

 

UML의 정의

-      복잡한 소프트웨어 시스템 개발 모델링에 필요한 구성요소를 제시하고 이를 이용한 추상화 방법과 산출물들을 프로젝트 참여자들이 쉽게 이해할 수 있도록 소프트웨어 개발방법론(표현 및 기법)들이 통합된 객체지향개발 표준통합 모델링 언어

-      표준화된 다이어그램을 통하여 소프트웨어 생명 주기 전체 단계에서 시스템의 산출물을 가시화하고 명세화하는 모델링 언어

-      비즈니스 모델링이나 대규모의 복잡한 분산시스템 모델링, 정보시스템 모델링 등을 시각적으로 구체화하고 구축하는 객체지향 모델링 언어

 

UML 발전 과정

객체지향분석/설계(OOA/D) 방법 중 Booch, Rumbaugh, jacobson의 방법론을 기초로 작성되고 OMG에 의하여 표준화됨.

95년 이전	97년 1월	2004년 5월
-      개발 방법론 -      Booch 방법론 -      OMT 방법론 -      OOSE 방법론 -      기타 방법론	-      UML 1.x -      UML 파트너 전문가 견해 취합 -      Unified Method -      OMG 공표	-       UML 2.0 -       OMG에서 UML 개선
개별화	통합/표준화	산업화

UML의 특징

-      각 개발공정에 다양하고 일관성 있는 표현방법을 제공하고 확장성이 뛰어남

-      소규모에서 대규모 프로젝트까지 모두 잘 적용할 수 있음

-      UML은 CASE 도구 및 개발프로세스(Unified Process) 지원

-      특정 개발 방법론에 얽매이지 않는 개방적이고 독립적 표기체계

-      별도의 비용이 없는 공개된 표준 모델링 제공

-      개발자간 의사소통 원활, 반복적 점진적 과정

-      사용자에게 사용하기 쉽고 표현이 풍부한 시각적 모형화 언어 제공

 

4+1 View

1.    Use-Case View

-      외부 사용자의 관점에서의 기능을 나타냄

-      시스템 행동을 설명

-      최종사용자, 분석가, 설계자, 테스트 담당자에게 제공 되는 뷰

-      시스템 아키텍쳐를 구체화하는 요인들을 명세화

Diagram

-      Static : Use-Case Diagram

-      Dynamic : Communication Diagram, State Chart Diagram, Activity Diagram

 

2.    Logical View

-       시스템 내부의 structure와 behavior로 functionality가 어떻게 설계되었는지를 표현

-       Logical View는 Service관점에서 시스템이 사용자에게 제공해야 하는 기능적 요구사항 표현

Diagram

-      Static : Class Diagram, Object Diagram

-      Dynamic : Sequence Diagram, Communication Diagram, State Chart Diagram, Activity Diagram

 

3.    Implementation View

-      개발 환경 내에서 실제 소프트웨어 모듈의 구성과 관련

-      개발의 용이성, 소프트웨어 관리, 재사용, 프로그램언어와 개발 도구에 따른 제약과 관련되어 파생된 요구사항을 고려

-      시스템 배포의 형상관리 표현

-      물리적인 시스템을 조립하고 배포하는데 사용되는 Component와 File 들로 구성

Diagram

-      Static : Component Diagram

-      Dynamic : Communication Diagram, State Chart Diagram, Activity Diagram

 

4.    Process View

-      절차적인 관점

-      Performance, Reliability, Scalability, Integrity, System Management, Synchronization등의 요구사항을 고려

Diagram

-      Static : Class Diagram, Object Diagram

-      Dynamic : Communication Diagram, State Chart Diagram, Activity Diagram

 

5.    Deployment View

-      시스템을 컴퓨터와 device의 node로 전개 시켜 표현

-      Deployment Diagram은 시스템에서 서로 다른 node들과 이 node들 간의 연결을 나타내기 위해 생성됨

Diagram

-      Static : Deployment Diagram

-      Dynamic : Communication Diagram, State Chart Diagram, Activity Diagram

 

UML Diagram의 종류

Use-Case Diagram	시스템이 해야 할 행동 명세화를 하고 순서 있는 액션의 집합을 기술한 것으로 Actor에게 해택이 있는 결과를 제공해야 함. l  사용자의 시각에서 SW 시스템의 범위와 기능을 쉽게 설명하고 정의한 모델 l  시스템의 모든 기능에 대한 Use Case와 이와 관련된 Actor들 및 이들간의 관계를 표현 l  고객과 개발자간에 시스템이 무엇을 수행하는지에 대한 명확하고 일관성 있는 정의를 제공 l  개발자에게 시스템에 대한 이해를 제공하여 개발을 도와줌 l  시스템 행동을 조직화하고 모델링 l  시스템의 정적 쓰임새 뷰
Sequence Diagram	시스템의 동작을 정형화 하고 객체간의 메시지 교환을 쉽게 표현하고 시간에 따른 메시지 발생순서를 강조한다. l  어떤 일을 하기 위해 참여하는 객체들 사이에 일어나는 상호작용을 시간 순으로 파악하기 위해 사용됨 l  객체들의 집합이 제시간에 상호 작용하는 방법을 표현 l  메시지의 시간적 순서를 강조
Class Diagram	시스템을 구성하는 클래스 구조를 나타내며 객체들의 공통구조와 동작을 추상화 하며, Dependency, Association, Aggregation, Realization 관계를 표현한다. l  시스템에 포함된 객체들의 유형들과 그 클래스들 사이의 정적 관계성을 표현 l  한 클래스의 속성과 연산을 표현 l  객체들을 연결하는 방법에 적용하는 제약사항을 표현 l  클래스, 인터페이스, 협력간의 관계를 나타내며 객체 지향 시스템 모형화에서 가장 공통적으로 많이 쓰임 l  객체들 사이의 행위를 나타내는 것은 Sequence Diagram과 동일
Communication Diagram	특정 메시지 집합 안에 참여하는 객체들의 조직에 초점을 두고 있으며 Sequence Diagram과 마찬가지로 설계 작업흐름에 적용 l  객체들 사이의 행위를 나타내는 것은 Sequence Diagram과 동일 l  객체들 사이의 정적인 구조에 더 초점
State Diagram	시스템의 동적 측면을 모델링 하는 것으로 Object행동 모델을 작성한다. l  한 객체가 가지는 상태와 사건에 따라 순차적으로 발생하는 행동에 중점을 두고 작성 l  하나의 상태전이 다이어그램에서 객체의 초기 상태를 나타내는 시작 상태는 오직 하나만 존재하며, 객체의 마지막 상태인 종료 상태는 여러 개 존재할 수 있음.
Activity Diagram	순서도의 일종으로 발생하는 활동을 강조 l  데이터의 활동이나 흐름, 또는 활동들 사이의 의사 결정을 표현 l  하나의 사용사례 내에서 일어나는 활동들을 분할하기 위해 사용 가능 l  시스템의 기능을 모형화하고 객체간의 제어 흐름 표현에 유용 l  순서나 병렬적인 처리를 요하는 행위를 표현
Object Diagram	객체들 사이의 관계표현, 클래스의 Instance에 대한 정적 스냅샷 l  객체들의 상호작용을 정의하기 위해 작성 l  특정 객체들이 전체 클래스 모델의 내용 안에서 사용되는 방법을 나타내기 위해 클래스 다이어그램에 추가 객체들 사이의 관계를 표현
Component Diagram	인터페이스를 가지고 자체 실행 가능한 컴포넌트 모임을 표현, 실행 Node에서 실행 가능한 컴포넌트를 명세화 l  물리적 구성단위 컴포넌트와 그들간의 구성 및 의존 관계를 표현 l  시스템의 논리적 모델을 개발자 관점에서 바라본 물리적 모델로 재배치하는 데 사용 l  어떤 클래스를 어떤 파일에 넣으면 어떤 파일을 모아 어떤 모듈을 만들 것인지 등을 정의하는 것
Deployment Diagram	노드들의 모임과 그들 사이의 의존과 연관관계를 보여주는 배치도 l  아키텍쳐의 정적 배치 뷰

 

UML 실무적용시 고려사항

-      개발 업무특성에 따라 적용될 산출물의 범위가 다르며 복잡한 업무 일수록 적용할 산출물의 종류가 증가될 수 있으며 이해당사자들 간의 의사소통에 중점을 둔다.

-      실제 현장에서 조직의 문화 및 환경에 맞는 UML 및 객체지향 모델링에 관한 선수지식확보 및 교육이 선행되어야 한다.

-      적용할 UML 다이어그램의 최적화를 위해 개발계획수립, 위험식별 및 평가, 개선사항 들은 반복을 통하여 관리되어야 한다.

-      기존 시스템을 역공학 하는 측면이면 사용자 매뉴얼을 참고하여 Use-Case을 도출한다.

-      설계 측면에서 정적 모델과 동적 모델 후 데이터베이스 전환을 위해 OR Mapping 적용 시 컴포넌트 재사용을 고려 한다.

[출처] UML(Unified Modeling Language)|작성자 후루꾸