schpritz1

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

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

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

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

출처

http://blog.naver.com/westengirl/140003983368

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이
됩니다.

출처

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(<<interface>>)

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

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

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

                            requestItemGroupInfo          listItemGroup

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

메시지                   searchItemGroupInfo           listItemGroup
                                                                    (searchArg:CMListSearchArg)

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

                            searchItemGroupInfo           listItemGroup

                                                                   (searchArg:CMListSearchArg,

                                                                     con:Connection)

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

ex)

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

출처

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. 사례

출처

http://blog.naver.com/westengirl/140003933502

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명+이벤트흐름{기본흐름+선택흐름}+특별요구사항+사전조건+사후조건+확장조건

※ 사례

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

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

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

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

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

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

  =>

출처http://blog.naver.com/westengirl/140003904775