정처기 1-3. 애플리케이션 설계
1. 공통 모듈 설계
< 공통 모듈 >
- 모듈 : 독립된 하나의 소프트웨어 또는 하드웨어 단위를 지칭하는 용어
- 상대적으로 독립성을 가지고 있음
- 단독으로 컴파일할 수 있으며, 재사용할 수 있음
- 독립성이 높은 모듈일수록 모듈 수정 시에도 다른 모듈들에 영향으르 거의 미치지 않고, 오류가 발생 시에도 쉽게 해결할 수 있다.
- 독립성을 높이려면 모듈의 결합도는 낮게, 응집도는 강하게, 모듈의 크기는 작게 만들어야 한다.
- 공통 모듈 : 전체 프로그램의 기능 중 특정 기능을 처리할 수 있는 실행 코드
- 원칙 : 정확성 / 명확성 / 완전성 / 일관성 / 추적성
< 모듈화 >
- 모듈화 : 프로그램이 효율적으로 관리될 수 있도록 시스템을 분해하고 추상화함으로써 소프트웨어 제품의 성능을 향상시키거나 시스템의 수정 및 재사용, 유지 관리를 쉽게 하는 기법
- 바람직한 모듈 설계 방안 :
- 결합도는 낮추고 응집도는 높인다.
- 모듈의 복잡도와 중복성을 줄이고 일관성을 유지한다.
- 모듈의 기능은 예측가능해야 하며, 지나치게 제한적이어서는 안 된다.
- 적당한 모듈의 크기를 유지한다.
- 설계에서 계층적 자료 조직이 제시되어야 한다.
- 유지보수가 용이해야 한다.
- 응집도 : 모듈 내부에서 구성요소 간에 밀접한 관계를 맺고 있는 정도
- 결합도 : 모듈과 모듈 간에 어느 정도 관련성이 있는지를 나탄는 정도
- 팬인(Fan-in) : 어떤 모듈을 제어(호출)하는 모듈의 수
- 팬아웃(Fan-out) : 어떤 모듈을 제어(호출)되는 모듈의 수
< 설계 모델링 >
- 설계 모델링 : 요구사항 분석 단계에서 규명된 필수 기능들의 구체적인 구현 방법을 명시하는 기법
- 소프트웨어 설계는 변경이 쉽도록 구조화되어야 한다.
- 독립적이고 기능적인 특성을 지닌 모듈 단위로 분할 설계한다.
- 유형 :
| 구조 모델링 | 시스템의 구성요소들과 이들 사이의 구조적인 관계와 특성들을 모델링 |
| 행위 모델링 | 시스템의 구성요소들이 언제 어떠한 순서로 수행되는가오 같은 동적인 특성들을 모델링 |
< 소프트웨어 설계 유형 >
| 자료 구조 설계 | 소프트웨어를 구현하는데 필요한 자료 구조로 변환하는 과정 |
| 아키텍처 설계 | 소프트웨어를 구성하는 컴포넌트 간의 관계를 정의 |
| 인터페이스 설계 | 소프트웨어와 상호작용하는 컴퓨터 시스템, 사용자 등이 어떻게 통신하는지를 기술 |
| 프로시저 설계 | 프로그램 아키텍처의 컴포넌트를 소프트웨어 컴포넌트의 프로시저 서술로 변환하는 과정 |
| 협약에 의한 설계 | 클래스에 대한 여러 가정을 공유하도록 명세한 설계 선행조건 / 결과조건 / 불변조건 |
- 자료 구조 설계, 아키텍처 설계, 인터페이스 설계, 프로시저 설계는 상위 설계에 속하지만 모듈 설계는 하위 설계에 속한다.
< 코드 설계 >
- 코드 설계 : 데이터의 분류나 조합을 쉽게 하기 위하여 사물을 표현하는 코드를 설계하는 기법
- 코드의 기능 : 표준화 / 분류 / 식별 / 배열 / 간소화 / 연상 / 암호화 / 오류 검출
- 코드 설계 종류 : 연상 코드 / 블록 코드 / 순차 코드 / 표의 숫자 코드 / 십진 코드 / 그룹 분류식 코드
- 코드 종목 오류 : 사본 오류 / 전위 오류 / 생략 오류 / 첨가 오류 / 이중 전위 오류
< HIPO >
- HIPO : 시스템의 분석 및 설계, 문서화할 때 사용되며, 하향식 소프트웨어 개발을 위한 문서화 도구
- 기능과 자료의 의존 관계를 동시에 표현할 수 있음
- HIPO 차트 종류 : 가시적 도표 / 총체적 도표 / 세부적 도표
< 소프트웨어 아키텍처 >
- 소프트웨어 아키텍처 : 여러가지 소프트웨어 구성요소와 그 구성요소가 가진 특성 중에서 외부에 드러나는 특성, 그리고 구성요소 간의 관계를 표현하는 시스템의 구조
- 소프트웨어 아키텍처 프레임워크 : 소프트웨어 집약적인 시스템에서 아키텍처가 표현해야 하는 내용 및 이들간의 관계를 제공하는 아키텍처 기술 표준
- 구성요소 :
| 아키텍처 명세서 | 아키텍처를 기록하기 위한 산출물들 |
| 이해관계자 | 시스템 개발에 관련된 모든 사람과 조직 |
| 관심사 | 시스템에 대해 이해관계자들의 서로 다른 의견과 목표 |
| 관점 | 개별 뷰를 개발할 때 토대가 되는 패턴이나 양식 |
| 뷰 | 서로 관련 있는 관심사들의 집합이라는 관점에서 전체 시스템을 표현 |
| 근거 | 아키텍처 결정 근거 |
| 목표 | 환경 안에서 한 명 이상의 이해관계자들이 의도하는 시스템의 목적, 사용, 운영 방법 |
| 환경 | 시스템에 영향을 주는 요인 |
| 시스템 | 각 애플리케이션, 서브 시스템, 시스템의 집합, 제품군 등의 구현체 |
- 소프트웨어 아키텍처 4+1 뷰 : 고객의 요구사항을 정리해 놓은 시나리오를 4개의 관점에서 바라보는 소프트웨어적인 접근 방법
- 구성요소 : 유스케이스 뷰 / 논리 뷰 / 프로세스 뷰 / 구현 뷰 / 배포 뷰
- 소프트웨어 아키텍처 비용 평가 모델 : 아키텍처 접근법이 품질 속성에 미치는 영향을 판단하고 아키텍처의 적합성을 평가하는 모델
- 종류 : SAAM / ATAM / CBAM / ADR / ARID
- 소프트웨어 아키텍처 패턴 : 소프트웨어를 설계할 때 참조할 수 있는 전형적인 해결 방식
- 유형 : 계층화 패턴 / 클라이언트-서버 패턴 / 파이프-필터 패턴 / 브로커 패턴 / MVC 패턴
2. 객체지향 설계
< 객체지향 >
- 객체지향 : 실세계의 개체를 속성과 메서드가 결합한 형태의 객체로 표현하는 기법
- 구성요소 : 클래스 / 객체 / 메서드 / 메시지 / 인스턴스 / 속성
- 기법 :
| 캡슐화 | 서로 관련성이 많은 데이터와 이와 관련된 함수들을 한 묶음으로 처리하는 기법 결합도가 낮아지고 재사용이 용이 인터페이스가 단순화 됨 |
| 상속성 | 상위 클래스의 속성과 메소드를 하위 클래스에서 재정의 없이 물려받아 사용하는 기법 |
| 다형성 | 하나의 메시지에 대해 각 객체가 가지고 있는 고유한 방법으로 응답할 수 있는 능력 |
| 추상화 | 공통 성질을 추출하여 추상 클래스를 설정하는 기법 |
| 정보 은닉 | 코드 내부의 데이터와 메소드를 숨기고 공개 인터페이스를 통해서만 접근이 가능하도록 하는 코드 보안 기술 |
| 관계성 | 연관화 / 집단화 / 분류화 / 일반화 / 특수화 |
- 설계 원칙 : SOLID
| 단일 책임의 원칙 | 하나의 클래스는 하나의 목적을 위해서 생성 |
| 개방 폐쇄의 원칙 | 소프트웨어의 구성요소는 확장에는 열려있고 변경에는 닫혀있어야 함 |
| 리스코프 치환의 원칙 | 서브 타입은 어디서나 자신의 기반 타입으로 교체할 수 있어야 한다는 원칙 |
| 인터페이스 분리의 원칙 | 한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다는 원칙 |
| 의존성 역전의 원칙 | 실제 사용 관계는 바뀌지 않으며, 추상을 매개로 메시지를 주고받음으로서 관계를 최대한 느슨하게 만드는 원칙 |
- 방법론 : OOSE(야콥슨) / OMT(럼바우) [객체지향 분석 절차 : 객체 모델링-동적 모델링-기능 모델링] / OOD(부치)
< 디자인 패턴 >
- 디자인 패턴 : 소프트웨어 공학의 소프트웨어 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계 방법을 정리한 패턴
- 구성요소 : 패턴명 / 문제 및 배경 / 솔루션 / 사례 / 결과 / 샘플 코드
- 종류 : 생성 패턴 / 구조 패턴 / 행위 패턴
| 생성 패턴 | Builder / Prototype/ Factory Method / Abstract Factory / Singleton |
| 구조 패턴 | Bridge / Decorate / Facade / Flyweight / Proxy / Conposite / Adapter |