dsgnmstr; Design Monster

[태그:] UML구성요소

  • 클래스 다이어그램의 언어: 이름, 속성, 연산, 접근 제어자 완벽 분석

    클래스 다이어그램의 언어: 이름, 속성, 연산, 접근 제어자 완벽 분석

    복잡하게 얽힌 시스템의 구조를 명쾌하게 보여주는 클래스 다이어그램이라는 지도를 제대로 읽기 위해서는, 먼저 지도에 사용된 기호와 범례, 즉 그 언어의 기본적인 문법을 마스터해야 합니다. 클래스 다이어그램의 가장 핵심적인 문법 요소는 바로 클래스를 표현하는 사각형 안에 담긴 ‘클래스 이름’, ‘속성(Attributes)’, ‘연산(Operations)’, 그리고 이들 앞에 붙는 ‘접근 제어자(Access Modifiers)’입니다. 이 네 가지 구성 요소는 단순한 표기를 넘어, 객체 지향의 핵심 철학인 캡슐화, 정보 은닉, 책임과 역할 등을 시각적으로 응축하고 있습니다.

    이 구성 요소들을 정확히 이해하는 것은 개발자뿐만 아니라, 시스템의 논리적 설계를 파악해야 하는 제품 책임자(PO)나 기획자에게도 필수적입니다. 각 요소가 어떤 의미를 가지며 왜 그렇게 표현되는지를 알게 되면, 기술팀이 작성한 설계도를 더 깊이 있게 해석하고, 비즈니스 요구사항이 어떻게 기술적으로 반영되는지에 대해 훨씬 더 정교하고 원활한 소통을 할 수 있게 됩니다. 정보처리기사 시험의 단골 문제이기도 한 이 네 가지 기본 문법을 하나씩 상세히 분석하여, 클래스 다이어그램이라는 언어를 자유자재로 구사하는 능력을 길러보겠습니다.

    클래스 이름 (Class Name): 모든 것의 정체성

    이름, 그 이상의 의미

    클래스 다이어그램의 시작은 하나의 클래스를 나타내는 사각형과 그 최상단에 위치한 ‘클래스 이름’입니다. 이 이름은 해당 클래스가 시스템 내에서 어떤 개념적, 실체적 대상을 모델링하는지를 나타내는 고유한 정체성입니다. 좋은 클래스 이름은 프로젝트에 참여하는 모두가 그 역할을 즉시 이해할 수 있도록 명확하고 간결해야 하며, 주로 해당 개념을 가장 잘 나타내는 단일 명사를 사용합니다. 예를 들어, User, Order, Product 처럼 도메인(해당 업무 영역)에서 통용되는 용어를 사용하는 것이 이상적입니다.

    이름을 짓는 방식에도 관례가 있습니다. 여러 단어가 조합될 경우, 각 단어의 첫 글자를 대문자로 쓰는 ‘파스칼 케이스(PascalCase)’를 따르는 것이 일반적입니다. ShoppingCart, PaymentGateway 등이 그 예입니다. 클래스 이름은 단순한 라벨이 아니라, 시스템의 어휘를 구성하는 첫 단추입니다. 명확하고 일관된 이름 체계는 다이어그램의 가독성을 높이고, 궁극적으로는 코드의 품질까지 향상시키는 중요한 첫걸음입니다.

    추상 클래스와의 구분: 기울임꼴의 약속

    모든 클래스가 구체적인 실체, 즉 인스턴스를 만들기 위해 존재하는 것은 아닙니다. 어떤 클래스들은 자식 클래스들이 상속받아야 할 공통적인 특징만을 정의하고, 스스로는 인스턴스화될 수 없도록 설계되는데, 이를 ‘추상 클래스(Abstract Class)’라고 합니다. 클래스 다이어그램에서는 이러한 추상 클래스를 일반 클래스와 구분하기 위해 클래스 이름을 기울임꼴(Italics)로 표기하거나, 이름 아래 {abstract} 라는 제약 조건을 명시하는 약속을 사용합니다.

    예를 들어, Shape 라는 추상 클래스는 draw() 라는 추상 연산을 가질 수 있습니다. Shape 자체는 인스턴스를 만들 수 없지만, 이를 상속받는 Circle, Rectangle 같은 구체적인 클래스들이 각자의 draw() 연산을 반드시 구현하도록 강제하는 역할을 합니다. 다이어그램에서 Shape 라는 이름이 기울임꼴로 되어 있다면, 우리는 이 클래스가 직접 사용되기보다는 다른 클래스들의 부모 역할을 하는 템플릿이라는 중요한 정보를 즉시 파악할 수 있습니다.

    속성 (Attributes): 객체의 상태를 정의하다

    속성의 기본 문법과 데이터 타입

    클래스 이름 아래, 사각형의 두 번째 구획은 클래스의 ‘속성’을 나열하는 공간입니다. 속성은 해당 클래스의 인스턴스가 가지게 될 정적인 데이터나 상태 정보를 의미하며, 클래스의 구조적 특징을 나타냅니다. 각각의 속성은 일반적으로 접근제어자 이름: 타입 = 기본값의 형식을 따릅니다. 예를 들어, User 클래스의 속성 - name: String = "Guest" 는 name 이라는 속성이 비공개(private) 접근 권한을 가지며, 문자열(String) 타입의 데이터를 저장하고, 별도로 지정하지 않으면 “Guest”라는 기본값을 가진다는 풍부한 정보를 담고 있습니다.

    속성의 데이터 타입은 int, boolean 과 같은 원시적인 데이터 타입을 명시할 수도 있고, Address, Date 와 같이 다른 클래스의 이름을 타입으로 지정할 수도 있습니다. 이는 해당 속성이 다른 객체에 대한 참조를 저장한다는 것을 의미하며, 클래스 간의 관계를 암시하는 중요한 단서가 됩니다. 이처럼 속성 정의는 클래스가 어떤 종류의 데이터를 품고 있는지를 명확하게 보여주는 역할을 합니다.

    정적 속성과 파생 속성: 특별한 의미를 담다

    일반적인 속성 외에도 특별한 의미를 지닌 속성들이 있습니다. ‘정적 속성(Static Attribute)’은 특정 인스턴스에 종속되지 않고 클래스 자체에 속하는 변수를 의미합니다. 다이어그램에서는 속성 이름에 밑줄을 그어 표현합니다. 예를 들어, User 클래스에 _numberOfUsers: int 라는 정적 속성이 있다면, 이는 생성된 모든 User 인스턴스가 공유하는 값으로, 전체 사용자 수를 나타내는 데 사용될 수 있습니다.

    ‘파생 속성(Derived Attribute)’은 다른 속성의 값으로부터 계산되어 유추할 수 있는 속성을 의미하며, 이름 앞에 슬래시(/)를 붙여 표현합니다. 예를 들어, Person 클래스에 - birthDate: Date 라는 속성이 있을 때, / age: int 라는 파생 속성을 정의할 수 있습니다. age는 birthDate 와 현재 날짜만 있으면 언제든지 계산할 수 있으므로 별도의 데이터로 저장할 필요가 없음을 나타냅니다. 이는 데이터의 중복을 피하고 모델을 더 명확하게 만드는 데 도움을 줍니다.

    연산 (Operations): 객체의 행동을 설계하다

    연산의 시그니처: 무엇을 받고 무엇을 돌려주는가

    사각형의 가장 아래 구획을 차지하는 ‘연산’은 클래스가 수행할 수 있는 행동, 즉 동적인 책임을 나타냅니다. 각 연산은 고유한 시그니처(Signature)를 가지며, 이는 접근제어자 이름(파라미터 목록): 반환 타입의 형식으로 구성됩니다. 예를 들어, + calculatePrice(quantity: int, discountRate: float): float 라는 연산 시그니처는 다음과 같은 정보를 제공합니다. 이 연산은 외부에서 호출할 수 있으며(public), 이름은 calculatePrice 이고, 정수형 quantity 와 실수형 discountRate를 입력받아, 계산 결과를 실수형(float)으로 반환한다는 것입니다.

    파라미터 목록과 반환 타입은 이 연산이 다른 객체와 어떻게 상호작용하는지를 보여주는 명세서와 같습니다. 이를 통해 개발자는 연산의 구체적인 구현 코드를 보지 않고도 이 기능을 어떻게 사용해야 하는지를 정확히 알 수 있습니다.

    생성자와 소멸자: 인스턴스의 탄생과 죽음

    연산 중에는 인스턴스의 생명주기와 관련된 특별한 연산들이 있습니다. ‘생성자(Constructor)’는 클래스의 인스턴스가 생성될 때 단 한 번 호출되는 특별한 연산으로, 주로 속성을 초기화하는 역할을 합니다. UML에서는 <<create>> 라는 스테레오타입을 붙여 표현하거나, 클래스와 동일한 이름을 가진 연산으로 표기하기도 합니다.

    반대로 ‘소멸자(Destructor)’는 인스턴스가 메모리에서 해제될 때 호출되는 연산으로, 객체가 사용하던 자원을 정리하는 역할을 합니다. 이는 <<destroy>> 스테레오타입으로 표현됩니다. 자바처럼 가비지 컬렉터가 자동 메모리 관리를 해주는 언어에서는 소멸자를 명시적으로 사용하는 경우가 드물지만, C++과 같이 수동 메모리 관리가 필요한 언어에서는 매우 중요한 역할을 합니다.

    정적 연산과 추상 연산: 공유되거나 약속된 행동

    속성과 마찬가지로 연산에도 정적(Static)이거나 추상(Abstract)적인 경우가 있습니다. ‘정적 연산’은 특정 인스턴스를 생성하지 않고도 클래스 이름을 통해 직접 호출할 수 있는 연산으로, 이름에 밑줄을 그어 표현합니다. 주로 인스턴스의 상태와 관계없는 유틸리티 기능을 제공할 때 사용됩니다. Math.max(a, b) 와 같이 객체 생성 없이 사용하는 기능이 대표적인 예입니다.

    ‘추상 연산’은 추상 클래스 내부에 선언되며, 실제 구현 코드가 없는 껍데기뿐인 연산입니다. 이름 부분을 기울임꼴(Italics)로 표기하여 나타냅니다. 이는 자식 클래스에게 “이러한 이름과 시그니처를 가진 연산을 너희 각자의 상황에 맞게 반드시 구현해야 한다”고 강제하는 일종의 계약서 역할을 합니다.

    접근 제어자 (Access Modifiers): 정보 은닉과 캡슐화의 미학

    Public (+): 모두를 위한 공개 창구

    + 기호로 표시되는 public은 가장 개방적인 접근 수준을 의미합니다. public으로 선언된 속성이나 연산은 프로젝트 내의 어떤 다른 클래스에서도 자유롭게 접근하고 사용할 수 있습니다. 일반적으로 클래스가 외부에 제공해야 할 공식적인 기능, 즉 API(Application Programming Interface) 역할을 하는 연산들을 public으로 지정합니다. 이를 통해 객체는 자신의 내부는 감추면서도 외부와 소통할 수 있는 명확한 창구를 제공하게 됩니다.

    Private (-): 나만이 아는 비밀

    - 기호로 표시되는 private은 가장 폐쇄적인 접근 수준입니다. private으로 선언된 속성이나 연산은 오직 해당 클래스 내부에서만 접근할 수 있으며, 외부에서는 존재조차 알 수 없습니다. 이는 객체 지향의 핵심 원리인 ‘캡슐화(Encapsulation)’와 ‘정보 은닉(Information Hiding)’을 구현하는 가장 중요한 장치입니다. 클래스의 민감한 데이터나 내부적으로만 사용되는 복잡한 로직을 private으로 감춤으로써, 데이터의 무결성을 지키고 외부의 변경에 흔들리지 않는 안정적인 객체를 만들 수 있습니다. 일반적으로 모든 속성은 private으로 선언하는 것이 권장됩니다.

    Protected (#): 우리 가족에게만

    # 기호로 표시되는 protected는 private과 public의 중간적인 성격을 가집니다. protected로 선언된 멤버는 해당 클래스 내부와, 그 클래스를 상속받은 자식 클래스 내부까지만 접근이 허용됩니다. 이는 상속 관계에 있는 클래스들, 즉 하나의 ‘가족’ 내에서만 공유하고 싶은 정보나 기능을 정의할 때 유용하게 사용됩니다. 외부에는 공개하고 싶지 않지만, 자식 클래스가 부모의 기능을 확장하거나 재정의하는 데 필요한 최소한의 정보를 제공하는 역할을 합니다.

    Package (~): 우리 동네 이웃에게만

    ~ 기호로 표시되는 package 접근 제어자는 동일한 패키지(또는 네임스페이스)에 속한 클래스들 사이에서의 접근을 허용합니다. 패키지는 서로 관련 있는 클래스들을 묶어놓은 하나의 디렉토리와 같은 개념입니다. package 접근 제어는 아주 밀접하게 협력해야 하는 클래스들의 그룹 안에서는 비교적 자유로운 접근을 허용하되, 이 그룹 외부에서는 해당 멤버를 감추고 싶을 때 사용됩니다. 이는 시스템을 기능 단위의 모듈(패키지)로 설계할 때 모듈 내부의 응집도를 높이는 데 도움을 줍니다.

    종합 예제: 온라인 서점의 ‘Book’ 클래스 분석

    지금까지 배운 모든 구성 요소를 종합하여 온라인 서점의 Book 클래스를 분석해 봅시다.

    ### Book (클래스 이름)

    - isbn: String {isID} - title: String - price: int # author: Author _minStock: int = 10 / finalPrice: float

    + Book(isbn: String, title: String)

    + getDetailInfo(): String

    – checkStock(): boolean

    # applyDiscount(rate: float): void

    _getTaxRate(): float

    위 다이어그램은 다음과 같이 해석할 수 있습니다. Book이라는 클래스가 있으며, 고유 식별자인 isbn과 title, price는 외부에서 직접 수정할 수 없는 private 속성입니다. 저자 정보(author)는 Author 클래스의 인스턴스로, 상속 관계에 있는 클래스에서는 접근 가능한 protected 입니다. 모든 책이 공유하는 최소 재고량(minStock)은 10이라는 기본값을 가진 static 속성입니다. 최종 판매가(finalPrice)는 가격과 세금 등을 조합하여 계산되는 derived 속성입니다.

    연산으로는 ISBN과 제목으로 인스턴스를 생성하는 public 생성자가 있고, 책의 상세 정보를 외부에 제공하는 public 연산 getDetailInfo()가 있습니다. 재고를 확인하는 checkStock()은 내부적으로만 사용되는 private 연산이며, 할인율을 적용하는 applyDiscount()는 상속받은 특별한 책(예: SaleBook)에서만 사용할 수 있는 protected 연산입니다. 마지막으로, 모든 책에 공통으로 적용되는 세율을 반환하는 getTaxRate()는 인스턴스 생성 없이 호출 가능한 static 연산입니다.

    결론: 시스템 설계를 읽고 쓰는 능력의 기초

    구성 요소 이해의 중요성

    클래스 다이어그램의 네 가지 핵심 구성 요소는 단순히 그림을 그리기 위한 기호가 아닙니다. 이들은 객체 지향 설계의 핵심 원칙과 철학을 담아내는 정교한 언어 체계입니다. 클래스 이름은 시스템의 어휘를, 속성은 데이터의 구조와 상태를, 연산은 객체의 책임과 행동을, 접근 제어자는 캡슐화와 정보 은닉의 수준을 결정합니다. 이 언어를 정확히 이해하고 사용할 때, 우리는 비로소 모호함 없이 견고하고 유연한 시스템의 청사진을 그리고 읽을 수 있게 됩니다.

    제품 설계 관점에서의 시사점

    제품 책임자나 기획자에게 이러한 이해는 개발팀과의 소통 수준을 한 차원 높여줍니다. 속성이 왜 대부분 private인지 이해하면, 특정 데이터를 변경하기 위해 왜 별도의 public 연산(예: updateProfile())이 필요한지를 납득하게 됩니다. protected와 상속의 개념을 알면, 서비스의 확장성을 고려한 설계에 대해 더 깊이 있는 논의를 할 수 있습니다. 결국 클래스 다이어그램의 구성 요소를 이해하는 것은 기술적 장벽을 넘어, 제품의 논리적 구조를 함께 만들어가는 파트너가 되기 위한 필수적인 교양 지식이라고 할 수 있습니다.

  • UML 구성요소

    UML 구성요소

    UML, 즉 통합 모델링 언어는 사물(Things), 관계(Relationships), 다이어그램(Diagrams)이라는 세 가지 핵심 요소로 구성됩니다. 이들은 마치 언어의 단어, 문법, 문장처럼 작용하여, 복잡한 소프트웨어 시스템의 구조와 동작을 명확하고 체계적으로 표현하는 기반을 이룹니다. 사물은 시스템을 구성하는 추상적인 개념 그 자체이며, 관계는 이 사물들 사이의 의미 있는 연결을 정의합니다. 그리고 다이어그램은 특정 목적에 맞게 사물과 관계를 조합하여 시스템의 한 단면을 시각적으로 보여주는 청사진입니다. 이 세 가지 구성요소의 조화를 통해 우리는 비로소 시스템에 대한 깊이 있는 분석과 설계를 수행할 수 있습니다.

    UML의 기본 단위, 사물 (Things)

    사물(Things)은 UML 모델을 구성하는 가장 기본적인 요소로, 시스템의 개념을 나타내는 명사(Nouns)와 같습니다. 이는 눈에 보이는 물리적 객체일 수도 있고, 추상적인 개념일 수도 있습니다. 사물은 그 역할에 따라 크게 네 가지로 분류됩니다.

    구조 사물 (Structural Things)

    구조 사물은 모델의 정적인 부분, 즉 시스템의 뼈대를 이루는 요소들입니다. 시간에 따라 변하지 않는 시스템의 구조, 개념, 물리적 요소를 표현합니다. 대표적으로 클래스(Class)는 객체를 생성하기 위한 설계도이며, 인터페이스(Interface)는 객체가 외부에 제공하는 기능의 명세입니다. 유스케이스(Use Case)는 사용자의 관점에서 시스템이 제공하는 기능 단위를, 컴포넌트(Component)는 시스템을 구성하는 독립적인 소프트웨어 모듈을, 노드(Node)는 소프트웨어가 실행되는 물리적인 하드웨어 장치를 의미합니다.

    행동 사물 (Behavioral Things)

    행동 사물은 모델의 동적인 부분, 즉 시스템의 행위를 나타내는 동사(Verbs)와 같습니다. 시간에 따라 변화하는 시스템의 동작을 표현합니다. 대표적으로 상호작용(Interaction)은 특정 기능을 수행하기 위해 객체 간에 주고받는 메시지의 흐름을 의미하며, 상태 머신(State Machine)은 하나의 객체가 생성되어 소멸될 때까지 겪게 되는 상태의 변화 과정을 나타냅니다.

    그룹 사물 (Grouping Things)

    그룹 사물은 UML의 여러 구성 요소를 담는 상자 역할을 하여 모델을 체계적으로 구성하고 관리하는 데 사용됩니다. 가장 대표적인 그룹 사물은 패키지(Package)로, 관련된 클래스나 유스케이스 등을 하나의 폴더처럼 묶어 모델의 복잡도를 낮추고 이해도를 높이는 역할을 합니다.

    주해 사물 (Annotational Things)

    주해 사물은 모델의 다른 요소들을 부가적으로 설명하거나 주석을 다는 데 사용됩니다. 마치 코드의 주석처럼, 다이어그램에 추가적인 정보를 제공하여 다른 사람의 이해를 돕는 역할을 합니다. 대표적인 주해 사물로는 노트(Note)가 있으며, 다이어그램의 특정 요소에 점선으로 연결하여 설명을 덧붙이는 형태로 사용됩니다.

    사물을 연결하는 힘, 관계 (Relationships)

    관계(Relationships)는 사물과 사물 사이의 의미 있는 연결을 표현하는 문법과 같은 역할을 합니다. 이 관계를 통해 각 사물이 어떻게 상호작용하고 서로에게 영향을 미치는지를 정의할 수 있습니다. UML에서는 주로 다음과 같은 관계들을 사용합니다.

    연관 관계 (Association)

    연관 관계는 클래스들 사이에 존재하는 일반적인 구조적 연결을 의미합니다. 한 클래스의 객체가 다른 클래스의 객체를 사용하는 ‘has-a’ 또는 ‘uses-a’ 관계를 나타내며 실선으로 표현합니다. 예를 들어, ‘고객’ 클래스와 ‘주소’ 클래스는 ‘고객이 주소를 가진다’는 연관 관계를 맺을 수 있습니다.

    집합 관계 (Aggregation)

    집합 관계는 전체와 부분의 관계(whole-part)를 나타내는 특수한 연관 관계입니다. 하지만 부분이 전체에 종속되지 않고 독립적인 생명주기를 가집니다. 예를 들어, ‘컴퓨터’와 ‘주변기기’의 관계에서 컴퓨터가 없어져도 마우스나 키보드는 독립적으로 존재할 수 있습니다. 전체 쪽에 속이 빈 다이아몬드(◇)로 표현합니다.

    복합 관계 (Composition)

    복합 관계는 집합 관계보다 더 강한 전체-부분 관계를 의미합니다. 부분이 전체에 완전히 종속되어, 전체가 사라지면 부분도 함께 사라지는 생명주기를 공유합니다. 예를 들어, ‘건물’과 ‘방’의 관계에서 건물이 철거되면 방도 함께 사라집니다. 전체 쪽에 속이 채워진 다이아몬드(◆)로 표현합니다.

    일반화 관계 (Generalization)

    일반화 관계는 ‘is-a-kind-of’ 관계, 즉 객체 지향의 상속 관계를 나타냅니다. 더 일반적인 개념인 상위 클래스(부모)와 더 구체적인 개념인 하위 클래스(자식) 간의 관계를 표현합니다. 예를 들어, ‘자동차’와 ‘트럭’은 모두 ‘탈 것’이라는 상위 클래스로부터 상속받는 일반화 관계에 있습니다. 자식에서 부모 쪽으로 속이 빈 화살표(△)를 사용하여 표현합니다.

    의존 관계 (Dependency)

    의존 관계는 한 사물의 명세가 변경될 때 다른 사물이 영향을 받는, 비교적 짧은 기간 동안 유지되는 관계를 의미합니다. 예를 들어, 특정 함수가 매개변수로 다른 클래스의 객체를 잠시 사용하는 경우가 이에 해당합니다. 영향을 받는 쪽에서 주는 쪽으로 점선 화살표( пунктирная линия с стрелкой)를 사용하여 표현합니다.

    실체화 관계 (Realization)

    실체화 관계는 명세와 그것을 구현한 것 사이의 관계를 나타냅니다. 주로 인터페이스와 그 인터페이스를 실제 기능으로 구현한 클래스 사이의 관계를 표현할 때 사용됩니다. 구현하는 클래스에서 인터페이스 쪽으로 속이 빈 삼각형과 점선(점선 삼각형)을 사용하여 표현합니다.

    관점의 시각화, 다이어그램 (Diagrams)

    다이어그램(Diagrams)은 앞서 설명한 사물과 관계들을 조합하여, 특정 목적과 관점에 따라 시스템의 한 단면을 시각적으로 표현한 결과물입니다. UML에는 다양한 종류의 다이어그램이 있으며, 이들은 크게 구조 다이어그램과 행위 다이어그램으로 나뉩니다.

    구조 다이어그램 (Structural Diagrams)

    구조 다이어그램은 시스템의 정적인 구조, 즉 시스템을 구성하는 요소들과 그들 간의 관계를 보여줍니다. 시스템이 무엇으로 이루어져 있는가(What)에 초점을 맞춥니다.

    • 클래스 다이어그램 (Class Diagram): 시스템의 클래스, 속성, 메서드 및 클래스 간의 정적 관계를 표현하는 가장 대표적인 구조 다이어그램입니다.
    • 객체 다이어그램 (Object Diagram): 특정 시점의 객체 인스턴스와 그들 간의 관계를 보여줍니다.
    • 컴포넌트 다이어그램 (Component Diagram): 시스템을 구성하는 물리적인 소프트웨어 컴포넌트들의 구조와 의존성을 보여줍니다.
    • 배치 다이어그램 (Deployment Diagram): 소프트웨어가 어떤 물리적인 하드웨어 노드에 배치되는지를 보여줍니다.

    행위 다이어그램 (Behavioral Diagrams)

    행위 다이어그램은 시스템의 동적인 행위, 즉 시스템의 요소들이 시간의 흐름에 따라 어떻게 동작하고 상호작용하는지를 보여줍니다. 시스템이 무엇을 하는가(Do)에 초점을 맞춥니다.

    • 유스케이스 다이어그램 (Use Case Diagram): 사용자(Actor)의 관점에서 시스템이 제공하는 기능과 그들 간의 관계를 보여줍니다.
    • 시퀀스 다이어그램 (Sequence Diagram): 특정 유스케이스를 수행할 때 객체들이 주고받는 메시지를 시간 순서에 따라 표현합니다.
    • 활동 다이어그램 (Activity Diagram): 업무나 로직의 처리 흐름을 순서도처럼 표현합니다.
    • 상태 머신 다이어그램 (State Machine Diagram): 하나의 객체가 특정 이벤트에 따라 상태가 어떻게 변하는지를 보여줍니다.

    결론: 사물, 관계, 다이어그램의 조합으로 시스템을 창조하다

    UML의 세계는 사물이라는 기본 블록을 관계라는 접착제로 연결하여, 다이어그램이라는 의미 있는 구조물을 만들어내는 과정과 같습니다. 이 세 가지 핵심 구성요소를 이해하는 것은 UML이라는 강력한 언어의 문법을 익히는 것과 같습니다. 어떤 사물을 선택하고, 그들 사이에 어떤 관계를 설정하며, 어떤 다이어그램으로 표현할지를 결정하는 능력이 바로 성공적인 모델링의 핵심입니다. 소프트웨어 개발에 참여하는 모든 전문가는 이 기본 구성요소들을 능숙하게 다룸으로써, 복잡한 아이디어를 명확한 청사진으로 바꾸고, 성공적인 시스템을 창조하는 기반을 다질 수 있습니다