UML - 관련 정리

CHAP.3 Class Diagram

* Property
    - class의 구조적인 특성을 나타 낸다.
    - 두 가지의 표기법으로 구성된다.
        1) 속성 (Attributes)
        2) 연관 (Associations)

* Attributes (속성)
    - Class box에 한줄로 표시된다.
    - 표현 방법
        # visibility name : type multiplicity = default {property-string}
        # Ex) - name : String [1] = "Untitled" {readOnly}
        # Class Diagram 그림
            

* Associations (연관)
    - Property를 표시 하는 또 다른 방법
    - 저자는 보통 Type이나 Boolean 같은 일반적인 것은 Attributes 방법으로 표시 하고, 중요한 class 는  Association 방법으로 표시 한다.
    - Association 그림
        

* Multiplicity (다중성)
    - Property내에 들어 갈 수 있는 객체의 수
    - 속성 부분의 예제중  String[1] 부분 이다. - name : String [1] = "Untitled" {readOnly} 
    - Mulitplicity 항목
        1) Optional - 하한이 0
        2) Mandatory - 하한이 1
        3) Single-valued - 상한이 1
        4) MultiValued - 상한이 1 이상(흔히 '*'로 표현)
    - 속성에 순서가 의미가 있는 경우 {ordered}를 붙인다.
    - 속성에 중복을 허용 한다면 {nonunique}를 붙인다.
    - 기본값을 명확하게 표현하려면 {unordered}, {unique} 사용
    - 중복을 허용하는 경우 {bag}

* Bidirectional Associations
    - class간에 서로 연관된 property
    - 예제 diagram (일반적으로 Propertye Type이 복수인 경우 cars 라고 namming한다.)
        

    - 속성을 명확하게 표현하기 위해 방향성 화살표를 추가 한다 (일반적으로 화살표 연관 표시는 동사형으로 표시).
        

    - 양방형 association의 경우 association의 한쪽이 둘간의 관계를 통제 해야 한다.

* Operation
   - Class가 수행 하는 action
    - Operation의 표기
        # visibility name (parameter-list) : return-type {property-string}
        # Parameter 표기
            + direction name : type = default value
        # Ex) + balance0n (date : Date) : Money
    - Visibility
        # '-': Private, '#': Protected, '+': Public
    - Operation의 Type
        1) 시스템의 상태를 변경하는 Operation - {query} 로 표시
        2) 시스템의 상태를 변경하지 않는 Operation - {modifier} 또는 {command}
        # {query} 와 {command} 판별 기준은 시스템 변경 여부를 외부에서 관찰 가능 여부에 따른다.
        # Cache 내용이 변경 되었어도 외부에서 변경 여부를 확인 할 수 없으므로 {query}에 해당한다.
        # 일반적로 modifier 또는 command는  void 형을 리턴 하는 것으로 정의 한다.
    - Operation과 Method의 차이
        # Operation - 객체에서 호출되는 Procedure
        # Method - Procedure 자체
        # If you have a supertype with three subtypes, each of which overrides the supertype's getPrice operation, ou have one operation and four methods that implement it

* Generalization
    - Ex) 기업 고객와 일반 고객
        # 기업고객와 일반 고객 class가 customer class로 부터 상속을 받은 경우 기업 고객은 일반고객의 인스턴스가 가능하다.
    - 소프트 웨어 관점에서 일반화는 상속과 연관이 있다.
    - 상속의 효과적인 사용은 substitutability 이다.
    - 위의 예제에서 기업 고객은 고객으로 대치가 가능하며, 이상없이 동작해야 한다.
    - inheritance는 강력한 방법이지만 substitutability를 만족시키는데 overhead가 존재 한다.
    - 디자인 패턴에는 subtyping without subclassing 방법들이 많이 존재 한다.

* Note & Comment
    - 단독으로 사용하거나 설명하고자 하는 요소에 점선으로 연결하여 사용한다.

* Dependency
    - Dependency가 존재 하는 것은 한부분의 변화가 다른 한부분에 영향을 미치는 것이다.
    - 그림으로 표현된 아래 예제는 multilayered app.에서 발생할 수 있는 dedpedency를 보여준다.
        

    - Dependency는 방향성을 가진다.
    - 위의 예제에서 Benefits Window 는 Employee Data Gateway, Benefits Data Gateway와는 간접적인 dependency를 가진다.
    - 프로젝트 수행시 가능하면 dependency를 줄이는 것을 base rule로 삼아야 한다.
    - Class Diagram에서 모든 dependency를 표현하는 것은 쓸모 없는 일이다.
    - 전달하고자 하는 특별한 부분과 밀접한 연관이 있을 경우에만 선택적으로 dependency를 표현 하는 것을 추천한다.
    - 저자가 dependency를 사용하는 경우
        # 어떤 객체가 다른 객체에 parameter로 전달 되는 경우에 사용한다.
        # 이경우 <<parameter>>, <<local>>, <<global>> 과 함께 사용하게 된다.
    - Dependency 분석은 툴을 이용하는 것이 이상적이다.
    - Dependency에서 사용하는 Keyword 일부
        

* Constraint Rules
    - Association, Property, Generalization 은 제약을 명시 하는데 중요한 역할을 한다.
    - Class Diagram은 제약을 표현 하는데 중요한 수단이다.
    - Constraint 을 사용하는 규칙은 '{}' 안에 constraint를 명시 한다.

* When to Use Class Diagrams
    - Class Diagram은 UML의 중요한 요소(backbone) 이다.
    - Class Diagram은 단순한 것부터 시작해라
    - 모든 것에 모델을 그리지 말고, 중요한 부분에 집중해라
    - 다수의 diagram 보다 적은 수의 diagram을 사용 하면서 갱신하는것을 추천한다.
    - Class diagram을 사용할때는 구조에 너무 신경을 써서 action을 무시 해서는 안된다.

* Reference
    UML Distilled A Brief Guide To The Standard Object Modeling Language Chapter 3. Class Diagram

 

CHAP.4 Sequence Diagram

 

* Interaction Diagram
    - 객체들간의 cowork를 설명한다.

* UML에서는 몇가지 interaction diagram이 있다.
    - 그중 Sequence Diagram이 가장 많이 사용된다.

* Sequence Diagram의 장점
    - Diagram 에서 객체간의 동작을 설명할 필요 없이 잘 표시 되어 있다.

* 중앙 집중형 Seq. Diagram 과 분상형 Seq. Diagram
    - 분산형이 객체 지향 설계에 적합하다.
    - 중앙 집중형(Centralized Control)은 모든 로직을 한곳에서 관리 하기 때문에 코드가 복잡해 진다.
    - 분산형(Distributed Control)은 각 객체가 행동에 책임을 가지고 있기 때문에 코드 단순하다.
    - 중앙 집중형에서는 an Order 객체가 aProduct 객체를 리턴 받는다. 모든 부분에서 리턴을 명시하면 diagram이복잡해 진다.
   중요한 부분만 리턴을 명시 하였다.
    - aProduct 객체는 'an order Line'에서 객체를 생성하여 리턴 받으며 getPricingDetails를 호출당하고 소멸된다.

           

    - 첫 번째 메시지는 확인되지 않은 source로부터 발생되기 때문에 메시지를 생성한 참가자가 없다. 이런 메시지를 found message라고 한다.
    - Parcipants의 Seq. Diagram 표현 Syntax
        # name : Class
        # Class는 option 이지만, class를 명시할 경우 ':'를 붙인다.
 
* Creating and Deleting Participants (참가자 생성 & 삭제)
    - Sequence Diagram 참가자 생성 삭제 표시 방법
        # participants 삭제는 'X' 표로 한다.
        # 'X' 표를 향하는 메시지 화살표는 한 참가자가 다른 participants 를 삭제 하는 것을 표시
        # Life line 끝에 'X'표는 participants 가 자기 자신을 삭제 하는 것을 표시
    - Participants Create & Delete 그림
        

* Loops, Conditionals, and the Like (루프 조건문 등등)
    - Seq. Diagram에서의 loop, conditional statement 표현
        # Seq. Diagram에서는 loop, conditional 을 표현 하기에 적합하지 않다.
        # Control structures를 표시 하기에는 activity diagram을 사용하거나 코드 자체를 이용하는 것을 추천한다.
    - Seq. Diagram에서의 loop, conditional statement 표현 예제
        

    - 'loop' operator
        # 반복 조건을 가드에 표시 한다.
    - 'alt' operator
        # 각 조각에 조건을 표시 한다.
    - 'opt' operator
        # 하나의 영역만 조건에 존재 하는 경우에 사용한다.
    - Interaction Frame의 Operator Table
        

    - UML 1 에서의 control logic 표기
        # UML 1에서는 mutual exclusive를 표시 할 수 없다
        # UML 1에서는 반복 표시자는 '*' 를 사용한다.
        # 하나의 loop에서 여러개의 메시지가 나오는 경우 표현에 적합하지 않다.
        # 그림 예제
            

    - UML 표준 에는 데이터를 전달하는 표기 법이 없다.
    - 대부분의 사람들이 이것을 표시 하기 위해 Data Tadpole를 사용한다. (비공식적)

* Seq. Diagram에서 존건문 표기에는 다양한 도식 사용이 가능 하지만, 저자는 이를 표현 하는 것을 코드가 가장 적합하다고 생각한다. 특히 interaction frame이 매우 복잡해지면 diagram의 주제를 흐리기 때문에 저자는 이런 경우 pseudomessages를 선호한다.

* Synchronous and Asynchronous Calls (동기, 비동기 호출)
    - Synchronous & Asynchronous call은 화살표 머리 모양으로 표시한다.
    - Synchronous message
        # filled arrowheads (머리가 채워진 화살표)
        # 호출하는 객체가 return을 대기해야 하는 경우
    - Asynchronous message
        # stick arrowheads
        # 호출하는 객체가 return을 대기할 필요가 없는 경우

* When to Use Sequence Diagrams
    - 하나의 Use case에서 객체간의 interaction을 확인 해야 하는 경우에 사용한다.
    - Action의 정의를 표현하는 데는 적합하지 않다.
    - 만약, 여러 use case에 걸친 하나의 객체의 behavior 을 확인 하고 싶으면 state diagram을 사용해야 한다.
    - 만은 user case 또는 thread에서 동작하는 객체의 behavior 을 보고 싶으면  activity diagram을 사용해야 한다.
    
* Reference
    UML Distilled A Brief Guide To The Standard Object Modeling Language Chapter 4. Sequence Diagram

 

출처 : http://gggura.egloos.com/3452986