What is object-orientation?
- 시스템 모델링을 위한 기술
- 여러 객체들이 상호작용하며 시스템을 모델링하는 방법

Object-oriented Analysis/Design Models
Static model (structural view)
- 시스템의 구조를 나타내며, 시스템의 클래스들, 클래스들 간의 관계, 그리고 시스템 내의 다른 정적 요소들을 설명
- Class Diagram
- 시스템을 구성하는 클래스들과 그 클래스들 사이의 관계를 보여주는 주요한 정적 모델링 도구
Dynamic model
- 시스템이 시간에 따라 어떻게 동작하는지를 나타냄
- Sequence Diagram
- 객체들 사이의 상호작용과 이러한 상호작용이 시간에 따라 어떻게 발생하는지를 시각적으로 표현
- 객체들 간의 메시지 전달 순서를 보여주며, 시스템의 특정 시나리오나 트랜잭션을 이해하는 데 유용
- Statechart Diagram
- 객체의 상태 변화와 그 상태 변화를 일으키는 이벤트를 모델링
- 객체가 가질 수 있는 다양한 상태들과 그 상태들 사이의 전환을 보여줌
Object vs. Class
Object
- 객체는 엔티티를 나타냄
- Attribute와 Method를 가짐
- 실세계의 물리적 엔티티(예: 자동차, 컴퓨터)
- 개념적 엔티티(예: 회사, 프로젝트)
- 소프트웨어 설계 모델에서의 엔티티(예: 사용자 인터페이스, 데이터베이스)
Class
- 공통의 특성을 가진 객체들의 집합
- 클래스를 바탕으로 실제 객체들이 생성
객체는 실제 세계의 대상을 소프트웨어 내에서 모델링한 것이고, 클래스는 이러한 객체들을 만들기 위한 설계도
Domain Model
- 실제 세계의 도메인 내 개념들을 시각화하는 것
- 문제 도메인 내의 개념적 클래스들을 도식화하여 표현
- 즉, 도메인 모델은 추상적 개념의 시각적 사전과 같음
- 도메인 모델을 한 번에 완성하는 것이 아니라, 여러 번의 반복 과정을 통해 점진적으로 발전시키는 것
- Physical classes. Entity classes – data intensive classes
Process for domain modeling
- List the candidate conceptual classes.
중요한 역할을 하는 개념이나 객체들을 식별
- Draw them in a domain model.
식별된 후보 개념 클래스를 도메인 모델에 그립니다. 이는 주로 UML(Unified Modeling Language) 같은 표준화된 모델링 언어를 사용하여 수행됨
- Add the associations necessary to record relationships between classes
클래스 간의 관계를 도메인 모델에 추가
- Add the attributes necessary to fulfill the information requirements
각 클래스가 정보 요구사항을 충족시킬 수 있도록 필요한 속성을 추가
- Refine domain model
도메인 모델을 지속적으로 검토하고 개선
Identifying conceptual classes
Use a conceptual class category list
- 어떤 정보가 시스템에 저장되어야할 지 생각해보기
Which information should be captured by the system?
- 모든 유형의 사용자 및 이해관계자와 협력하여 목록을 확장
• Tangible object (book, item, etc.)
• Hardware devices (register, card reader, sensor, etc.)
• Places, sites, locations (store, factory, etc.)
• Transactions, events that need to be recorded (sale, payment, etc.)
• Role of people (student, cashier, customer, librarian, etc.)
Identifying Noun phrase
- 도메인의 텍스트 설명에서 명사와 명사 구문을 식별하여 개념적 클래스를 찾는 방법
- A mechanical noun-to-class mapping은 불가능
- 자연 언어에서 단어가 모호할 수 있음
NextGen POS Domain Model
Initial domain model

Add associations

- 객체 지향 모델링에서 클래스 간의 정적이고 구조적인 관계
- E.g., Register records-current Sale, Sale recorded-on Register
- 클래스 간의 선: 두 클래스 사이의 연결을 나타내기 위해 사용됩니다. 이 선에는 관계의 이름이 포함될 수 있음
Multiplicity
Identifying Associations
“need-to-know” association
일정 기간 동안 관계에 대한 정보가 보존되야할 필요가 있는 association
Common Associations list
-
A는 B의 물리적 또는 논리적 부분이다 (예: Sale – SalesLineItem)
"SalesLineItem"은 "Sale"의 일부로, 판매된 각 상품의 정보를 담고 있습니다.
-
A는 B에 물리적 또는 논리적으로 포함되어 있다 (예: Store – Register)
"Register"는 "Store" 내에 위치해 있으며, 매장에서의 거래를 처리합니다.
-
A는 B에 기록된다 (예: Sale – Register)
"Sale"은 특정 "Register"에서 발생한 거래로, 이 거래 정보는 "Register"에 기록됩니다.
-
A는 B를 사용하거나 관리한다 (예: Cashier – Register)
"Cashier"는 "Register"를 사용하여 고객의 결제를 처리하고, 이를 통해 판매 거래를 관리합니다.
-
A는 B와 관련된 이벤트이다 (예: Sale – Customer)
"Sale"은 "Customer"와 관련된 이벤트로, 특정 고객이 상품을 구매하는 행위를 나타냅니다.
Multiplicity
- 클래스 A의 인스턴스가 클래스 B의 한 인스턴스와 얼마나 많이 연결될 수 있는지를 정의

• A Register captures zero or more Sale.
• A Sale is captured by exactly one Register
• A Sale contains one or more SalesLineItem
• A SaleLineItem is part of exactly one Sale
다대다 관계에서는 관계를 더 세밀하게 정제할 필요가 있음
- 를 위해 '연관 클래스(association class)'라고 불리는 클래스를 정의하여 관계를 설명

Add attributes
- "속성(attribute)"은 객체의 특성이나 상태를 나타내는 a logical data value
- 속성을 통해 객체는 필요한 정보를 저장하고, 이 정보를 바탕으로 메서드(methods)를 통한 연산이나 처리를 수행할 수 있음
- 클래스 다이어그램에서는 클래스 상자의 두 번째 구획(컴파트먼트)에 속성을 표시
- "속성 이름 : 속성 타입"
Refine the domain model
• Generalization/Specialization Relationship
• Aggregation and Composition Relationship
Generalization/Specialization
- 클래스 간의 상속 구조를 설계하는 데 사용
- 이러한 관계는 공통된 특성을 공유하는 클래스들 사이의 계층을 구성하여, 코드의 재사용성을 높이고 변경에 더 유연하게 대응할 수 있게 함
Generalization
- 여러 개념들 사이에 공통점을 식별하는 활동
- 이를 통해 superclass (general concept) 와 subclass (specialized concept) 사이의 관계를 정의
- 상위 클래스는 공통의 속성이나 동작을 정의하고, 이를 하위 클래스가 상속받아 사용할 수 있습니다
Specialization
- 보다 일반적인 개념에서 구체적인 특징을 가진 하위 클래스를 생성하는 것
- 하위 클래스는 상위 클래스의 모든 속성과 동작을 상속받으면서도 추가적인 속성이나 동작을 정의할 수 있음
Generalization/Specialization validation
클래스 간의 상속 관계가 올바르게 설계되었는지 확인
“Is-a” test (membership test)

특정 객체가 상위 클래스의 인스턴스로도 적절하게 간주될 수 있는지 확인하는 방법입니다. 즉, 하위 클래스의 모든 인스턴스가 개념적으로 상위 클래스의 인스턴스로도 여겨질 수 있어야 합니다.
"100%" test

- 하위 클래스가 상위 클래스의 정의와 특성을 완전히 충족하는지 확인하는 방법
- 상위 클래스에 정의된 모든 attributes과 associations가 하위 클래스에도 100% 적용되어야 함
- 만약 하위 클래스가 상위 클래스의 모든 속성을 사용하지 않거나, 상위 클래스의 정의와 부합하지 않는 행동을 한다면, 그 상속 관계는 잘못 설계되었다고 볼 수 있습니다.
Whole-part relationship
한 클래스가 다른 클래스의 일부 또는 구성 요소인 클래스 간의 관계
Aggregation
- 부분이 전체에서 독립적으로 존재하고 제거하거나 교체할 수 있는 관계
- 집합은 클래스를 연결하는 선의 끝에 열린 다이아몬드로 표시

Composition
- 부분이 전체에서 분리될 수 없는 더 강한 관계
- 구성은 채워진 다이아몬드로 표시
