5. Object-Oriented Analysis Model (Dynamic view)

Object-oriented Analysis Models

Static model (structural view)
시스템을 구성하는 요소들과 그 요소들 간의 관계를 표현

• Domain model - Class Diagram of problem domain

Dynamic model
시스템의 행동과 그 행동이 시간에 따라 어떻게 변화하는지를 설명

• Analysis Sequence Diagram (functional view)
• Statechart Diagram (behavioral view)

Analysis Sequence Diagram

• Use case는 external actors가 시스템과 상호 작용하는 방법을 설명
• Domain model은 문제 도메인의 conceptual objects를 설명
• use case 시나리오를 기반으로 하여, actors와 시스템 내의 개념적 객체들 사이의 상호작용을 순서대로 나타냄
  • 행위자와 분석 객체 사이의 상호작용을 메시지의 순서로 나타냄(sequence of messages)
• System Sequence Diagram는 시스템을 '블랙 박스'로 보고, 행위자와 시스템 전체 사이의 상호작용만을 나타냅니다. 시스템 내부의 분석 객체들은 표시되지 않습니다.

Process for analysis sequence diagramming

1. Pick a use case scenario
2. Refine Analysis Objects with Object Responsibility
   시스템 내부에서 역할을 수행할 분석 객체를 정의
   • Interface object, control object, business logic object (if applicable)
3. Put actors, analysis objects, object lifeline
   다이어그램에 액터(시스템과 상호 작용하는 외부 요소)와 앞서 정의한 분석 객체를 배치
   lifeline: 객체의 생성부터 소멸까지의 생명주기를 나타내며, 주로 세로선으로 표시
4. Identify Messages among actors and analysis objects
   액터와 분석 객체 간에 교환되는 메시지를 식별
   • Input message, return message
   • sequence of message

Refine Analysis Objects with Object Responsibility

• Entity-Control-Boundary Pattern
  
• 이 패턴은 시스템을 세 가지 주요 유형의 객체, 즉 Entity 객체, Control 객체, 그리고 Boundary 객체로 나누어 설계
• Actor: 시스템 외부의 사용자나 다른 시스템을 의미합니다. Actor는 Boundary 객체와만 직접적으로 소통
  • Actors may only know and
    communicate with boundaries
• Boundary 객체 (Interface 객체): Actor와 시스템 간의 인터페이스 역할을 합니다.
  • Boundary 객체는 외부 Actor와 직접적으로 소통하며, 필요한 경우 내부의 Control 객체와도 소통
  • Boundaries may communicate with
    actors and controls only
• Control 객체: 시스템의 비즈니스 로직을 처리하고, 다양한 객체 간의 상호작용을 조정하며, 사용 사례의 전반적인 흐름을 관리
  • Control 객체는 Boundary 객체로부터 입력을 받아 처리하고, 필요에 따라 Entity 객체와 소통합니다. 또한, 필요한 경우 다른 Control 객체와도 소통할 수 있음
  • Controls may know and communicate
    with boundaries and entities, and if
    needed other controls
• Entity 객체: 시스템 내의 핵심 비즈니스 데이터를 나타내고 관리합니다. 예를 들어, 고객, 주문, 제품 등이 있습니다. Entity 객체는 다른 Entity 객체에 대해 알고 있으며, 필요한 경우 Control 객체와도 소통할 수 있습니다.
  • Entities may only know about other
    entities but could communicate also
    with controls;

---

• Entity Object (엔티티 객체)
  • data-intensive object
• interface Object (Boundary Object, 인터페이스 객체)
  • 외부 환경과의 인터페이스 역할을 하는 객체
  • (UI) 컴포넌트나 외부 시스템과의 API 등
  • 사용자의 입력을 받아들이고, 시스템의 출력을 사용자 혹은 다른 시스템에 전달
• Control Object (컨트롤 객체)
  • 여러 객체들의 조정 및 순서화를 담당하는 객체
  • system handler
  • use case handler: 사용자의 요청을 받아 해당 요청을 처리하기 위한 엔티티 객체들 간의 상호작용을 조정하고, 전체 유즈케이스의 흐름을 관리
• Business Logic Object (비즈니스 로직 객체)
  • 비즈니스 로직이 상대적으로 단순하면, 이 로직을 컨트롤 객체 내에서 처리할 수 있음

Statechart Diagram

• 객체의 상태에 따라 변화하는 행동을 모델링하는데 사용되는 다이어그램

1. 상태(State)

• 객체가 특정 시점에 존재할 수 있는 조건이나 상황
• '로그인 상태', '로그아웃 상태'

2. 이벤트(Event)

• 상태를 변경할 수 있는 중요하거나 주목할 만한 발생
• 사용자의 입력, 시간의 경과, 외부 시스템의 메시지

3. 전환(Transition)

• 두 상태 간의 관계로, 특정 이벤트가 발생할 때 객체가 이전 상태에서 후속 상태로 이동하는 것을 나타냄
• 보통 화살표로 표현되며, 이벤트 이름이나 조건이 함께 표시
  

---

State dependent objects
• Entire “system”
• Class (Conceptual, software)

• State-dependent Control Object, Entity Object

• Use case