객체 지향 분석의 방법론

객체 지향 분석

• 객체 지향 분석(OOA; OBJECT ORIENTED ANALYSIS)은 사용자의 요구사항과 관련된 객체, 속성, 연산, 관계 등을 정의하여 모델링 하는 작업이다.
• 개발을 위한 업무를 객체와 속성, 클래스와 멤버, 전체와 부분 등으로 나누어서 분석한다.
• 클래스를 식별하는 것이 객체지향 분석의 주요 목적이다.

객체 지향 분석의 방법론

• Rumbaugh(럼바우)방법: 분석 활동을 객체 모델, 동적 모델, 기능 모델로 나누어 수행함
• 객체 모델: 주문 시스템에서 고객, 주문, 제품을 클래스로 모델링. 동적 모델: 주문 상태가 '처리 중'에서 '완료'로 변하는 흐름을 상태 다이어그램으로 표현. 기능 모델: 주문 과정에서의 데이터 흐름을 분석하여 흐름도를 작성.
• Booch(부치)방법: 미시적(Micro) 개발 프로세스와 거시적(Macro) 개발 프로세스를 모두 사용하며, 클래스와 객체들을 분석 및 식별하고 클래스의 속성과 연산을 정의함
• Micro: 특정 객체를 식별하고 해당 객체의 속성 및 메서드를 정의. 예를 들어, User 클래스를 정의하고 그 속성(이름, 이메일)과 메서드(로그인, 로그아웃)를 설정. Macro: 전체 시스템을 설계하여 객체들이 어떻게 상호작용하는지 파악. class User: def __init__(self, name, email): self.name = name self.email = email def login(self): print(f"{self.name} 님이 로그인하셨습니다.") user1 = User("Alice", "alice@example.com") user1.login()
• Jacobson 방법: 유스케이스(Use Case)를 강조하여 사용함
• 유스케이스: "사용자가 로그인하고 주문 생성" 1. 사용자는 로그인 페이지로 이동. 2. 로그인 후, 제품 카탈로그를 확인. 3. 제품을 선택하여 주문을 생성.
• Coad와 Yourdon 방법: e-r 다이어그램을 사용하여 객체의 행위를 모델링하며, 객체 식별, 구조 식별, 주제 정의, 속성과 인스턴스 연결 정의, 연산과 메시지 연결 정의 등의 과정으로 구성함
• 객체 식별: Customer, Order, Product 객체 간의 관계: Customer는 여러 Order를 생성할 수 있음. 속성 정의: Customer - 이름, 주소; Order - 주문 번호, 날짜.
• Wirfs-Brock 방법: 분석과 설계 간의 구분이 없고, 고객 명세서를 평가해서 설계 작업까지 연속적으로 수행함
• 고객 명세서: "고객이 주문할 수 있는 시스템이 필요하다." 객체 책임: Order 객체는 주문을 생성하고 처리할 책임이 있다.

Rumbaugh 럼바우의 분석기법

• 럼바우의 분석 기법은 모든 소프트웨어 구성 요소를 그래픽 표기법을 이용하여 모델링 하는 기법이다.
• 객체 모델링 기법(OMT, Object-Modeling Technique)이라고 한다.
• 분석 활동은 ‘객체 모델링→동적 모델링→기능 모델링’ 순으로 이루어 진다.
  • 객체 모델링: 정보 모델링이라고도 하며, 시스템에서 요구되는 객체를 찾아내어 속성과 연산 식별 및 객체들 간의 관계를 규정하여 객체 다이어그램으로 표시하는 모델링
  • 동적 모델링: 상태 다이어그램을 이용하여 시간의 흐름에 다른 객체들 간의 제어 흐름, 상호 작용, 동작 순서 등의 동적인 행위를 표현하는 모델링
  • 기능 모델링: 자료 흐름도를 이용하여 다수의 프로세스들 간의 자료 흐름을 중심으로 처리 과정을 표현한 모델링

객체 지향 설계 원칙(solid 원칙)

• 단일 책임 원칙(SRP): 객체는 단 하나의 책임만 가져야 한다는 원칙
  • 만능 리모컨보다, TV 리모컨과 에어컨 리모컨처럼 하나의 리모컨이 한 가지 기기만 제어하는 것이 효율적이다.
  • 한가지일만!
• 개방-패쇄 원칙(OCP): 기존의 코드를 변경하지 않고 기능을 추가할 수 있도록 설계해야 한다는 원칙
  • 레고 블록은 항상 새 조각을 추가할 수 있지만, 이미 만든 구조물은 변경되지 않는다.
  • 열려 있지만 닫혀 있다!
• 리스코프 치환 원칙(LSP): 자식 클래스는 최소한 부모 클래스의 기능은 수행할 수 있어야 한다는 원칙
  • 전구 소켓에 어떤 전구를 끼워도 작동해야 한다. (낮은 전력, LED 전구 등)
  • 자식은 부모를 대체할 수 있다!
• 인터페이스 분리 원칙(ISP): 자신이 사용하지 않는 인터페이스와 의존 관계를 맺거나 영향을 받지 않아야 한다는 원칙
  • TV 리모컨엔 TV 기능만 있어야 해!
  • 필요한 인터페이스만!
• 의존 역전 원칙(DIP): 의존 관계 성립시 추상성이 높은 클래스와 의존 관계를 맺어야 한다는 원칙
  • 전기 제품은 전원 콘센트만 알면 된다. 그 뒤의 복잡한 전선 구조는 몰라도 된다.
  • 큰 것에 의존하자!