UML 2
UML 2의 두 가지 기본적인
- 구조 다이어그램(structure diagram)
- 목적은 모델링 되는 시스템의 정적인 구조를 보여주는 것이다.
- 클래스 다이어그램, 컴포넌트 다이어그램, 객체 다이어그램이 포함된다.
- 작동 다이어그램(Behavioral Diagram)
- 시스템의 객체들 간 동적인 작동을 보여준다.
- 메소드, 협업, 액티비티 등이 포함된다.
- 액티비티 다이어그램, 유스케이스 다이어그램, 시퀀스 다이어그램 등이 있다.
- 구조 다이어그램 특징.
- 모델링 되는 시스템의 정적인 구조를 보여준다.
- 시간에 상관없이 시스템의 요소들에 초점을 맞춘다.
- 정적 구조는 시스템에 있는 유형들과 이들의 인스턴스를 나타낸다.
- 요소들 간 관계를 보여주고 심지어 내부 구조까지도 보여준다.
- 사용
- 소프트웨어 라이프 사이클 동안 팀 멤버들에게 유용하게 사용된다.
- 디자인의 유효성 감사와 개인과 팀들 간 디자인 통신에 사용된다.
- 비즈니스 분석가들은 클래스나 객체 다이어그램을 사용하여 계정 대장, 제품, 지리적 계층 같은 비즈니스의 현재 에셋과 리소스를 모델링 할 수 있다.
- 아키텍트는 컴포넌트와 전개 다이어그램을 통하여 자신들의 디자인이 튼튼하다는 것을 테스트 및 입증한다.
- 개발자들은 클래스 다이어그램을 사용하여 시스템의 코딩 된(또는 코딩 될) 클래스들을 디자인 및 문서화 한다.
- 클래스 다이어그램 개요.
- UML2는 구조 다이어그램을 하나의 범주로 간주한다.
- Structure Diagram이라는 다이어그램은 없다.
- 클래스 다이어그램은 구조 다이어그램의 대표적인 예이며, 모든 구조 다이어그램들이 사용하는 초기 표기법 요소들을 제공한다.
- 클래스 다이어그램 기초
- 대부분의 UML 모델에서는 다음과 같은 유형들이 있다.
- 클래스, 인터페이스, 데이터 유형, 컴포넌트.
- UML은 이러한 유형들에 대해 특별한 이름을 사용한다. "classifier"이다. 일반적으로 classifier를 클래스로 생각할 수도 있지만, 기술적으로 classifier는 위에 언급한 다른 세가지 유형들을 언급하는 보다 포괄적인 용어이다.
- 클래스 이름.
- 클래스의 UML표현은 수직적으로 쌓은 세 개의 부분들을 포함하고 있는 직사각형이다.
- (그림1) 맨 위 부분은 클래스의 이름을 나타낸다.
- 중간 부분은 애트리뷰트이다.
- 맨 아래 부분은 클래스의 연산이다.
- 클래스 요소를 그릴 때, 맨 위의 이름은 필수이며 중간과 맨 아래는 선택이다.
- 클래스 애트리뷰트 리스트
- 한 클래스의 애트리뷰트 섹션은 각 클래스의 애트리뷰트를 각 라인 별로 나열 한다.
- 이것을 사용한다면, 하나의 리스트 포맷으로 디스플레이 된 클래스의 애트리뷰트가 포함된다. 이 라인은 다음과 같은 포맷을 사용한다.
- 이 Flight 클래스 예제에서, 애트리뷰트 유형 정보와 함께 클래스의 애트리뷰트를 기술할 수 있다.(표1)
- 비즈니스 클래스 다이어그램에서, 애트리뷰트 유형들은 다이어그램의 독자들이 이해할 수 있는 단위들에도 상응한다. (예, 분, 달러, 등)
- 코드를 생성하기 위해 사용될 클래스 다이어그램은 애트리뷰트 유형이 프로그래밍 언어에서 제공하는 유형 또는 시스템에 구현될 모델에 포함되는 유형으로 제한된 클래스가 필요하다.
- 클래스 다이어그램에 특정 애트리뷰트가 기본 값을 갖고 있음을 보여주는 것도 유용하다.
- Name : attribute type = default value
- Balance : Dollars = 0
- 클래스 연산 리스트
- 클래스의 연산은 클래스 다이어그램의 세 번째 부분에 나타난다.
- 이 부분은 선택적이며, 아래 표기법을 사용하여 문서화된다.
- Name(parameter list) : type of value returned
- Flight 클래스는 표 2로 매핑 될 수 있다.
- (그림3)을 보면 delayFlight 연산이 Minutes 유형의 인풋 매개변수 numberOfMinutes를 작고 있다는 것을 알 수 있다. 하지만 delayFlight 연산에는 리턴 값이 없다.
- 하나의 연산이 매개변수를 갖고 있을 때, 매개변수들은 연산의 괄호 안에 놓이게 된다. 각 매개 변수들은 "parameter name : parameter type"포맷을 사용한다.
- 연산의 매개 변수들은 문서화 할 때, 매개변수가 연사의 인풋인지 또는 아웃풋인지 보여주기 위해 선택적인 인디케이터를 사용할 수도 있다. 이러한 인디케이터들은 (그림3)처럼 "in" 또는 "out"으로 나타난다.
- 이러한 인디케이터는 Fortran 같은 오래된 언어를 사용하지 않는 이상 불필요하다.
- C++과 자바에서 모든 매개변수들은 'in' 매개변둘들이기 때문에 대부분 생략한다.
- 상속
- 객체 지향 디자인의 가장 중요한 개념인 상속(inheritance)은 하나의 클래스(자식)가 또 다른 클래스(부모)의 동일한 기능을 상속 받을 수 있고, 고유의 새로운 기능을 추가할 수 있다는 것을 의미한다.
- 클래스 다이어그램에서 상속을 모델링 하려면, 속이 투명한 화살표(또는 삼각형)가 부모 클래스를 향하도록 한다.
- (그림4)과 같이 상속 관계는 각 하위 클래스 마다 개별 라인으로 그려지는데, 이것은 IBM Rational Rose와 IBM Rational XDE에서 사용되는 방식이다.
- 트리 표기법(tree natation)으로 상속을 그리는 방법도 있다. (그림4)와 같이 두 개 이상의 자식 클래스들이 있을 경우, 트리 표기법을 사용할 수 있다.
- 추상 클래스와 연산
- 주의 깊게 보았다면 (그림4,5)에서 BankAccount와 withdrawal이 이탤릭 체를 사용하고 있음을 알아차렸을 것이다. 이는 BankAccount는 추상클래스고 withdrawal 메소드는 추상 연산이라는 것을 나타낸다.
- 부모 클래스는 추상 클래스일 필요가 없고, 일반적으로 표준 클래스가 슈퍼 클래스가 된다.
- 제휴(Association)
- 시스템을 모델링 할 때, 특정 객체들은 서로 연관될 것이고, 이러한 관계들이 명확하게 모델링 되어야 한다.
- 다섯 가지 제휴 유형들이 있다.
- 양방향 (표준) 제휴
- 제휴는 두 클래스들간 연결이다.
- 제휴는 언제나 양방향(bi-directional)으로 간주된다.
- 일부 다른 유형으로 수정하지 않는 이상, 두 개의 클래스는 서로를 인식하고 그 관계를 알고 있다는 의미이다.
- 양방향 제휴는 두 클래스들 간 일직선으로 표시된다.
- 각 라인의 양 끝에 역할과 값을 표시한다.
- Plane는 "assignedPlane"역할을 하며, 비행계획에 상응하는 비행기가 있거나 없을 수 있기에 Multiplicity 값 0..1이다.
- Flight는 "assignedFlights"역할을 하며, 비행계획이 없거나, 또는 많은 비행 스케줄과 연결될 수 있다.
- Multiplicity 값과 인디케이터.
- 일방향 제휴.
- 두 개의 클래스들은 관련이 있지만, 단 하나의 클래스만 그 관계를 인식하고 있다.
- 알려진 클래스를 가리키는 개방된 화살표가 있는 직선으로 그린다.
- 표준 제휴와는 달리 알려진 클래스에만 역할 이름과 Multiplicity 값이 포함된다.
- 패키지
- 대형 시스템 또는 비즈니스의 큰 유형을 모델링 한다면, 모델에 다양한 Classifier가 있을 것이다.
- 이 모든 클래스를 관리하기란 매우 어렵다. 그래서 UML은 패키지(package)라는 요소를 제공한다.
- 패키지는 모델러가 모델의 Classifier를 네임스페이스로 구성할 수 있도록 하는데, 이는 일종의 파일링 시스템의 폴더와 같은 것이다.
- 시스템을 다중 패키지로 나누면 시스템은 더욱 이해하기 쉽고, 특히 각 패키지가 시스템의 특정 부분을 나타낼 때 더욱 그렇다.
- 패키지를 그리는 방법은 두 가지가 있다. 표기법 선택에 대한 규칙은 없다.
- 큰 직사각형 안에 패키지의 멤버들을 보여주는 방법
- 큰 직사각형 밖에 패키지의 멤버들을 보여주는 방법
- 인터페이스
- Classifier은 보다 일반적인 개념이고, 여기에는 데이터 유형과 인터페이스가 포함된다.
- 가끔은 구조 다이어그램에서 Classifier 유형들을 모델링 해야 할 때가 있고, 이를 수행할 때 올바른 표기법을 사용하는 것이 중요하다.
- 클래스와 인터페이스는 다르다.
- 클래스는 그 유형의 실제 인스턴스를 가질 수 있다.
- 인터페이스는 이를 실행할 적어도 한 개의 클래스를 가져야 한다.
- UML 2에서 인터페이스는 클래스 모델링 요소를 특화 한 것으로 간주한다. 따라서 인터페이스는 클래스처럼 그려지지만, 직사각형의 맨 위 부분에는 "<<interface>>"라는 텍스트가 붙는다.
- (그림 10)의 다이어그램에서, Professor와 Student 클래스들은 Person 인터페이스를 구현하는 것이다. 상속이 아니다.
- (그림 10)에서 보듯이 속이 비어있는 폐쇄 화살표가 연결된 점선은 구현을 의미한다.
- UML 2 추가.
- 인스턴스
- 시스템의 구조를 모델링 할 때, 클래스의 예제 인스턴스를 보여주는 것이 가끔 유용하다.
- UML 2에서는 엘리먼트를 제공한다. 이것은 시스템의 예시(또는 실제)인스턴스를 사용하여 흥미로운 정보를 보여준다.
- 인스턴스 표기법은 클래스와 같다. 차이점은 이름에 밑줄이 생긴다.
- Instance Name : Class Name
- 예를 들면
- Donald : Person
- 전체 인스턴스의 애트리뷰트와 연산을 포함할 필요는 없다 관심있는 부분만 추가한다.
- 관계에 대한 설명 없이 몇 가지 인스턴스들만 보여주는 것은 쓸모가 없다.
- UML 2에서는 인스턴스 레벨에서 관계/제휴 모델링을 적용한다.
- 제휴 관계는 클래스 다이어그램의 관계와 매치해야 하고, 제휴의 역할 이름역시 클래스 다이어그램과 매치되어야 한다.
- 역할
- 클래스의 인스턴스를 모델링 하는 것은 기대 이상으로 상세하다.
- 가끔 보다 일반적인 레벨에서 클래스의 관계를 모델링 하고 싶을 때가 있다.
- 위와 같은 경우 역할(role)표기법을 사용한다.
- 인스턴스 표기법과 유사하다.
- 박스를 그리고 그 안에, 클래스의 역할 이름과 클래스 이름을 적는다.
- 단, 인스턴스와 다르게 밑줄을 긋지 않는다.
- 평범한 클래스 다이어그램에서 클래스의 역할을 모델링 할 수 없다. (그림18)은 가능한 것처럼 보여도 모델링은 불가능 하다. 역할 표기법을 사용하려면, Internal Structure 표기법을 사용해야 한다.
- Internal Structures 표기법
- UML 2의 새로운 유용한 기능들 중 하나이다.
- 클래스와 또 다른 Classifier가 내부에서 구성되는 방법을 보여주고 있다.
- Plane은 두 개의 ControlSoftware 객체들을 갖고 있고, 각각 두 개의 엔진들을 제어하고 있다. 이 다이어그램의 왼쪽에 있는 ControlSoftware는 엔진 1과 엔진2를 제어한다.
- 결론
- 클래스 다이어그램을 이해해야 하는 이유.
- 시스템에서 Classifier의 정적 구조를 보여주는 것은 중요하다.
- 다이어그램이 UML에서 정한 다른 구조 다이어그램에 대한 기본적인 표기법을 제공하기 때문이다.
'Uml' 카테고리의 다른 글
| UML 작동 다이어그램(Behavioral Diagram) (0) | 2013.02.17 |
|---|