I. 소프트웨어 설계 - 애플리케이션 설계 (1)

(1) 공통 모듈

 1. 공통 모듈의 개념

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

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

  - 여러 기능 및 프로그램에서 공통으로 사용할 수 있는 모듈을 의미하며 처리를 위한 유틸리티 모듈 등이 해당

*컴파일 (Compile) : 원시 코드 (Source Code)를 프로그래밍 언어의 목적 코드 (Object Code)로 옮기는 기법

 

 2. 공통 모듈 원칙

원칙	설명
정확성 (Correctness)	시스템 구현 시 필요한지 아닌지 알 수 있도록 정확하게 작성
명확성 (Clarity)	일관되게 이해되고 한 가지로 해석될 수 있도록 작성
완전성 (Completness)	시스템 구현될 때 필요하고 요구되는 모든 것을 기술
일관성 (Consistency)	공통 기능 간에 상호 충돌이 없도록 작성
추적성 (Traceability)	공통 기능에 대한 요구사항 출처와 관련된 시스템 등의 유기적 관걔에 대한 식별이 가능하도록 작성

 

 3. 모듈화

  1) 모듈화 개념

   - 소프트웨어 제품의 성능을 향상시키거나 시스템의 수정 및 재사용, 유지 관리를 쉽게 하는 기법

 

  2) 모듈화 필요성

   - 모듈의 크기가 너무 작아 모듈 개수가 많아지면 통합 비용이 발생한다

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

   - 모듈 개수와 모듈 통합 비용은 비례, 노력 비용과는 반비례

   - 둘 사이의 접점이 최소 비용 용역

 

 4. 모듈화 유형

  - 응집도와 결합도가 존재

유형	설명
응집도	- 모듈 내부에서 구송요소 간에 밀접한 관계를 맺고 있는 정도 - 응집도가 높을수록 필요한 요소들로 구성되어 있고 낮을수록 관련이 적은 요소들로 구성
결합도	- 모듈과 모듈 간에는 어느 정도 관련성이 있는지를 나타내는 정도 - 관련이 적을수록 모듈의 독립성이 높아 모듈 간 영향이 적어짐

5. 응집도 유형

유형	설명
우연적 응집도 (Coincidental Cohesion)	모듈 내부의 각 구성요소들이 연관이 없을 경우
논리적 응집도 (Logical Cohension)	특정 형태로 분류되는 처리 요소들이 한 모듈에서 처리되는 경우
시간적 응집도 (Temporal Cohension)	특정 시간에 처리되어야 하는 활동들을 한 모듈에서 처리할 경우
절차적 응집도 (Procedural Cohension)	모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성요소들이 그 기능을 순차적으로 수행할 경우
통신적 응집도 (Communication Cohesion)	동일한 입력과 출력을 사용하여 다른 기능을 수행하는 활동들이 모여있을 경우
순차적 응집도 (Sequential Cohesion)	모듈 내에서 한 활동으로부터 나온 출력 값을 다른 활동이 사용할 경우
기능적 응집도 (Functional Cohesion)	모듈 내부의 모든 기능이 단일한 목적을 위해 수행되는 경우

위에서 부터 순차적으로 응집도 낮음 (나쁜 품질)-> 응집도 높음 (좋은 품질)

 

 6. 결합도 유형

유형	설명
내용 결합도 (Content Coupling)	다른 모듈 내부에 있는 변수나 기능을 다른 모듈에서 사용하는 경우
공통 결합도 (Common Coupling)	모듈 밖에 선언된 전역 변수를 참조하고 전역 변수를 갱신하는 식으로 상호 작용하는 경우
외부 결합도 (External Coupling)	두 개의 모듈이 외부에서 도입된 데이터 포맷, 통신 프로토콜 또는 디바이스 인터페이스를 공유할 경우
제어 결합도 (Control Coupling)	처리할 대상이 값 뿐만 아니라 어떻게 처리를 해야 한다는 제어 요소가 전달되는 경우
스탬프 결합도 (Stamp Coupling)	모듈 간의 인터페이스로 배열이나 오브젝트, 스트럭처 등이 전달되는 경우
자료 결합도 (Data Coupling)	모듈간의 인터페이스로 전달되는 파라미터를 통해서만 모듈 간의 상호 작용이 일어나는 경우

위에서 부터 순차적으로 결합도 높음(낮은 품질) -> 결합도 낮음(좋은 품질)

 

(2) 설계 모델링

 1. 설계 모델링 개념

  - 요구사항 분석 단계에서 규명된 필수 기능들의 구체적 구현방법을 명시하고 소프트웨어의 기능, 구조 및 동적 행위들을 모델링하여 표현, 분석, 검증하는 과정

 

 2. 설계 모델링 원칙

  - 변경이 쉽도록 구조화 되어야 하며 필요한 자료만 사용하도록 규제한다

  - 모듈단위로 분할 설계하며 계층적 구조를 가져야 한다

 

 3. 설계 모델링 유형

유형	설명	구성요소
구조 모델링	- 소프트웨어를 구성하는 컴포넌트들의 유형, 인터페이스, 내부 설계 구조 및 이들의 상호 연결 구조를 모델링 - 시스템의 구성요소들과 이들 사이의 구조적인 관계와 특성들을 모델링	- *프로시저, 데이터 구조, *모듈, 파일 구조
행위 모델링	- 소프트웨어의 구성요소들의 기능들과 이들이 언제, 어떠한 순서로 기능을 수행하고 상호 작용하는지를 모델링 - 시스템의 구성요소들이 언제 어떠한 순서로 수행되는가와 같은 동적인 특성들을 모델링	- 입력 데이터, 출력 데이터, 데이터 흐름, 데이터 변환, 데이터 저장

*프로시저 (Procedure) : 프로그램을 기능에 따라 여러개의 단위로 분해하여 작성하는 것

*모듈 (Module) : 프로그램을 구성하는 구성요소의 일부. 관련된 함수나 변수 또는 클래스를 모아놓은 파일

 

유형	정적 (Static) 요소	동적 (Dynamic) 요소
구조 모델	- 구성 요소의 유형 및 유형 계통 - 구성 요소들의 배열, 결합 관계 - 구성 요소들의 인터페이스 - 구성 요소들의 상호작용 채널	- 다이나믹 생성 및 소멸 - 동적 결합 / 연결 - 위치 이동, 복제
행위 모델	- 입력 데이터, 출력 데이터 - 입출력 매핑 - 데이터 흐름 체널	- 제어, 상태전이 - 상호작용 프로토콜 - 처리 순서, 입출력 순서, 알고리즘

 

 4. 소프트웨어 설계 유형

설계 유형	설명
자료 구조 설계 (Data Structure Design)	요구 분석 단계 정보를 바탕으로 소프트웨어를 구현하는데 필요한 자료구조로 변환하는 과정
아키텍처 설계 (Architecture Design)	예비 설계 또는 상위 수준 설계 소프트웨어 시스템의 전체 구조 기술 소프트웨어 구성 컴포넌트 간의 관계 정의
인터페이스 설계 (Interface Design)	소프트웨어와 상호작용하는 컴퓨터 시스템, 사용자 등이 어떻게 통신하는지를 기술
프로시저 설계 (Procedure Design)	소프트웨어 컴포넌트의 프로시저 서술로 변환하는 과정

 

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

 1. 소프트웨어 아키텍처 (Software Architecture) 개념

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

 

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

  - 이해관계자들간의 조율을 통한 시스템 최적화

  - 비기능적인 요소에 집중해서 만들어지고 기능적인 요소도 고려

 

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

  1) 소프트웨어 아키텍처 프레임워크 구성요소

구성요소	설명
아키텍처 명세서	- 아키텍처를 기록하기 위한 산출물들 - 이해관계자들의 시스템에 대한 관심을 관점에 맞추어 작성한 뷰로 표현 - 개별 뷰, 뷰 개괄 문서, 인터페이스 명세 등이 있음
이해관계자	- 시스템 개발에 관련된 모든 사람과 조직 - 고객, 최종사용자, 개발자, 프로젝트 관리자, 유지보수자, 마케팅 담당자 등
관심사	- 시스템 개발에 관련된 모든 사람과 조직  사용자 입장 : 기본적인 기능, 신뢰성, 보안, 사용성  유지보수자 입장 : 유지보수의 용이성  개발자 입장 : 적은 비용과 인력으로 개발
관점	- 개별 뷰를 개발할 때 토대가 되는 패턴이나 양식 - 이해관계자들이 서로 다른 역할이나 책임으로 시스템이나 산출물들에 대해 보고 싶은 관점
뷰	- 서로 관련 있는 관심사들의 집합이라는 관점에서 전체 시스템을 표현 - 시스템에 대한 아키텍처 설명에는 하나 이상의 뷰로 구성
근거	- 아키텍처 결정 근거 - 회의 결과, 보고 결과

 

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

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

   - 고객의 요구사항을 4개의 관점에서 바라보는 접근 방법

   - 4개의 구조가 서로 충돌되지 않으며 시스템의 요구사항을 충적시키는지 증명하기위해 유스케이스 사용

 

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

   - 4+1 에서 1은 유스케이스 뷰이고 4는 논리, 구현, 프로세스, 배포 뷰 이다.

뷰	설명
유스케이스 뷰 (Usecase View)	- 아키텍처를 도출하고 설계하는 작업 주도 - 다른 뷰를 검증하는데 사용
논리 뷰 (Logical View)	- 시스템의 기능적인 요구사항 지원 - 설계 모델의 추상ㅇ화이며 주요 설계 패키지와 서브 시스템 클래스를 식별 - 클래스와 이들 간 관계에 대한 집합을 보여주는 클래스 다이어그램으로 표현
프로세스 뷰 (Process View)	- 시스템의 테스크 (Task), 스레드 (Thread),  프로세스 (Process)와 상호작용 관계 표현 - 성능, 가용성과 같은 시스템의 비기능적인 요구사항을 고려
구현 뷰 (Implementation View)	- 정적인 소프트웨어 모듈의 구성을 표현 - 컴포넌트 뷰라고도 함
배포 뷰 (Deployment View)	- 가용성, 신뢰성, 성능, 확장성 등의 비기능적인 요구사항을 고려 - 노드의 구성과 상호 연결 관계를 배포 다이어그램으로 표현

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

  1) 소프트웨어 아키텍처 비용 평가 모델 개념

   - 아키텍처 접근법이 품질 속성에 미치는 영향을 판단하고 아키텍처의 적합성을 평가하는 모델이다

 

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

   - 관계도 첨부 -

종류	설명
SAAM	- Software Architecture Analysis Method - 변경 용이성과 기능성에 집중과 평가가 용이하여 경험없는 조직에서도 활용 가능
ATAM	- Architecture Trade-off Analysis Method - 아키텍처 품질 속성을 만족시키는지 판단 및 품질 속성들의 이해 상층관계까지 평가
CBAM	- Cost Benefit Analysis Method - 경제적 의사결정에 대한 요구를 충족 - ATAM 바탕으로 부족한 경제성 평가를 보강
ADR	- Active Design Review - 소프트웨어 아키텍처 구성요소 간 응집도 평가
ARID	- Active Reviews for Intermediate Designs - 전체 아키텍처가 아닌 특정 부분에 대한 품질 요소에 집중