[펌] UML 설계의 첫걸음

Ⅰ. UML 개요

1. UML 이란..?

   : Unified

   : Modeling Language

   : Object Oriented

   : 적용분야에 제한이 없다.

2. UML 특징

   * 가시화 언어 + 명세화 언어 + 구축언어 + 문서화 언어

3. UML 등장의 의의

   * 표기체계의 통합 및 표준화

   * 개발 프로세스와 개발언어에 독립적 표기체계

   * 적용에 제한없는 범용적 표기체계

----------------------------------------------------------------------------------------

 

4. 모델링

   * 모델 : 간소화 시켜놓은것.

   * 목적 - 시스템의 시각화

             - 시스템의 구조나 행위 명시

             - 시스템 구축 안내 템플릿 제공

             - 결정사항을 문서화

   * 원칙 - 작성할 모델의 적절한 선택

             - 다양한 각도에서 작성 가능

             - 실체의 정확한 반영

             - 하나의 모델은 충분치 않음.

----------------------------------------------------------------------------------------

5. 객체지향

   * 객체 : 현실에 존재하는 실체가 인간의 사고과정을 통해 머리속에 정리된 개념

   * 객체의 조건 = 상태 + 행위 + 식별자

   * 클래스 : 유사한 특성을 가진 객체들의 모임

               = Attribute + Operation

   * 객체지향의 특성

        - 캡슐화 : 속성과 오퍼레이션의 객체내 결합. 정보은폐가능.

        - 추상화 : 실체의 관심부분만 취하는 방식. 다양성을 가짐.

        - 상   속 : Generation 과 Specialization으로 중복 제거.

        - 다형성 : 동일한 외부 명령에 대해 각 객체가 서로 다른 방식으로 수행.

                       고수준의 추상성 제공, 외부에서 객체의 오퍼레이션 접근용이. 재사용성 증대.

   * 객체지향의 장점

        - 실세계를 정확히 반영

        - 하나의 패러다임

        - 재사용성

        - 높은 안정성

   * 객체지향의 단점

        - 전문가 부족

        - 분석, 설계, 구현 모두가 적용되어야 의미 있음.

        - 다소간의 시스템 성능 저하

Ⅱ. UML구성요소

Diagram = Things + Relationships

----------------------------------------------------------------------------------------

1. Diagram

   ① Usecase Diagram

       * 용도 - 사용자관점에서 논리적인 시스템의 기능 정의

                 - 인수측과 개발측이 이해를 같이하는 도구

                 - 시스템 전체 개발범위 결정

                 - 시스템 분석, 설계 기준

                 - 인수테스트 기준

       * 작성시기

           요구정의→분석→기본설계→상세설계→개발→구현

   ② Class Diagram

       * 용도 - SW의 기본구성단위인 클래스와 그들간의 관계 정의

                 - 정적인 관점에서 클래스 구조 표현

                 - 기본적 데이터 모델링 수행(분석단계)

                 - 객체지향 언어코딩을 위한 설계 사양 제공(설계단계)

                 - 분석에서 설계까지 일관된 형식의 SW시스템 분석, 설계 도구

       * 작성시기

           요구정의→분석→기본설계→상세설계→개발→구현

   ③ Sequence Diagram

       * 용도 - 객체들간 협력 과정을 동적으로 정의한 Diagram

                 - 유즈케이스 단위로 작성

                 - 분석에서 설계까지 일관된 형식의 SW 시스템 분석 설계 도구

                 - 클래스 다이어그램과 병행되며 상호간 일관성 요구됨

       * 작성시기

           요구정의→분석→기본설계→상세설계→개발→구현

   ④ Collaboration Diagram

       * 용도 - Sequence Diagram과 동일함.

                 - 객체와 메시지를 구조적으로 표현.

                 - Sequence Diagram과 의미 손실없이 변환 가능.

       * 작성시기

           요구정의→분석→기본설계→상세설계→개발→구현

   ⑤ State Chart Diagram

       * 용도 - 하나의 객체가 생성되어 소멸 될 때까지의 모든 상태를 분석 표현.

       * 작성시기

           요구정의→분석→기본설계→상세설계→개발→구현

   ⑥ Activity Diagram

       * 용도 - 일(Activity)의 수행 순서와 처리흐름 모델링. 플로우 차트와 용도 비슷.

       * 작성시기

           요구정의→분석→기본설계→상세설계→개발→구현

   ⑦ Component Diagram

       * 용도 - 컴포넌트로 이루어진 구성체계 표현. 정적 구성관계 표현.

       * 작성시기

           요구정의→분석→기본설계→상세설계→개발→구현

   ⑧ Deployment Diagram

       * 용도 - 컴퓨팅 환경인 노드와 그 노드에 배치할 컴포넌트 구성을 나타냄.

       * 작성시기

           요구정의→분석→기본설계→상세설계→개발→구현

   ⑨ Object Diagram

       * 용도 - 특정 조건하에서 주요 객체들의 속성과 객체관계를 분석함으로써

                   클래스 모델의 완전성 검증.

       * 작성시기

           요구정의→분석→기본설계→상세설계→개발→구현

----------------------------------------------------------------------------------------

2. Things

    = Structural Things + Behavior!al Things + Grouping Things + Annotation Things

   ① Structural Things

       * Class : 같은 종류의 객체 집합

       * 인터페이스 : 오퍼레이션을 선언만 하고 구현하지 못함.

       * Collaboration(협력) : 구현관점에서 어떤 목적을 달성하기 위한 일련의 행위

                 

       * Use Case : 시스템이 제공하는 서비스 혹은 기능단위

                   

       * Active Class : 하나 이상의 프로세스나 쓰레드를 갖는 객체를 파생하는 클래스 기술

                    

       * Component : 시스템에서 독립적인 실행단위 혹은 배포단위로 관리되는 한 묶음의 SW

                     

       * Node : 연산능력이 있는 물리적 요소(컴퓨팅)

                       

   ② Behavior!al Things(행위사물)

       * Interaction(교류) : 객체들간 주고받는 메시지

                          

       * State Machine(상태머신) : 객체의 상태와 상태간 허용된 액션 정의

                           

    ③ Grouping Things(그룹사물)

       * Package : UML요소를 그룹으로 묶어놓은 것

                                 

   ④ Annotation Things(주해사물)

       * Note : 주석

                     

----------------------------------------------------------------------------------------

3. Relationshhip(관계)

   ① Dependency : 한 쪽사물이 그 역할을 수행키 위해 다른 사물의 도움이 반드시 필요한 경우

                       

   ② Association : 한 쪽 사물에서 상대편 사물 참조.

                       

   ③ Generalization : 상속관계

                       

   ④ Realization : 선언하는 사물과 구현하는 사물간 관계.

                       

----------------------------------------------------------------------------------------

Ⅲ. Use Case Diagram, Use Case 정의서

1. Use Case Diagram 개요

    ① 정의 : 사용자 관점에서 SW 시스템의 범위와 기능 정의.

                 시스템애 해야할 무엇을 작성. 어떻게는 서술하지 않음.

    ② 목적 - 업무범위 정의

               - 사용자 정의

               - 업무기능 정의

               - 사용자 요구사항 정의

               - 사용자와 개발자간 의사소통 도구

               - 분석, 설계 작업 기준

               - 테스트 기준

    ③ 작성단계

        * 액터식별 → 유즈케이스 식별 →         관계정의            →  유즈케이스 구조화

                    

2. Use Case Diagram 구성요소

    ① Actor : 시스템 외부에 독립적으로 존재하면서        ② UseCase : 사용자 관점의 시스템이

                    시스템과 교류하는 것                                                 제공하는 서비스

                                                                     

    ③ Association : 액터와 유즈케이스간 관계

                

          : 상호교류시..                                             : 커뮤니케이션을 받는 쪽이 화살표를 받음.

    ④ Generalization : 액터끼리, 유즈케이스끼리 관계로 일반화 관계 정의

               

          : 화살표를 받는 쪽이 상위개체.

    ⑤  Include : 한 유즈케이스가 다른 유즈케이스에게 서비스를 요청하는 관계

                      서비스는 반드시 수행되어야 함.                   

                   

    ⑤ Extend : 한 유즈케이스가 다른 유즈케이스에게 서비스를 요청하는 관계

                     but 서비스는 조건에 따라 수행될 수도 안 될 수 도 있다.

                

     ex) 프리즘 시스템

       

3. Use Case 정의서

    : Use Case의 처리내용을 기술한 문서

    

    ① 작성시기 : Use Case Diagram이 만들어진 직후

    ② 구성

        = UseCase명+이벤트흐름{기본흐름+선택흐름}+특별요구사항+사전조건+사후조건+확장조건

※ 사례

           

   *  병원관계자가 원하는 기능

      - 진료비는 진료정보를 입력하면 자동 산정된다

      - 환자는 진료예약을 하고, 환자의 과거 병력과 진료정보는 관리된다.

      - 일반 사용자는 병원정보와 의료진 정보를 조회하고 상담한다.

      - 의료진은 자신의 진료스케쥴을 자동 생성하고 진료내역을 관리하고, 환자정보를 조회 한다.

      - 원무와 직원은 이 시스템을 통해 진료비 청구서를 조회, 발행하고, 진료예약을 확정한다.

  =>

Ⅳ. Class Diagram

1. Class Diagram 개요

    ① 정의 : 클래스간 정적인 정의와 관계 표현

    ② 작성목적

        * 클래스 식별 및 관계 정의

        * 클래스간 관계를 정의함으로써 시스템 이해용이.

        * 클래스의 오퍼레이션과 속성을 정의함으로써 SW 시스템 설계

        * 일관된 형식으로 분석설계 방식 제공.

    ③ 작성순서

        * 클래스 정의 → 속성, 오퍼레이션 정의 → 클래스간 관계정의 ┐

               ↑__________________________________________________┘

2. Class Diagram 구성요소

    ① Class

        

    ② Association : 두 클래스간 일반적 협력 관계

: 양방향 관계

: 화살표는 참조 방향

            ex)

            

    ③ Aggregation : 두 클래스간 전체-부분 관계. 각 클래스가 독립적 생명 주기를 갖는다.

        Composition : 두 클래스간 부분-전체 관계. 부분 생명주기가 전체 클래스의 영향을 받음.

              

    ④ Generalization : 두 클래스가 일반화-특수화 관계. 상속(Inheritance)의 특성을 지님.

               

    ⑤ Dependency : 클래스간 사용관계- 다른 객체를 생성하고 소멸시키는 보다 종속적 관계임.

3. Multiplicy와 특별한 Class 간 관계

    ① Multiplicity(관계수) : 클래스가 관계에 참여하는 개체의 수.

           - Many                                                  - Exactly 5

       

           - Zero or more                                        - one to ten

       

            - exactly 2,3,5

       

    ② Multiple Association(다중연관관계) : 두 클래스 간 두 가지 이상의 Association이 존재.

    

    ③ Reflexive Association : 같은 클래스기리 맺어지는 관계

    ④ Qualifier 연관관계 : 관계수가 복잡한 경우

    ⑤ Association Class(연관 클래스) : Association 관계 에서 고유의 속성이나

                                                       오퍼레이션이 필요한 경우

      

4. 사례

Ⅴ. Sequence Diagram

1. Sequence Diagram 개요

    ※ UML은 기존에 제공하지 못했던 객체간 동적 상호 작용을 제공한다.

        이를 Interaction이라 하는데 UML에는 Sequence Diagram과 Colleboration Diagram이

        Interaction Diagram에 속한다.

    ① 정의 : 문제해결에 필요한 객체를 정의하고 객체간 동적 상호관계를 시간순서에 따라 정의.

    ② 작성목적

        * 객체간 동적 상호작용을 시간적 개념을 중시하여 모델링

        * 객체의 오퍼레이션과 속성을 상세히 정의

        * Usecase를 실현

        * 프로그래밍 사양 정의

    ③ 작성시기 : 유즈케이스 다이어그램 정의 후부터 프로그램 코딩전

    ④ 작성순서

        * 작성대상 선정 : 유즈케이스를 선정하고 유즈케이스 정의서 분석

        * 액터 위치시킴 : 액터는 좌측부터 위치..

        * 클래스 위치시킴 : 유즈케이스에 참여하는 클래스 위치.

        * 객체간 메시지정의 : 시간순서대로 객체간 메시지 정의

        * 객체 추가정의 : 요구사항 처리를 위해 필요한 객체가 정의되지 않았으면 추가 정의.

2. Sequence Diagram 구성요소

    ① Thing

        * Actor : Usecase에서의 actor.

        * Object : 클래스의 인스턴스. 클래스 타입으로 선언된 변수형태로 존재.

                      

    ② Rlationship

        * Message : 객체와 객체가 통신하는 유일한 수단

            - Flat Flow of Control : 가장 일반적 메시지

            

            - Nested Flow of Control : 메시지가 중첩 시 메시지가 모두 돌아와야 다음 처리진행

           

            - Asynchronous Flow of control : 메시지의 결과를 기다리지 않고 다음 처리 진행

           

            - Return Flow : 메시지를 처리한 결과. 필요한 경우에만 사용.

            

    ③ etc

        * Life Line : 객체의 생존기간. 점선에 X표시가 객체가 소멸하는 시점.

          

        * Activation : 객체가 활성화 되어있는 기간. -점선표기

                           객체가 외부 메시지를 받고 보낸 메세지를 기다리는 기간.-좁고긴시각형

            

    

3. Sequence Diagram 사례

    ① 설계단계 Sequence Diagram

       

    ② 상세설계단계 Sequence Diagram

       

   단계                     설계단계                      상세설계단계

------------------------------------------------------------------------------------

Actor                     User                                  Buyer System User

------------------------------------------------------------------------------------

Boundary 객체        SearchItemGroupListUI         ListItemGroupUI

------------------------------------------------------------------------------------

Control 객체           ItemGroupCtl                       ICCMItemGroup(<>)

------------------------------------------------------------------------------------

Entity객체               ItemGroupEty                     CMItemGroupDAO(<>),
                                                                    CMItemGroupVO(<>)

------------------------------------------------------------------------------------

                            requestItemGroupInfo          listItemGroup

                            ------------------------------------------------------------------ 

메시지                   searchItemGroupInfo           listItemGroup
                                                                    (searchArg:CMListSearchArg)

                            ------------------------------------------------------------------

                            searchItemGroupInfo           listItemGroup

                                                                   (searchArg:CMListSearchArg,

                                                                     con:Connection)

------------------------------------------------------------------------------------

ex)

모듈. Use case Diagram, Use case/ 6. 유즈케이스 정의서의 사례/ 사례 2를 시퀀스 다이어그램으로 작성한 것입니다. 액터는 Prism Admin입니다. 설계단계에서 나온 것으로 객체들은 Boundary, Control, Entity가 도출되었으며, 아이콘으로 표기되었습니다. 액터로부터 이벤트를 받는 역할은 Boundary인 'CreateWbsCodeView' 객체가 담당 하고, Control인 'WbsMngtCtl' 객체가 비지니스 로직을 담당하는 역할을 하고 있음을 알 수 있습니다. 메시지 1.1.6:*[For each Wbs Code]updateWbsCodePriority():void에서 몇 가지를 살펴 보겠습니다.

- 1.1.6 : 메시지의 흐름 순서를 표기(필수는 아님) - * : 메시지가 반복되는(looping) 것을 표기 - [For each Wbs Code] : 메시지가 실행되기 위한 조건(Guard Condition) - updateWbsCodePriority() : 메시지 명 - void : Return 값

ex) 앞서 언급한 회계 시스템 시퀀스 다이어그램

Ⅵ. Collaboration Diagram

1. Collaboration Diagram 개요

    ① 정의 : Sequence Diagram과 같으며 모델링공간에 제약이 없어 구조적인 면을 중시 가능.

    ② 작성목적

        * 객체간 동적 상호작용을 구조적 측면을 중시하여 작성

        * 객체를 더욱 상세히 정의

        * 유즈케이스 실현

        * 프로그래밍 사양 정의

    ③ 작성시기 : 유즈케이스 작성 후부터 코딩 전.

        ※ 시퀀스 다이어그램과 콜레보레이션 다이어그램 중 하나만 작성하면 됨.

    ④ 작성순서 : Sequence Diagram과  동일.

2. Collaboration Diagram 구성요소

    ① Thing

        * Actor : Sequence Diagram과  동일

        * Object : Sequence Diagram과  동일

    ② Relationship

        * Message

          - Flat Flow of Control

           

         

          - Nested Flow of Control

          

          - Asynchronous Flow of control

           

          - Return Flow

           

        * Link : 객체와 객체간 연관관계.

                   메시지는 링크를 따라 움직이므로 객체가 통신하려면 링크되어 있어야 함.

                  

3. Collaboration Diagram 사례

   

모듈. Use case Diagram, Use case/ 6. 유즈케이스 정의서의 사례/ 사례 2를
컬레보레이션 다이어그램으로 작성한 것입니다. 이 IS 운영시스템을 개발하는 프로젝트
에서는 실제로 작성하지 않았습니다. 앞의 자기진단에서 언급한 것처럼 케이스 도구를
이용하여 시퀀스 다이어그램에서 컬레보레이션 다이어그램을 만들었습니다.
시퀀스 다이어그램에서는 메시지가 위에서 아래로 시간 순서대로 흐르는데,
컬레보레이션 다이어그램에서는 Numbering을 통해서 순서가 나타납니다. 이 또한,
케이스 도구로 컬레보레이션 다이어그램을 자동 생성할 경우, 자동으로 Numbering이
됩니다.

Ⅶ. Activity Diagram

1. Activity Diagram 개요

    ① 정의 : 처리 로직이나 조건에 따른 처리흐름을 순서에 따라 정의한 모델

    ② 작성목적

        * 처리순서 표현 (대상에 관계없이..)

        * 비즈니스 프로세스 정의(이 용도로 가장많이 사용됨) : 업무의 As-is분석, To-be 분석 가능

        * 프로그램 로직 정의 : 처리흐름의 도식화로 프로그램 로직 정의 가능

        * 유즈케이스 실현

    ③ 작성시기 : 그 시점이 한정되어 있지 않고 다양하게 사용 가능

        * 업무 프로세스 정의 시점.

        * 유즈케이스 정의서 작성 시, 처리절차 기술할 때

        * 오퍼레이션 사양 정의시

    ④ 작성순서

        * 작성대상 선정 : 업무프로세스 모델링, 오퍼레이션 사양 정의

           ↓

        * Swim lane 정의 : 대상영역에 명확한 역할을 정의해야 할 때.

           ↓

        * 처리절차 모델링 : 시작점, 끝점 반드시 표현.

2. Activity Diagram 구성요소

    ① Things

        * Activity : 행위나 작업 ( 내부적으로 구조를 가지는 단위0

              ex) 상품조회, 구매결정, 결재내용입력, 결재자지정....

        * Initial State : ●         * Final State : ⊙

            

        * Decision(Branch) : ◇

        * Synchronization bar : 병렬처리절차가 시작되거나 모이는 지점

          

            ex)

                    

    ② Relationship

        * Transition(전이) : 하나의 액티비티가 행위를 완료하고 다른 액티비티로 처리순서가 옮겨

                                    지는 제어흐름 표현 

    ③ Swim lane : 하나의 처리를 구분지음.

       

3. Activity Diagram 사례

    ① SCM 시스템의 일반 정보에 대한 Role 액티비티 다이어그램

        * AS-IS

         

        * TO-BE

         

         → 모든 사용자에게 일반정보를 제공했던 것을 등록여부와 거래품목 등록여부 확인 후

             등록된 사용자에게만 일반정보 제공.

    ② 프리즘에서 유지보수 절차 프로세스를 정의한 액티비티 다이어그램

 

출처 : Tong - e돌람바님의 기타잡동산이통