소프트웨어공학 - 7강. 소프트웨어 설계

설계

• 물건을 만들기 위한 계획 또는 제작을 위해 물건을 의미있게 표현

설계 프로세스

• 설계 작업의 입력
  • 요구사항과 분석 모델
  • 환경적 제약 사항
• 설계 작업의 결과물
• 반복 수행하면서 점점 정형화

설계 프로세스

• 요구사항 명세
• 데이터베이스 설계
• 서브 시스템 설계
• 컴포넌트 설계
• 자료구조 / 알고리즘 설계

설계 원리

• 분할 후 정복
  • 문제를 작은 것들로 나누고 각각을 독립적으로 정복
  • 수평 분할
  • 수직 분할
• 추상화
  • 내부의 상세한 내용을 생략
  • 외부 행위만을 기술하는 것
  • 추상화의 적용
    • 시스템 설계에서 구성 모듈들을 추상화하여 표현
  • 기능 추상화
  • 데이터 추상화
• 하향식과 상향식 설계
  • 하향식 설계
    • 낮은 수준의 컴포넌트들로 분해하는 것
    • 단계적 정제
  • 상향식 설계
    • 가장 기본적인 컴포넌트 설계
    • 상위 수준의 컴포넌트 설계
  • 고려사항
    • 새로 개발하는 작업에는 하향시이 적합
    • 기존 컴포넌트 조합하여 개발하는 경우에는 상향식이 적합

아키텍쳐 설계와 중요성

• 아키텍쳐 설계
  • 시스템 품질 특성과 제약사항을 반영해야 함
  • 아키텍쳐의 중요성
    • 개발이 진행된 후에는 시스템 구조 수정하기 어려움
• 아키텍쳐 스타일
  • 유사한 애플리케이션들에서 사용되는 공통적인 아키텍쳐 패턴
  • 아키텍쳐 설계의 초안이 됨
• 데이터 중심 아키텍쳐
  • 저장소 모델
• 데이터 흐름 아키텍쳐
  • 파이프 필터 구조
  • 데이터 요소들에 대한 개별 변환 작업들을 연결하여 시스템을 구성
• 클라이언트 - 서버 아키텍쳐
  • 분산 시스템의 아키텍쳐
  • 서버와 클라이언트는 네트워크로 연결됨
  • 데이터 처리가 분산됨
  • 새로운 서버 추가하기 쉬움
  • 모든 서버가 각각 데이터 관리 책임을 가짐
  • 공유 데이터 모델이 없으므로 데이터 교환이 비효율적
• 계층형 아키텍쳐
  • 추상 기계 모델
  • 시스템을 계층별로 구성
  • 하위 계층이 제공하는 서비스를 상위 계층이 이용
  • OSI 7 계층
  • 각 계층은 특정 서비스를 제공
  • 서브 시스템 간의 점증적 개발이 가능
• MVC 아키텍쳐
  • 모델 (M), 뷰 (V), 컨트롤러 (C)로 분리

아키텍쳐와 비기능적 속성

• 소프트웨어 아키텍쳐는 비기능적 요구사항에 영향을 줌
• 비기능적 속성을 고려하여 설계해야 함
  • 성능: 서브시스템들 간의 통신을 최소화
  • 보안: 계층형 아키텍쳐를 사용하고 보안이 중요한 시스템을 내부 계층에 위치시킴
  • 안전성: 안전성이 요구되는 요소들을 하나의 서브시스템에 집중시킴
  • 가용성: 동일 기능의 컴포넌트를 중복시킴
  • 유지보수성: 자료의 공유를 피하고 모듈화 시켜야 함

구조적 설계

• 구조적 분석(SA)의 결과물을 이용해 아키텍쳐를 설계하고 모듈을 개발하는 방법
• 구조도
  • 모듈들의 계층 구조, 모듈의 매개변수, 모듈들 간의 상호 연결 관계를 보여줌
  • 모듈들은 블랙박스로 표현되며 계층적으로 배열됨
• 변환 분석에 의한 구조적 설계
  • 데이터 흐름의 유형이 변환 흐름인 경우 사용
  • 변환 흐름은 데이터를 입력받고, 변환 가공하고 결과를 출력하는 유형
  • 변환 분석
    • 데이터흐름도에서 입력 흐름과 출력 흐름의 경계를 표시
    • 구조도에 입력, 변환, 출력 모듈을 제어하는 모듈을 추가로 만듦

트랜잭션 분석에 의한 구조적 설계

• 트랜잭션 흐름은 한 프로세스에서 입력을 여러 경로의 데이터 흐름으로 유출하는 유형
• 트랜잭션 분석
• 상세 설계
• 모듈화
  • 구성 요소들이 기능적으로 독립적이어서 이해하기 쉬움
  • 테스트 디버깅 유지보수 작업이 쉬움
  • 재사용하기 용이함
• 모듈의 독립성
  • 다른 모듈과의 결합도가 느슨해야 함
  • 하나의 모듈은 높은 응집력을 가져야 함
• 결합도
  • 두 모듈 사이의 상호 의존성 정도를 의미
  • 두 모듈을 연결하는 인터페이스의 복잡도에 좌우됨
• 결합도의 수준
  • 데이터 결합
  • 스탬프 결합
  • 제어 결합
  • 공통 결합
  • 내용 결합
• 응집력
  • 하나의 모듈이 가지는 기능적 집중성에 관한 척도
    • 모듈을 구성하는 요소들이 기능적으로 얼마나 관련성이 있는가
  • 응집력의 수준
    • 기능적 응집력
    • 순차적 응집력
    • 통신 응집력
    • 절차적 응집력
    • 시간적 응집력
    • 논리적 응집력
    • 우연적 응집력

SOLID 원칙

• 단일 책임 원칙
  • 모든 클래스는 하나의 책임만 가져야 한다
    • 유일한 이유로만 변경 될 수 있다
• 개방 폐쇄의 원칙
  • 클래스가 확장에는 열려 있고, 수정에는 닫혀 있어야 한다
  • 새로운 기능을 추가하면서도 기존 코드를 수정하지 않아도 된다
• 리스코프 교체의 원칙 (LSP)
  • 프로그램에 존재하는 부모 유형(T)의 객체를 자식 유형(S)의 객체로 교체할 수 있어야 함
  • T와 S간 상속관계가 적절해야 한다는 의미
  • LSP가 만족되면 새로운 자식 클래스를 추가할 때 기존 코드의 수정이 필요 없음
  • 자식 클래스에서 부모 클래스의 메소드를 재정의 하지 않으면 LSP의 문제가 없음
• 인터페이스 분리의 원칙 (ISP)
  • 하나의 큰 범용 인터페이스가 아닌 작고 특화된 여러 인터페이스로 나누어 설계 할 것
  • ISP를 만족하지 못한다면 사용하지 않는 인터페이스가 바뀔 때도 클라이언트에게 소프트웨어를 재배포 해야 함
  • 복합기 인터페이스 대신에 프린팅, 복사, 스캔 인터페이스로 나눌 것
• 의존 관계 역전의 원칙 (DIP)
  • 구체적 저수준 사물(구체 클래스)이 아닌 추상적 고수준 개념(인터페이스)에 의존해야 함
  • 실제 작업을 수행하는 저수준 구체 클래스는 변경되기 쉬움