UML 구조 다이어그램(structure diagram)

UML 2

UML 2의 두 가지 기본적인

구조 다이어그램(structure diagram)
1. 목적은 모델링 되는 시스템의 정적인 구조를 보여주는 것이다.
2. 클래스 다이어그램, 컴포넌트 다이어그램, 객체 다이어그램이 포함된다.
작동 다이어그램(Behavioral Diagram)
1. 시스템의 객체들 간 동적인 작동을 보여준다.
2. 메소드, 협업, 액티비티 등이 포함된다.
3. 액티비티 다이어그램, 유스케이스 다이어그램, 시퀀스 다이어그램 등이 있다.

구조 다이어그램 특징.
1. 모델링 되는 시스템의 정적인 구조를 보여준다.
2. 시간에 상관없이 시스템의 요소들에 초점을 맞춘다.
3. 정적 구조는 시스템에 있는 유형들과 이들의 인스턴스를 나타낸다.
4. 요소들 간 관계를 보여주고 심지어 내부 구조까지도 보여준다.
사용
1. 소프트웨어 라이프 사이클 동안 팀 멤버들에게 유용하게 사용된다.
2. 디자인의 유효성 감사와 개인과 팀들 간 디자인 통신에 사용된다.
  1. 비즈니스 분석가들은 클래스나 객체 다이어그램을 사용하여 계정 대장, 제품, 지리적 계층 같은 비즈니스의 현재 에셋과 리소스를 모델링 할 수 있다.
  2. 아키텍트는 컴포넌트와 전개 다이어그램을 통하여 자신들의 디자인이 튼튼하다는 것을 테스트 및 입증한다.
  3. 개발자들은 클래스 다이어그램을 사용하여 시스템의 코딩 된(또는 코딩 될) 클래스들을 디자인 및 문서화 한다.

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