애플리케이션 설계 - 모듈, 설계 모델링, 소프트웨어 아키텍처

(1) 공통 모듈

1. 모듈이란

- 모듈은 크게 독립된 하나의 소프트웨어 또는 하드웨어 단위

 

 

2. 모듈의 특징

• 독립성 : 각각의 모듈은 상대적인 독립성을 가짐(결합도와 응집도에 의해 측정)
• 다양한 조합 : 모듈 내부에는 모듈을 하나로 통합하는 수많은 조합이 존재
• 재사용 : 모듈은 단독으로 컴파일 할 수 없으며 재사용 가능
• 영향 최소화 : 독립성이 높은 모듈일수록 수정 시 다른 모듈에 영향을 거의 미치지 않음 

 

3. 공통 모듈이란

- 전체 프로그램의 기능 중 특정 기능을 처리할 수 있는 실행 코드

- 자체적으로 컴파일 가능하고, 다른 프로그램에서 재사용 가능

- 여러 기능 및 프로그램에서 공통으로 사용할 수 있는 모듈을 의미

 

 

4. 공통 모듈 원칙

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

 

5. 모듈화

- 모듈화는 프로그램이 효율적으로 관리될 수 있도록 시스템을 조립하고 추상화하면서 소프트웨어 제품의 성능을 향상시키거나 시스템의 수정 및 재사용, 유지 관리를 쉽게 하는 기법이다. 

- 기능 단위의 모듈로 분해하는 설계 및 구현 기법이다.

 

▶ 모듈화 기법

• 루틴 : 특정 동작을 수행하는 일련의 코드로 기능을 가진 명령들의 모임
• 메인 루틴 : 전체의 대략적인 동작 절차를 표시하도록 만들어진 루틴(메인 루틴은 서브 루틴을 호출)
• 서브 루틴 : 메인 루틴에 의해 필요할 때마다 호출되는 루틴

 

그렇다면 모듈화가 왜 필요할까?

- 모듈의 크기가 너무 작으면 비용이 너무 많이 발생함

- 반대로 모듈의 크기가 너무 크면 모듈 당 개발 비용이 커진다

 

▶ 모듈화 유형

• 응집도 : 모듈 내부에서 서로 간에 얼마나 밀접한 관계를 갖고 있는지
• 결합도 : 모듈과 모듈 간에 어느 정도 관련성이 있는지

 

6. 팬인 및 팬아웃

- 모듈을 계층적으로 분석하기 위해서 팬인, 팬아웃을 활용한다. 이를 통해 시스템의 복잡도를 측정할 수 있다.

 

구분	팬인(Fan-In)	팬아웃(Fan-Out)
개념	어떤 모듈을 호출하는 모듈의 수	어떤 모듈에 의해 호출되는 모듈의 수
모듈 숫자 계산	모듈 자신을 기준으로 모듈에 들어오면 팬인	모듈 자신을 기준으로 모듈에서 나가면 팬아웃
고려사항	팬인이 높으면 재사용 측면에서 설계가 잘 되어있지만 관리 비용이 증가할 수 있음	팬아웃이 높으면 불필요한지를 검토, 단순화도 검토해야 함

- 그래서 팬인은 높게, 팬아웃은 낮게 설계하는 것이 가장 이상적임

 

(2) 설계 모델링

1. 설계 모델링이란

- 필수 기능들의 구체적은 구현 방법을 명시하는 기법

- 소프트웨어에서 요구되는 기능을 만족하는 기능 등을 모델링하여 표현, 분석, 검증하는 과정

 

2. 설계 모델링 유형

유형	설명	구성요소
구조 모델링	컴포넌트들의 유형, 인터페이스, 내부 구조 등을 상호 연결 구조로 모델링	프로시저, 데이터 구조, 모듈, 파일구조
행위 모델링	기능들이 언제, 어떠한 순서로 기능을 수행하는지를 모델링	입력 데이터, 출력 데이터, 데이터 흐름 등

 

!!여기서 잠깐!!

컴포넌트란?

- 독립적인 소프트웨어 모듈을 뜻한다 

 

3. 소포트웨어 설계 유형

• 자료 구조 설계 : 정보를 바탕으로 소프트웨어를 구현하는 데 필요한 자료구조로 변환
• 아키텍처 설계 : 예비 설계 또는 상위 수준 설계, 소프트웨어 시스템의 전체 구조를 기술(하드웨어적 접근)
• 인터페이스 설계 : 소프트웨어와 상호작용하는 컴퓨터 시스템이나 사용자가 어떻게 통신하는지 기술
• 프로시저 설계 : 아키텍처 컴포넌트를 소프트웨어 컴포넌트의 프로시저 서술로 변환하는 과정
• 협약에 의한 설계 : 클래스에 대한 여러 가정을 공유하도록 명세한 설계

- 시스템 명세가 명확한 경우에는 하향식으로, 기존 컴포넌트들을 조합하여 시스템을 개발하는 경우네는 상향식이 좋음

- 모듈 설계는 하위 설계

- 자료 구조, 아키텍처, 인터페이스, 프로시저, 협약에 의한 설계는 상위 설계

 

 

4. 코드 설계

- 코드의 기능으로는 표준화, 분류, 식별, 배열, 간소화, 연상, 암호화, 오류 검출 기능이 있다. 

 

▶ 코드 설계 종류

1. 연상 코드 : 코드만 보고 대상을 연상할 수 있도록 간단하게 만든 부호로 구성된 코드
2. 블록 코드 : 공통성이 있는 것끼리 블록으로 구분 
3. 순차코드 : 일정한 기준에 따라 순서대로 일련번호를 부여한 코드
4. 표의 숫자 코드 : 대상 자료의 물리적인 길이나 넓이를 표시한 코드
5. 십진 코드 : 10진수로 표현한 코드
6. 그룹 분류식 코드 : 대분류, 중분류, 소분류로 구분하여 번호를 매긴 코드

▶코드 오류 종류

1. 사본 오류 : 한 자리를 잘못 표기한 경우
2. 전위 오류 : 연속된 두 글자가 서로 바뀌어 표기된 경우
3. 생략 오류 : 한 글자를 빼먹고 기술한 경우
4. 첨가 오류 : 한 글자를 추가되어 기술한 경우
5. 이중 전위 오류 : 전위 오류가 중복 발생한 경우

 

5. HIPO

1. HIPO란

- HIPO는 시스템을 분석하거나 설계하거나 문서화할 때 사용되며, 하향식 소프트웨어 개발을 위한 문서화 도구이다.

 

2. HIPO 특징

- 체계적인 문서관리 가능

- 기호, 도표 등을 사용해서 보기 쉬움

- 유지 보수하기 좋음

- 기능과 자료의 의존 관계를 동시에 표현 가능

- 고유 모듈들로 분할하여 이들 간의 인터페이스를 계층구조로 표현한 것이 HIPO 차트

 

▶ HIPO 차트 종류

종류	설명
가시적 도표	시스템의 전체적인 흐름을 보여줌
총체적 도표	입력, 처리, 출력에 대한 정보를 제공(기능에 대한)
세부적 도표	기능을 구성하는 기본 요소들을 상세히 기술하는 도표

 

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

 

1. 소프트웨어 아키텍처란

- 소프트웨어 아키텍처는 소프트웨어 구성요소와 그 특성 중에서 외부에 드러나는 특성, 그리고 그것간의 관계를 표현하는 시스템의 구조이다. 

- 소프트웨어 아키텍처가 필요한 이유는 시스템을 최적화하고 비기능적인 요소에도 집중해서 만들 수 있기 때문이다. 

 

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

- 아키텍처가 표현해야 하는 내용이나 이들 간의 관계를 제공하는 기술 표준이다. 

 

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

- 고객의 요구사항을 정리해 놓은 시나리오를 4개의 관점으로 바라보는 소프트웨어적인 접근 방법(논리 뷰, 구현 뷰, 프로세스 뷰, 배포 뷰, 유스케이스 뷰)

 

• 유스케이스 뷰 : 다른 뷰를 검증하는 데 사용되는 뷰
• 논리 뷰 : 시스템의 기능적인 요구사항이 어떻게 제공되는지 설명해주는 뷰
• 프로세스 뷰 : 시스템의 비기능적인 속성 
• 구현 뷰 : 정적인 소프트웨어 모듈의 구성을 보여주는 뷰
• 배포 뷰 : 컴포넌트가 어떻게 배치되는가를 매핑해서 보여주는 뷰

 

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

- 이 아키텍처 접근법이 아키텍처에 적합한지를 평가하는 모델

 

- 소프트웨어 아키텍처 비용 평가 모델 종류

종류	설명
SAAM	변경 용이성과 기능성에 집중
ATAM	아키텍처 품질 속성이 만족스러운지를 평가
CBAM	ATAM 분석 중심으로 경제적 의사결정에 대한 요구 충족 비용
ADR	구성요소 간 응집도 평가
ARID	특정 부분에 대한 품질요소에 집중하는 비용 평가

 

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

- 소프트웨어의 골격이 되는 기본 구조

- 안정적으로 수행이 가능하고 개발 전에 예측이 가능하다.

 

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

• 계층화 패턴 : 시스템을 계층으로 구분하여 구성하는 패턴
• 클라이언트 서버 패턴 : 하나의 서버와 다수의 클라이언트로 구성된 패턴
• 파이프-필터 패턴 : 데이터 스트림을 생성하고 처리하는 시스템에서 사용 가능한 단방향 패턴
• 브로커 패턴 : 분리된 컴포넌트들로 이루어져서 원격 서비스 실행을 통해 상호 작용이 가능한 패턴
• 모델-뷰-컨트롤러 패턴 : MVC 패턴이기도 함. 모델, 뷰, 컨트롤 뷰 3개의 서브 시스템으로 구조화하는 패턴
• 마스터-슬레이브 패턴 : 조정을 책임지는 마스터와 동기화되는 대상인 슬레이브로 구성되는 패턴

 

6. 소프트웨어 아키텍처 품질 속성

1. 시스템 품질 속성 : 가용성, 변경 용이성, 성능, 보안성, 사용 편의성, 시험 용이성
2. 비즈니스 품질 속성 : 시장 적시성, 비용과 이익, 프로젝트 생명주기 등
3. 아키텍처 품질 속성 : 개념적 무결성, 정확성과 안정성 등