객체지향 분석과 설계

Starting Object-Oriented Analysis and Design

• 객체 지향 분석 (Object-Oriented Analysis, OOA)
  개발하려는 시스템의 요구사항을 이해하고, 문제 영역(Problem Domain)에서 핵심적인
  객체(Object)
  들과 그 객체들의
  속성(Attribute)
  ,
  행동(Behavior)
  , 그리고 객체들 간의
  관계(Relationship)
  를 식별하고 정의하는 과정입니다.
  "무엇을 만들어야 하는가?"에 대한 답을 객체 지향적인 용어로 찾는 활동입니다.
• 객체 지향 설계 (Object-Oriented Design, OOD)
  OOA 단계에서 식별된 객체와 관계들을 바탕으로, 실제 소프트웨어 시스템의 구조를 설계하는 과정입니다.
  각 객체를 어떤
  클래스(Class)
  로 표현할지, 클래스들 간의 상호작용은 어떻게 이루어질지, 시스템 전체의 아키텍처는 어떻게 구성할지 등을 결정합니다.
  "어떻게 만들 것인가?"에 대한 답을 구체화하는 활동입니다.

현실을 모델링하다

1. 명사/명사구 찾기
   요구사항 명세서, 유스케이스, 문제 설명서 등 관련 문서에서 반복적으로 등장하거나 중요한 의미를 가지는 명사나 명사구를 후보 객체로 식별합니다.
   • 예시: "고객은 상품을 장바구니에 담고 주문한다." -> 후보 객체: 고객, 상품, 장바구니, 주문
2. 실세계의 사물 또는 개념
   문제 영역에서 실제로 존재하는 물리적 사물(예: 자동차, 센서), 장소(예: 강의실, 창고), 조직(예: 회사, 부서), 개념적인 것(예: 계좌, 정책, 예약) 등을 객체로 고려할 수 있습니다.
3. 역할(Role) 기반 식별
   시스템과 상호작용하거나 시스템 내에서 특정 역할을 수행하는 주체들을 객체로 식별합니다. (예: 사용자, 관리자, 결제 처리기)
4. 이벤트(Event) 기록
   시스템에서 발생하는 중요한 사건이나 그 사건으로 인해 생성되는 정보(예: 주문 발생, 로그인 시도, 오류 보고)도 객체화될 수 있습니다.
5. 구조(Structure) 기반 식별
   다른 객체들을 포함하거나 관리하는 '전체-부분' 관계의 구조를 나타내는 객체를 식별합니다. (예: 자동차는 엔진, 바퀴 등을 포함)

• 클래스 이름
  보통 단수 명사로, 첫 글자는 대문자로 작성합니다. (예: Customer, Product, Order)
• 속성 (Attributes)
  클래스에 속한 객체들이 가지는 상태 정보나 특징을 나타냅니다. (예: Customer 클래스의 속성 - 이름, 주소, 이메일)
• 행동/메서드 (Behaviors/Methods)
  클래스에 속한 객체들이 수행할 수 있는 동작이나 기능을 나타냅니다. (예: Customer 클래스의 메서드 - 주문하다(), 정보수정하다())

이미지 제안: CRC 카드 예시. 카드 앞면이 세 칸으로 나뉘어 맨 위에는 클래스 이름, 왼쪽 아래 칸에는 책임 목록, 오른쪽 아래 칸에는 협력자 클래스 목록이 적혀 있는 모습. 여러 장의 CRC 카드가 테이블 위에 놓여 있는 모습도 좋음.

CRC 카드

• 아는 책임 (Knowing Responsibilities)
  • 자신의 private 데이터에 대해 아는 것
  • 관련된 다른 객체에 대해 아는 것 (참조)
  • 계산할 수 있는 값에 대해 아는 것
• 하는 책임 (Doing Responsibilities)
  • 자기 자신 객체의 상태를 변경하는 것 (예: 속성 값 수정)
  • 다른 객체를 생성하거나 계산을 수행하는 것
  • 다른 객체에게 작업을 요청(메시지 전송)하여 협력하는 것

• 정보 전문가 (Information Expert)
  책임을 수행하는 데 필요한 정보를 가장 많이 알고 있는 객체에게 그 책임을 할당합니다. (데이터와 그 데이터를 사용하는 행동을 가깝게 유지)
• 낮은 결합도 (Low Coupling)
  객체 간의 의존성을 최소화하는 방향으로 책임을 할당합니다.
• 높은 응집도 (High Cohesion)
  하나의 객체는 서로 밀접하게 관련된 책임들만 가지도록 합니다. (단일 책임 원칙과 유사)
• 생성자 (Creator)
  객체 B를 생성하거나 포함하는 객체 A가 있다면, B를 생성할 책임은 A에게 할당될 가능성이 높습니다.

• 목적
  • 데이터 보호 (Information Hiding)
    객체 내부의 상태가 외부에서 임의로 변경되는 것을 막아 데이터의 무결성을 유지합니다.
  • 결합도 감소
    내부 구현이 변경되어도 공개된 인터페이스만 동일하다면 외부 코드에 영향을 주지 않아 유지보수성이 향상됩니다.
• Java 예시
  접근 제어자(private, protected, public)를 사용하여 속성은 주로 private으로 선언하고, 이 속성에 접근할 수 있는 public getter/setter 메서드를 제공하는 것이 일반적인 캡슐화 방법입니다.

public class BankAccount {
    private String accountNumber; // private으로 데이터 보호
    private double balance;       // private으로 데이터 보호
 
    public BankAccount(String accountNumber, double initialBalance) {
        this.accountNumber = accountNumber;
        this.balance = initialBalance;
    }
 
    // 공개된 인터페이스(메서드)를 통해서만 잔액 조회 가능
    public double getBalance() {
        return balance;
    }
 
    // 공개된 인터페이스를 통해 입금 (내부 로직은 숨겨짐)
    public void deposit(double amount) {
        if (amount > 0) {
            balance += amount;
            System.out.println(amount + "원이 입금되었습니다. 현재 잔액: " + balance);
        } else {
            System.out.println("입금액은 0보다 커야 합니다.");
        }
    }
 
    // 공개된 인터페이스를 통해 출금 (내부 로직 및 잔액 확인은 숨겨짐)
    public boolean withdraw(double amount) {
        if (amount > 0 && amount <= balance) {
            balance -= amount;
            System.out.println(amount + "원이 출금되었습니다. 현재 잔액: " + balance);
            return true;
        } else {
            System.out.println("출금액이 유효하지 않거나 잔액이 부족합니다.");
            return false;
        }
    }
}

• 목적
  • 복잡성 감소
    시스템을 이해하고 설계하기 쉽게 만듭니다.
  • 재사용성 증가
    잘 정의된 추상화는 다양한 상황에서 재사용될 수 있습니다.
• Java 예시
  • 인터페이스 (Interface)
    객체가 수행해야 하는
    행동의 명세(계약)
    만을 정의합니다. 실제 구현은 이 인터페이스를 구현하는 클래스에서 담당합니다.
  • 추상 클래스 (Abstract Class)
    공통된 속성과 메서드를 가지지만, 일부 메서드는 자식 클래스에서 반드시 구현하도록 남겨둔 불완전한 클래스입니다.

// 추상화 예시: 인터페이스를 사용한 도형 그리기
interface Drawable { // "그릴 수 있는" 이라는 추상적인 개념 정의
    void draw();     // 무엇을 그릴지는 구체적인 클래스가 결정
}
 
class Circle implements Drawable {
    private int x, y, radius;
    public Circle(int x, int y, int radius) { this.x=x; this.y=y; this.radius=radius; }
 
    @Override
    public void draw() {
        System.out.println("원 그리기 (중심: " + x + "," + y + " 반지름: " + radius + ")");
    }
}
 
class Rectangle implements Drawable {
    private int x1, y1, x2, y2;
    public Rectangle(int x1, int y1, int x2, int y2) { /* ... */ }
 
    @Override
    public void draw() {
        System.out.println("사각형 그리기");
    }
}
 
public class DrawingEditor {
    public void drawShape(Drawable shape) { // Drawable 인터페이스 타입으로 받음
        shape.draw(); // 구체적인 도형이 무엇인지는 신경 쓰지 않고 "그린다"는 행위만 호출
    }
}

• 목적
  • 코드의 유연성 및 확장성 향상
    새로운 자식 클래스가 추가되어도 기존 코드를 거의 수정하지 않고 동일한 방식으로 처리할 수 있습니다. (OCP 원칙과 관련)
  • 코드 간결성
    다양한 타입의 객체를 동일한 인터페이스로 처리하므로 코드가 간결해집니다.
• Java 예시 (메서드 오버라이딩을 통한 다형성)
  위의 Drawable 예제에서 DrawingEditor의 drawShape 메서드가 다형성의 좋은 예입니다. shape.draw()를 호출할 때, shape 변수에 실제로 어떤 Drawable 구현 객체(Circle 또는 Rectangle)가 전달되었는지에 따라 해당 객체의 draw() 메서드가 실행됩니다.

public class Main {
    public static void main(String[] args) {
        DrawingEditor editor = new DrawingEditor();
        Drawable circle = new Circle(10, 10, 5);
        Drawable rectangle = new Rectangle(0,0, 20, 20);
 
        editor.drawShape(circle);    // Circle의 draw() 호출
        editor.drawShape(rectangle); // Rectangle의 draw() 호출
 
        // 새로운 Drawable 구현체가 추가되어도 editor.drawShape() 코드는 변경 불필요
        Drawable triangle = new Drawable() { // 익명 클래스로 Triangle 구현
            @Override
            public void draw() {
                System.out.println("삼각형 그리기");
            }
        };
        editor.drawShape(triangle);
    }
}

다음 시간에는 지금까지 배운 여러 방법론들을 좀 더 넓은 시각에서 비교해보고, 특히 현대 소프트웨어 개발에서 많이 사용되는 반복적, 진화적, 그리고 애자일 개발 방법론에 대해 자세히 알아보겠습니다.

• Object-oriented analysis and design - Wikipedia↗
• Responsibility-driven design - Wikipedia↗