[SW Architect] UML

mandu·2025년 6월 13일

[SW Architect]

목록 보기

4/10

1. UML(Unified Modeling Language)

1.1 UML이란?

UML(Unified Modeling Language)은 소프트웨어 집약 시스템의 설계, 명세, 시각화, 구축, 문서화를 위한 표준화된 모델링 언어이다. 객체지향 패러다임을 효과적으로 구현하고 다양한 개발 참여자 간의 의사소통을 원활하게 하기 위해 고안되었다.

복잡한 시스템의 구조와 동작을 다양한 관점에서 시각화 가능
설계자, 개발자, 분석가, 테스트 엔지니어 간의 공통된 언어로 작용
객체지향 분석 및 설계(OOAD)의 핵심 도구이며, Waterfall, UP, Agile 등의 다양한 프로세스와 함께 사용됨
다양한 모델링 방식의 장점을 통합 (데이터 모델링, 워크플로우 모델링, 객체 모델링, 컴포넌트 모델링)
de facto industry standard(사실상의 산업 표준)이며, OMG(객체관리 그룹)에 의해 관리됨
UML 공식 웹사이트: uml.org
무료 사용 도구: PlantUML

1.2 UML의 구조: 4계층 메타모델 아키텍처

UML은 MOF(Meta-Object Facility)를 기반으로 한 4계층 메타모델 구조를 갖고 있다.

계층	이름	설명
M3	Meta-Meta Model	UML을 정의하는 메타메타 모델, MOF 자체
M2	Meta Model	UML의 메타모델로서, UML 다이어그램의 규칙과 요소 정의
M1	Model	개발자가 작성하는 실제 UML 모델 (예: 클래스 다이어그램 등)
M0	Information	실제 실행되는 객체, 시스템, 데이터 등 애플리케이션 레벨의 정보

이러한 계층은 시스템을 점진적으로 추상화하거나 구체화할 수 있도록 도와주며, 모델 간 일관성 유지와 자동화된 도구 연계에 필수적이다.

1.3 UML 다이어그램의 분류 및 개요

UML 2.x 버전은 총 13개의 다이어그램으로 구성되며, 이는 시스템의 정적인 구조와 동적인 행위를 각각 표현하는 데 사용된다. 크게 구조적 다이어그램과 행동적 다이어그램으로 분류된다.

구조적(Structural) 다이어그램

Class Diagram
Object Diagram
Package Diagram
Component Diagram
Composite Structure Diagram
Deployment Diagram

행동적(Behavioral) 다이어그램

Use Case Diagram
Sequence Diagram
Communication Diagram
Activity Diagram
Statechart Diagram
Timing Diagram
Interaction Overview Diagram

각 다이어그램은 특정 목적에 따라 선택되며, 소프트웨어 생명주기의 분석, 설계, 구현, 테스트 단계마다 활용도가 다르다.

1.4 DeepDive: 13 Diagram

1. Use Case Diagram

시스템이 외부 사용자(Actor)에게 제공하는 기능(Use Case)을 시각적으로 표현
시스템 범위와 주요 기능, 사용자 유형, 상호작용 정의에 유용
유스케이스는 단지 다이어그램이 아닌 텍스트 기반 서술이 중심이며, 다이어그램은 개요 수준 요약 수단임(유스케이스 다이어그램이 중요한 게 아님)
유스케이스는 주로 기능적 요구사항을 나타냄
블랙박스 유스케이스를 작성해야 함
- 시스템의 내부 작동 방식, 구성 요소, 설계를 설명하지 말아야 함
- 시스템이 무엇을 하는지(analysis)를 정의하고, 어떻게 하는지(design)는 정의하지 않음
  → Implement decision은 개발자에게 맡김

use case 클릭하면 오른쪽의 detail 내용 나옴
Actor를 위 아래 그려도 되고 너무 빡빡하게 말고 이해만 잘 되게 그려도 됨

Actor
Something with behavior, such as a person, computer system, or organization
Primary Actor(주 액터) : 시스템을 사용해 목표를 달성하는 주체 (예: 계산원)
Supporting Actor(보조 액터) : 시스템에 서비스를 제공하는 주체 (예: 결제 승인 서비스)
Offstage Actor(비활성 액터) : 유스케이스의 동작에 관심은 있지만, 직접 참여하지 않는 주체 (예: 세무 기관)

서술 형식 3가지:

Brief: 한 문단으로 간단 요약
Casual: 다양한 시나리오를 여러 문단으로 표현 → Main Scenario와 Alternative Scenario 구분
Fully Dressed: 전제조건, 주 시나리오, 예외 흐름 등 포함한 정식 서술 형식 → OOAD에서는 FR(Functional Requirement)을 대체함

2. Class Diagram

클래스, 속성, 연산(method), 관계(상속, 집합, 의존 등)를 시각화
도메인 모델링 또는 상세 설계에서 핵심 다이어그램
다른 구조적 다이어그램의 기반이 되는 가장 중요한 다이어그램

클래스 다이어그램은 다양한 관점에서 사용될 수 있음:
- 개념적 관점에서는 Domain model
- 설계 관점에서는 Design Class Diagram (DCD)
속성 접근 권한
- + (public): 모든 객체가 접근 가능
- - (private): 객체 자신만 접근 가능
- # (protected): 클래스와 그 하위 클래스에서 접근 가능
- ~ (package): 동일 패키지 내의 클래스들만 접근 가능
- // (파생 속성): 다른 속성이나 연관 관계로부터 계산된 속성
  - e.g., age는 birthDate로부터 계산될 수 있음
- Operation default: +
  Attribute default: -

속성 종류
1. 데이터 타입:
  - 원시 데이터 타입:
    - 미리 정의된 타입: Boolean, Integer, Unlimited Natural, String
    - 사용자 정의 타입: <<primitive>>
  - 복합 데이터 타입: <<datatype>>
2. 열거형: <<enumeration>>

속성 문법 - 다중성(Multiplicity)
- 속성이 가질 수 있는 값의 개수를 나타냄
  - 기본값: 1
  - 표기법: [min..max]
  - 최대값이 없을 경우: [ * ] 또는 [0..*]

속성 문법 - 속성 특성(Properties)
- 미리 정의된 속성 특성:
  - {readOnly}: 값 변경 불가
  - {unique}: 중복 불가
  - {non-unique}: 중복 허용
  - {ordered}: 고정된 값 순서
  - {unordered}: 순서 없음
- 속성 집합 유형:
  - Set: {unordered, unique}
  - Multi-set (Bag): {unordered, non-unique}
  - Ordered set: {ordered, unique}
  - List: {ordered, non-unique}
연산 문법 - 매개변수(Parameters)
- 매개변수 방향:
  - in: 입력 매개변수
  - out: 출력 매개변수
  - inout: 입력/출력 매개변수

연산 문법 - 반환 타입(Type)
- 연산의 반환 타입을 정의함.
- e.g.,updateLastName(newName: String): boolean
Operation vs Method
- 구현하겠다고 선언하는 Design 단계 용어: Operation
- Operation을 실제로 구현한 코드: Method
클래스 변수(Class Variable)
- 클래스마다 한 번만 정의되며, 해당 클래스의 모든 인스턴스가 공유하는 변수임.
클래스 연산(Class Operation)
- 인스턴스가 생성되지 않아도 사용할 수 있는 연산임.
Getter & Setter
- 속성 접근 연산: 속성 값을 가져오거나 설정하는 연산임
- e.g.,getPNumber()와 setPNumber().
- 너무 많은 getter와 setter가 생길 수 있으므로, 종종 클래스 다이어그램에서는 필터링하여 표시함.

클래스 다이어그램에서 관계:

의존성(Dependency):

의존성 관계는 한 클래스가 다른 클래스를 잠깐 참조하거나 사용할 때 나타냄.
화살표(양뱡향이면 그냥 점선만)로 표시되며, 일시적인 관계임.

class Engine:
    def start(self):
        print("Engine started")

class Car:
    def start_car(self, engine: Engine):
        engine.start()  # 의존성: Car 클래스는 Engine 클래스를 참조함

engine = Engine()
car = Car()
car.start_car(engine)

연관(Association):

연관 관계는 두 클래스가 지속적으로 연결되는 관계를 나타냄.
화살표(양뱡향이면 그냥 실선만)로 표시

class Address:
    def __init__(self, city):
        self.city = city

class Person:
    def __init__(self, name, address: Address):
        self.name = name
        self.address = address  # 연관 관계

address = Address("Seoul")
person = Person("John", address)
print(person.name, person.address.city)

집합(Aggregation):

집합 관계는 클래스가 다른 클래스를 부분으로 포함하지만, 포함된 객체가 삭제되어도 집합을 구성하는 클래스는 영향을 받지 않음.
연관 관계로 집합 관계가 표현 가능하기 때문에 집합 관계를 안 써도 됨

class Engine:
   def start(self):
       print("Engine started")

class Car:
   def __init__(self, engine: Engine):
       self.engine = engine  # 집합 관계

   def start_car(self):
       self.engine.start()

engine = Engine()
car = Car(engine)  # Engine은 독립적으로 존재할 수 있음
car.start_car()

합성(Composition):

합성 관계는 집합 관계의 강한 형태로, 포함된 객체가 삭제되면 그 객체도 함께 삭제되는 관계임.

class Engine:
   def start(self):
       print("Engine started")

class Car:
   def __init__(self):
       self.engine = Engine()  # 합성 관계: Car가 삭제되면 Engine도 삭제됨

   def start_car(self):
       self.engine.start()

car = Car()
car.start_car()

상속(Inheritance):

상속 관계는 한 클래스가 다른 클래스의 속성이나 연산을 상속하는 관계임.
하위 클래스는 상위 클래스의 모든 특성을 물려받고, 재정의(overriding)할 수 있음.

class Animal:
   def speak(self):
       print("Animal speaks")

class Dog(Animal):  # 상속 관계
   def speak(self):
       print("Dog barks")

dog = Dog()
dog.speak()  # Dog는 Animal의 메서드를 상속받아 사용할 수 있음

싱글턴 클래스(Singleton Class):
- 싱글턴 클래스는 하나의 인스턴스만 존재하는 클래스로, 설계상 문제가 될 수 있으므로 주의해야 함.
인터페이스(Interfaces):
- UML에서는 인터페이스 구현을 표현하는 여러 방법을 제공함.
  - 소켓 + 롤리팝 표기법: <<interface>>로 표시되며, 클래스를 통해 구현할 수 있는 인터페이스를 나타냄.
  - 의존성 라인 표기법: 의존성 관계로 인터페이스 구현을 나타낼 수 있음.

3. Object Diagram

실제 객체들과 그들 사이의 관계를 탐색하는 데 유용함.
특정 시점의 객체 인스턴스 상태 표현

4. Package Diagram

클래스들을 패키지 단위로 묶어, 복잡한 클래스 다이어그램을 단순화함
패키지(Package)는 논리적으로 관련된 UML 요소들의 집합
시스템의 논리적 아키텍처를 표현하는 데 사용됨
관련 있는 클래스 묶음을 패키지 단위로 시각화

5. Component Diagram

시스템의 물리적 구성 요소(컴포넌트) 간 의존 관계를 표현
모듈화, 재사용성, 의존성 분석에 유용

6. Composite Structure Diagram

실행 중인 객체들이 통신 링크를 통해 협력하는 구조를 탐색하는 데 사용됨
구성요소의 내부 구조(부분 객체들과 연결 관계 포함)를 보여줌
컴포넌트 내부의 구조, 역할, 포트를 상세히 표현

7. Deployment Diagram

실행 시점의 하드웨어 노드 구성과 그 위에서 동작하는 소프트웨어 구성 요소들을 정적인 관점에서 보여줌
실행 환경에서의 노드 간 관계 및 컴포넌트 배치를 표현
실제 하드웨어와 그 위에 배치된 소프트웨어를 연결해 시각화함

8. Sequence Diagram

시간 순서를 기반으로 한 객체들의 협업 방식을 모델링함
특정 유스케이스 시나리오에서 객체들이 어떻게 상호작용하는지를 보여줌
내부 시스템에 존재하는 객체들에 대해서만 작성
시간 축을 따라 객체 간 메시지 흐름을 표현
Lifeline, Activation, message 등 시간 기반 요소 시각화
- Lifeline: 모델링 되는 인스턴스를 나타냄
  - 네모와 점선으로 이루어져 있음
  - 네모가 객체의 관점으로 표현했다면 클래스이고 서비스 관점으로 표현했으면 컴포넌트
  - 점선은 시간의 경과를 나타냅니다.
- Activation: Lifeline의 인스턴스가 다른 인스턴스와 상호 작용을 하며 활성화 되어 있는 것을 나타냄
  - Activation은 직사각형의 막대로 Lifeline의 점선 가운데에 표시
- Message: 메시지는 인스턴스 간 주고 받은 데이터를 나타냄
  - 일반적으로 요청과 응답 (HTTP 통신 기준)으로 나타냅니다.
  - 3가지 유형을 가짐 (주로 Synchoronuous message와 Response message 사용, Thread일 때만 Asynchronous !)

Other Types of Messages

Signleton Objects는 오른쪽 위에 1 적어주면 됨
Instance Creation
Object Destruction
Combined Fragments and Operators
- 12개의 미리 정의된 연산자 유형
- alt(switch), opt(if), loop, break를 주로 사용
- 다양한 제어 구조를 프레임을 사용하여 모델링함
- 프레임: 연산자와 보호 조건(guard)을 가진 다이어그램의 영역이나 프래그먼트
- 프레임은 중첩될 수 있음
- alt, opt
- loop, break
  - break는 밖에 네모칸이 있으면 네모칸을 벗어나고, 네모칸이 없으면 전체 시나리오 종료
- seq: 여러가지 시나리오가 있으니까 다 고려하라
- ref: 다른 Sequence diagram을 그대로 사용하는 법

9. Communication Diagram

커뮤니케이션 다이어그램(Communication Diagram)은
유스케이스의 동적 동작을 모델링하는 데 사용됨 (Called collaboration diagram)
시퀀스 다이어그램과 유사하지만, 시간 순서보다는 객체 간 협력 구조를 더 중점적으로 표현함
객체 협력을 강조한 다이어그램 (sequence diagram과 목적 유사)
객체 간 관계와 메시지 흐름을 위주로 표현하며, 시간 축보다는 구조에 초점

10. Timing Diagram

타이밍 다이어그램(Timing Diagram)은 주어진 시간 동안 객체들의 행동 변화를 보여줌
시퀀스 다이어그램의 특수한 형태임
시간이 왼쪽에서 오른쪽으로 흐르며, 각 객체의 생명선은 수직으로 나뉜 구획에 표시됨
시간에 따른 객체 상태 변화 집중 표현

11. Interaction Overview Diagram

상호작용 간 제어 흐름의 전체적인 개요에 집중함
액티비티 다이어그램의 변형으로, 각 노드가 상호작용 또는 상호작용 발생(Interaction Occurrence)을 나타냄
다양한 상호작용을 Activity 형식으로 요약 정리

12. Statechart Diagram

하나의 객체(엔터티)가 가질 수 있는 여러 상태와 이벤트에 따라 상태가 어떻게 변화하는지를 보여줌
Statecharts 형식에서 유래되었음
객체의 상태 변화 이력을 Finite State diagram)로 모델링함
객체의 상태(State) 변화와 전이(Transition)를 시각화
각 상태에서 수행되는 동작 및 이벤트 기반 전이 조건 표현
상태 기반 시스템(예: IoT, UI 등) 설계에 적합

13. Activity Diagram

대상 시스템의 제어 흐름을 설명하는 데 도움을 줌
복잡한 비즈니스 규칙이나 작업, 유스케이스 및 비즈니스 프로세스를 표현할 때 사용됨
순서도(Flowchart)와 데이터 흐름도(DFD)의 객체지향 버전이라고 볼 수 있음
복잡한 로직 흐름, 분기, 병렬 처리 등을 시각화
객체 간 연계보다는 프로세스 흐름에 집중
조건, 루프, 병렬 분기, 종료 조건 등 다양한 노드 제공

1.5 UML & OOAD

UML은 객체지향 분석 및 설계(OOAD)의 모든 단계에서 활용된다.

개발 단계	적용 다이어그램
분석 단계 (OOA)	Use Case Diagram, Domain Class Diagram
설계 단계 (OOD)	Sequence Diagram, Class Diagram, State Diagram, Activity Diagram
구현/배포 단계	Component Diagram, Deployment Diagram

UML은 RUP(UP), Agile 등 다양한 개발 방법론과 함께 사용되며, 역할에 따라 필요한 시각화가 달라짐
UML은 개발 방법론이 아닌 모델링 언어이며, 팀 간 공통된 이해를 돕는 도구이다.

1.6 UML 작성 시 유의사항

Use Case는 UI-Free 방식으로 작성 (시스템 동작 설명 X → 사용자 목적과 시스템 책임 중심)
가능하면 Black Box 관점 유지: 시스템 내부 구조나 구현을 기술하지 않음
기능 중심으로 FURPS+의 F 요구사항에 집중하여 표현
시나리오는 명확한 흐름을 가지되, 예외 상황까지 고려하여 설계
용어의 일관성, 명확성 유지 (예: Actor vs System, Event vs Action)

FURPS+
소프트웨어 품질 요구사항을 분류하는 프레임워크로, 기능적 요구사항과 비기능적 요구사항을 체계적으로 구분할 수 있도록 도와주는 모델

항목 설명
Functionality 기능성: 기능, 보안, 상호 운용성 등 시스템이 수행해야 하는 일
Usability 사용성: UI, 학습 용이성, 접근성 등 사용하기 쉬운 정도
Reliability 신뢰성: 오류율, 고장 간 평균 시간(MTBF), 복구 시간 등
Performance 성능: 응답 시간, 처리량, 자원 사용률 등
Supportability 지원성: 유지보수성, 확장성, 테스트 용이성 등

항목	설명
Functionality	기능성: 기능, 보안, 상호 운용성 등 시스템이 수행해야 하는 일
Usability	사용성: UI, 학습 용이성, 접근성 등 사용하기 쉬운 정도
Reliability	신뢰성: 오류율, 고장 간 평균 시간(MTBF), 복구 시간 등
Performance	성능: 응답 시간, 처리량, 자원 사용률 등
Supportability	지원성: 유지보수성, 확장성, 테스트 용이성 등

mandu

만두는 목말라