2013년 9월 29일 일요일

UML 패턴

원문 :
Practical UML: A Hands-On Introduction for Developers
By: Randy Miller

번역 : 이원찬

소개

클래스 다이어그램(Class Diagram)은 클래스와 클래스간의 관계를 통해 시스템의 전체적인 모습을 보여줍니다. 클래스 다이어그램은 정적입니다. 즉, 이것은 무엇을 주고받는지를 보여줍니다만 이때 무슨일이 일어나는지를 표현하지는 않습니다.

아래 클래스 다이어그램은 사용자의 쇼핑 주문에 대한 모델링 예제입니다. 여기서 중심이 되는 클래스는 Order입니다. 이것은 Customer가 Payment를 지불하도록 연관되어 있습니다. Payment는 Cash, Check 또는 Credit의 세가지중 하나입니다. 

사용자 삽입 이미지


UML클래스 표기는 사각형안에 클래스명(class name), 속성(attributes), 오퍼레이션(operation)의 세가지 부분으로 나누어 집니다. Payment와 같이 추상클래스(abstract class)는 이탤릭체로 나타냅니다. 클래스간의 관계는 선으로 연결됩니다.

위의 다이어그램은 세가지 관계를 가지고 있습니다.

  • 연관(association) -- 두 클래스의 인스턴스간의 관계. 이 연관에서 한쪽 클래스의 인스턴스는 반드시 반대편 클래스에 대해 알고 있어야만 재대로 작동할 수 있습니다.
  • 집합(aggregation) -- 이 연관은 한 클래스가 컬렉션으로 포함되는것을 나타냅니다. 집합은 다이아몬드 모양의 끝이 포함하는 클래스를 향하도록 나타냅니다. 위의 다이어그램에서는 Order클래스가 OrderDetails의 컬렉션을 포함하고 있습니다.
  • 일반화(generalization) -- 상속연결은 한 클래스가 다른 클래스들의 상위클래스(super class)임을 나타냅니다. 일반화는 삼각형 모양이 상위클래스(super class)를 향하도록 표현합니다. 위의 다이어그램에서 Payment는 Cash, Check, Credit의 상위클래스(super class)입니다.

하나의 연관은 두개의 끝점(end point)을 가집니다. 끝점은 연관의 형태를 명확히 하기위해 역할명(role name)을 가집니다. 예를들어, OrderDetail은 각 Order의 항목(line item)입니다.

운항성(navigability)은 화살표가 가르키는 방향에 있는 클래스를 탐색하거나 질의할 수 있음을 나타냅니다. OrderDetail은 그것의 Item에 대해 질의(query)할 수 있지만 그 반대로는 할 수 없습니다. 화살표는 누가 연관에서 구현을 하는 "주체"인지 알 수 있게 해줍니다. 이경우, OrderDetail은 Item을 가지고 있습니다. 연관에서 화살표를 생략할 경우 묵시적으로 양방향  운항가능성을 내포합니다.

다중성(multiplicity)은 하나의 인스턴스에 연관된 다른쪽 클래스의 가능한 인스턴스의 수를 의미합니다. 다중성은 하나의 숫자 또는 수의 범위로 나타낼 수 있습니다. 위의 예제에서는 각 Order에 하나의 Customer만 연관이 되지만, Customer는 다수의 Order를 가질 수 있습니다. 

아래는 대부분의 다중성을 표현한 것입니다.

표기법                      의미
0..1                          0 또는 하나의 인스턴스. n..m 표기법은 n에서 m까지의 범위.
0..* 또는 *                 0을 포함한 무한수. 제한없음.
1                             명백한 하나.
1..*                          적어도 하나이상.


모든 클래스 다이어그램은 클래스(class), 연관(association), 그리고 다중성(multiplicies)을 가집니다. 운항성(navigability)과 역할은 다이어그램내에서의 위치를 명확히 하기위한 옵션입니다.

모든 클래스 다이어그램은 클래스, 링크, 다중성을 가진다고 언급했습니다. 하지만, 클래스 다이어그램은 더 많은정보를 보여줄 수 있습니다.  우리는 이미 일반화(generalization), 집합(aggregation), 그리고 운항성(navigability)에 대해 알아보았습니다. 지금부터 다음의 항목들에 대해 더 알아 보겠습니다.

  • 합성(composition)
  • 클래스 멤버에 대한 접근성(visibility)과 범위(scope)
  • 종속성(dependencies)과 제약조건(constraints)
  • 인터페이스(interfaces)

합성과 집합(Composition and aggregation)

객체가 특정클래스의 일부로 속하는 연관을 집합(aggregation)이라 했었습니다. 합성(composition)은 이보다 더 강한 연관의 의미로서 객체가 부모(whole)의 일부일 뿐만 아니라 부모없이는 존재할 수 없는것을 의미합니다. 합성은 집합의 표기에서 다이아몬드를 채운형태로 표현됩니다.

아래 다이어그램은 BoxOffice가 반드시 MovieTheater에 속함을 보여줍니다. MovieTheater를 제거하면 BoxOffice도 함께 제거됩니다. 하지만, Movie 컬렉션은 이처럼 MovieTheater와 밀접하게 연관되어있지 않습니다.

 
사용자 삽입 이미지


집합과 합성

집합은 대부분의 경우 연관과 특별히 다른점이 없습니다. UML은 명확한 집합의 정의를 제공하지 않습니다. 그렇기 때문에 집합에 관해 많은 혼란이 생겼으며 실제 UML 2.0에서 집합은 배제되었습니다. 집합에서 명확한 규칙은 두개 또는 그 이상의 객체가 자기자신의 부분이 될수 없고 서로 상대 객체의 부분이 될수 없습니다. 즉, 객체간의 관계의 고리를 만들수 없다는 것입니다.

합성도 집합과 같은 규칙이 적용됩니다. 그리고, 합성은 주인이 피보호자의 수명 전체에 책임을 집니다. 만약, 주인이 복사되면 피보호자도 함께 복사됩니다. 피보호자의 한 인스턴스를 두 주인이 동시에 소유할 수 없습니다. 합성이 사용되는 경우는 딥카피(deep copy)입니다. 즉, 복사된 값이 별도로 변경되는 경우와 같이 특수한 경우에 사용될 수 있습니다.

클래스 정보: 접근성과 범위(visibility and scope)


클래스표기는 클래스명(class name), 속성(attributes), 오퍼레이션(operation)의 세영역으로 나눕니다. 속성과 오퍼레이션은 접근성(access)과 범위(scope)에 따라 레이블을을 붙일 수 있습니다. 여기 새롭게 확장된 Order 클래스를 봅시다.

 
사용자 삽입 이미지

위 그림은 다음의 UML관습(conventions)을 따르고 있습니다.
  • static 멤버는 밑줄로 표현합니다. 반대로, 인스턴스는 밑줄이 없습니다.
  • 오퍼레이션은 다음의 형식을 따릅니다.
    <접근 구분자> <이름> ( <파라미터 목록> ) : <리턴 타입>
  • 파라미터 목록에서 각 타입은 콜론(colon)뒤에 따라옵니다.
  • 접근 구분자는 각 멤버의 맨앞에 위치합니다.
    + : public
    - : private
    # : protected

종속성(dependencies)과 제약조건(constraints)

종속성(dependency)은 두 클래스간의 관계에서 한쪽이 변경되면 다른 한쪽도 영향을 받을 경우를 말합니다. 종속성은 점선으로 표현됩니다. 아래 클래스 다이어그램에서 Co_op는 Company에 종속적입니다. 만일 Company를 변경하기로 마음먹었다면 Co_op또한 변경해야 할것입니다.

사용자 삽입 이미지
 

제약조건(constraints)은 디자인이 연관이 성립되기 위해 만족시켜야할 구현조건을 명시한 것입니다. 제약조건(constraints)은 중괄호( { } )사이에 쓰여집니다. 위의 다이어그램에서 constraint 는 Section이 CourseSchedule의 부분이 될수 있음을 나타냅니다.

인터페이스(Interfaces)와 스테레오타입(Stereotypes)

인터페이스는 오퍼레이션 시그니처의 집합입니다. C++에서 인터페이스는 순수한 가상멤버(virtual members)로만 구성된 추상클래스(abstract class)처럼 구현됩니다. 자바에서는 직접 구현됩니다. 

아래의 클래스 다이어그램은 컨퍼런스과정을 모델링한 예제입니다. 여기서 핵심적인 클래스는 하나의 프레젠테이션을 나타내는 SessionTalk와 하루에 진행되는 SessionTalk의 컬렉션인 Session 입니다. ShuttleSchedule과 그 리스트인 ShuttleStops은 호텔에서 기다리고 있는 참석자들에게 매우 중요합니다. 이 다이어그램은 ShuttleStops가 순서화(ordered)되어 있다는 하나의 제약조건(constraints)을 가집니다.

 
사용자 삽입 이미지

위의 다이어그램은 세개의 인터페이스(interfaces)를 가지고 있습니다: IDated, ILocatable, ITimed. 인터페이스의 이름은 일반적으로 "I"로 시작합니다. 인터페이스명을 포함한 오퍼레이션 시그니처들은 이탤릭(Italic)체로 표현되어 있습니다. 

ShuttleStop은 ILocatable을 구현(또는 구체화)하기 위해 동일한 오퍼레이션(location():String)을 구현하고 있습니다.

ShuttleStop을 <<place>>라는 스테레오타입을 가지고 있습니다. 스테레오타입(stereotypes)은 존재하지 않는 새로운 종류의 모델을 정의하여 UML을 확장시키는 방법을 제공합니다. 그런의미에서 인터페이스(Interface) 또한 스테레오타입의 한종류라 할 수 있습니다. 스테레오타입은 guillemets라는 특수문자 사이에 삽입됩니다만 통상 "<"와 ">"을 두개씩 겹쳐서 "<<" , ">>"으로 표현하기도 합니다.

인터페이스(Interfaces)를 UML로 표현하는데는 두가지 방법이 있습니다. 아래 다이어그램은 위의 다이어그램과 동일하며 막대사탕(lollipop), 또는 원형(circle) 표기법이라 부릅니다.

 
사용자 삽입 이미지


이 표기법에서, 인터페이스는 원형으로 표현되며 구현클래스와 연결되어 있습니다. 이 표기법은 다이어그램의 전체적인 가독성을 높이고 단순화한 장점은 있으나 상세한 정보는 표현되지 않습니다.

댓글 없음:

댓글 쓰기