2. OO Analysis and Design (OOAD)

 

OOA 단계객체지향 분석 (Object Oriented Analysis)

- 문제를 정의하고 이 정의로부터 개념 모델(객체에 대한 추상적 정의)을 사용하여 객체, 관계 및 동작을 식별한다.

 

사물이나 컨셉을 설명하거나 찾아내는 것.

즉, 요구사항을 찾아내고, 그 속의 객체들의 목록을 찾아내는 것

 

OOA 단계

1. 요구사항 도출

 - 소프트웨어가 수행해야 하는 작업과 해결하려는 문제를 정의

 

2. 요구사항 지정

 - 일반적으로 사용사례 및 시나리오 또는 사용자 스토리를 사용하여 요구사항 설명

 

3. 개념 모델(Conceptual model)

 - 중요한 객체를 식별하고 다듬고 관계와 동작을 정의하여 간단한 도표로 표현

 

개념 모델의 종류

1. 객체 모형 (Object Model)

 - 객체들과 그 특성을 식별하여 객체들의 정적 구조(static structure)와 그들과의 관계(Interface)를 보여주는 객체 다이어그램(Object Diagram)을 작성한다.

 

2. 동적 모형 (Dynamic Model)

 - 시간 흐름에 따른 시스템의 변화를 보여주는 상태 다이어그램(State Diagram)을 작성한다. 실시간(real-time) 시스템에서는 반드시 필요하다.

 

3. 기능 모형 (Function Model)

 - 시스템 내에서 데이터 값이 변하는 과정을 보여주는 것으로 잘 알려진 자료 흐름도(DFD)가 사용된다.

 

객체지향 설계 (Object Oriented Design)

- 설계 단계에서는 객체와 그들의 속성(attribute), 동작(behavior), 상호작용(interaction)을 설명한다.

 

즉, OOA를 통해 찾아진 객체들 간의 관계를 설정하는 것.

 

설계 단계에서는...

올바른 요구에 맞는 다양한 다이어그램을 선택하는 것이 중요하다. 

1. 클래스 다이어그램를 사용하여 클래스와 클래스의 관계를 설명
- 필요한 클래스를 시각적으로 나타낸다. 이 단계에서 유전성(Inheritance)이나 다형성(Polymorphism)과 같은 객체 지향적인 원칙에 대해서 구체적으로 알게 된다.

2. 시퀀스 다이어그램를 사용하여 개체 간의 상호작용을 설명

3. 그 외에도 객체간의 상호작용, 시스템의 구조, 시스템의 동작, 어떻게 이벤트에 반응하는지에 대해 표현할 수 있는 다이어그램이 많다.

그리고 소프트웨어 설계 원칙 및 설계 패턴을 적용하여 설계한다.

 

 

객체지향 설계의 종류

1. 시스템 설계(System Design)

 - 시스템의 구조를 서브시스템으로 분해한다. 이 과정중에서 성능 최적 방안, 문제 해결 전략, 자원 분배 등이 확정된다.

 

2. 객체 설계(Object Design)

 - 구현에 필요한 상세한 내역을 설계 모형으로 제작하고 상세화된다. 구체적인 자료구조와 알고리즘 들이 정의된다. 

 

Q) When would you use X Diagram?

Use Case Diagram

사용자의 요구를 기능적인 측면에서 명시하며, 시스템이 제공해야 하는 서비스의 목록을 얻기 위해 사용.
또한, 특정 기능이 동작 후에 어떤 기능이 추가로 실행되는지, 또는 어떤 조건 하에 후속 기능이 수행되는지를 검토해보면서 공통 기능을 추출해 볼 수 있고, 유사 기능 분류를 통해 기능 단위로 Encapsulation을 수행해 볼 수 있다.
"시스템이 제공하고 있는 기능 및 그와 관련된 외부요소를 사용자의 관점에서 표현하는 다이어그램"
"시스템 외의 요소와 기능적 요구사항을 Actor와 Use case, Relationship으로 표현"

 

Relationships

• 연관(Association): Use Case와 Actor의 관계를 표현(실선)
• 확장(Extend): 기본 Use Case 수행 시 특별한 조건을 만족할 때 수행하는 Use Case
• 포함(Include): 시스템의 기능이 별도의 기능을 포함(점선)
• 일반화(Generalization): 하위 Use Case/Actor가 상위 Use Case/Actor에게 기능/역할을 상속 받음
• 그룹화(Grouping): 여러 개의 Use Case를 단순화 하는 방법

Granularity of Use Case

Use Case의 적당한 크기는 Use Case의 정의에 충실하게 되어 있고, 개발과 관리에 용이한가를 만족하면 된다.

Use Case Description / Scenario

사용자 중심 접근 (story와 예제 중심의 형식으로 기술)

사용자가 시나리오를 사용하여 요구사항 분석 지원

 

Class Diagram

도출한 Class들 간의 관계를 정의하고 검증함으로써 Persistence한 Dataset과 그들의 관계, 속성들을 결정한다.
Entity type의 class와 그들의 관계 및 cardinality, 그리고 몇개의 key 속성을 보여준다.
시스템을 구성하는 클래스의 구성 (Attribute, Operation)과 클래스 간의 관계를 표현하기위해 사용
Class Name, Attribute, Operation, Relationship을 가지고 있음.

5 Types of Relationship

Q) Order the strengths of 5 relationship types. Justify the ordering.

• Inheritance : 상속 (Strong)
• Composition : 생명 주기 함께
• Aggregation : 레퍼런스 객체 가지고 있음.
• Associate : 지속적 호출 (보통 한 클래스 내에서만 사용) / 한 객체가 다른 객체와 연결되어 있음을 나타낼때 사용.
• Dependency : 잠깐 호출 (보통 한 메서드 내에서만 사용) (Weak)

Sequence Diagram

"Workflow related to Use Case Description"

"Applying MVC style paradigm in drawing Sequence Diagram"

Use case에 대해서 어떻게 Sequence적으로 동작하는지 설명

외부 사용자 또는 Actor가 발생시키는 이벤트, 메시지 호출의 순서 등을 이용하여 기능적인 요소들이 실시간에 어떤 메시지를 주고 받는지를 설계하기 위한 다이어그램.
시간의 흐름에 따라 여러 Object간의 상호작용을 구성 요소 간의 메시지 전달로 표현.

State Machine Diagram

목표 시스템이 State 종속적으로 실행되는 Behavior를 가지고 있을 때, 상태와 상태 간에 전이에 관련된 설계.

State Machine이 이벤트에 따라 어떠한 상태변화가 있는지를 모델링하는 다이어그램.

Transition, Event, Guard, Action

Event가 발생하면 현재 상태에 따라 상태 Transition이 발생한다.

Guard를 만족하지 못하면 이벤트가 발생하지 않는다.

State가 변경되면 entry, exit, do에 명시된 Action이 발생한다.

Final State는 실제로 존재할 수 있는 State이지만 Terminated Node는 아예 State Machine이 종료.

Timing Diagram

타이밍 다이어그램은 시퀀스 다이어그램 의 특수한 형태입니다 . 타이밍 다이어그램과 시퀀스 다이어그램의 차이점은 축이 반대로 되어 왼쪽에서 오른쪽으로 시간이 증가하고 생명선이 수직으로 배열된 별도의 구획에 표시된다는 것입니다.

Activity Diagram

여러 Action들이 순차 병행 방식 등을 수행하는 상황을 표현.

복잡한 Workflow나 병행 처리, 시간 제약이 있는 중요한 알고리즘에 대한 설계.

Action을 묶어 Activity로 나타낼 수 있음.

설계 단계에서는 클래스나 컴포넌트의 알고리즘을 Activity Diagram을 통해서 표현할 수도 있음.

Component Diagram

컴포넌트란 시스템을 구성하는 임의의 물리적인 요소를 의미
물리적인 요소란 가상의 모델을 실제로 구현하여 나타낸 것
객체지향 원리에서 컴포넌트는 인터페이스에 의해서 기능이 정의된 독립적으로 개발, 배포, 조립이 가능한 시스템의 구성 단위 (Ex. JAR, DLL)
컴포넌트 다이어그램의 구성요소는 컴포넌트, 인터페이스, 의존관계, 지원관계로 나뉨
의존관계는 컴포넌트와 컴포넌트 사이의 관계이고 지원관계는 인터페이스와 컴포넌트의 관계
컴포넌트들은 서로간 loosely coupled 해야 함.

Provided Interface

다른 컴포넌트가 사용할 수 있는 서비스를 명시하는것.

Required Interface

플러그인 컴포넌트가 구현해야 하는 프로토콜을 명시하는것.

 

Q) Why is required interface essential in designinig platform SW?

A) 컴포넌트는 하나의 구성 요소. S/W 디자인의 SRP에 따라 모든 인터페이스를 하나의 컴포넌트에 구현하는 것은 불가능함. 따라서 필요한 인터페이스는 외부의 다른 컴포넌트에서 얻어와야 할 수 있으며, 그렇기에 필수적이라 생각.

Deployment Diagram

이 다이어그램은 노드, 노드 간 네트워크 연결 및 노드에 배포된 소프트웨어 아티팩트를 지정.

UML Constructs for Parallel Processing

Activity Diagrm에서 fork & join 을 활용하여 표현 할 수 있습니다.

Consistency

Among Use Case Model, Class Diagram, & Sequence Diagram

Between State Machine Diagram & Class Diagram

Between Activity Diagram & Use Case Diagram

Q) How do you check the consistency between <X diagram> & <Y diagram>