OOAD 객체지향 분석 및 설계 프로세스

객체 지향 프로그래밍 (OOP)

Object-Oriented Programming (OOP), 다른 말로 객체 지향 프로그래밍은 데이터랑 코드를 담을 수 있는 객체(Objects)라는 개념을 기반으로한 프로그래밍의 패러다임의 일종입니다.

 객체 지향 개발은 문제 해결 domain에서 객체(Objects)들의 상호작용(interaction)을 통해서 해결하는것을 말합니다.

OOP는 구조적이고 재사용성이 좋고 수정과 유지보수가 편리한 소프트웨어 프로그램을 만드는데 좋습니다.

---

OOP의 특성

OOP의 특성은 아래와 같습니다

• Encapsulation : 캡슐화로 내부 필드와 동작을 접근하지 못하도록해서 프로그램의 무결성을 보장합니다
• Abstraction : 개념을 추출해서 정의해서 추상화를 합니다.
• Polymorphism : 추상 클래스 등을 상속받은 뒤, 알맞게 재정의를 해서 이용하는 다형성을 의미합니다.
• Inheritance : 상속이란 개념을 이용해서 코드의 재사용성을 늘립니다.
• Class : 객체의 설계도를 클래스라는 개념으로 설명합니다.
• Object : 클래스를 이용해서 만든 인스턴스를 객체(Object)라고 합니다.

OOP에 핵심 기둥은 캡슐화, 추상화, 다형성, 상속이 있습니다.

그러나 객체 지향 프로그래밍을 하려면 객체지향 언어를 아는 것만으로 부족합니다.

객체지향 분석 및 설계 Object-Oriented Analysis and Design (OOA/D)를 알아야 합니다.

---

OOA/D 란?

소프트웨어 아키텍쳐 설계 및 개발은 System, Model, Software로 분류할 수 있습니다

System은 domain에 있는 모든것(만드려는 것들)을 말합니다.

Model은 System(domain)에 있는 개념과 과정들을 추출해서 모델링 한것이고, 그것을 Implement(구현)하면 Solution 소프트웨어 프로그램이 됩니다.

 

Analysis(OOA)는 System domain의 용어로 분석해서 개념적 모델을 만드는 것이고, Design(OOD)는 그 개념적 모델을 SW개발자의 관점과 용어로 객체지향적으로 설계하는 것을 말합니다.

 

 

세부적으로 OOA는 System domain의 개념과 용어로 분석하는것이고, OOD는 Software의 용어와 개념으로 논리적인 설계 모델을 디자인하는 것을 말합니다.

 

---

객체지향 분석(OOA)

문제 도메인의 문제를 System domain의 개념과 용어 분석하는 단계입니다.
만들고자 하는 SW시스템의 내부 구성할 도메인 개념(객체가 될 가능성)을 찾고 설명하는 과정입니다.

객체지향 설계(OOD)

구현을 위해 (동적/정적) 논리적 설계모델(Solution)을 객체지향구조로 만드는 단계입니다.
만드는 유스케이스을 수행하기 위해 객체들이 어떻게 협력하는지를 정의합니다.

 

---

객체지향 분석 및 설계의 핵심은 "어떻게 객체 지향적으로 사고하는가"입니다.

 

객체 지향적으로 설계하는것은 책임(responsibility)을 소프트웨어 객체에 할당하는 것입니다.

책임이라고 하는것은 기능, 곧 메서드입니다.

 

책임이 어떻게 클래스에 할당돼야하고, 객체 들이 어떻게 서로 협동해야 하는지, 원칙과 패턴을 어떻게 적용할 것 인지 사고하는것입니다.

그의 맞는 도구에는 UML(Unified Modeling Language)로 표준 다이어그램 표기법이 있습니다.

 

책임을 넘겨준다는것은 어떠한 기능을 메서드로 접근하는것이고, 세부적인 과정은 객체 내부에 책임을 넘겨줬으므로 객체 내부로 숨기는것(캡슐화 모듈화)입니다.

---

OOAD 설계 프로세스 란?

 

객체지향적 분석 및 설계 프로세스는 아래와 같이 진행됩니다.

다이어그램 작성법등 세부내용은 다이어그램 포스트에서 다루겠습니다.

 

1. 유스케이스 정의
2. Conceptional(Domain) Model 정의
3. Interaction(Collaboration) 다이어그램(동적) 정의
4. Design class 다이어그램(정적) 정의

---

1. 유스케이스(use case) 정의

유스케이스란 시스템의 하나 이상의 액터 또는 이해관계자(stakeholder)에게 관측 가능한 결과를 산출하는 시스템에 의해 수행되는 일련의 활동의 명세서로 정의할 수 있습니다.

아래는 제가 직접 정의한 로봇 청소기 시스템의 유스케이스입니다.

UseCase	Description
유스케이스 이름	Start Cleaning & Select Cleaning Mode
범위	RVC 시스템: 로봇 청소기의 작동과 모드 선택, 청소 진행 상태를 제어하고 모니터링하는 시스템.
수준	사용자 목적 수준: 고객이 청소를 편리하게 관리하고 선택한 모드에 따라 로봇 청소기를 시작하는 것을 목표로 한다.
주요 액터	사용자(User), 로봇 청소기(RVC)
사전조건	고객은 로봇 청소기를 소유하고 있으며, 시스템이 정상 작동하고 있다.
사후 조건	로봇 청소기가 선택된 모드로 청소를 시작한다. 시스템은 고객의 선택을 기록하고 청소 진행 상황을 모니터링 한다.
기본 흐름(성공 시나리오)	1.고객이  IOT기기 또는 리모컨을 이용해서 시스템을 제어한다. 2.고객이 "청소 시작" 버튼을 클릭한다. 3.시스템은 사용자에게 일반, 집중, 퀵 청소등 사용 가능한 청소 모드를 보여준다. (리모컨으로 제어하는 경우 이 단계를 건너뛴다.) 4.고객이 원하는 청소 모드를 선택한다. 5.시스템이 로봇 청소기를 시작하고, 선택된 모드로 청소를 진행한다 6.시스템은 고객의 선택을 기록하고 청소 진행 상황을 모니터링 한다. 7.고객은 IOT기기 등으로 시스템에 접속하여 청소 진행 상황을 실시간으로 모니터링할 수 있다.
대체 흐름 (모드 선택 취소)	1.고객이 청소 모드를 선택하는 과정에서 "취소" 버튼을 클릭한다. 2.로봇 청소기가 청소를 중단하고 원위치로 복귀한다. 3.시스템이 초기 화면으로 돌아간다.

 

---

2. Conceptional(Domain) Model 정의

유스케이스의 기본 흐름은 항상 3형식(주어 목적어 서술어)로 작성하는 것이 좋습니다.

 

우선 명사들(주어 목적어)를 추출해서 Concepts(개념)들을 찾아서 클래스를 추출합니다.

아래는 로봇청소기의 한 유스케이스에 관해서 제가 직접 추출한 예시입니다.

---

그다음은 서술어들을 통해서 객체들의 상호작용을 찾고 그 기반으로  Associations(연관관계)를 추출합니다.

아래는 제가 직접 Association를 추출한 예시입니다.

•User Owns Device

•User Creates Cleaning Schedule

•User Controls RVC

•RVC interacts with System

•System Manages Update File

•RVC Records Cleaning Progress

•Cleaning Progress Monitered by System

•User interacts with System

•Cleaning Schedule Managed By System

---

 

마지막으로 이 모든 요구사항에서 제안됐거나 기억될 필요가 있었던 정보들을 Attributes(속성)으로 추출합니다.

아래는 제가 직접 추출한 속성(attributes)입니다.

---

지금까지 분석한 내용을 가지고 만들어낸 Conceptual Model를 다이어그램으로 표현하면 아래와 같습니다.

starUML를 통해서 만들었습니다.

---

3. Interaction 다이어그램 정의

인터렉션 다이어그램은 큰 의미로 객체의 책임이나 다른 객체과의 협동을 정의한 다이어그램으로 동적인 시각에서 본 다이어그램입니다.

동적 다이어그램의 예시로는 시퀸스 다이어그램과 커뮤니케이션 다이어그램이 있습니다.

 

Sequence diagram

울타리 형식의 다이어그램으로 객체들 간의 메시지 전송 순서에 따라 표현되는 다이어그램으로 프로세스 시간들을 계산 할때 이용됩니다.

Communication diagram

객체가 많은 경우의 유리한 다이어 그램으로 객체들간의 관계를 한눈에 볼 수 있어, 어디 객체에 책임이 과중되는지 한눈에 볼 수 있습니다.

 

-저도 나중에 동적 다이어그램을 작성하게되는 기회가 있으면 로봇청소기에 대한 다이어그램도 그려보겠습니다..ㅎㅎ

---

4. Design class 다이어그램 정의

객체의 속성 메소드로 표현된 클래스를 정의하는 다이어그램으로, 보통 개발자들이 보는 클래스 다이어그램입니다.

이것 말고도 정적 다이어그램에서 상태 다이어그램 등이 있습니다.

---

OOAD를 위한 SW 개발 프로세스

OOAD를 위한 소프트웨어 개발 프로세스에는 agile, UP(Unified Process)등이 있습니다.

sw개발 프로세스는 다음 포스트에 자세히 다루겠습니다!