Creative Commons License

Software Dev

프로그래밍기본
객체지향
프로젝트관리
알고리즘
데이타베이스

소프트웨어 개발에 필수적이고 필요한 주제에 대한 강의 및 공유

.

객체지향

객체재향 프로그래밍 패러다임과 각종 기법 및 방법론에 대해 다룹니다

[UML] UML 이란?

작성자 : 박종명
최초 작성일 : 2008-05-13 (화요일)
최종 수정일 : 2008-05-13 (화요일)
조회 수 : 4071

1. UML (Unified Modeling Language)

현시대의 소프트웨어의 개발은 다양한 참여자와 복잡한 비즈니스, 빈번한 변화요소를 수반하고 있다. 또한 비지니스의 복잡도와 더불어 시스템도 복잡해 지고 있다. 더 이상 소프트웨어 개발은 (간단한 계산기 프로그램을 취미삼아 개발하는 것이 아니라면…) 아 그거요? 바로 짜(코딩) 드리죠!’ 라고 할 수 없게 되었다.  (물론 이전에는 그럴수 있다는 것은 아니다)

 

건축에서 빌딩을 짓기 위해 바로 벽돌을 쌓지 않듯이 소프트웨어를 개발하기 위해 바로 코딩을 할 수는 없다. 건물에 대한 체계적이고 자세한 청사진이 반드시 존재해야 비로써 그 청사진 대로 건물을 지을 수가 있을 것이다. 이처럼 소프트웨어 개발은 탄탄한 설계를 필요로 한다. 또한 탄탄한 설계를 공유할 수 있는 표기법 역시 필요하다. 즉 시스템 설계를 표현하기 위해 여러 사람이 공통적으로 이해할 수 있는 표준적인 표기를 위한 통일된(Unified) 설계(Modeling) 언어(Language)가 필요하게 된 것이다.

 

요구분석, 시스템 설계, 시스템 구현 등 소프트웨어 개발 전반에 걸친 과정에서 시스템 개발에 참여하는 모든 사람(의뢰인, 개발자, 분석가 등) 간의 의사소통을 원활하게 하기 위해 사용되는 표준화된 모델링 언어가 UML 이다

 

UML 은 올바른 소프트웨어 개발을 위해 필요한 설계사항들에 대한 적합한 표기법(이해하기 쉬움, 상황에 맞는 다이어그램, 표현력 좋은 표기)이며 누구나 해석할 수 있는 통일(공통언어)되고 표준적인 표기법이다.

 

 

2. UML 탄생 배경

 

UML이 정식으로 모델링 언어로 채택된 것은 1997 11월이다.

이 시기에 객체 관련 표준화 기구인 OMG(Object Management Group) 에 의해 정식으로 UML 1.1 이 상정되었다. 이 후 OMG 는 계속해서 UML 에 대한 새로운 수정안을 발표하면서 그 버전이 올라갔으며 소프트웨어 모델링 언어로써의 입지를 다졌다.

 

사실 UML 의 개념을 최초로 발상한 것은 Three Amigos(3인방) 로 유명한 그래디 부치, 제임스 럼버, 이바 야콥슨이었다. 객체지향 전문가인 이 들은 모델링언어에 대한 각자의 아이디어를 합쳤고 이렇게 합쳐진 결과물로써 UML 이라는 것이 탄생하게 되었다. (최초로 UML 개발에 착수하게 된 시기는 1994 10월이라고 한다)

UML 툴로 유명한 Rational사 멤버인 이 3인방은 UML 컨소시엄의 멤버로써 활동하며 UML 버전 1.0 을 만들었으며 이것을 OMG 에 제출하게 된 것이다.

 

3. UML 다이어그램

 

구성요소

도식화 범위

유스케이스 다이어그램

사용자 입장에서 본 객체의 행동,기능,쓰임새

활동 다이어그램

객체의 동작중에 발생하는 활동

시퀀스 다이어그램

객체끼리 주고받는 메시지의 시간흐름에 따른 순서

클래스 다이어그램

유사한 속성과 행위를 가진 동일 범주에 대한 추상화

객체 다이어그램

클래스의 인스턴스

상태 다이어그램

시간 및 행위에 의한 객체의 상태 변경

협력 다어이그램

객체의 협력 관계

배치 다이어그램

시스템의 물리적 구조

컴포넌트 다이어그램

조립가능한 단위모델

 

 

 

4. UML 너무 과대 표장 하지 말기

 

① 무분별한 다이어그램 지양

UML은 설계과정을 보다 명확히 하고 프로젝트에 참여하는 많은 사람들에 의해 쉽게 해석되어져 실제 소프트웨어 탄생에 순기능을 함을 목적으로 한다. 간혹 UML 다이어그램 작성 자체가 목적이 되는 경우가 종종있다. 화려하고 복잡한 다이어그램을 만들어야 뭔가 분석한다는 느낌을 가진다면 조심해야 한다. 프로젝트의 성격에 따라서 UML 을 융통성 있게 만들어야 한다. 위의 모든 다이어그램이 모든 프로젝트에 반드시 필요한 것은 아니다. 또한 각 다어이그램 역시 반드시 모든 요소를 다 포함할 필요도 없다. 모든 것은 그때그때 상황에 적합하도록 의미있게 만들어 사용해야 한다.

기억하자. UML 자체가 목적이 되어서는 절대 안된다. 이것은 성공적인 소프트웨어 개발활동을 위한 수단으로써 가치가 있는 것이다.

 

② 각 단계별 변경요소 적용

전형적인 폭포수 개발방법론이 아니라면 분석,설계 단계가 지나 구현단계에 갔더라도 다시 설계요소를 변경해야 할 경우가 생긴다. 중요한 것은 설계문서에 그 변경요소를 반드시 명시해야 하는 것이다. 보통 귀찮다는 이유로 또는 더 이상 공유할 필요(보고할 필요)가 없다는 이유로 이미 만들어진 설계문서는 버전업 하지 않고 설계요소를 구현단에서만 변경하는 경우가 많다. 반드시 프로젝트 수행기간 동안의 변경요소를 위해 설계문서를 버전업 하도록 하자. 이것은 인수인계를 위해서도 꼭 필요한 활동이다.

 

③ 표준적인 사용

UML 자체가 약속되고 표준적인 언어이다.

그렇지만 경우에 따라 프로젝트 참여자들 사이의 해석방법이 달라지기도 한다. (심지어 어떤 UML 책을 봤느지에 따라 달라지기도 한다 --;) 프로젝트 참여자들 간에 이러한 gap 이 크다면 기껏 만들어진 UML 문서도 의미가 없어진다.

따라서 필요하다면 UML 표기법에 대한 표준을 다시한번 확인할 필요가 있으며 모두가 공감하는 표준적인 기법으로 설계문서를 작성하도록 하자.

 

UML 은 시스템의 구현방법을 표현하지는 않는다.

UML 은 시스템의 목적행동을 설명하는 언어이다.

UML 이 구현자체를 표현하지 않는다는 것에 주의하도록 하자. 물론 상세한 시퀀스 다이어그램처럼 실제 구현에 상당한 의미를 부여하는 설계문서가 있기는 하지만 이것 역시 구현방법이 아니라 궁극적으로 시스템이 흘러가야할 목적행동에 대한 설계임을 기억하자

이름
비밀번호
홈페이지
MZ <- 왼쪽의 문자를 오른쪽 박스에 똑같이 입력해 주세요