📌 애플리케이션 설계 - 객체지향 분석 및 설계

 

 

목차

 

객체지향 분석의 개념

📌 객체지향 분석(OOA: Object Oriented Analysis)은 사용자의 요구사항을 분석하여 요구된 문제와 관련된 모든 클래스(객체), 이와 연관된 속성과 연산, 그들 간의 관계 등을 정의하여 모델링 하는 작업이다.

 

• 소프트웨어를 개발하기 위한 비즈니스(업무)를 객체와 속성, 클래스와 멤버, 전체와 부분 등으로 나누어서 분석한다.
• 분석가에게 중요한 모델링 구성 요소인 클래스, 객체, 속성, 연산들을 표현해서 문제를 모형화할 수 있게 해준다.
• 객체는 클래스로부터 인스턴스화되고, 이 클래스를 식별하는 것이 객체지향 분석의 주요한 목적이다.

 

 

객체지향 분석의 방법론

📌 객체지향 분석을 위한 여러 방법론이 제시되었으며 각 방법론은 다음과 같다.

 

• Rumbaugh(럼바우) 방법 : 가장 일반적으로 사용되는 방법으로 분석 활동을 객체 모델, 동적 모델, 기능 모델로 나누어 수행하는 방법이다.
• Booch(부치) 방법 : 미시적(Micro) 개발 프로세스와 거시적(Macro) 개발 프로세스를 모두 사용하는 분석 방법으로, 클래스와 객체들을 분석 및 식별하고 클래스의 속성과 연산을 정의한다.
• Jacobson 방법 : Use Case를 강조하여 사용하는 분석 방법이다.
• Coad와 Yourdon 방법 : E-R 다이어그램(ERD-Entity Relation Diagram : 개체 관계 모델)을 사용하여 객체의 행위를 모델링하며, 객체 식별, 구조 식별, 주제 정의, 속성과 인스턴스 연결 정의, 연산과 메시지 연결 정의 과정으로 구성하는 기법이다.
• Wirfs Brock 방법 : 분석과 설계 간의 구분이 없고, 고객 명세서를 평가해서 설계 작업까지 연속적으로 수행하는 기법이다.

 

💡 Use Case(사용 사례) : 사용자, 외부 시스템, 다른 요소들이 시스템과 상호 작용하는 방법을 기술한 설명

 

 

럼바우 (Rumbaugh)의 분석 기법

📌 럼바우의 분석 기법은 모든 소프트웨어 구성 요소를 그래픽 표기법을 이용하여 모델링 하는 기법으로, 객체 모델링 기법(OMT, Object-Modeling Technique)이라고도 한다.

 

• 분석 활동은 '객체 모델링 - 동적 모델링 - 기능 모델링' 순으로 이루어진다.

객체 모델링 (Object Modeling)	정보 모델링이라고도 하며, 시스템에서 요구되는 객체를 찾아내어 속성과 연산 식별 및 객체들 간의 관계를 규정하여 객체 다이어그램으로 표시하는 것이다.
동적 모델링 (Dynamic Modeling)	상태 다이어그램(상태)을 이용하여 시간의 흐름에 따라 객체들 간의 제어흐름, 상호 작용, 동작 순서 등의 동적인 행위를 표현하는 모델링이다.
기능 모델링 (Functional Modeling)	자료 흐름도(DFD)를 이용하여 다수의 프로세스들 간의 자료 흐름을 중심으로 처리 과정을 표현한 모델링이다.

 

💡 객체 다이어그램 ? 소프트웨어를 구성하는 객체와 객체 간의 관계를 표현하는 그래픽 표기법
💡 상태 다이어그램 ? 객체의 상태가 시간에 따라 어떻게 변하는지를 표현하는 그래픽 표기법

 

 

객체지향 설계 원칙

📌 객체지향 설계 원칙은 시스템 변경이나 확장에 유연한 시스템을 설계하기 위해 지켜야 할 다섯 가지 원칙으로, 다섯 가지 원칙의 앞 글자를 따 SOLID 원칙이라고도 불린다.

 

단일 책임 원칙 (SRP, Single Responsibility Principle)	- 객체는 단 하나의 책임만 가져야 한다는 원칙이다. - 응집도는 높고, 결합도는 낮게 설계하는 것을 의미한다.
개방폐쇄 원칙 (OCP, Open-Closed Principle)	- 기존의 코드를 변경하지 않고 기능을 추가할 수 있도록 설계해야 한다는 원칙이다. - 공통 인터페이스를 하나의 인터페이스로 묶어 캡슐화하는 방법이 대표적이다.
리스코프 치환 원칙 (LSP, Liskov Substitution Principle)	- 자식 클래스는 최소한 자신의 부모 클래스에서 가능한 행위는 수행할 수 있어야 한다는 설계 원칙이다. - 자식 클래스는 부모 클래스의 책임을 무시하거나 재정의하지 않고 확장만 수행하도록 해야 한다.
인터페이스 분리 원칙 (ISP, Interface Segregation Principle)	- 자신이 사용하지 않는 인터페이스와 의존 관계를 맺거나 영향을 받지 않아야 한다는 원칙이다. - 단일 책임 원칙이 객체가 갖는 하나의 책임이라면, 인터페이 분리 원칙은 인터페이스가 갖는 하나의 책임이다.
의존 역전 원칙 (DIP, Dependency Inversion Principle)	- 각 객체들 간의 의존 관계가 성립될 때, 추상성이 낮은 클래스보다 추상성이 높은 클래스와 의존 관계를 맺어야 한다는 원칙이다. - 일반적으로 인터페이스를 활용하면 이 원칙은 준수된다.