OO Analysis & Design

OOA

- 문제 영역에서 객체나 개념들을 찾아서 기술하는데 중점
Use Case 정의, Domain Model (개념, 속성, 관계등을 식별)

OOD

- 소프트웨어 객체를 정의한다.
- 요구 사항을 만족시키기 위해 어떻게 협동하는지에 중점을 둔다.
- 협동은 메소드 호출을 통해서 이루어진다.
- 어떤 객체들이 어떤 동작을 할 것인지, 클래스에게 어떤 책임을 할당할 것인가를 다룸
- 객체들이 어떻게 상호작용하는지, 메소드의 호출 순서와 방법
Sequence Diagram, Class Diagram 정의

구현을 위해 "요구사항"들을 "어떻게 구체화할 것인가"를 서로 연결하는 작업

OOA/D에서 가장 중요한 능력은 객체지향 분석 및 설계기술
- UML(Unified Modeling Language) 적용
- Iterative development(반복적인 개발) => agile approach to the Unified Process (반복적이고, 진화적이며, 기민한 접근)

Agile

유연하고 적응력 있는 계획, 신속하고 유연하게 대응하는 기민성(agility)을 권장하는 실행기술들을 포함

UP의 주요 활동 분야
- Business Modeling
- 문제 영역에서의 객체 모델링
- Requirement
- Use Case를 이용한 요구 사항 분석
- Design
- 전체 구조, 객체, 데이터베이스, 네트워크 등에 관한 여러가지 설계 문제 포함

Use Case Diagram

시스템과 사용자의 상호작용을 다이어그램으로 표현한 것으로
사용자의 관점에서 시스템의 서비스 혹은 기능 및 그와 관련한 외부 요소를 보여줘야 할 때 사용한다.

구성요소(Component)
유즈케이스 다이어그램의 구성요소는 시스템(System), 액터(Actor), 유스케이스(Usecase), 관계(Relation)로 구성되어 있다.

1) 시스템(System)
만들고자 하는 프로그램을 나타낸다.

2) 액터(Actor)
시스템의 외부에 있고 시스템과 상호작용을 하는 사람(시스템의 기능을 사용하는 사람), 시스템(시스템에 정보를 제공하는 또 다른 시스템)을 말한다. usecase의 기능을 invoke하는 주체, invoke 당하는 주체
액터 => To model a specific type of role that is played by an external entity that interacts with the target system.
Effictively identified by considering the operations of Create-Retrieve-Update-Delete(CRUD) for each dataset manipulated by the system

3) 유즈케이스(Usecase)
사용자 입장에서 바라본 시스템의 기능
시스템이 액터에게 제공해야 하는 기능으로 시스템의 요구사항을 나타낸다.
유즈케이스명은 "~한다"와 같이 동사로 표현

4) 관계(Relation)
액터와 유즈케이스 사이의 의미있는 관계를 나타낸다. 종류는 연관(Association), 의존(Dependency), 일반화(Generalization)이 있으며 의존관계는 포함(Include), 확장(Extend)로 나눠진다.

1. 연간관계(Association)는 유즈케이스와 액터간의 상호작용이 있음을 표현
유스케이스와 액터를 실선으로 연결

2. 포함관계(Include)는 하나의 유즈케이스가 다른 유즈케이스의 실행을 전제로 할 때 형성되는 관계
포함되는 유스케이스는 포함하는 유스케이스를 실행하기 위해 반드시 실해오디어야 하는 경우에 적용
포함하는 유스케이스에서 포함되는 유스케이스 방향으로 화살표를 점선으로 연결하고 <<include>>라고 표기

자판기에 동전을 투입하면 금액이 자동으로 표시된다.

3. 확장관계(Extend)는 확장 기능 유스케이스와 확장 대상 유스케이스 사이에 형성 되는 관계
확장 대상 유스케이스를 수행 할 때 특정 조건에 따라 확장 기능 유스케이스를 수행하는 경우에 적용
확장 기능 유스케이스에서 확장 대상 유스케이스 방향으로 화살표를 점선으로 연결하고 <<extend>>라고 표기

KTX를 예약한 후 결과를 확인하거나 확인하지 않을 수 있다.

4. 일반화 관계(Generalization)는 액터들이 유스케이스와 중복하여 관계가 나타나면 액터들을 통합하여 일반화 관계로 표현, 추상적인 액터와 좀 더 구체적인 액터 사이에 관계를 맺어줌

액터 간 일반화의 개념 예

5. 그룹화(Grouping)는 여러 개의 Use Case를 단순화 하는 방법

Granularity of Use Cases

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

Use Case Description/Scenario

사용자 중심 접근(Story와 예제 중심의 형식으로 기술)
사용자가 시나리오를 사용하여 요구사항 분석 지원

Class Diagram

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

5 Types of Relationships

Sequence Diagram

정의 : 시간 순서를 기반으로 객체의 협업을 보여주는 Diagram
시간에 따라 객체지향 메시지 단위로 디테일한 behavior 보여주기 위해서
외부 사용자 또는 Actor가 발생시키는 이벤트, 메시지 호출의 순서 등을 이용하여, 기능적인 요소들이 실시간으로 어떤 메시지를 주고 받는지를 설계하기 위한 다이어그램

Workflow related to Use Case Description

시간의 흐름에 따라 여러 Object 간의 상호작용을 구성 요소 간의 메시지 전달로 표현한다. Use Case에 대해 어떻게 Sequence적으로 동작하는지 설명해 준다.

Applying MVC style paradigm in drawing Sequence Diagram

아래의 일반 MVC 시퀀스 다이어그램에서 View 객체가 사용자 입력 및 출력을 담당하는 것을 보여준다. 즉, 대화 상자는 View의 좋은 예이다. Controller 객체는 Model에서 수행할 수 있는 허용 가능한 트랜잭션에 대한 로직을 구현한다. Model 객체는 세분화된 비즈니스 로직과 데이터를 캡슐화 한다.

State Machine Diagram

목표 시스템이 State 종속적으로 실행되는 Behavior를 가지고 있을 때, 상태와 상태 간에 전이에 관련된 설계입니다. State Machine이 이벤트에 따라 어떠한 상태변화가 있는지를 모델링하는 다이어그램입니다.
용도 : 객체의 상태 변화를 상세히 분석, 이벤트에 의한 객체의 반응을 분석, 객체의 속성이나 동작을 검증

Transition, Event, Guard, Action

Event가 발생하면 현재 상태에 따라 상태 Transition이 발생한다. Guard를 만족하지 못하면 이벤트가 발생하지 않는다. State가 변경되면 entry, exit, do에 명시된 Action이 발생한다.

• Transition(전이) : 객체의 상태가 다른 상태로 변경되는 것, 실선으로 표기
• Event(이벤트) : 객체의 전이를 유발하는 자극, 전이 위에 이름표기
• Guard(가드) : 이벤트가 상태 전이가 되기위한 조건을 만족하면 상태 전이를 시킨다는 조건

Timing Diagram

상호작용 다이어그램의 일종으로서 상호작용에 참여하는 생명선의 상태 변화 및 메시지에 대하여 정확한 시간적 정보를 표현하는데 편리하다.

Activity Diagram

정의 : 사건의 발생에 관련된 객체들의 상호 관계를 각종 처리 로직이나 조건을 순서에 따라 도식화한 다이어그램, 시스템 안에서 프로세스들 사이에서 데이터의 흐름을 보여준다.
목적 : 대상에 상관없이 로직과 처리 순서를 표현하기 위해 작성, 프로그램 처리 흐름을 도식화하여 간단하고 명료하게 처리 로직을 표현, 실행 순서를 병렬처리, 이벤트기반 behavior를 잘보여줌

• Action : Activity안에 단일 스탭, Atomic operation임, 결과를 가져오는 행동
• Activity : Action들의 그룹, 그 자체로 결과를 발생시키지 않는다. 결과보다는 움직임과 활동에 초점
• Decision Node : 분기점
• Fork Node : 평행적으로 수행되는 Flow를 나누는 노드
• Join Node : Fork Node로 나눠진 Control Flow를 다시 하나로 합치는 노드

Component Diagram

클래스 기반 실행 단위인 컴포넌트 단위로 시스템 구조를 표현하는 다이어그램입니다. 복잡하고 큰 시스템에서 내부 의존성과 구조를 나타내는 설계입니다.

Provided Interface는 다른 구성 요소가 활용할 수 있는 서비스를 지정한다.
Required Interface는 플러그인 컴포넌트가 구현하는 프로토콜을 지정한다. -> Replaceability of components 상황에 따라 가변적으로 변경해야 할때, 내부적으로 구현할 것은 아닌데 필요할 때 외부로부터 required interface를 plugin하여 사용하겠다.
Pluggable Object (Pluggable Adpater?)

Deployment Diagram

실행시점의 시스템의 구조를 모델링하기 위한 다이어그램으로, 하드웨어 구성과 소프트웨어 배치구성을 표현합니다. 즉, 소프트웨어가 구동되는 컴퓨팅 노드와 노드 간의 연결관계를 나타냅니다.

• Node: 시스템을 구성하는 소프트웨어 컴포넌트가 배치(Deploy)되어 수행되는 하드웨어 자원을 뜻한다.
• Artifacts: 물리적인 형태의 모든 정보. (모델 파일, 소스 코드, 산출물, 실행 파일)

UML Constructs for Parallel Processing

시퀀스 다이어그램의 “par” combined fragment(복합적 부분)를 이용하여 표현 가능
Activity 다이어그램의 Fork를 이용하여 표현가능
State 다이어그램의 Fork를 이용하여 표현가능

Consistency (UML간 일관성을 갖춰야 한다)

Among Use Case Model, Class Diagram & Sequence Diagram

- Sequence Diagram의 화살표가 가리키는 Method가 Class 다이어그램에서 Public method로 정의되어 있어야 한다.
- Use Case 다이어그램에서 명시된 use case는 Sequence 다이어그램에서 Activity나 Action으로 표현되어야 한다.
- Use Case 다이어그램에서 정의된 Actor가 명시되어 있는 특정 Use Case를 달성하기 위해 Class 다이어그램에 정의된 Object와 어떤 Interaction을 가지는지 Sequence 다이어그램을 통해 표현된다.
- Use Case에 등장하는 명사(Noun)들을 추출하여 클래스로 만들 수 있다. Use Case에 등장하는 actor와 system 사이의 상호 작용을 시나리오에 따라 Sequence Diagram으로 나타낼 수 있다.

Between State Machine Diagram & Class Diagram

- 일반적으로 Class 다이어그램은 persistence한 data를 표현한다. Class 하나에 대해서 state machine 다이어그램을 그린다. State machine 다이어그램의 event는 class 다이어그램의 Public method가 되어야 한다.
- 정의한 상태별로 클래스가 구성된다. 해당 클래스의 Method는 실행 가능한 Event에 대해서는 구현하고 그렇지 않은 함수는 Block처리하여 두 다이어그램의 일관성을 유지한다.

Between Activity Diagram & Use Case Diagram

- 모든 Use Case가 Activity Diagram에서 Activity 또는 Action으로 표현되어야 하며 Activity에서는 전체적인 제어흐름도 확인할 수 있는 다이어 그램이다. 등장하지 않았던 Action이 나타나면 일관성이 유지되지 않는다.

Diagram의 장점

1. common vocabulary, 국제 표준
2. 여러사람이 봐도 오해가없음
3. Limited vocabulary, precise하게 디자인 표현 가능

https://googry.tistory.com/2
https://theodor.tistory.com/21
https://itpenote.tistory.com/69
https://m.blog.naver.com/wowzzin/221467947512