[실기] 소프트웨어 구축 - 소프트웨어 설계

소프트웨어 설계 원리

• 분할과 정복
  • 여러개의 작은 시스템으로 나누고 각 각을 만든다.
• 모듈화 (Modulartly)
  • 시스템 기능을 모듈 단위로 분류 -> 성능 / 재사용성 향상
  • 모듈 크기가 클 수록 만들 모듈의 수는 적다. 그럼 통합할 비용도 적어진다. 대신 모듈 하나의 비용이 높음
  • 모듈 크기가 작을 수록 모듈 수는 많아지고 통합하는데 비용이든다.
• 추상화 (Abstraction)
  • 불필요한 부분은 생략, 필요한 부분만 강조
  • 문제의 포괄적인 개념 설계 -> 세분화 -> 구체화
  • 과정 추상화 : 전반적인 흐름만 파악가능하도록 설계
  • 데이터(자료) 추상화: 데이터의 세부적 속성이나 용도는 정의하지 않고 구조만 표현한다.
    • private 으로 외부에서는 이 정보를 모르고 생성자로 정보의 구조만 알려주고 캡슐화로 정보를 얻는다.
  • 제어 추상화: 이벤트 발생의 정확한 절차나 방법은 정의하지 않는다. 대표 가능한 표현으로 대체한다.

// 과정 추상화
abstract class CoffeeShop {
    void processOrder(CoffeeOrder order) {
        takeOrder(order);
        prepareCoffee(order);
        serveCoffee(order);
    }

    abstract void takeOrder(CoffeeOrder order);
    abstract void prepareCoffee(CoffeeOrder order);
    abstract void serveCoffee(CoffeeOrder order);
}

// 데이터 추상화
class CoffeeOrder {
    private String customerName;
    private String coffeeType;
    private int quantity;

    public CoffeeOrder(String customerName, String coffeeType, int quantity) {
        this.customerName = customerName;
        this.coffeeType = coffeeType;
        this.quantity = quantity;
    }

    public String getCustomerName() {
        return customerName;
    }

    public String getCoffeeType() {
        return coffeeType;
    }

    public int getQuantity() {
        return quantity;
    }
}

// 제어 추상화
interface Button {
    void onClick();
}

• 단계적 분해 (Stepwise refinement)
  • 하향식 설계 전략으로 추상화를 반복해서 세분화
• 정보 은닉 (Information Hiding)
  • 다른 모듈의 접근/ 변경 불가
  • 모듈이 독립적이라 요구사항에 따라 수정/테스트/유지보수 용이

---

UML (Unified Modeling Language)

• 고객/개발자 간 워놜한 소통을 위해 표준화된 대표적 객체지향 모델링 언어
• Rumbaugh, Booch, Jacobson 등 객체지향 방법론의 장점을 통합함.
• 사물 (Things)
  • 구조 (개념, 물리적 요소), 행동, 그룹, 주해(부가적 설명, 제약조건)
• 관계 (Relationship)
  • 연관 관계 (Association)
    • 2개 이상의 사물이 서로 연관 된 경우, 양방향 or 단방
    • 다른 클래스의 정보를 사용할 수 있는 경우
    • private void setOtherclass(OtherClass other) { this.other = other; }
  • 집합 관계 (aggregation)
    • 하나의 사물이 다른 사물에 포함된 경우 (전체-부분 관계)
    • 즉, 다른 클래스가 꼭 있어야 완성 되는 경우
    • private OtherClass other = other;
  • 포함 관계 (Composition)
    • 집합 관계 내 한 사물의 변화가 다른 사물에게 영향
    • 다른 클래스가 있어야 완성되지만 다른 클래스가 나에게 종속된 경우
    • 내가 사라지면 다른 클래스도 사라짐.
    • private OtherClass other = new OtherClass();
  • 일반화 관계 (Generalization)
    • 다른 사물에 비해 일반적인지 구체적인지 표현
    • 상속 개념 extends
    • Child extends Parent
  • 의존 관계 (Dependency)
    • 사물 간 서로 영향을 주는 관계
    • 한 클래스에서 다른 클래스의 기능을 사용
    • public print(OtherPrint print) { print.print(); }
  • 실체화 관계 (Realization)
    • 한 객체가 다른 객체에게 오퍼레이션을 수행하도록 지정
    • 인터페이스를 구현
    • implements OtherClass
• 다이어그램 (Diagram)
  • 구조, 정적 다이어 그램
    • 클래스 : 클래스 간 관계, 클래스의 변수 자료형, 변수명 정보
    • 객체 : 인스턴스를 객체, 객체의 값 정보
    • 컴포넌트 : 구현 모듈 간 관계
    • 배치 : 물리적 요소의 위치/구조 표현 Server 에서 어떤 정보가 Client에게 어떤 정보로
    • 복합체 구조 : 클래스와 컴포넌트의 복합체 내부 표현
    • 패키지 : 패키지 구조를 표혀
  • 행위, 동적 다이어그램
    • 유스케이스 : 사용자 + Use Case
    • 시퀀스 : 시스템과 객체가 주고 받는 메시지 표현
    • 커뮤니케이션: 객체들 간 주고 받는 메시지와 연관관계
    • 상태: 다른 객체와 상호작용에 따른 상태 변화
    • 활동 : 객체의 처리 로직, 조건에 따른 처리의 흐름 순서에 따라 표현
    • 타이밍: 객체 상태 변화, 시간 제약을 표현
    • 상호작용 개요 : 상호작용 다이어그램 간 제어 흐름 표현

---

• UI 설계 (User Interface)
  • 직관성, 유효성, 학습성, 유연성
  • CLI(command line), GUI(graphic), NUI(natural), VUI(voice), OUI(organic)
  • Wireframe : 기획 초 대략적인 레이아웃 설계
  • Story Board: 최종적 산출 문서 (와이어프레임 UI, 프로세스)
  • Prototype : 와이어프레임 / 스토리보드에 인터렉션(동적 효과) 적용
  • Mockup : 실제 화면과 유사한 정적인 형태 모형
  • Use case : 사용자 측면 요구사항 및 목표를 다이어그램으로 표현