1-소프트웨어 설계 3. 애플리케이션 설계 1) 공통 모듈 설계

(1) 공통 모듈 ***

1. 공통 모듈의 개념

• 모듈의 개념

  • 독립된 하나의 소프트웨어/하드웨어 단위를 지칭
  • 모듈화를 통해 분리된 시스템의 기능들로 서브 프로그램, 서브 루틴, SW 내 단위프로그램, 작업 단위 등과 같은 의미로 사용

• 모듈의 특징

  • 각 모듈은 상대적으로 독립성을 가짐

  • 모듈 내부에는 그 모듈을 하나로 통합하는 수많은 조합이 존재할 수 있음

  • 단독으로 컴파일 및 재사용 가능

  • 독립성 높다 → 다른 모듈에 영향 미치지 않고 수정 가능

    ⇒ 결합도와 응집도에 의해 측정 → 결합도는 약하게, 응집도는 강하게, 모듈 크기는 작게!

• 공통 모듈의 개념

  • 전체 프로그램의 기능 중 특정 기능을 처리할 수 있는 실행 코드
  • 자체적 컴파일 및 재사용 가능
  • 여러 프로그램에서 공통으로 사용할 수 있는 모듈 ex) 날짜 처리 유틸리티 모듈 등

2. 공통모듈 원칙

• 정확성 : 해당 기능이 시스템 기능이 필요한지 정확하게 작성
• 명확성 : 해당 기능에 대해 일관되게 이해되고 한 가지로 해석되게
• 완전성 : 시스템 구현에 필요한 모든 것을 기술
• 일관성 : 공통 기능 간에 상호 충돌이 없도록
• 추적성 : 공통 기능에 대한 요구사항 출처와 관련 시스템 등의 유기적 관계에 대해 식별 가능하게

3. 모듈화

• 모듈화 개념
  • 프로그램이 효율적으로 관리될 수 있도록 시스템 분해 및 추상화 → 성능 향상 및 재사용/유지 관리 용이
  • 기능 단위 모듈로 분해하는 설계 및 구현 기법
  • 기법
    • 루틴 : 특정 동작을 수행하는 기능을 가진 일련의 코드 명령들의 모음
    • 메인 루틴 : 프로그램 주요한 부분, 전체 개략 동작 절차 표시하도록 만든 루틴 → 서브 루틴 호출
    • 서브 루틴 : 메인 루틴에 의해 필요할 때마다 호출되는 루틴
• 모듈화의 필요성
  • 모듈이 너무 작아 개수가 많아짐 → 통합 비용 많이 발생
  • 모듈이 너무 큼 → 모듈 당 개발 비용 커짐
• 바람직한 모듈 설계 방안
  • 독립성과 재사용성을 높이기 위해 결합도 $\downarrow$, 응집도 $\uparrow$
  • 모듈 복잡도와 중복성 줄이고 일관성 유지
  • 모듈의 기능은 예측 가능, 지나치게 제한적이어서는 안됨
  • 적당한 모듈 크기 유지
  • 설계에서 계층적 자료 조직 제시
  • 유지보수 용이

4. 모듈화 유형

• 응집도
  • 구성 요소 간에 밀접한 관계를 맺는 정도
  • 응집도 높다 → 필요한 요소들로 구성되어 있다.
• 결합도
  • 모듈과 모듈간에 어느 정도 관련성이 있는지
  • 결합도 높다 → 모듈 간의 영향이 적다

5. 팬인(Fan-in) 및 팬아웃(Fan-Out)

• 팬인(Fan-in) 및 팬아웃(Fan-Out) 개념

  • 모듈 계층적으로 분석하기 위해 사용 → 시스템 복잡도 측정 가능

    

  • 최적화를 위해서는 팬인 높게, 팬아웃 낮게

• 팬인(Fan-in) 및 팬아웃(Fan-Out) 계산법

  

  • 팬인 : A-0 | B-1 | C-1 | D-1 | E-1 | F-2 | G-1 | H-2 | I-1 | J-1
  • 팬아웃 : A-3 | B-2 | C-2 | D-1 | E-1 | F-1 | G-1 | H-0 | I-0 | J-0

(2) 설계 모델링

1. 설계 모델링

• 설계 모델링 개념
  • 요구사항 분석 단계에서 규명된 필수 기능들의 구체적인 구현 방법 명시
  • 교수되는 기능과 성능 조건들을 만족하는 내부 기능, 구조, 동적 행위들을 모델링하여 표현, 분석, 검증 과정
• 설계 모델링 원칙
  • 설계는 변경이 쉽도록 구조화 되어야 함
  • 하나의 함수 안에 특정 기능을 수행하는 데 필요한 자료만 사용하도록 제한
  • 독립적이고 기능적 특성을 지닌 모듈 단위로 분할 설계
  • 계층적 구조를 가져야 함
• 설계 모델링 유형
  • 구조 모델링
    • 컴포넌트들의 유형, 인터페이스, 내부 설계 구조 및 상호 연결 구조 모델링
    • 시스템 구성 요소들과 이 사이의 구조적인 관계와 특성 모델링
    • 프로시저, 데이터 구조, 모듈, 파일 구조
  • 행위 모델링
    • 소프트웨어의 구성 요소들의 기능들이 언제, 어떤 순서로 수행하고 상호작용 하는지를 모델링
    • 시스템 구성요소들이 언제 어떠한 순서로 수행되는가와 같은 동적 특성 모델링
    • 입력 데이터, 출력 데이터, 데이터 흐름, 데이터 변환, 데이터 저장 등

2. 소프트웨어 설계 유형

• 자료 구조 설계
  • 요구 분석 단계에서 생성된 정보를 바탕으로 구현하는데 필요한 자료 구조로 변환
• 아키텍처 설계
  • 예비 또는 상위 수준 설계
  • 시스템 전체 구조 기술
  • 컴포넌트 간의 관계 정의
• 인터페이스 설계
  • 소프트웨어와 상호작용하는 시스템, 사용자등이 어떻게 통신하는지 기술
• 프로시저 설계
  • 아키텍처의 컴포넌트를 소프트웨어 컴포넌트의 프로시저 서술로 변환
• 협약에 의한 설계
  • 클래스에 대한 여러 가정을 공유하도록 명세
  • 선행 조건 : 컴포넌트 오퍼레이션 사용 전에 참이 되어야할 조건
  • 결과 조건 : 사용 후 만족되어야 할 조건
  • 불변 조건 : 오퍼레이션이 실행되는 동안 항상 만족되어야할 조건

⇒ 위의 설계들은 모두 상위 설계에 속하지만, 모듈 설계는 하위설계에 속함

3. 코드 설계

• 코드 설계 개념
  • 데이터의 분류나 조합을 쉽게하기 위해 사물을 표현하는 코드를 설계
• 코드의 기능
  • 표준화 : 일정 기준에 따라 통일적으로 표현
  • 분류 : 동일한 특성을 가진 데이터로 그룹화하여 나눔
  • 식별 : 다른 것과 구별될 수 있는 기능
  • 배열 : 일련의 순서로 나열할 수 잇는 기능
  • 간소화
  • 연상 : 대상체의 뜻과 의미가 코드에 내포
  • 암호화
  • 오류 검출
• 코드 설계 종류
  • 연상 코드
    • 코드만 보고 대상을 연상할 수 있도록 명칭 일부를 약호 형태로 넣어 구성된 코드
  • 블록 코드
    • 공통성 있는 것끼리 블록으로 구분, 각 블록 내에서 일련번호 부여
    • 구분 코드라고도 불림 ex) 지역번호, 국번
  • 순차 코드
    • 일정한 기준에 따라 순서대로 일련번호를 부여한 코드 ex) 반 번호
  • 표의 숫자 코드
    • 대상 자료의 물리적인 수치인 길이, 넓이 용량 등을 표시한 코드 ex) 사이즈
  • 십진 코드
  • 그룹 분류식 코드
    • 기준에 따라 대분류, 중분류, 소분류로 구분하여 번호를 부여한 코드
• 코드 설계 절차
  1. 코드화 항목 선정
  2. 코드화 목적 설정
  3. 코드와 대상 확인
  4. 코드화 범위 설정
  5. 코드 사용 기간 설정
  6. 코드화 항목의 특성 분석
  7. 코드화 방식 결정
• 코드 오류 종류
  • 사본 오류 : 한 자리를 잘못 표기 → 필사 오류, 오자 오류라고도 함
  • 전위 오류 : 연속된 두 글자가 서로 바뀌어 표기
  • 생략 오류 : 한 글자를 빼먹고 기술
  • 첨가 오류 : 한 글자 추가되어 기술
  • 이중 전위 오류 : 전위 오류가 중복 발생

4. HIPO

• HIPO(Hierarchy Input Process Output) 개념
  • 시스템 분석 및 설계, 문서화 할 때 사용 → 하향식 소프트웨어 개발을 위한 문서화 도구
• HIPO 특징
  • 체계적 문서 관리 가능
  • 이해 쉬움
  • 기능과 자료의 의존 관계 동시 표현 가능
  • 변경, 유지 보수 용이
  • HIPO 차트 : 시스템의 기능을 고유 모듈로 분할하여 이들간의 인터페이스를 계층 구조로 표현
• HIPO 차트 종류
  • 가시적 도표 : 시스템 전체적 기능 및 흐름을 보여주는 계층 구조도
  • 총체적 도표 : 입력/처리/출력에 대한 정보를 제공하는 도표 → 프로그램 구성하는 기능 기술
  • 세부적 도표 : 총체적 도표에 표시된 기능을 구성하는 기본 요소 상세히 기술

(3) 소프트웨어 아키텍처

1. 소프트웨어 아키텍처 개념

• 외부에 드러나는 특성, 구성 요소간의 관계를 표현하는 시스템 구조

2. 소프트웨어 아키텍처의 필요성

• 주요 이해관계자들 간의 관점 조율을 통한 시스템을 최적화
• 비기능적 요소에 집중, 기능적 요소 또한 고려

3. 소프트웨어 아키텍처 프레임워크

• 소프트웨어 아키텍처 프레임워크 개념
  • 아키텍처가 표현해야 하는 내용 및 이들 간의 관계를 제공하는 아키텍처 기술

• 소프트웨어 아키텍처 프레임워크 구성 요소
  • 아키텍처 명세서
  • 이해 관계자
  • 관심사
  • 관점 : 개별 뷰를 개발할 때 토대가 되는 패턴이나 양식
  • 뷰 : 서로 관련 있는 관심사들의 집합이라는 관점에서 전체 시스템을 표현
  • 근거 : 아키텍처 결정 근거
  • 목표
  • 환경
  • 시스템

4. 소프트웨어 아키텍처 4 + 1 뷰

• 소프트웨어 아키텍처 4 + 1 뷰 개념

  • 고객의 요구사항을 정리해놓은 시나리오를 4개의 관점에서 바라보는 접근 방법
  • 4개의 분리 구조로 구성되는 아키텍처 개념 제시 → 충돌, 요구사항 충족하는 지 체크방법으로 유스케이스를 사용

• 소프트웨어 아키텍처 4 + 1 뷰 구성 요소

  • 유스케이스 뷰

    • 유스케이스 or 아키텍처를 도출하고 설계, 다른 뷰를 검증하는 데 사용
    • 사용자, 설계자, 개발자, 테스트 관점

  • 논리 뷰

    • 시스템의 기능적 요구사항이 어떻게 제공되는지 설명
    • 설계자, 개발자 관점

  • 프로세스 뷰

    • 시스템의 비기능적 속성 → 자원 효율성, 병행 실행, 비동기, 이벤트 처리 등
    • 개발자, 시스템 통합자 관점

  • 구현 뷰

    • 개발 환경 안에서 정적인 소프트웨어 모듈 구성
    • 컴포넌트 구조와 의존성 및 부가 정보 정의

  • 배포 뷰
    - 컴포넌트가 물리적인 아키텍처에 어떻게 배치되는가를 매칭해서 보여줌

    

5. 소프트웨어 아키텍처 비용 평가 모델

• 소프트웨어 아키텍처 비용 평가 모델 개념
  • 아키텍처 접근법이 품질 속성에 미치는 영향 판단 및 아키텍처의 적합성 평가
• 소프트웨어 아키텍처 비용 평가 모델 종류
  • SAAM : 변경 용이성, 기능성에 집중 → 평가 용이하여 경험 없는 조직도 활용 가능한 비용 모델
  • ATAM : 아키텍처 품질 속성을 만족시키는지 판단 및 품질 속성들의 이해 상충 관계까지 평가
  • CBAM : ATAM 바탕의 시스템 아키텍처 분석 중심으로 경제적 의사결정에 대한 요구 충족 평가
  • ADR : 구성 요소간 응집도를 평가하는 모델
  • ARID : 특정 부분에 대한 품질 요소에 집중

6. 소프트웨어 아키텍처 패턴

• 소프트웨어 아키텍처 패턴 개념

  • 소프트웨어 설계 시 참조할 수 있는 해결 방식

• 소프트웨어 아키텍처 패턴 필요성

  • 상황별 패턴을 수립 및 적용하여 요구사항 만족시키고, 개발 생산성과 품질 확보 가능
  • 개발 시행착오 및 시간 단축, 높음 품질 소프트웨어 생산
  • 이미 검증된 구조로 개발 → 개발 안정적
  • 시스템 특성을 개발 전에 예측 가능

• 소프트웨어 아키텍처 패턴 유형

  • 계층화 패턴
    

    • 시스템을 계층으로 구분하여 구성
    • 하위 모듈은 특정 수준의 추상화 제공 → 다음 상위 계층에 서비스 제공
    • 서로 마주보는 2개의 계층 사이에서만 상호 작용 이루어짐

  • 클라이언트-서버 패턴

    

    • 하나의 서버 ↔ 다수의 클라이언트
    • 사용자가 클라이언트를 통해 서버에 서비스 요청 → 서버는 클라이언트에 서비스 제공
    • 서버는 클라이언트 요청 계속 대기

  • 파이프-필터 패턴

    

    • 데이터 스트림 생성하고 처리하는 시스템에 적합
    • 서브 시스템이 입력 받아 처리 → 결과를 다음 서브 시스템으로 넘김
    • 필터 컴포넌트는 재사용성이 좋고, 추가가 쉽기에 확장 용이

  • 브로커 패턴

    

    • 분리된 컴포넌트들로 이루어진 분산 시스템에 사용 → 원격 서비스 실행을 통해 상호작용
    • 브로커 컴포넌트 → 컴포넌트 간 통신 조정
    • 서버 → 자신의 기능을 브로커에 넘겨줌(Publish) → 클라이언트 → 브로커에 서비스 요청 → 브로커 → 자신의 레지스트리에 있는 적합한 서비스로 리다이렉션

  • 모델-뷰-컨트롤러 패턴

    

    • MVC 패턴 → 대화형 애플리케이션을 3개의 서브 시스템으로 구조화

      • 모델 : 핵심 기능과 데이터 보관
      • 뷰 : 사용자에게 정보 표시
      • 컨트롤러 : 요청을 입력받아 처리

    • 각 부분이 별도의 컴포넌트 분리

      → 서로 영향 받지 않고 개발 가능

      → 코드 재사용 가능

    • 여러 개의 뷰가 있어야 하는 대화형 애플리케이션 구축에 적합