4장 설계 원리

설계 기본 개념

설계

요구 분석: '무엇을 만들 것인가를 다루는 작업

설계는 '어떻게 실현할 것인가'를 구체적으로 결정하는 활동

1. 아키텍처 설계 - 기본 구조 설계로 각 모듈의 역할과 인터페이스를 정의
2. 상세 설계 - 모듈 내부의 알고리즘, 데이터를 명세화 설계는 개발자의 창의성이 발휘되는 창조적인 과정

설계 원리

• 복잡한 시스템을 분할하고 하나씩 해결하는 분할 정복의 원리를 적용하면 복잡함을 잘 다룰 수 있음
  • 우리가 인지할 수 있는 개념부터 작업
  • 세분화 하면서 나눌 수 있다.

기본 개념

• 설계
  • 높은 수준의 의사 결정 과정의 연속
  • 설계 원리가 중요
• 전통적 설계 방법
  • 분할 정복, 추상화, 합성 등의 원리를 적용
• 최근의 방법
  • 아키텍처 기반의 설계 방법
• 아키텍처 이해
  • 서브시스템, 모듈의 개념과 설계 작업의 관점, 설계 작업 과정을 숙지 해야

서브 시스템

아키택처

• 시스템을 구성 하는 컴포넌트와 컴포넌트 상호작용의 집합

서브시스템

• 시스템의 복잡도를 줄이기 위하여 분할한 것 (개발중 개발자간의 커뮤니케이션 및 수정에 대한 영향 감소)
• 복잡한 시스템은 서브시스템을 반복적으로 분할하여 계층화 할 수 있음

 

	컴포넌트	모듈	서브시스템
개념	가지고 있으며 독릴적으로 존재할- 같은 기능을 가진 컴포넌트로 대체 가능。 - 재사용이 가능하게 설계됨 - 특정 목적(시스템의 사용자 인터페이스 제공)도 수행 함	-프로그래밍 언어의 문법구조에서 정의된 컴포넌트를 의미 - 모듈은 구체적인 프로그래밍 언어로 작성된 여 사용 - ex> 클래스, 메서드 패기 지는 Java 프로그램의 모듈이며, 함수, 파일은 C언어의 모듈임	- 여러 다른 방법들로 구현될! 객체 - 컴포넌트, 모듈보다는 더 추상적 - 정의 가능한 책임과 목적을 가지며, 소프트웨어나 하드웨어로 구성된 논리적 개표 -컴포넌트들이 변하거나 교체되더라도 지속적으로 존재 함 - 큰 시스템의 일부분으로 유한한 인터페이스를 가짐

 

설계관점

소프트웨어는 개발 과정에 여러 가지 다양한 형식으로 표현

• 요구 모델링 단계
  • 유스케이스나 기능 리스트
• 설계 단계
  • 서브시스템의 구조
• 구현 단계 : 원시 코드, 제어 흐름도 등으로 표현
• 전통적인 설계
  • Top-down, Bottom-up, 분할 정복 등 기능 실현 중심
• 아키텍쳐 설계
  • 관점에 근거한 품질 중심의 설계 작업
  • 아키텍쳐 설계에서의 세 가지 관점
    • 모듈 관점
      • 일정 책임을 구현한 코드 단위인! 모듈과 그 관계로 소프트웨어 구조를 설 명함
    • 컴포넌트 관점
      • 실행될 때 동작하는 요소와 상호작용으로 구조를 설명 ( 더 추상화 )
    • 할당 관점
      • 소프트웨어 하드웨어 설치, 작업 할당, 구현, 데이터 저장 등에 대한 관점

설계 작업 과정

• 설계작업
  • 의사 결정 과정이면서 동시에 시스템을 알아가는 과정
• 시스템 유형을 고려하는 것이 가장 중요
  • 아키텍처 스타일 선택에 지대한 영향
• 설계 목적 : 품질과 관련
  • 보안이 설계의 중요한 목적이라면 보안을 위한 인증 모듈과 정보 보호를 위한

설계 목표 설정

• 전체 시스템에 대한 설계 목표를 파악하고 결정
  • 예를 들어 전화 교환 시스템을 개발한다면 고장에 대한 내성(fault tolerance), 안전과 보안, 최대성능이 설계 목표
• 스타일 결정
  • 시스템이나 서브시스템의 타입을 결 정하기 위하여 설계 목표와 유형에 맞은 아키텍처 스타일을 선택 적용할 수 있는 아키텍처 스타일이 있다면 이를 적용하여 시스템의 표준 아키텍처를 설계, 없다면 맞춤형 아키텍처를 설계
• 서브시스템의 기능, 인터페이스 명세
  • 서브시스템 사이의 인터페이스를 정의하고 서브시스템 사이의 상호작용을 위한 동작을 작성
• 아키텍처 설계
  • 설계한 아키 텍처가 요구, 설계 목표, 설계 원리를 잘 만족하는지 검토

품질 목표

• 요구사항중 기능을 만족하는 모텔은 하나이 나 품질의 요구는 여러가지일수 있음
• 품질 제약사항(비기능적요구)은 설계에 대한 목표가 될 수 있음
• 비기능적인 요구를 설계 목표로 구체적으로 명시
• 이를 만족시키기 위하여 요구분석에서 찾은 비기능적 요구로 설계안을 만들고 그 중에 최적 안을 골라내는 작업
• 품질 요구사항을 충족하게끔 설계할 때는 다른 속성에 미치는 영향을 고려하여 설계
• 품질 속성의 우선순위를 정하고 상반되는 요구에 대한 절충안을 찾는 것이 중요

전통적인 설계 원리

소프트웨어 설계시 전통적으로 중요하게 보는 특징

• 효율성(efficiency)
  • 시스템이 사용하는 자원의 처리 시간과 기억 공간이 효과적인지
  • 컴퓨터 사용 초기에는 CPU와 메모리를 효율적으로 사용하는 것이 중요
• 단순성 (simplicity)
  • 유지보수성에 영향을 주는 가장 중요한 특성

추상화

• 컴포넌트가 어떻게 동작하는지 내부의 상세한 사항에 구애 받지 않고
• 외부에 보이는 동작을 나타내는 것
• 대상에 대하여 특정한 목적에 관련된 정보에 집중하고 나머지 정보는 무시하는 관점 ex) 자동차는 엑셀, 브레이크로 추상화 / 원리)(데이터 나 절 차적인 동작 관점으로 정의 ex) send
• 복잡성을 줄이고 복잡한 소프트웨어 시스템을 효율적으로 다루고 구현할 수 있음
• 존재 하는 컴포넌트의 추상은 유지보수에 중요한 역할을 함
• 20문제에서 30문제, 개념을 묻는 문제가 나온다.. 연습 문제 위주로 나온다. 판이 너무 큰 것은 나오지 않을 수 있다.

캡슐화

모듈화

• 문제를 소프트웨어의 구성요소가 될 만한 수준으로 분할하는 과정
  • 복잡한 시스템을 세분화 된 구성 요소로 정의하면 개발자와 고객이 더 쉽게 이해
• 소프트웨어를 작은 구성 요소, 즉 패키지 또는 클래스로 나누는 것
• 장점
  • 필요한 부분의 수정, 재사용이 용이함(모듈을 수정해도 일부분만 컴파일을 할 수 있기 때문)
  • 시스템의 문제를 국한(한정) 시키며 시스템을 고치는 작업도 수월하게 가능함
• 단점
  • 너무 많은 모듈화가 있으면 상호작용에 문제가 생길 수 있음

결합

• 모듈 간에 서로 의존하는 정도
• 좋은 소프트웨어는 낮은 결합력을 가짐
• 모듈 간의 결합 정도
  1. 모듈 간 인터페이스 수
  2. 각 인터페이스의 복잡성(통신 유형에 따라 결정됨)
•  

응집

• 하나의 모듈 안에서 수행되는 작업들이 서로 관련된 정도
• 모듈 안의 여러 요소들이 하나의 목적을 위하여 유기적으로 관련되어 있는 것이 제일 좋음
• 재사용하기도 쉽고 이해하기도 좋음
• 수정에 의하여 받는 영향이 적음

객체지향 설계 원리

상속과 인터페이스 등 새로운 구문과 함께 발전

• SOLID

0 Martin이 제안한 5가지 중요한 설계 원칙

0 2000년의 =。 '디자인 원칙 및 디자인 패턴'에서

소개된 것으로 각 원칙 영문 명칭의 앞글자만을 따온

SOLID

단일 책 임의 원 리(Single Responsibility Principle)

개 방 폐쇄의 원 리(Open Close Principle)

리 스코프 교체의 원 리 (Liskov Substitution Principle)

인 터 페 이스 분리 의 원 리(Interface Segregation Principle)

의 존관계 역 전의 원 리(Dependency Inversion Principle)

인터페이스와 구현의 분리

• 인터페이스

• 공개된 에소드의 프로토타입만을 정의해 놓은 것

• 공개된! 메소드를 인터페이스로 따로 정의하고 이를 구현 상속

• 컴포넌트의 공개 인터페이스를 컴포넌트가 어떻게

구현되는지 상세하게 나타낸 것과 분리

단일 책임의 원리 SOP

• 클래스의 역할과 책임을 단일화 하여 클래스를 변경해야 할 이유를 하나로 제한

Book은 책 이름, 저자, 내용을 관리하고 저장해야 하는 책임이 있음

Book은 다른 매체에 Print를 해 주면서 해상도 등의 책임도 있음

--> 분리 필요

개방 폐쇄의 원리 OCP

소프트웨어 개체(클래스, 모듈, 기능 등)가 확장을 위해서는 열려 있어야 하지만 수정을 위해서는 닫혀야함

상속을 이용하여 클래스가 정의 되었을때 다형성이 적용되어 서로 대체할 수 있는 인터페이스를 구현할수 있다. 클래스 자체를 수정하지 않고 쉽게 확장 가능

SortAlgorithm을 이용하는 Client 프로그램이 있다고 하면 SortAlgorithm을 상속 받은 여러 정렬

알고리즘들은 다형성을 이용하여 확장할 수 있도록 열려있다.

상속 관계가 아니라면 접근을 할 수 없기에 Client는 SortAIgorithm을 수정할 수 없음을 알 수 있다. (

수정에 닫힘 )