출처 : https://blog.naver.com/he1000/220725205602


1. 작성 단계 및 유의 사항

  • 1-1. 작성 단계

    클래스 다이어그램을 작성하는 순서는 딱 정해진 바는 없습니다.그러나 프로젝트 현장에서는 다음의 순서대로 작성하는 것이 일반적입니다.물론 순서를 꼭 지켜야만 하는 것은 아닙니다

     

    1. 객체를 식별하고 클래스를 정의합니다

    - 사용자 문서나 유즈케이스 정의서, 문제 기술서등을 참고하여 객체를 식별합니다
    - 식별된 객체를 바탕으로 클래스를 정의합니다
    - 이 단계에서는 클래스 명 정도만 표현합니다

    2. 속성과 오퍼레이션을 정의합니다
    - 클래스의 속성과 오퍼레이션을 정의합니다
    - 한번에 상세한 정의를 마치지 못하므로 여러 번 정제과정을 거쳐야 합니다

    3. 클래스간 관계를 정의합니다
    - 클래스와 클래스간 관계를 정의합니다
    - 관계의 종류를 결정하고, 관계 명을 부여합니다
    - 관계 수를 정의합니다

    4. 정제과정을 반복합니다
    - 클래스 다이어그램은 분석과 설계 과정에서 지속적으로 정제되어야 합니다
    - 다른 모델을 작성하는 과정에 새로운 클래스가 추가되기도 하고, 관계가 변경되기도 합니다.
    - 이러한 변화와 상세화 과정을 클래스 다이어그램에 반영합니다

  • 1-2. 작성시 주의 사항
    다음은 클래스 다이어그램 작성시 주의사항입니다
    1. 모델의 단순성을 유지하도록 합니다
    불필요하게 복잡한 클래스 다이어그램이 되지 않도록 단순성을 유지하는 것이
    좋습니다


    2. 의미있는 이름을 부여하도록 합니다
    클래스 명, 속성 명, 오퍼레이션 명, 관계 명 등은 직관적으로 의미가 이해될 수
    있도록 의미있는 이름으로 정해야 합니다. 명칭은 모호하지 말아야 하고 명확해야
      함은 물론입니다


    3. 포인터나 레퍼런스는 관계성으로 대신합니다
    Association은 그 자체가 상대 클래스의 인스턴스에 대한 포인터나 레퍼런스의
    의미를 이미 가지고 있기 때문에 별도로 정의할 필요가 없습니다


    4. 여러 클래스가 동시에 관계를 가지는 association의 경우는 이를 둘 간의 관계로 분리하는 것이 좋습니다
    세 클래스 이상이 한꺼번에 관계를 가지는 것이 가능합니다. 그러나 이는 구현과정이 어렵기 때문에 미리 두 클래스의 관계로 분리하는 것이 좋습니다

    5. 관계 수는 복잡하지 않게 정의하는 것이 좋습니다

    6. 객체모델은 많은 반복 작업을 통하여 완성합니다
    빈번한 클래스 다이어그램의 수정을 두려워하지 않도록 합니다. 클래스
    다이어그램은 많은 반복 작업을 통하여 완성되는 것임을 명심합시다

 

2. 사례 연구

  • 2-1. 사례1
    다음은 대학에서 교과목과 교수, 학생을 클래스 다이어그램으로 모델링한 사례입니다.
    다이어그램을 잘 살펴보고 의미하는 바를 해석해 봅시다.

      대학에서 교과목과 교수, 학생을 클래스 다이어그램으로 모델링한 사례입니다.
      모델링 초기단계라서 속성과 오퍼레이션은 정의되어 있지 않습니다.
      이 모델은 다음과 같은 정보를 줍니다

      - 교수는 교과목을 3개까지 강의할 수 있습니다
      - 학생은 과목은 수강하지 않거나 네 과목까지 수강할 수 있습니다
      - 한 교과목당 적어도 3명이상 많아도 10명까지 수강할 수 있습니다

  • 2-2. 사례2
    다음은 정보처리 시스템에서 흔히 볼 수 있는 전형적인 클래스입니다.
    다이어그램을 잘 살펴보고 의미하는 바를 해석해 봅시다

      제일 윗쪽의 클래스들은 boundary class입니다. UI를 제어하는 역할을 가집니다.
      Boundary Class
들은 UI 이벤트가 발생할 때 MemberManagement 클래스를
      생성시키고, 이 클래스의 오퍼레이션에 적절한 처리를 의뢰하게 됩니다.
      명령을 접수한 MemberManagement 클래스는 실제로 데이터를 관리하는
      <<entity>>
형 클래스인 Member 클래스에게 실제 데이터를 저장하고 조회하도록
      의뢰합니다. Member 클래스는 Data Base에 접근하여 접수한 처리를
      수행합니다.

      이 예는 정보처리 시스템에서 흔히 볼 수 있는 전형적인 클래스의 구조이자 형태입니다.

  • 2-3. 사례3
    실제 현실에서 경험할 수 있는 사례를 가지고 모델링을 수행한 결과를 살펴보도록
    하겠습니다. 아래에 기술된 문제영역은 모델링의 대상이 되는 주제와 이것과 관련된
    주변정보를 제공합니다. 이 문제영역을 분석하여 클래스 다이어그램을 작성해 보세요.
    그런 다음 다이어그램 보기 버튼을 클릭하여 클래스 다이어그램과 비교해 보시기
    바랍니다.


    A병원은 이번 기회에 SW 시스템을 구축하여 업무의 일부를 자동화 하기를
    원합니다. A병원에는 기존 시스템으로 병원의 수입과 지출을 관리하는
    "
    회계 시스템"이 운영되고 있습니다. 이 시스템과 연계하면서 병원정보, 환자의
    병력 및 진료정보, 의료진 정보의 각종 정보 관리와 진료 예약 처리 및 수납지원을
    수행하는 신규 시스템을 구축하기를 원하고 있습니다.

    병원의 각 관계자는 시스템을 통해 아래와 같은 기능을 수행하기를 원합니다.

    - 진료비는 진료정보를 입력하면 자동 산정됩니다
    - 환자는 진료 예약을 하고, 환자의 과거병력과 진료정보는 관리됩니다
    - 일반사용자는 병원 정보와 의료진 정보를 조회하고 상담 및 문의를 할 수 있습니다.
    - 의료진은 자신의 진료스케쥴을 자동 생성하고, 진료 내역을 관리하고, 환자 정보를 조회하기를 원합니다.
    - 원무과 직원은 이 시스템을 통해 진료비 청구서를 조회,발행하고, 진료예약을 확정하기를 원합니다

      - 오퍼레이션,속성과 관계 수는 생략된 상태입니다
      - 가장 초기상태(Conceptual Level)에 해당되는 모델입니다.
      - 이 클래스들은 모두 <<entity>> 형 클래스입니다
      - 상세화가 진행되면 여기에 추가로 <<control>> <<boundary>> 클래스가 부가되어 사례2와 같은 형태가 됩니다


출처 : https://blog.naver.com/he1000/220725205602

반응형

출처 : https://blog.naver.com/he1000/220722818923


1. Association 관계

  •  1. 정의와 특징
    - Association은 두 클래스간 일반적인 협력 관계가 있을 경우 정의됩니다.
    - Association은 두 클래스의 객체들 사이에 존재하는 공통의 성질 및 의미를 갖는 링크들의 집합에 대한 표현입니다
    - 두 클래스가 서로 Association관계가 있다면 한쪽 객체에서 다른 객체를 참조할 수 있음을 의미합니다
    - Association은 향후 다른 클래스에 대한 포인터나 레퍼런스로 구현됩니다

  •   2. 표기법
       2-1 화살표 없는 실선(양방향 관계)

 

           - 제품과 공급자는 Association관계
           - 
보통 분석단계에서 정의하는 형태
           - 
아직 참조방향이 결정되지 않은
 의미적인 관련성만을 표현한 형태

         2-2 한쪽 화살표를 가진 실선으로 표현(단방향-Navigation 관계)

           - 화살표는 참조의 방향을 나타냄
           - 공급자는 제품을 참조할 수 있지만그 반대는 참조할 수 없음을 나타냄 (Navigation)
           - 
참조방향을 정의하는 것은 모델링 과정에서 진전함을 의미
           - 
클래스간 참조 방향을 정의하는 것이 구현 과정에서 편리

         2-3 여러가지 장식(adornment)이 부가된 상세한 표현

           - Association관계에 대해 표현할 수 있는 모든 것을 표현한 형식
           - 
실무에서는 모든 클래스 다이어그램에서 위와 같은 상세한 표기를 전부 적용하지는 않음
           - 
일반적으로 역할 명 > 관계 명 > 관계 수의 순서로 생략하는 비율이 높음
           - 
관계 수는 가른 두 종류의 부가표현보다 훨씬 의미가 중요하기 때문에상세화가 진행되면서 반드시 정의하고 있음

2. Aggregation 관계

  • 1. 정의 및 특징
    - Aggregation 관계는 Association관계의 일종입니다
    - Aggregation은 두 클래스간에 "전체-부분(whole-part)"의 관계가 있을 경우 정의됩니다
    - Aggregation 관계는 클래스 각각이 독립적인 생명주기를 가집니다. , 전체에 해당되는 클래스가 소멸되더라도 부분에 해당되는 클래스는 소멸하지 않고 계속 존재할 수 있습니다

  • 2. 표기법
    - 속이 빈 마름모가 붙은 실선

           - 마름모가 붙은 쪽이 "전체" 클래스반대쪽은 "부분" 클래스
           - 
왼쪽의 예는 자동차는 1개의  엔진과 1개의 변속기와 4개의 바퀴로 구성된다는 의미 자동차가 소멸되더라도 부품으로서의 엔진 변속기,바퀴는 소멸되지 않음

3. Composition 관계

  • 1. 정의와 특징
    - Composition 관계 역시 Association 관계의 일종입니다
    - Composition 관계는 Aggregation 관계와 유사하게 두 클래스 간에 "부분-전체" (part-of)의 관계가 있을 경우 정의됩니다
    - 그러나 Composition 관계는 부분의 생명주기가 전체의 생명주기에 종속적인 관계입니다. , 전체가 생성될 때 부분도 생성되고, 전체가 소멸될 때 부분도 함께 소멸 합니다.

  • 2. 표기법
    - 속이 찬 마름모가 붙은 실선

           - Aggregation관계와 "전체-부분" 의미는 동일
           - 이 관계는 생명주기가 서로 같은 관계
           - 
왼쪽 예에서 고객등록 윈도우가 생성될 때 저장버튼,취소버튼도 생성됨

           - 고객등록 윈도우가 소멸될 때 저장버튼, 취소 버튼도 소멸. , 부분의 생명주기는 전체의 생명주기에 종속적

4. Generalization 관계

  • 1. 정의와 특징
    - generalization 관계는 두 클래스는 일반화-특수화 관계가 있을 때 정의합니다
    - , 보다 보편적인 것과 보다 구체적인 것 사이의 관계입니다.(is-a 관계라고도합니다)
    - generalization관계는 상속(inheritance) 특성을 가집니다

  • 2. 표기법
    - 삼각형 화살표가 붙은 실선

           - 결재 클래스는 보다 일반적인 클래스 (Generalized Class)이고, 금결재카드결재, e-cash결재는 보다 특수화(Specialized Class)된 관계임
           - 결재 클래스의 속성과 오퍼레이션은 공통적이고 일반적인 것으로 정의되고하위의 3개의 클래스는 자신만의 특수한 속성과 오퍼레이션을 정의함
           - 일반화된 속성, 오퍼레이션과 동일한 것을 하위의 클래스가 정의해야할 필요가 있더라도 이를 정의하지 않음. (상속되어 따로 정의하지 않더라도 일반 클래스의 것을 그대로 사용할 수 있기 때문)

5. Dependency 관계

  • 1. 정의와 특징
    - 한 쪽 클래스가 실행 도중 다른 쪽 클래스의 실행을 요청하는 경우에 정의합니다
    - Dependency 관계는 클래스간의 사용 관계를 표현합니다
    - Association 관계에 비해 훨씬 종속적입니다
    (Association은 존재하는 단순히 다른 객체를 참조하고 실행을 의뢰하지만,
    Dependency 
    관계는 다른 객체를 생성하고,소멸시키는 등 보다 종속적인 관계에
    대해 정의합니다.)

  • 2. 표기법
    - 화살표 붙은 점선

           - TransactionManager 클래스와 Course 클래스 사이에 Dependency 관계가 존재
           - 
위의 예는 TransactionManager 클래스의 오퍼레이션에서 Course 클래스가 파라메터로 사용됨


           [Tip] Dependency 관계로 정의되는 사례
           클래스 사이에 Dependency 관계가 정의되는 경우는 다음과 같습니다.
           (A 
클래스와 B 클래스 사이에 A-->B Dependency 관계를 가정합니다.)

           - B 객체가 A 객체의 오퍼레이션에서 파라메터로 사용될 경우
           - B 객체가 A 객체의 오퍼레이션에서 지역 변수(local variable)로 선언될 경우
           - B 객체가 전역 객체일 경우 (속성과 오퍼레이션 모두 public 접근선언)

6. 클래스 식별 방법

  • 6-1 부적합한 것을 탈락 시키는 방법
    클래스를 식별하는 것은 객체지향 패러다임에 익숙하지 않은 초보자에게 쉬운 일은
    아닙니다. 클래스를 식별하는 쉽고 확실한 방법은 경험이 가져다 주는 직관입니다.
    그러나 초보자에게는 막막하기만 합니다.

    가장 효과적인 방법은 후보 클래스에서 부적합한 것을 탈락시키는 방법입니다.
    초보자가 사용할 수 있는 적절한 방법은 클래스가 될 수 있는 후보 클래스를 가능한 한
    많이 나열한 후 부적합한 것들을 제거해 나가는 방법입니다. 후보 클래스를 나열하기
    위해서는 문제영역을 잘 분석하여 이해하는 것이 선행되어야 합니다.

    클래스를 식별하기 위해서 다음 순서로 진행합니다.

  • 6-2 식별 사례
    다음은 SW 시스템에 대한 문제영역 기술서입니다. 아래의 기술서를 읽어 보고 클래스를
    식별해 봅시다


    "An automatic teller machine accepts a cash card, interacts with the user,
    communicates with the central system to carry out the transaction
    , dispenses cash, and prints receipts. The system requires appropriate
    record keeping and security provisions. The system must handle concurrent
    accesses to the same account correctly. The banks will provide their own
    software for their own computers; you are to design the software for the
    ATMs and the network. The cost of the shared system will be apportioned to
    the banks according to the number of customers with cash cards
    ."

    1. 후보클래스 나열 (명사)
     위 문제 기술서를 토대로 찾아낸 후보 클래스는 다음과 같습니다

    - Software , Banking Network , cashier
    - ATM , Bank , Bank Computer
    - Account, Transaction, Account Data
    - Central Computer, User, Cash, Receipt
    - System , Record Keeping , Security Provision
    - Access , Cost , Customer

    2. 부적합한 것을 탈락 시킨다
    - 문제영역과 상관없는 것 :
    Banking Network , Recording Keeping, System, Security Provision
    - 속성에 해당하는 것 :
    Receipt , Cash , Account Data
    - 모호한 것 :
    Cost

    - 중복된 것 :
    User

    3. 클래스로 채택된 것
    - Account , ATM , Bank
    - Bank Computer, Cash Card , Cashier
    - Central Computer, Customer , Transaction

7. 관계수와 특별한 클래스 간 관계

  • 7-1 관계 수 (Multiplicity)
    1 정의
    - 클래스와 클래스가 인스턴스화 되어 연결 관계를 맺을 때, 관계에 참여하는 객체의 개수를 정의한 것입니다

    - 특정 클래스의 인스턴스에 대해 Association 관계에 있는 다른 클래스의 인스턴스가 몇 개 관련되어 있는가를 의미합니다

    2. 관계 수의 유형
    - Many (* 또는 n )
    클래스 B의 인스턴스 하나에 A 인스턴스 여러 개와 관계

       - Exactly five(5)
       클래스 B의 인스턴스 하나에 A 인스턴스 다섯 개와 관계

       - Zero or more (0..n)
       클래스 B의 인스턴스 하나에 관계된 A 인스턴스가
       없거나 여러 개

       - One to Ten (1..10)
       클래스 B의 인스턴스 하나에 관계된 A 인스턴스가 1개보다 많고 10개 보다 적음

       - Exactly two, three or five(2,3,5)
       클래스 B의 인스턴스 하나에 관계된 A 인스턴스가 2개 혹은 3개 혹은 5개임

  • 7-2. 특별한 클래스간 관계
    1. 다중 연관 관계 (Multiple Association)
    두 클래스간에 두 가지 이상의 Association이 존재하는 경우를 말합니다. 이 경우
    Association
    에는 반드시 관계 명이 정의되어야 합니다. 일반적으로 다중
    연관관계는 바람직하지 않으며, 클래스를 분할하는 방식으로 이를 해소하는 것이
    좋습니다.

       - 사람과 교과목 사이에는 수강하다(사람이 수강생일 경우)와 강의하다(사람이 교수인 경우)의 두 가지 Association이 존재할 수 있습니다.

       2. 재귀 연관 관계 (Reflexive Association)

       같은 클래스끼리 맺어지는 관계가 존재합니다.

       - 과목에는 선수과목이라는 과목이 0개 혹은 다수 개가 존재합니다.

       3. Qualifier 연관관계
       관계 수가 복잡할 때 사용합니다. (one-to-many, many-to-many)
       Qualifier
       - 속성 혹은 속성의 집합이며 이들 값으로 Association에서 객체의 집합을
         
구별하는 목적으로 쓰입니다.
       - Association
에서 객체를 분리하기 위한 Key의 일종으로 간주되기도 합니다.
       - 
복잡한 관계 수를 간략하게 하기 위해 정의합니다.

       한번의 주문(주문 클래스)에는 여러 가지의 주문상품 Item(주문Item)이 있을 수
       있습니다. 원래는 주문에 대한 주문 Item의 관계는 0..n 이었지만, Qaulifier
       "
제품"이 정의된 후의 관계는 0..1로 되었습니다. 왜냐하면 어떤 주문에서 특정
       제품에 대한 주문 Item은 없거나 하나이기 때문입니다.


       4. 연관 클래스(Association Class)
       - 연관 클래스는 Many-to-many Association 관계에서 도출됩니다.
       - Association 관계가 고유의 속성이나 오퍼레이션이 필요할 경우에 정의됩니다
       - Association 관계당 하나의 연관 클래스만이 도출 가능합니다

       첫 번째 모델에서 기술수준이라는 속성을 추가하고 할 때, 그 대상은 사람
       클래스도 부적절하고 기술 클래스도 부적절합니다. Association에 추가해야
       하는데, 이렇게 해서 연관 클래스가 새롭게 정의되었습니다


출처 : https://blog.naver.com/he1000/220722818923 

 

반응형

출처 : https://blog.naver.com/he1000/220718741438
클래스 다이어그램을 처음 작성하면서 찾다가 좋은 글을 발견하여 기록해둔다.


1. 정의

클래스 다이어그램 "시스템에서 사용되는 객체 타입(클래스)을 정의하고 그들 간에 존재하는 정적인 관계를 다양한 방식으로 표현한 다이어그램"입니다.

클래스 다이어그램은 객체지향 SW 시스템을 분석하고 설계하는 데 사용되는 핵심적인 모델입니다. 객체지향 SW 시스템은 클래스와 그 관계로 뼈대가 구성되기 때문에 이를 정의한 클래스 다이어그램은 곧 시스템의 구현될 모습을 정의한 것입니다. 클래스 다이어그램은 분석되거나 설계되는 모든 클래스를 한 장의 다이어그램으로 정의한 것 입니다.

 

클래스 다이어그램은 클래스의 정적인 정의와 관계를 표현합니다. 

객체가 아닌 클래스본질적으로 "정적(靜的)"입니다. 시간과 조건이 개입되지 않기 때문입니다. 그러나 객체그 자체가 동적(動的)인 개념을 가집니다. 클래스에서 파생된 것이
객체이고, 객체는 상태와 행위가 시간과 구체적인 조건에 따라 변화하고, 또한 다른
객체와 동적으로 상호 작용하는 것이기 때문입니다.

2. 작성 목적

단연 대표적인 UML의 다이어그램이라고 할 수 있는 클래스 다이어그램을 작성하는 목적은 다음과 같습니다.

  • 객체지향 SW시스템의 기본 단위인 클래스를 식별하고 그 관계를 정의하는 유용한
    방식을 제공합니다. 클래스 다이어그램은 객체지향 SW 시스템의 기본 단위인 클래스의 정의를
    용이하게 함으로써 시스템을 구축하는 본격적인 단계로 인도
    합니다.

  • 클래스 간의 정적인 협력관계를 정의함으로써 시스템을 이해하는데 용이하게 합니다
    하나의 클래스가 할 수 있는 일은 적습니다. 한 단위의 임무를 수행하려면 클래스간의
    협력은 필수적으로 필요합니다. 클래스 다이어그램은 이러한 클래스간의 정적인
    협력관계를 정의함으로써 시스템을 분석하고 이해하는데 도움을 줍니다.

  • 클래스의 오퍼레이션과 속성을 상세히 정의함으로써 SW시스템을 설계합니다
    클래스의 속성과 오퍼레이션을 상세히 정의하는 일은 객체지향 SW 시스템에
    있어서의 설계를 의미합니다. 클래스 다이어그램은 이러한 설계관점의 작업을 쉽게
    수행하는데 도움을 주어, 시스템 구축 과정에 큰 역할을 합니다.

  • 논리적인 관점으로부터 물리적인 관점까지 시종 일관된 형식으로 SW 시스템을
    분석, 설계하는 방식을 제공합니다
    기존 방식의 가장 큰 단점인 분석/설계 모델간의 차이(gab)를 극복하고, 동일한
    형식과 관점을 제공함으로써 의미의 소실없이 효과적인 시스템 분석, 설계방식을
    제공합니다. 클래스 다이어그램을 적용한 분석설계는 객체지향 프로그래밍에 가장
    가깝고 효과적인 방식입니다.

3. 작성 시기

클래스 다이어그램을 작성하는 시기는 정확히 언제라고 단정할 수는 없습니다.
보통 SW시스템의 분석단계와 설계단계에서 여러 번 작성됩니다. 여러 번에 걸쳐
클래스 다이어그램이 작성되면서 점점 상세화되고 정련되는 과정
을 거칩니다

이렇게 여러 번 작성하는 이유는 이 다이어그램을 작성하는 시기마다 그 관점이
변화하기 때문입니다. 분석단계에서는 분석의 관점에서 클래스를 정의하고
설계단계에서는 설계의 관점에서 클래스를 정의하게 됩니다. 그래서 클래스
다이어그램은 작성이 반복될 때마다 진화하지만, 단계 단계마다 작성되는 클래스
다이어그램 자체도 나름대로 의미가 있습니다.

보통의 경우 아래와 같은 시기에서 클래스 다이어그램이 작성됩니다

A.분석 단계 - B.개략설계 단계 - C.상세 설계 단계

클래스 다이어그램을 작성하려면 사용자의 요구사항이 정의되고, 개발할 SW 시스템에
대한 범위가 정의되어야 합니다

4. 작성시 3가지 관점

Class diagram을 처음부터 상세하게 정의할 수는 없습니다. 그래서 상세한 class
diagram
을 얻기 위해 단계적으로 상세화시켜 나가는 방식을 사용합니다.
Class Diagram
은 다음과 같이 3가지 관점으로 반복적이면서 점증적인 방식으로
작성
해 나갑니다.


Conceptual level
- 개발범위에 속해있는 문제영역에 대해 단순한 관계를 도출하는데 중점
- 업무 관점의 class 들만 도출하고, 구현에 관련된 시각은 최대한으로 배제

Specification level
- 구현관점을 살려 모델링을 수행
- 어떻게 코딩할 건지에 대한 관점을 배제
- 클래스의 속성과 오퍼레이션을 될 수 있는 한 상세히 정의하고, 구체적인 플랫폼(개발언어의 특성 등)특성을 반영하지 않음

Implementation level
- 언어와 개발플랫폼이 가진 특성 및 제한 사항을 반영
- 정의된 class를 보고 정해진 개발언어로 개발자가 코딩을 하기에 충분한 정보를 모두 표현

  • 구성요소
    클래스 다이어그램의 구성요소는 다음과 같습니다.

 

  • 클래스 표기
    일반적인 클래스 표기법
    클래스는 일반적인 표기와 icon 표기 두 가지의 표기가 가능합니다. 일반적인
    표기는 단순형 표기와 정규형 표기등 두 가지가 있습니다



A. 단순형 표기
- 직사각형에 클래스 명을 표기
Conceptual Level(개념 단계)의 클래스
- 다이어그램을 작성할 경우나, 클래스가 많아 그림이 복잡할 경우의 생략형 표현

B. 정규형 표기
- 세 개의 가로 간이 있는 사각형에 각각 클래스 명, 속성, 오퍼레이션을 차례로 표기

스테레오 타입이 정의된 클래스 표기법 >
스테레오 타입이 정의된 클래스의 경우 그 표기법은 달라집니다. 클래스의 스테레오
타입 중 대표적인 것은 <<boundary>> , <<control>> , <<entity>>, <<interface>>

입니다. 이를 일반형 표기와 icon 표기로 나타낸 것은 다음과 같습니다

  • 클래스의 기본 스테레오 타입
    클래스는 크게 대별하면 Boundary, Entity, Control 다음 세 가지 종류로 구분할 수
    있습니다


    <Boundary Class>
    사용자와 인터페이스를 담당하는 클래스입니다.
    주로 UI(User Interface)에 짝을 이루어 정의됩니다.
    이 클래스의 역할은 다음과 같습니다


    - 사용자로부터 UI 이벤트를 직접 받아서 시스템 내부에 처리를 의뢰합니다
    - 시스템으로부터의 응답을 UI를 조작하여 사용자에게 보여 줍니다
    - 사용자의 적절치 못한 입력에 대해서는 오류 메시지 등을 통해 직접 처리합니다

    <Control Class>
    Boundary Class Entity Class사이의 처리를 중재하고 제어하는 클래스입니다.
    이 클래스의 역할은 다음과 같습니다


    - 여러 클래스간의 협력작업을 제어하고 클래스간의 실행순서를 통제합니다
    - 결과를 조합하여 Boundary Class에 전달합니다
    - 데이터를 처리하는 도중에 발생하는 Transaction을 관리합니다

    <Entity Class>
    원하는 처리에 필요한 정보(데이터)를 관리하는 클래스입니다.
    이 클래스의 역할은 다음과 같습니다


    처리에 필요한 데이터를 읽어 옵니다
    - 데이터를 저장합니다
    - 데이터를 삭제합니다
    - 데이터를 수정합니다


출처 : https://blog.naver.com/he1000/220718741438 

반응형

유스케이스 다이어그램을 처음 그려보는데


알기쉽게 정리해둔 블로그가 있어 기록해둔다.


( 출처 : https://googry.tistory.com/2 )



유스케이스 다이어그램


시스템과 사용자의 상호작용을 다이어그램으로 표현한 것으로 사용자의 관점에서 시스템의 서비스 혹은 기능 및 그와 관련한 외부 요소를 보여주는 것이다.

사용자가 시스템 내부에 있는 기능 중에 어떤 기능을 사용 할 수 있는지 나타내며 유스케이스 다이어그램을 사용함으로써 고객과 개발자가 요구사항에 대한 의견을 조율 할 수 있다.


한마디로 사용자랑 시스템사이에 관계를 나타내는 것으로 볼 수 있다.


유스케이스 다이어그램은 프로젝트에 대한 요구사항을 정의하고 세부기능을 분석하며 개발 범위를 정할 때 작성한다.





구성요소(Component)


유스케이스 다이어그램의 구성요소는 시스템(System), 액터(Actor), 유스케이스(Usecase), 관계(Relation)로 구성되어 있다.


1) 시스템(System)

만들고자 하는 프로그램을 나타낸다.


-표기

유스케이스들을 둘러싼 사각형 틀로 시스템 명칭을 안쪽 상단에 작성한다.



2) 액터(Actor)

시스템의 외부에 있고 시스템과 상호작용을 하는 사람(시스템의 기능을 사용하는 사람), 시스템(시스템에 정보를 제공하는 또 다른 시스템)을 말한다.


-표기

원과 선을 조합하여 사람(졸라맨) 모양으로 표현

액터명은 위나 아래에 표시하며 액터의 역할을 작성한다.



3) 유스케이스(Usecase)

사용자 입장에서 바라본 시스템의 기능

시스템이 액터에게 제공해야 하는 기능으로 시스템의 요구사항을 나타낸다.


-표기

타원으로 표시하고 안쪽에 유스케이스명을 작성한다.

유스케이스명은 "~한다"와 같이 동사로 표현한다.




4) 관계(Relation)


액터와 유스케이스 사이의 의미있는 관계를 나타낸다. 종류는 연관(Association), 의존(Dependency), 일반화(Generalization)이 있으며 의존관계는 포함(Include), 확장(Extend)로 나눠진다.


1. 연관관계(Association)는 유스케이스와 액터간의 상호작용이 있음을 표현한다.

유스케이스와 액터를 실선으로 연결한다.

위 그림은 "사용자"(액터)가 "글을 등록한다"(유스케이스)는 기능과 상호작용이 있다는 것을 나타낸다.



2. 포함 관계(Include)는 하나의 유스케이스가 다른 유스케이스의 실행을 전제로 할 때 형성되는 관계이다.

포함되는 유스케이스는 포함하는 유스케이스를 실행하기 위해 반드시 실행되어야 하는 경우에 적용한다.

포함하는 유스케이스에서 포함되는 유스케이스 방향으로 화살표를 점선으로 연결하고 <<include>>라고 표기한다.

위 그림은 "글을 등록한다" 기능을 동작하기 위해서 "로그인 한다" 기능이 반드시 동작되어야 한다는 것을 나타낸다.



3. 확장 관계(Extend)는 확장 기능 유스케이스와 확장 대상 유스케이스 사이에 형성 되는 관계이다.

확장 대상 유스케이스를 수행 할 때 특정 조건에 따라 확장 기능 유스케이스를 수행하는 경우에 적용한다.

확장 기능 유스케이스에서 확장 대상 유스케이스 방향으로 화살표를 점선으로 연결하고 <<extend>>라고 표기한다.

위 그림은 "글을 등록한다" 기능을 수행 할 때 "파일을 첨부한다" 기능을 선택적으로 수행 할 수 있다는 것을 나타낸다.



4. 일반화 관계(Generalization)는 유사한 유스케이스 또는 액터를 모아 추상화한 유스케이스 또는 액터와 연결시켜 그룹을 만들어 이해도를 높이기 위한 관계이다.

구체적인 유스케이스에서 추상적인 유스케이스 방향으로 끝부분이 삼각형으로 표현된 화살표를 실선으로 연결하여 표현한다.

위 그림은 "글을 검색한다"를 "글쓴이로 검색한다"와 "날짜로 검색한다"로 좀더 구체화 한 것을 나타낸다.




작성 순서

유스케이스 작성 순서로는 1. 액터 식별 2. 유스케이스 식별 3. 관계 정의 이다.


1. 액터 식별

액터는 시스템에 관련이 있는 사용자의 역할과 외부 시스템으로 식별 할 수 있다.


액터를 식별하기 위한 질문?

 - 누가 정보를 제공하고, 사용하고, 삭제하는가?

 - 누가 또는 어떤 조직에서 개발될 시스템을 사용할 것인가?

 - 누가 요구사항에 대해 관심을 가지고, 시스템이 만들어낸 결과에 관심이 있는가?

 - 누가 시스템이 잘 운영될 수 있도록 유지보수 및 관리를 하는가?

 - 개발될 시스템과 상호작용하는 하드웨어나 소프트웨어 시스템은 무엇인가?


2. 유스케이스 식별

액터가 요구하는 서비스, 정보를 유스케이스로 식별 할 수 있고 액터가 시스템과 상호작용하는 행위를 유스케이스로도 나타낼 수 있다.


유스케이스를 식별하기 위한 질문?

 - 액터가 원하는 시스템 제공 기능은 무엇인가?

 - 액터는 시스템에 어떤 정보를 생성, 수정, 조회, 삭제하고 싶어 하는가?

 - 모든 기능 요구사항들을 만족할 수 있도록 유스케이스가 모두 식별 되었는가?


3. 관계 정의

액터간, 유스케이스간의 일반화, 연관관계를 정의하고 유스케이스간의 포함, 확장관계를 정의한다.


관계를 식별하기 위한 질문?

 - 연관 관계: 액터와 유스케이스 간에 상호 작용이 존재하는가?

 - 포함 관계: 유스케이스를 실행하기 위하여 반드시 실행되어야 하는 유스케이스가 존재하는가?

 - 확장 관계: 유스케이스를 실행함으로써 선택적으로 실행되는 유스케이스가 존재하는가?

 - 일반화 관계: 액터 또는 유스케이스가 구체화 된 다른 액터 또는 유스케이스를 가지고 있는가?


출처 : https://googry.tistory.com/2

반응형

StarUML을 사용하여 다이어그램을 그리고나서


그린 부분만 캡쳐해서 문서에 넣을 시 그리드, 격자가 눈에 거슬린다.


그리드를 숨기는 방법에 대해 알아보자.




( 사용자 가이드 : http://staruml.sourceforge.net/docs/user-guide(ko)/ch06.html )


사용자 가이드를 보면 그리드를 보이거나 안보이게 할 수 있는데

(도대체 그 옵션이란놈이 어디있는지 보이질 않는다.)


[Tools] - [Options]

를 클릭하여 옵션에 들어가주자


웬만한 StarUML 환경설정은 여기서 하니 위치를 알아두면 좋다.




Options 창이 하나 열릴텐데


[Environment] - [Diagram] - [Grid]

부분을 보면


"Show grid" 라는게 보일텐데 그냥 이것을 체크/언체크 해주면 끝이다

참 간단하다.





위에서 설정을 마치고 OK 버튼을 눌러주면!


이렇게 그리드 격자가 사라진것을 볼 수 있다.






반응형
  1. BlogIcon 팀드모네 2020.12.01 09:54 신고

    감사합니다~~ 👍👍

StarUML 은 클래스 다이어그램 , 유스케이스 다이어그램 등


기타 다이어그램을 그리는 툴/도구 이다.


- Use Case 다이어그램

- Class 다이어그램

- Sequence 다이어그램

- Collaboration 다이어그램

- Statechart 다이어그램

- Activity 다이어그램

- Component 다이어그램

- Deployment 다이어그램

- Composite Structure 다이어그램


이러한 다이어그램 모델링을 도와주는 툴이다.




StarUML을 구글링해 들어가보면 다운로드 받는곳이 두곳이나 있어서 매우 당황스러운데


우선 가장 먼저 나오는


http://staruml.io/


라는 곳은 현재 계속 업데이트를 진행하는 정식버전(?) 이라고도 할 수 있는 공식 홈페이지다.


하지만 이 홈페이지에서 제공하는 StarUML당연히 유료이다.


현재는 3.1.0 까지 나왔으며


"In evaluation mode, there will be watermarks in the exported diagram images. There is no time limit for evaluation, but it is only allowed for evaluation purpose. If you want to use for other purposes including educational, personal, or commercial purpose, you need to purchase licenses."


라는 말을 쓰며 


"평가 모드에서는 내 보낸 다이어그램 이미지에 워터 마크가 있습니다. 평가에는 시간 제한이 없지만 평가 목적으로 만 허용됩니다. 교육, 개인 또는 상업적 목적을 포함한 다른 목적으로 사용하려면 라이센스를 구입해야합니다."


개인으로도 사용하지 못하도록 직접 입장을 말하고있다.


그 전까지는 오픈소스 기반이라 무료로 제공하였지만 새롭게 버전을 내보이면서 유료로 바뀌었다.


무료로제공되는 버전은 StarUML 5.0 이다

(2014년 이후로 업데이트가 전혀 되지않은 무료버전이다...아마도?)


https://sourceforge.net/projects/staruml/


이 무료버전 StarUML을 다운로드 및 설치해보자.


위에 무료 버전을 받는 사이트로 들어가면


떡하니 Download버튼이 있으니 클릭해주도록 하자.




페이지가 넘어가면

그냥 기다리면 5초후에 다운로드가 된다.




다운로드 받은 staruml-5.0-with-cm.exe 파일을 실행해

설치를 진행해 보도록 하자


역시나 Next를 눌러준다.




accept를 체크해주고 Next





설치 경로를 설정해주고

Next





무슨 폴더 이름을 만드는거 같은데

뭔지 모르겠으니 Next




그냥 뭐 바탕화면에 바로가기 만드는거같은데

필요하면 체크 나중에 만들어도 되니 혹시 모르니 그냥 Next 를 눌러주어도 좋다





그냥 지금까지 설정해준것들 체크하는 부분이라 확인 후 이제 Install을 눌러주자




설치를 진행한다.




설치가 완료됐으니 StarUML실행을 체크에 한 상태로 Finish를 눌러주면 자동 실행된다.





이런 화면이 나오면 설치는 끝난것이다.


이제 무료버전인 StarUML을 잘 이용하여 다이어그램을 그려보자





- 기타 무료버전 사용법에 관해서는


http://staruml.sourceforge.net/docs/user-guide(ko)/toc.html


가이드 사이트가 존재하니 참고하도록 하자.



반응형
  1. BlogIcon macgyver 2020.11.20 00:16

    유용한 글 잘 배우고 가여