[소프트웨어공학] 소프트웨어 설계

6 분 소요

<h1 id="설계의-기본-개념">설계의 기본 개념</h1>
<h2 id="소프트웨어-설계-절차">소프트웨어 설계 절차</h2>
<ul>
  <li>DFD, DD 분석</li>
  <li>외부 설계<br />
파일 설계, 입출력 설계 등 S/W의 내적인 기능보다는 외부적은 특성을 설계</li>
  <li>내부 설계(기본설계)<br />
S/W의 내부 설계이며 주로 모듈의 기능을 정의하거나 모듈 간의 관계를 정의하는 설계</li>
  <li>내부 설계(상세설계)<br />
모듈 내부의 알고리즘을 정의</li>
  <li>설계 명세서</li>
</ul>

<h2 id="설계-모형">설계 모형</h2>
<ul>
  <li>문서량 기준
    <ul>
      <li>
        <p>데이터(Data) 설계<br />
요구분석의 자료 사전(DD, 메타 데이터)을 분석</p>
      </li>
      <li>
        <p>구조(Architectural) 설계<br />
구조도 작성(외부 설계)</p>
      </li>
      <li>
        <p>관계(Interface) 설계<br />
모듈 간의 관계를 표현(기본 설계)</p>
      </li>
      <li>
        <p>절차(Procedure) 설계<br />
PDL로 알고리즘을 작성(상세 설계)</p>
      </li>
    </ul>
  </li>
  <li>노력 기준
    <ul>
      <li>절차 설계</li>
      <li>관계 설계</li>
      <li>구조 설계</li>
      <li>데이터 설계</li>
    </ul>
  </li>
</ul>

<h2 id="설계의-종류">설계의 종류</h2>
<ul>
  <li>상위 설계(High-Level Design) : 아키텍처/예비 설계, 하위 설계를 위한 바탕
    <ul>
      <li>구조 설계</li>
      <li>DB 설계</li>
      <li>인터페이스 설계</li>
    </ul>
  </li>
  <li>하위 설계(Low-Level Design) : 시스템 수준에서의 소프트웨어 구성 컴포넌트 간의 관계
    <ul>
      <li>컴포넌트 설계</li>
      <li>자료구조 설계</li>
      <li>알고리즘 설계</li>
    </ul>
  </li>
</ul>

<h2 id="구조적-설계의-원칙">구조적 설계의 원칙</h2>
<ul>
  <li>
    <p><strong>모듈화(Modularization)</strong><br />
단일 기능을 갖출 수 있도록 부분적으로 묶어서 처리하는 기술<br />
단위 프로그램, 함수, 서브 프로그램을 작성하기 위한 설계 기법</p>
  </li>
  <li><strong>추상화(Abstraction)</strong><br />
세부적은 설계를 배제하고 전체 흐름과 구조를 알아볼 수 있도록 개관적인 설계부터 점차 세부적으로 진행하는 설계 기법
    <ul>
      <li>기능 추상화 : 수행의 흐름만을 정의</li>
      <li>제어 추상화 : 선택, 반복, 분기 등의 설계를 추상화</li>
      <li>자료 추상화 : 변수 및 레코드 등을 추상화</li>
    </ul>
  </li>
  <li>
    <p><strong>구조화(Structured)</strong><br />
모듈을 수행하기 위한 위치나 시기를 전체 구조에 적절하게 배치시키는 설계 기법</p>
  </li>
  <li>
    <p><strong>정보 은닉(Information Hiding)</strong><br />
모듈 간의 관계성을 최소화시키는 설계 기법.(S/W 변경 용이)<br />
설계상의 결정 사항들이 각 모듈 안에 숨겨져 있어 다른 모듈이 접근하거나 변경을 못한다</p>
  </li>
  <li>
    <p><strong>분할과 정복</strong><br />
Bottom-Up 방식으로 작은 시스템을 개발하고, 이를 합쳐 큰 시스템을 만든다</p>
  </li>
  <li><strong>단계적 분해</strong><br />
하향식 설계에서 사용. 문제를 상위 수준에서 점증적으로 더 구체적인 하위 수준으로 분할하는 기법
    <ul>
      <li>문제를 하위 수준의 독립된 단위로 나눈다</li>
      <li>구분된 문제의 자세한 내용은 가능한 뒤로 미룬다</li>
      <li>점증적으로 구체화 작업을 계속한다</li>
    </ul>
  </li>
</ul>

<h2 id="좋은-설계">좋은 설계</h2>
<ul>
  <li>요구사항을 모두 표현(완전성)</li>
  <li>유지보수하기 쉽고(변경이 용이) 가독성이 좋고 객관성 있게 작성</li>
  <li>구현 관점에서 데이터/기능/행위 영역을 설명하는 완전한 그림을 제공</li>
  <li><strong>모듈적이어야 하며, 두 모듈 간의 상호 의존도는 약하게 해야 한다</strong></li>
</ul>

<h1 id="모듈화">모듈화</h1>
<h2 id="모듈의-특징">모듈의 특징</h2>
<ul>
  <li>구현, 컴파일, 설계는 독립적으로 수행, 실행은 종속적으로 수행</li>
  <li>다른 모듈을 호출할 수도, 호출당할 수 있다</li>
  <li>모듈 호출 시 매개변수를 전달하거나 전달받을 수 있다</li>
</ul>

<h2 id="모듈화의-장점">모듈화의 장점</h2>
<ul>
  <li>단위 프로그램을 독립적으로 설계할 수 있기 때문에 설계가 용이</li>
  <li>모듈만을 구분하면 되므로 프로그램의 복잡도를 감소</li>
  <li>다른 모듈에 영향을 주지 않을 수 있으므로 수정이 용이</li>
</ul>

<h2 id="공유도--제어도">공유도 / 제어도</h2>
<ul>
  <li>공유도(Fan-in)
얼마나 많은 모듈이 주어진 모듈을 호출하는가를 나타내는 척도.</li>
  <li>제어도(Fan-out)
주어진 모듈이 호출하는 모듈의 개수</li>
</ul>

<h1 id="모듈의-응집력cohesion">모듈의 응집력(Cohesion)</h1>
<p>모듈 안의 요소들이 서로 관련되어 있는 정도로 강할수록 좋은 설계(좋은 설계 순서)</p>

<ul>
  <li>
    <p><strong>기능적(Functional)</strong> 응집<br />
모듈 내부가 하나의 단일 기능으로 존재하는 경우</p>
  </li>
  <li>
    <p><strong>순차적(Sequential)</strong> 응집<br />
모듈 내부의 루틴들이 이전의 명령어로부터 나온 출력 결과를 그 다음 명령어의 입력자료로 사용하는 경우</p>
  </li>
  <li>
    <p><strong>교환적(Communication)</strong> 응집<br />
모듈 내부의 루틴들이 작업 대상이 같은 기능끼리 존재하는 경우나 동일한 입력과 출력을 사용하는 작업들이 모인 경우<br />
예시) 하나의 파일을 대상으로 갱신 작업을 하는 루틴끼리 묶인 루틴</p>
  </li>
  <li>
    <p><strong>절차적(Procedural)</strong> 응집<br />
모듈 내부의 루틴들이 수행 시기에 순위가 있는 기능끼리 존재하는 경우</p>
  </li>
  <li>
    <p><strong>시간적(Temporal)</strong> 응집<br />
모듈 내부의 루틴들이 시간상으로 수행 시기가 같은 기능끼리 존재</p>
  </li>
  <li>
    <p><strong>논리적(Logical)</strong> 응집<br />
모듈 내부의 루틴들이 같은 범주에 속하는 기능끼리 묶은 모듈.<br />
유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들이 하나의 모듈로 형성</p>
  </li>
  <li>
    <p><strong>우연적(Coincidental)</strong> 응집<br />
모듈 내부의 루틴들이 뚜렷한 관계없이 묶인 경우</p>
  </li>
</ul>

<h1 id="모듈의-결합도coupling">모듈의 결합도(Coupling)</h1>
<p>두 모듈 간의 관계성(상호 의존성)의 척도로, 약할수록 좋은 설계(좋은 설계 순서)</p>

<ul>
  <li>
    <p><strong>자료(Data)</strong> 결합도<br />
두 모듈 간의 인터페이스가 자료 요소만으로 구성된 결합도<br />
Call By Value 기법으로 결합된 모듈</p>
  </li>
  <li>
    <p><strong>구조(Stamp)</strong> 결합도<br />
두 모듈 간의 인터페이스로 배열이나 레코드같은 자료 구조가 전달</p>
  </li>
  <li>
    <p><strong>제어(Control)</strong> 결합도<br />
호출 모듈에서 전달된 자료에 의해서 운용되는 피 호출 모듈의 관계(종속적인 관계)</p>
  </li>
  <li>
    <p><strong>외부(Extern)</strong> 결합도<br />
외부 변수에 의해 영향을 받는 두 모듈이 결합된 관계. 전역 변수 관련</p>
  </li>
  <li>
    <p><strong>공통(Common)</strong> 결합도<br />
공유되는 공통 데이터 영역을 여러 모듈이 사용하는 모듈 관계.<br />
Call By Referrence, 메모리 번지의 공유</p>
  </li>
  <li>
    <p><strong>내용(Content)</strong> 결합도<br />
모듈이 다른 모듈 내부 기능 및 그 내부 자료를 참조하는 형태의 결합</p>
  </li>
</ul>

<h1 id="구조적-설계-표기법">구조적 설계 표기법</h1>
<h2 id="n-snassi-schneiderman-chart">N-S(Nassi-Schneiderman) Chart</h2>
<p>IBM사에 의해 개발되었으며 입출력 자료와 소프트웨어 모듈들 사이의 관계를 표현하는 뛰어난 능력을 가지고 있다.</p>

<ul>
  <li>고려사항
    <ul>
      <li>도표는 항상 직사각형</li>
      <li>도표의 제어 흐름은 맨 위에서 시작</li>
      <li>제어 흐름은 위에서 아래로 흐른다(하향식)</li>
      <li>수평으로 그어진 줄은 모두 평행이 되어야 한다</li>
      <li>사각형 안의 내용이 수행된 후에는 아래 방향으로 빠져나온다</li>
      <li>사각형에 빈 공간이 있을 수 있다</li>
    </ul>
  </li>
</ul>

<ul>
  <li>특징
    <ul>
      <li>논리적 기술에 중점을 둔 도형을 이용한 표현 방법</li>
      <li>연속, 선택 및 다중 선택, 반복 등의 제어 논리 구조로 표현</li>
      <li>임의의 제어 이동이 어렵다</li>
      <li>상자 도표라고도 하며 프로그램으로 구현이 쉽다</li>
      <li>조건이 복합된 곳의 처리를 시각적으로 명확히 식별하는데 적합</li>
    </ul>
  </li>
</ul>

<h2 id="hipohierarchy-plus-input-process-output">HIPO(Hierarchy plus Input Process Output)</h2>
<p>IBM에서 개발한 방법으로 프로그램을 기능 위주로 문서화하는 하향식 설계 기법.</p>

<p>입력/처리/출력으로 구성되어 시각적으로 알아보기 쉽게 표현할 수 있으며 구조화된 방법으로 구현될 수 있도록 한다.</p>

<ul>
  <li>종류
    <ul>
      <li>
        <p>도식 목차(가시적 도표, Visual Table of Contents)<br />
전체적인 흐름과 구조를 나타내는 도표</p>
      </li>
      <li>
        <p>총괄 도표(총체적 도표, Overview Diagram)<br />
입력/처리/출력 등의 기능을 명확히 표현한 도표(<strong>사용자관점</strong>)</p>
      </li>
      <li>
        <p>상세 도표(세부적 도표, Detail Diagram)<br />
총괄 도표의 일부 기능을 구체적으로 표현한 모듈 도표(<strong>개발자관점</strong>)</p>
      </li>
    </ul>
  </li>
  <li>특징
    <ul>
      <li>분석 및 설계 도구로 사용</li>
      <li>하향식(Top-Down) 개발에 적당</li>
      <li>수정 및 유지보수가 용이</li>
      <li>소규모 프로젝트에 적합</li>
      <li>기능과 자료의 관계를 동시에 표현할 수 있다</li>
    </ul>
  </li>
</ul>

<h1 id="설계-방법론">설계 방법론</h1>
<h2 id="구조적-설계-방법론">구조적 설계 방법론</h2>
<ul>
  <li>기본구조
    <ul>
      <li>순차(Sequence) 구조</li>
      <li>선택(Condition) 구조</li>
      <li>반복(Repetition) 구조</li>
    </ul>
  </li>
  <li>특징
    <ul>
      <li>단일 입출력으로 처리</li>
      <li>실행 효율성을 중시할 때 한정된 범위 내에서 GOTO문을 사용</li>
      <li>프로그램의 이해가 쉽고 유지보수와 검증이 용이</li>
    </ul>
  </li>
</ul>

<h2 id="자료-흐름-중심-설계-방법론">자료 흐름 중심 설계 방법론</h2>
<ul>
  <li>자료 흐름 설계 과정
    <ul>
      <li>정보 <strong>흐름의 유형</strong>을 설정</li>
      <li>흐름의 <strong>경계</strong>(Flow Boundaries)를 표시</li>
      <li>자료 흐름도를 프로그램 구조로 <strong>사상</strong> → <strong>변환 사상</strong></li>
      <li><strong>제어 계층을 분해</strong>시켜서 정의</li>
      <li><strong>경험적 방법</strong>을 구체화</li>
    </ul>
  </li>
  <li><strong>변환 사상(Transform Mapping)</strong><br />
변환 흐름에 특성을 갖는 <strong>DFD(Data Flow Diagram)</strong> 을 전체 혹은 일부를 분할해서 <strong>구조도</strong>로 변화하는 작업</li>
</ul>

<h2 id="자료-구조-중심-설계-방법론">자료 구조 중심 설계 방법론</h2>
<p>입출력 자료의 구조 파악으로 소프트웨어 구조를 추출</p>

<h3 id="dssd-방법론-warnier-orr-기법">DSSD 방법론 (Warnier-Orr 기법)</h3>
<p>Warnier가 개발한 LCP(Logical of Program)를 Orr와 공동으로 개발한 자료 구조 지향 설계 방법으로 출력 자료를 중심으로 입력 자료를 설계하고 제어 구조도 설계하는 방법</p>

<ol>
  <li>출력 자료 정의 : 출력할 자료를 파악하여 배열</li>
  <li>논리적 레코드 정의 : 출력할 레코드의 구조를 정의</li>
  <li>사건 분석 : 출력할 레코드 항목을 기준으로 입력 항목을 정의</li>
  <li>물리적 레코드 정의 : 입력할 레코드의 구조를 정의</li>
  <li>논리적 절차 정의 : 입력/처리/출력 모듈로 구분하여 Warnier-Orr 도표를 그림</li>
  <li>물리적 절차 정의 : 명시된 도표를 보고 알고리즘 기술</li>
</ol>

<h3 id="jsd-방법론-jackson-기법">JSD 방법론 (Jackson 기법)</h3>
<p>프로그램의 입력과 출력 자료의 구조를 대응시켜서 설계하는 자료 구조 지향 설계 방법론으로 자료 구조를 정의하면서 제어 구조를 유도하는 방식</p>

<ol>
  <li>자료 구조 정의<br />
입출력 구조를 정의하여 일치되지 않는 부분을 처리 루틴으로 모듈화하고 일치하는 부분은 입력과 출력 루틴으로 모듈화</li>
  <li>구조도 작성<br />
입력/처리/출력으로 분류하여 잭슨 표기법으로 구조도를 세분화하여 작성</li>
  <li>
    <p>연산 목록 작성<br />
  구조도를 보고 필요한 제어 구조 명시</p>
  </li>
  <li>구조문 작성<br />
  명시된 제어 구조를 보고 알고리즘 기술</li>
</ol>

<h1 id="소프트웨어-설계-solid-원칙">소프트웨어 설계 SOLID 원칙</h1>
<h2 id="single-responsibility-priciple단일-책임-원칙--srp">Single Responsibility Priciple(단일 책임 원칙 : SRP)</h2>
<blockquote>
  <p>소프트웨어의 설계 부품은 반드시 한 개의 책임을 가져야 한다는 원칙</p>
</blockquote>

<h2 id="open-closed-principle개방-폐쇠-원칙--ocp">Open-Closed Principle(개방 폐쇠 원칙 : OCP)</h2>
<blockquote>
  <p>기존의 코드를 변경하지 않고 기능을 수정하거나 추가할 수 있도록 설계해야한다는 원칙</p>
</blockquote>

<p>한 번 설계가 되고 단위 테스트가 완료된 객체는 향후 외부에 변경 사항이 발생하더라도 객체 자체는 변경되지 않아야 한다는 것을 의미</p>

<h2 id="liskov-substitution-principle리스코프-치환-원칙--lsp">Liskov Substitution Principle(리스코프 치환 원칙 : LSP)</h2>
<blockquote>
  <p>자식 클래스는 부모클래스에서 가능한 행위를 수행할 수 있어야 한다는 원칙</p>
</blockquote>

<p>MIT 컴퓨터 사이언스 교수인 리스코프가 제안한 설계 원칙으로 상속관계에 있는 두 객체에 있어서 부모 클래스의 인스턴스가 사용된 자리에 자식 클래스의 인스턴스를 넣어도 <strong>코드의 맥락이 변하지 않아야</strong> 한다는 것을 의미한다.</p>

<p>자식 클래스가 부모 클래스를 대체하기 위해서는 부모의 기능에 대해 오버라이드되지 않도록 하면 된다. 즉, 자식 클래스는 부모 클래스의 책임을 무시하거나 재정의하지 않과 <strong>확장만 수행</strong>하도록 해야 LSP를 만족하게 된다.</p>

<h2 id="interface-segregation-principle인터페이스-분리-원칙--isp">Interface Segregation Principle(인터페이스 분리 원칙 : ISP)</h2>
<blockquote>
  <p>객체 자신이 사용하지 않을 인터페이스는 구현하면 안된다는 원칙</p>
</blockquote>

<p>가능한 경우라면, 범용 인터페이스를 구현하는 것보다 객체에 <strong>특화된 인터페이스를 분리</strong>해내어 구현한다.</p>

<h2 id="dependency-inversion-principle의존-역전-원칙--dip">Dependency Inversion Principle(의존 역전 원칙 : DIP)</h2>
<blockquote>
  <p>의존 관계를 맺을 때, 변화하기 쉬운 것(구체화)보다 변화하기 어려운 것(추상화)에 의존해야 한다는 원칙</p>
</blockquote>

<p>구체적인 클래스보다 <strong>추상성이 높은 인터페이스나 추상클래스와 관계</strong>를 맺는다는 것을 의미. 일반적으로 Interface를 활용 시 이 원칙을 준수할 수 있다.</p>

설계의 기본 개념

소프트웨어 설계 절차

DFD, DD 분석
외부 설계
파일 설계, 입출력 설계 등 S/W의 내적인 기능보다는 외부적은 특성을 설계
내부 설계(기본설계)
S/W의 내부 설계이며 주로 모듈의 기능을 정의하거나 모듈 간의 관계를 정의하는 설계
내부 설계(상세설계)
모듈 내부의 알고리즘을 정의
설계 명세서

설계 모형

문서량 기준
- 데이터(Data) 설계
  요구분석의 자료 사전(DD, 메타 데이터)을 분석
- 구조(Architectural) 설계
  구조도 작성(외부 설계)
- 관계(Interface) 설계
  모듈 간의 관계를 표현(기본 설계)
- 절차(Procedure) 설계
  PDL로 알고리즘을 작성(상세 설계)
노력 기준
- 절차 설계
- 관계 설계
- 구조 설계
- 데이터 설계

설계의 종류

상위 설계(High-Level Design) : 아키텍처/예비 설계, 하위 설계를 위한 바탕
- 구조 설계
- DB 설계
- 인터페이스 설계
하위 설계(Low-Level Design) : 시스템 수준에서의 소프트웨어 구성 컴포넌트 간의 관계
- 컴포넌트 설계
- 자료구조 설계
- 알고리즘 설계

구조적 설계의 원칙

모듈화(Modularization)
단일 기능을 갖출 수 있도록 부분적으로 묶어서 처리하는 기술
단위 프로그램, 함수, 서브 프로그램을 작성하기 위한 설계 기법
추상화(Abstraction)
세부적은 설계를 배제하고 전체 흐름과 구조를 알아볼 수 있도록 개관적인 설계부터 점차 세부적으로 진행하는 설계 기법
- 기능 추상화 : 수행의 흐름만을 정의
- 제어 추상화 : 선택, 반복, 분기 등의 설계를 추상화
- 자료 추상화 : 변수 및 레코드 등을 추상화
구조화(Structured)
모듈을 수행하기 위한 위치나 시기를 전체 구조에 적절하게 배치시키는 설계 기법
정보 은닉(Information Hiding)
모듈 간의 관계성을 최소화시키는 설계 기법.(S/W 변경 용이)
설계상의 결정 사항들이 각 모듈 안에 숨겨져 있어 다른 모듈이 접근하거나 변경을 못한다
분할과 정복
Bottom-Up 방식으로 작은 시스템을 개발하고, 이를 합쳐 큰 시스템을 만든다
단계적 분해
하향식 설계에서 사용. 문제를 상위 수준에서 점증적으로 더 구체적인 하위 수준으로 분할하는 기법
- 문제를 하위 수준의 독립된 단위로 나눈다
- 구분된 문제의 자세한 내용은 가능한 뒤로 미룬다
- 점증적으로 구체화 작업을 계속한다

좋은 설계

요구사항을 모두 표현(완전성)
유지보수하기 쉽고(변경이 용이) 가독성이 좋고 객관성 있게 작성
구현 관점에서 데이터/기능/행위 영역을 설명하는 완전한 그림을 제공
모듈적이어야 하며, 두 모듈 간의 상호 의존도는 약하게 해야 한다

모듈화

모듈의 특징

구현, 컴파일, 설계는 독립적으로 수행, 실행은 종속적으로 수행
다른 모듈을 호출할 수도, 호출당할 수 있다
모듈 호출 시 매개변수를 전달하거나 전달받을 수 있다

모듈화의 장점

단위 프로그램을 독립적으로 설계할 수 있기 때문에 설계가 용이
모듈만을 구분하면 되므로 프로그램의 복잡도를 감소
다른 모듈에 영향을 주지 않을 수 있으므로 수정이 용이

공유도 / 제어도

공유도(Fan-in) 얼마나 많은 모듈이 주어진 모듈을 호출하는가를 나타내는 척도.
제어도(Fan-out) 주어진 모듈이 호출하는 모듈의 개수

모듈의 응집력(Cohesion)

모듈 안의 요소들이 서로 관련되어 있는 정도로 강할수록 좋은 설계(좋은 설계 순서)

기능적(Functional) 응집
모듈 내부가 하나의 단일 기능으로 존재하는 경우
순차적(Sequential) 응집
모듈 내부의 루틴들이 이전의 명령어로부터 나온 출력 결과를 그 다음 명령어의 입력자료로 사용하는 경우
교환적(Communication) 응집
모듈 내부의 루틴들이 작업 대상이 같은 기능끼리 존재하는 경우나 동일한 입력과 출력을 사용하는 작업들이 모인 경우
예시) 하나의 파일을 대상으로 갱신 작업을 하는 루틴끼리 묶인 루틴
절차적(Procedural) 응집
모듈 내부의 루틴들이 수행 시기에 순위가 있는 기능끼리 존재하는 경우
시간적(Temporal) 응집
모듈 내부의 루틴들이 시간상으로 수행 시기가 같은 기능끼리 존재
논리적(Logical) 응집
모듈 내부의 루틴들이 같은 범주에 속하는 기능끼리 묶은 모듈.
유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들이 하나의 모듈로 형성
우연적(Coincidental) 응집
모듈 내부의 루틴들이 뚜렷한 관계없이 묶인 경우

모듈의 결합도(Coupling)

두 모듈 간의 관계성(상호 의존성)의 척도로, 약할수록 좋은 설계(좋은 설계 순서)

자료(Data) 결합도
두 모듈 간의 인터페이스가 자료 요소만으로 구성된 결합도
Call By Value 기법으로 결합된 모듈
구조(Stamp) 결합도
두 모듈 간의 인터페이스로 배열이나 레코드같은 자료 구조가 전달
제어(Control) 결합도
호출 모듈에서 전달된 자료에 의해서 운용되는 피 호출 모듈의 관계(종속적인 관계)
외부(Extern) 결합도
외부 변수에 의해 영향을 받는 두 모듈이 결합된 관계. 전역 변수 관련
공통(Common) 결합도
공유되는 공통 데이터 영역을 여러 모듈이 사용하는 모듈 관계.
Call By Referrence, 메모리 번지의 공유
내용(Content) 결합도
모듈이 다른 모듈 내부 기능 및 그 내부 자료를 참조하는 형태의 결합

구조적 설계 표기법

N-S(Nassi-Schneiderman) Chart

IBM사에 의해 개발되었으며 입출력 자료와 소프트웨어 모듈들 사이의 관계를 표현하는 뛰어난 능력을 가지고 있다.

고려사항
- 도표는 항상 직사각형
- 도표의 제어 흐름은 맨 위에서 시작
- 제어 흐름은 위에서 아래로 흐른다(하향식)
- 수평으로 그어진 줄은 모두 평행이 되어야 한다
- 사각형 안의 내용이 수행된 후에는 아래 방향으로 빠져나온다
- 사각형에 빈 공간이 있을 수 있다

특징
- 논리적 기술에 중점을 둔 도형을 이용한 표현 방법
- 연속, 선택 및 다중 선택, 반복 등의 제어 논리 구조로 표현
- 임의의 제어 이동이 어렵다
- 상자 도표라고도 하며 프로그램으로 구현이 쉽다
- 조건이 복합된 곳의 처리를 시각적으로 명확히 식별하는데 적합

HIPO(Hierarchy plus Input Process Output)

IBM에서 개발한 방법으로 프로그램을 기능 위주로 문서화하는 하향식 설계 기법.

입력/처리/출력으로 구성되어 시각적으로 알아보기 쉽게 표현할 수 있으며 구조화된 방법으로 구현될 수 있도록 한다.

종류
- 도식 목차(가시적 도표, Visual Table of Contents)
  전체적인 흐름과 구조를 나타내는 도표
- 총괄 도표(총체적 도표, Overview Diagram)
  입력/처리/출력 등의 기능을 명확히 표현한 도표(사용자관점)
- 상세 도표(세부적 도표, Detail Diagram)
  총괄 도표의 일부 기능을 구체적으로 표현한 모듈 도표(개발자관점)
특징
- 분석 및 설계 도구로 사용
- 하향식(Top-Down) 개발에 적당
- 수정 및 유지보수가 용이
- 소규모 프로젝트에 적합
- 기능과 자료의 관계를 동시에 표현할 수 있다

설계 방법론

구조적 설계 방법론

기본구조
- 순차(Sequence) 구조
- 선택(Condition) 구조
- 반복(Repetition) 구조
특징
- 단일 입출력으로 처리
- 실행 효율성을 중시할 때 한정된 범위 내에서 GOTO문을 사용
- 프로그램의 이해가 쉽고 유지보수와 검증이 용이

자료 흐름 중심 설계 방법론

자료 흐름 설계 과정
- 정보 흐름의 유형을 설정
- 흐름의 경계(Flow Boundaries)를 표시
- 자료 흐름도를 프로그램 구조로 사상 → 변환 사상
- 제어 계층을 분해시켜서 정의
- 경험적 방법을 구체화
변환 사상(Transform Mapping)
변환 흐름에 특성을 갖는 DFD(Data Flow Diagram) 을 전체 혹은 일부를 분할해서 구조도로 변화하는 작업

자료 구조 중심 설계 방법론

입출력 자료의 구조 파악으로 소프트웨어 구조를 추출

DSSD 방법론 (Warnier-Orr 기법)

Warnier가 개발한 LCP(Logical of Program)를 Orr와 공동으로 개발한 자료 구조 지향 설계 방법으로 출력 자료를 중심으로 입력 자료를 설계하고 제어 구조도 설계하는 방법

출력 자료 정의 : 출력할 자료를 파악하여 배열
논리적 레코드 정의 : 출력할 레코드의 구조를 정의
사건 분석 : 출력할 레코드 항목을 기준으로 입력 항목을 정의
물리적 레코드 정의 : 입력할 레코드의 구조를 정의
논리적 절차 정의 : 입력/처리/출력 모듈로 구분하여 Warnier-Orr 도표를 그림
물리적 절차 정의 : 명시된 도표를 보고 알고리즘 기술

JSD 방법론 (Jackson 기법)

프로그램의 입력과 출력 자료의 구조를 대응시켜서 설계하는 자료 구조 지향 설계 방법론으로 자료 구조를 정의하면서 제어 구조를 유도하는 방식

자료 구조 정의
입출력 구조를 정의하여 일치되지 않는 부분을 처리 루틴으로 모듈화하고 일치하는 부분은 입력과 출력 루틴으로 모듈화
구조도 작성
입력/처리/출력으로 분류하여 잭슨 표기법으로 구조도를 세분화하여 작성
연산 목록 작성
구조도를 보고 필요한 제어 구조 명시
구조문 작성
명시된 제어 구조를 보고 알고리즘 기술

소프트웨어 설계 SOLID 원칙

Single Responsibility Priciple(단일 책임 원칙 : SRP)

소프트웨어의 설계 부품은 반드시 한 개의 책임을 가져야 한다는 원칙

책임 대신 기능이라 해석해도 무방하다.

Open-Closed Principle(개방 폐쇠 원칙 : OCP)

기존의 코드를 변경하지 않고 기능을 수정하거나 추가할 수 있도록 설계해야한다는 원칙

한 번 설계가 되고 단위 테스트가 완료된 객체는 향후 외부에 변경 사항이 발생하더라도 객체 자체는 변경되지 않아야 한다는 것을 의미

Liskov Substitution Principle(리스코프 치환 원칙 : LSP)

자식 클래스는 부모클래스에서 가능한 행위를 수행할 수 있어야 한다는 원칙

MIT 컴퓨터 사이언스 교수인 리스코프가 제안한 설계 원칙으로 상속관계에 있는 두 객체에 있어서 부모 클래스의 인스턴스가 사용된 자리에 자식 클래스의 인스턴스를 넣어도 코드의 맥락이 변하지 않아야 한다는 것을 의미한다.

자식 클래스가 부모 클래스를 대체하기 위해서는 부모의 기능에 대해 오버라이드되지 않도록 하면 된다. 즉, 자식 클래스는 부모 클래스의 책임을 무시하거나 재정의하지 않과 확장만 수행하도록 해야 LSP를 만족하게 된다.

LSP의 만족 여부는 [자식 클래스 is a kind of 부모 클래스]의 참/거짓으로 간단히 파악이 가능

Interface Segregation Principle(인터페이스 분리 원칙 : ISP)

객체 자신이 사용하지 않을 인터페이스는 구현하면 안된다는 원칙

즉, 자신이 사용하지 않는 기능에는 영향을 받지 말아야 한다는 것을 의미한다

가능한 경우라면, 범용 인터페이스를 구현하는 것보다 객체에 특화된 인터페이스를 분리해내어 구현한다.

Dependency Inversion Principle(의존 역전 원칙 : DIP)

의존 관계를 맺을 때, 변화하기 쉬운 것(구체화)보다 변화하기 어려운 것(추상화)에 의존해야 한다는 원칙

구체적인 클래스보다 추상성이 높은 인터페이스나 추상클래스와 관계를 맺는다는 것을 의미. 일반적으로 Interface를 활용 시 이 원칙을 준수할 수 있다.

Twitter Facebook LinkedIn

SG Yoo.