UML Diagram

• Use Case Diagram
  • Use Case Diagram의 개념
    • 정의
      • Use Case 는 사용자의 입장에서 본 시스템의 행동을 표현
      • 사용자의 요구 사항을 어떻게 문서화 하는가에 대한 방법 제시, 즉 사용자는 Visual한 정의, 개발자는 분석/설계로 전이가 용이
    • 특징
      • 이해하기 쉽고, 사용자 참여 용이
      • SDLC 전 체계에 영향
      • 시스템과 사용자의 관계 정립
    • 구성요소
      • Use Case : 사용자에 의해 수행되는 트랜잭션
      • Actor : Stick man, 시스템 외부에서 시스템의 작동 요인
      • Specification : Use Case 흐름을 기술
      • Relation : 일반적인 사용, extends
    • 수행절차
      Actor 선정 --> Use Case 선정 --> Diagram 작성 --> Spec 작성
  • Actor
    • 정의
      시스템과 상호작용하는 것(Thing: 사람과 사물 모두 포함)
    • 특징
      • 시스템 사용자의 역할을 의미
      • 반드시 시스템 외부에 존재
      • 능동적으로 시스템과 정보 교환/제공이 가능
      • 시스템으로부터 일방적인 정보 수신이 가능
      • 유즈 케이스를 동작시키는 요소
      • 사람, 기계 도는 다른 시스템이 될 수도 있음
    • Actor 기술방법
      • 엑터 명 : 시스템과의 상호작용에서의 역할 중심으로 명명
      • 간단한 설명 : 액터가 상징하는 것이 무엇(누구)인지, 이 액터는 왜 필요한지, 시스템에서 이 액터가 관심을 갖고 있는 것은 무엇인지를 간략히 작성(3~4줄)
  • Use Case
    • 정의
      액터가 해당 시스템을 통해 원하는 결과를 얻어내기까지 시스템 내부에서 이루어지는 이벤트들의 흐름
    • 특징
      • 항상 시스템이 제공하는 특정 기능과 연관된 액터에 의해 시작
      • 액터와 시스템 간의 상호작용을 표현
      • 단순한 기능의 열거가 아닌 이벤트들의 흐름
      • 시작과 끝이 명확하며, 액터에게 결과물을 제공해야 함
  • Use Case 관계
    • 포함(Include) 관계
      2개 이상의 유즈 케이스에서 공통으로 이벤트 흐름이 존재할 때 공통된 이벤트 흐름을 별도의 유즈 케이스로 추출할 경우
    • 확장(Extends) 관계
      • 유즈 케이스의 일부분이 선택적(Optional)인 경우
      • 유즈 케이스의 일부분이 특정 조건에 의해 발생할 경우
      • 기존 유즈 케이스를 수정하지 않고 새로운 요구 사항을 추가로 표현하고자 할 경우
    • 일바화(Generalization) 관계
      구체화된 유즈 케이스는 일반화된 유즈 케이스의 기능과 의미를 상속받고, 자신만의 기능을 추가하거나 재정의한 후 하나의 완전한 유즈 케이스를 생성할 경우
    •    
• Class Diagram
  • Class Diagram의 개요
    • 정의
      여러 가지 객체들의 타입, 즉 클래스들을 표현하고 그 클래스들의 정적인 관계(Associated, Dependent, Specialized, Packaged)를 표현
    • 특징
      • 시스템의 파이프 사이클과 수명을 같이 하며, 하나의 시스템은 여러 개의 Class Diagram으로 표현 가능
      • 시스템에서 사용되는 모든 데이터와 관련된 기능을 속성과 연산으로 표현
      • 클래스는 클래스의 기능별 분류를 나타내는 스테레오 타입을 비롯한 클래스에 대한 자세한 사양을 표현할 수 있음
      • 시스템의 논리적 모델에서 가장 중요한 다이어그램
  • 클래스
    • 정의
      • 클래스는 특정 관점에서 공통적인 속성과 연산을 가지는 객체 집합 명세
      • 구현될 시스템 내의 주요 개념
    • 표기법
      
  • 클래스 스테레오 타입
    • 정의
      • UML의 확정 메커니즘으로 클래스, 컴포넌트,노드 등의 모델 요소들을 의미적인 관점에서 기능별로 분류한 것
      • UML에서 약 40여 가지의 스테레오 타입을 미리 정의하고 있으며, 분석가의 주관적인 관점에서 추가적인 정의도 가능
    • 클래스 스테레오 타입의 종류
      • 경계 클래스(Boundary Class) : 시스템의 외부와 내부 작업 사이의 의사소통을 위한 클래스
      • 엔터티 클래스(Entity Class) : 오랫동안 지속되는 정보를 저장하는 역할을 하는 클래스로, 시스템의 주된 개념
      • 제어 클래스(Control Class) : 다른 클래스를 제어하는 클래스로 논리 제어(Logic Control), 트랜잭션 처리, 여러 개의 엔터티 클래스의 내용을 사용 또는 변경
  • 클래스 관계(Relationship)
    • 특징
      객체들은 서로 연관이 되어 시스템의 행위를 지원하며, 객체들 간의 Collaboration은 관계를 통해 형성
    • 연관(Association) : 독립적인 링크
      클래스 간에 표현되는 개념적 관계로, 클래스 간의 의미적 연결
    • Qualified 연관 관계
      One-to-Many, Many-to-Many 연관에서 사용
    • 포함 관계
      "Part-of" 또는 "Containment' 관계
    • 상속 관계(Generalization-일반화) : Is-A 관계
      • 클래스의 속성/연산을 다른 클래스들이 공유하는 관계
      • 하위 클래스는 하나 이상의 상위 클래스로부터 상속 받는 추상화 계층 정의
           
• Interaction Diagram
  • 특징
    • 객체 간의 상호작용을 표현
    • Interaction Diagram이 필요한 경우 : 하나의 Use Case 내부에 포함된 객체들간의 행위를 보일 때 필요하나, 객체 상호간의 관계에 역점을 두었기 때문에 객체 하나의 행위를 정확하게 표현하기에는 부적절한
  • Sequence Diagram
    • 정의
      시나리오의 흐름을 순차적으로 표현한 다이어그램으로, 객체와 객체 간의 상호작용을 메시지 흐름으로 표시
    • 특징
      • Use Case별로 작성 : 하나의 Use Case에서 다양한 이벤트 흐름별로 작성
      • 시간의 경과에 따른 객체의 상호작용을 표현
      • 분석 단계에서 발견된 객체는 설계 단계에 이르러 모두 클래스에 할당되며, 문장으로 서술된 메시지는 클래스의 연산으로 바뀌게 됨
  • Collaboration Diagram
    • 정의
      객체들 간의 행위를 나타내는 것으로, 객체 간 정적인 구조에 역점을 두고 표현
    • 특징
      • Use Case 별로 작성 : 하나의 Use Case에서 다양한 이벤트 흐름별로 작성
      • 객체들 간에 교환되는 메시지에 초점
           
• State Diagram
  • 정의
    • 특정 클래스의 객체가 가질 수 있는 전체 Use Case에 걸친 상태와 상태 간의 전이를 표현하는 다이어그램
    • 객체가 가질 수 있는 모든 상태와 어떠한 이벤트를 받았을 때의 결과로 어떠한 상태로 변화하는지를 표현
  • 특징
    • 클래스로부터 생성된 객체의 Life history를 표현, 즉 상태(State), 이벤트(Event): 상태전이의 원인, 액션(Action): 상태전이에 대한 결과
    • 각 클래스 마다 하나씩 만들 수 있으며, 하나의 상태 전이 다이어그램에서 객체의 초기 상태를 나타내는 시작 상태는 오직 하나만 존재하며, 객체의 마지막 상태인 종료 상태는 여러 개 존재 가능
    • 설계 단계에서 클래스 객체의 동적인 행동 방식을 표현하는 데 사용
  • 구성요소
    • Event
      특정 시점에서 발생하며, 상태 전이의 원인
    • Transition
      객체가 이벤트로 인해 원래 상태에서 다음 상태로 변화되는 것
    • Guard Condition
      상태 전이 시에 특정 조건을 만족할 경우에만 전이가 이루어지도록 하기 위해 사용되는 속성 값의 불리언 식
    •    
• Activity Diagram
  • 정의
    • Activity의 의미 : 인간이나 컴퓨터에 의해 수행이 필요한 어떠한 업무(task)를 의미하며, 상세화(Specification) 하는 다이어그램, 구현을 위한 다이어그램의 경우 Activity는 클래스의 메소드(Method)가 됨
    • 시스템이 액터에게 제공해야 할 기능을 Activity들의 순차적인 나열로 표시
  • 특징
    • 순서도나 병렬적인 처리를 요하는 행위를 표현할 때 사용하면 유용
    • 순서에 따른 Activity를 나타내는 것으로 모델링하고 있는 다이어그램에서 activity의 의미를 파악하는 것이 중요
  • 구성요소
    • Activity State
      Activity 수행 또는 이벤트 흐름의 단계 표시
    • Transition
      한 Activity 상태에서 다른 Activity 상태로의 전이 표시
    • Decision
      조건 분기 표시
    • Synchronization Bar
      이벤트 흐름에서 동시에 발생하는 스레드들 간에 동기화 표시
    •    
• Component Diagram
  • 정의
    • 시스템의 논리적 모델을 개발자 관점에서 바라본 물리적 모델로 재배치하는 데 사용
    • 어떤 클래스를 어떤 파일에 넣으며, 어떤 파일을 모아 어떤 모듈을 만들 것인지 등을 정의 하는 것
  • 특징
    컴포넌트 모델링은 Component Diagram으로 표현되며, Component Diagram은 시스템을 구성하는 컴포넌트, 컴포넌트 패키지, 그리고 이들 간의 관계로 표현
  • 구성요소
    • Software Component
      • 논리적(Logical) 아키텍처(클래스, 객체, 관계, Collaborations) 안에서 정의된 기능들을 구현한 것
    • Component Stereotype
      Exe, dll, main program, headers, modules, forms
    • Component notation
    • Component Relationship
      • 의존성(Dependency)만 존재(점선)
      • 구현 파일들의 컴파일 시간의 종속 관계 표현
• Deployment Diagram
  • 정의
    • 하드웨어 시스템들은 각각 고유의 특성을 가지고 있고, 이런 환경에서 분산 한경으로의 시스템 구축은 고유 특성을 갖고 있는 시스템 간의 관계를 표현한 다이어그램을 필요로 하게됨
    • 각 시스템마다의 하드웨어, 소프트웨어 컴포넌트들의 관계를 나타냄
  • 특징
    • 프로세서, 장치, 소프트웨어 컴포넌트들의 실행 시간 아키텍처를 설명
    • 시스템 구현 관점에서 컴포넌트들을 노드(node)에 할당
    • 시스템과 다른 노드(프로세서, 장치 등)들 간의 관계 설명
  • 구성요소
    • 노드 : 계산하는(Computational) 단위(대부분 하드웨어적인 부분)를 표현
    • 연결(Connection) : 노드들 간의 통신 연관성을 표현