소프트웨어공학

설계 (Part2) UML 모델링

chlqhrud0208 2024. 10. 21. 15:44

UML 모델링

UML (Unified Modeling Language)

  • 객체 지향 프로그램 설계를 표현하기 위한 표기법
  • 개발자들의 의사소통을 돕기 위해 표준화한 모델링 언어 (실제 언어는 아님)
  • 설계단계 뿐만 아니라 요구 분석(유스케이스 다이어그램)이나 구현 단계에서도 사용 가능
  • 목적 : 가시화, 명세화, 문서화

모델링

  • 요구사항에서 발생한 도메인을 체계화하는 것
  • 중요한 특성들(캡슐화) 사이의 관계를 파악해 다이어그램으로 정형화 하는 것

UML이 필요한 이유

  • UML 모델링이 있으면 개발자간의 빠른 소통이 가능하고 빠른 코딩이 가능
    ( UML 모델링이 없으면 각자 마음대로 설계하여 개발자간의 소통이 어려워지고 빠른 코딩이 불가능 )
  • 개발자가 자신의 설계 결과물을 다른 사람과 효과적으로 주고 받으며 공유할 수 있음
  • 시스템을 가시화하고 설계 단계에서 일관된 해석(나의 생각이 들어가서는 안됨)을 유지하기 위해

UML의 구성요소

  • 사물 : 다이어그램 안에서 관계를 가질 수 있는 대상 (ex. 객체, 기능)
  • 관계 : 사물과 사물 사이의 연관성
  • 다이어그램 : 사물과 관계를 도형으로 나타낸 것 (관점에 따라 선택함)
    - 정적 다이어그램 : 구조적 다이어그램 -> 전체 시스템의 관계
    - 동적 다이어그램 : 행위 다이어그램 -> 객채와 관련 (시간의 흐름)

사물

  • 구조 사물 
    - 모델의 정적인 부분을 정의, 시스템의 개념적 요소를 표현
       (ex. 유스케이스, 노드, 클래스, 컴포넌트...)
  • 행동 사물
    - 모델의 동적인 부분을 정의, 공간과 시간에 따라 달라지는 행위를 표현
       (ex. 상태 머신, 상호작용)
  • 그룹 사물 
    - 요소들을 그룹으로 묶어서 표현
  • 주해 사물
    - 주석과 같은 부가적인 설명

관계 (Relationship)

  • 의존 관계
    - 한 사물이 변경되면 다른 사물에게 영향을 주는 관계 (반대는 성립하지 않음)
  • 연관 관계
    - 객체 사이의 연결 관계
  • 일반화 관계(상속)
    - 일반화된 사물과 더 특수화된 사물 사이의 관계
  • 실체화 관계
    - 사물이 할 수 있거나 해야하는 기능으로 그룹화할 수 있는 관계

다이어그램 (Diagram)

  • 구조적 다이어그램 - 정적 모델링
    - 클래스 다이어그램 : 클래스와 클래스 사이의 관계
       (전체 시스템의 구조를 알고 싶을 때, 시간적 관계 X)
    - 오브젝트 다이어그램 : 특정 시점의 객체와 객체의 관계를 표현
       (동적 같지만 한 시점에 멈췄을 때를 보는 것이기 때문에 동적 아님)
    - 컴포넌트 다이어그램 : 소스코드 간의 관계
       (코드 구현을 할 때 필요)
  • 행위 다이어그램 - 동적 모델링
    - 시퀀스 다이어그램 : 객체들이 주고받는 메시지를 표현
    - 상태 다이어그램 : 하나의 객체가 어떻게 변화하는 지
    - 활동 다이어그램 : 시스템이 어떤 기능을 수행하는지 (시스템 중심)
  • 유스케이스 다이어그램
    - 동적으로 구분하는 경우도 있고 기능적으로 구분하는 경우도 있음
    - 동적 : 액터가 어떤 기능을 수행하고 그 기능이 어떤 기능을 수행함 (순서가 있는 느낌)
    - 기능적 : 전체 시스템에서 어떤 기능이 있고 그 기능간의 관계를 알고자 하는 것이 목적

UML 모델링

장점

  • 설계를 가시화할 수 있음
  • 협업과 커뮤니케이션에 도움이 됨
  • 추상화와 모델링 : 중요한 부분에 집중할 수 있음
  • 유지보수하기가 쉬움
  • 주관적으로 해석할 여지가 없기 때문에 오류감소에 도움을 줌

단점

  • 너무 상세해지면 모델이 복잡해질 수 있음 (추상화의 범위가 애매함)
  • 모델이 다양하기 때문에 어떤 모델을 사용해야할지 혼란
  • 비용과 도구 의존성 (약한 단점)

UML 모델링 과정 (유스케이스 다이어그램이 작성되었을 때)

  1. 요구를 정리하여 유스케이스 다이어그램 작성
  2. 초기 클래스 다이어그램 작성
  3. 유스케이스를 기초하여 시퀀스 다이어그램 작성
  4. 객체 모형 완성
  5. 상태 다이어그램이나 행위 다이어그램을 추가하여 UML 모델 완성

절차지향 모델링

  • UML은 객체지향 모델링임
  • 절차지향 모델링은 UML 모델링이 아님
  • 데이터를 어떻게 주고 받는지에 초점을 맞춤
    ex. 자료흐름도 (DFD)
  • 단점
    - 유지보수가 어려움
    - 코드의 순서가 바뀌면 결과를 보장하기 어려움