Software Design

- 분석된 요구사항 명세서를 참조하여 개발자가 실제적으로 개발할 수 있는 문서를 작성하는 과정

- 설계 목표를 설정하고 아키텍처안을 만든 후 최적의 설계

- 시스템 구조에 대한 설계, 모듈 설계, 자료에 대한 설계, 사용자 인터페이스 설계, 통신 방법에 대한 설계 등

- 설계 작업의 결과는 명세서로 작성되며 이 명세서는 프로그래밍을 위한 도면 역할

 

설계의 두 단계

Architectural Design (구조 설계, 초벌 설계, 상위 설계, 개략 설계)

- 시스템의 전체적인 구조(아키텍처)를 파악

Detailed Design (모듈 설계, 상세 설계, 하위 설계)

- 각 모듈별로 구체적인 알고리즘 레벨까지 정의

---

개략 설계

- 초벌 설계, 구조 설계, 아키텍처 설계 등으로도 불림

- 개발할 시스템의 모듈들끼리의 구조를 보여줌

- 함수지향 : 함수의 구조적 다이어그램

- 객체지향 : 클래스들의 정적 구조와 동적 구조

 

Datailed Design

- 각 모듈 내의 알고리즘 수준으로 내용을 설계

- 일반적으로 잘 안하는 경향이 있음

- 모든 모듈이 아니더라도 중요 모듈은 작성 후 검증이 필요

---

User Interface Design

- 쓰기 쉽게

- 이해하기 쉽게

- 배우기 쉽게

 

소프트웨어의 특징

- 복잡성(Complexity) : 시스템의 어느 두 부분도 동일하지 않으며 실행 중에 매우 많은 상태를 가질 수 있음

- 순응성(Conformiy) : 소프트웨어는 다른 구성 요소에 의해 부과된 표준을 준수해야 함

- 변화성(Changeability) : 소프트웨어는 지속적으로 변경될 필요가 있음

- 무가시성(Invisibility) : 소프트웨어의 구조나 상태를 직관적으로 이해하거나 시각화하기 어려움

 

Design Principles (설계 원리)

- 단순성(Simplicity)

- 효율성(Efficiency)

- 모듈화(Modularity)

- 추상화(Abstraction)

 

모듈(Module)

- 시스템을 모듈로 분할하면 각각의 모듈을 별개로 만들고 수정할 수 있어 좋은 구조로 만들 수 있음

- 모듈 별로 컴파일이 가능하면 일부 수정 후 전체 컴파일이 필요 없음

- 디버깅에 도움

- 모듈의 단위 : 함수, 객체, 컴포넌트, 서비스 등

- 모듈화의 기준 : 결합도(Coupling)와 응집도(Cohesion)

 

모듈화의 트레이드오프

모듈이 너무 많아지면 -> 모듈 간 오류가 많이 발생

모듈이 너무 작아지면(한 모듈이 커지면) -> 모듈 내 오류가 많이 발생

모듈 크기를 적절히 맞춰야 함

---

Cohesion (응집도)

- 응집도는 각 모듈 내에서의 태스크들의 응집 정도를 측정

- 응집도는 높을 수록 좋은데, 한 모듈에서는 하나 또는 관련있는 일을 하는 것이 좋음

Cohesion Type
Type	Desirability	Description
Functional	Acceptable	하나의 일만 함
Sequential	Acceptable	같은 데이터를 쓰되, 메소드 간 순서가 있음
Communicational	Acceptable	같은 데이터를 쓰고, 메소드 간 순서가 없음
Procedural	Occasionally Acceptable	다른 데이터를 쓰는데, 같은 시간에 쓰임(각 작업이 순서에 따라)
Temporal	Not Acceptable	다른 데이터를 쓰는데, 같은 시간에 쓰임(작업 간 논리적 관계 없음)
Logical	Not Acceptable	상호 배타적인 작업이 논리적으로 병렬 수행됨
Coincidental	Not Acceptable	연관 없음

 

Coupling (결합도)

- 모듈 사이에 어떤 정보가 교환되며, 모듈들끼리 서로 종속되는 정도

- 독립적일수록 느슨한 결합이고 좋은 것

- 반대로 의존성이 높으면 밀결합이라 하고 좋지 않음

Coupling Type
Type	Desirability	Description
Data	Acceptable	간단하거나 단일 필드로 구성된 매개변수
Stamp	Acceptable	여러 필드로 구성된 데이터 구조
Control	Not Acceptable	컨트롤 플래그 (한 모듈이 플래그를 통해 다른 모듈의 내부 로직을 제어하도록 설계된 경우)
Common	Not Acceptable	공통 영역 데이터 (두개 이상의 모듈이 동일한 공통 영역 또는 전역 영역을 참조)
Content	Not Acceptable	모듈 내부 변경 (한 모듈이 다른 모듈의 내부를 직접 참조)

 

좋은 설계

- 복잡도 최소

- 느슨한 결합

- 강한 응집력

- 확장성

- 재사용성

- 좋은 유지보수성

- 유연성

 

OOAD ( Object-Oriented Analysis & Design )

- 객체를 위주로 분석 및 설계

- 다른 방법에 비해 자연스러움

- 분석과 설계의 갭이 비교적 적음

- 구조적 방법은 분석과 설계의 갭이 큼

- OOP는 객체지향 언어로 OOD를 현실화시키는 것