정보처리기사 6일차

1.소프트웨어 설계

 1.3 애플리케이션 설계

  1.3.1 애플리케이션 설계 능력 단위 정의

  1.3.2 공통 모듈 설계

---

- 애플리케이션 설계 능력 단위 정의

애플리케이션 설계란 요구사항 확인을 통한 상세 분석 결과, 소프트웨어 아키텍처 가이드라인 및 소프트웨어 아키텍처 산출물에 의거하여 이에 따른 애플리케이션 구현을 수행하기 위해 공통모듈 설계, 타 시스템 연동에 대하여 상세 설계하는 능력이다.

 

-공통 모듈 설계

 

1. 공통 모듈

 

1.1 공통 모듈의 개념

날짜 처리를 위한 유틸리티 모듈 등과 같이 전체 프로그램의 기능 중 공통적으로 사용할 수 있는 모듈을 의미한다.

• 정확성 : 실제 시스템 구현 시 필요한 기능인지 여부를 알 수 있도록 정확하게 작성한다.
• 명확성 : 해당 기능에 대한 일관된 이해와 하나로 해석될 수 있도록 작성한다.
• 완전성 : 시스템의 구현 시 요구사항과 필요한 모든 것을 기술한다.
• 일관성 : 공통 기능 사이에 충돌이 발생하지 않도록 작성한다.
• 추적성 : 해당 기능에 대한 요구사항의 출처와 관련 시스템 등 유기적 관계에 대한 식별이 가능하도록 작성한다.

1.2 모듈화 개념

소프트웨어의 성능을 향상시키거나 시스템의 수정 및 재사용 유지 관리를 용이하게 하여 프로그램을 효율적으로 관리할 수 있도록 시스템을 분해하고 추상화하는 기법을 의미한다.

모듈의 크기가 과도하게 작은 경우 모듈의 개수가 많아져 모듈 간의 통합 비용이 과다 발생하고, 모듈의 크기가 과도하게 크면 모듈 간의 통합 비용이 상대적으로 감소하는 대신 하나의 모듈을 개발하는데 소용되는 비용이 커진다.

 

1. 응집도

응집도는 모듈 내부의 구성 요소간 관계의 밀접 정도로 평가되며, 응집도가 높을수록 필요한 요소들로 구성되어 지고 낮을수록 요소들 간의 관련성이 적은 요소들로 구성되어진다.

품질측면에서 가장 높은 품질은 기능적 응집이며, 가장 낮은 품질은 우연적 응집도 이다.

• 기능적 응집도 : 모듈 내부의 모든 기능이 단일한 목적을 위해 수행되는 경우이다.
• 순차적 응집도 : 모듈 내에서 한 활동으로부터 나온 출력값을 다른 활동이 사용할 경우이다.
• 통신적 응집도 : 동일한 입력과 출력을 사용하여 다른 기능을 수행하는 활동들이 모여 있을 경우이다.
• 절차적 응집도 : 모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성 요소들이 그 기능을 순차적으로 수행할 경우이다.
• 시간적 응집도 : 연관된 기능이라기보다는 특정 시간에 처리되어야 하는 활동들을 한 모듈에서 처리할 경우이다.
• 논리적 응집도 : 유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들이 한 모듈에서 처리되는 경우이다.
• 우연적 응집도 : 모듈 내부의 각 구성 요소들이 연관이 없을 경우이다.

2. 결합도

결합도는 모듈과 모듈 사이의 관련성이 어느 정도인가를 나타내며, 관련성이 적을수록 모듈의 독립성이 높아 모듈간 영향이 작아지게 된다.

품질 측면에서 가장 높은 품질은 자료 결합이며, 내용 결합이 가장 낮다.

• 자료 결합도 : 모듈 간의 인터페이스로 전달되는 파라미터를 통해서만 모듈 간의 상호 작용이 일어나는 경우이다.
• 스탬프 결합도 : 모듈 간의 인터페이스로 배열이나 오브젝트, 스트럭처 등이 전달되는 경우이다.
• 제어 결합도 : 단순 처리할 대상인 값만 전달되는 게 아니라 어떻게 처리를 해야한다는 제어 요소가 전달되는 경우이다.
• 외부 결합도 : 모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성 요소들이 그 기능을 순차적으로 수행할 경우이다.
• 공통 결합도 : 파라미터가 아닌 모듈 밖에 선언되어 있는 전역변수를 참조하고 전역 변수를 갱신하는 식으로 상호 작용하는 경우이다.
• 내용 결합도 : 다른 모듈 내부에 있는 변수나 기능을 다른 모듈에서 사용하는 경우이다.

2. 설계 모델링

 

2.1 소프트웨어 설계와 모델링의 개념

소프트웨어 설계는 요구사항 분석 단계에서 규명된 필수 기능들의 구체적인 구현 방법을 명시하는 단계로 장치, 프로세스, 시스템을 명확하고 상세하게 정의하며 실현가능 하도록 관련 변형된 기술과 원칙을 적용하는 과정을 말한다.

설계 모델링은 소프트웨어에 요구되는 기능과 성능 조건들을 만족하는 소프트웨어의 내부 기능외에 구조 및 동적 행위들을 모델링하여 표현, 분석하는 과정이다.

2.2 구조와 행위 모델링

1. 구조 모델링

소프트웨어를 구성하는 컴포넌트들의 유형, 인터페이스, 내부 설계 구조 및 이들의 상호 연결구조를 모델링한다.

2. 행위 모델링

소프트웨어의 구성요소들이 기능들과 이들이 언제, 어떠한 순서로 기능을 수행하고 상호작용하는지를 모델링한다.

모델유형	개요	내용
구조모델	시스템의 구성요소들과 이들 사이의 구조적인 관계와 특성들의 모델링이다.	구성요소 : 프로시저, 데이터구조, 모듈, 파일구조 시스템 구조 : 구성요소들의 연결구조, 포함관계
행위모델	시스템의 각 구성 요소들의 기능적 특성들에 대한 모델링이다.	입출력데이터, 데이터 흐름, 데이터 변환, 데이터 저장등
	시스템의 구성 요소들이 언제 어떠한 순서로 수행되는가와 같은 동적 특성들의 모델링이다.	상태전이, 데이터 흐름경로, 사건발생 순서, 실행 경로 등

 

2.3 설계 모델의 구성과 요소

1. 설계 모델의 구성

2. 설계 모듈의 동적요소와 정적요소

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

 

3. 소프트웨어 아키텍처

 

3.1 소프트웨어 아키텍처 개념

소프트웨어 아키텍처는 소프트웨어 시스템의 구조를 비롯한 시스템 개발에 중요한 영향을 미치는 결정들로, 소프트웨어 시스템 개발에서 특정 시스템에 대하여 요구되는 기능과 품질을 확보하고 또한 소프트웨어 시스템의 구축 및 지속적인 개선이 용이하도록 하는 역할을 한다.

 

1. 소프트웨어 아키텍처의 역할

요구사항 분석 활동에 의해 도출된 요구사항을 모두 충족시킬 수 있는 시스템이 만들어 질 수 있도록 하기 위한 설계 활동으로서 설계 및 구현을 위한 구조적/ 비구조적 틀을 제공한다.

틀이란 아키텍처 설계의 결과물로서 실행을 요구하는 결정 또는 모델을 의미한다. 구조적틀은 시스템 개발을 위해 결정된 컴포넌트의 구조모델을 말하고, 비구조적 틀은 이 구조모델 이외의 다른 아키텍처설계의 결정들을 말한다.

 

2. 아키텍처 설계의 입력과 출력

시스템 개발은 모든 요구사항을 달성대상으로 하지만 아키텍처 설계는 아키텍처에 관련된 대표적인 요구사항들로만 주된 관심의 대상이 된다. 이와 같은 특별한 요구사항들을 아키텍처 드라이브라고 한다.

설계의 결과는 아키텍처를 문서화한 아키텍처 문서가 주된 출력물이 되고 이에 대한 추가적인 관련사항을 정리한 아키텍처 가이드 라인이 이차적인 출력물이 된다.

테스크는 한 명의 수행자가 수행하는 일을 지칭하며, 소프트웨어 설계 모델링 언어인Uml의 활동 다이어그램은 더 이상 분해하지 않는 일의 단위를 테스크라고 부르고 다른 태스크 혹은 활동으로 구성된 일의 단위를 활동이라고 부르고 있다.

 

3.2 아키텍처 설계 절차와 적용 원리

 

1. 아키텍처 드라이버

시스템의 요구사항 중 아키텍처에 영향을 주는 요구사항을 아키텍처 드라이버라하며, 아키텍처 설계에 더 집중할 수 있기 위해 아키텍처 드라이버를 먼저 잘 식별해낸 후 아키텍처 설계에 효과적으로 반영해야 한다.

 

2. 품질속성, 검증가능성, 품질속성 시나리오

아키텍처 드라이버들을 먼저 검증할 수 있는 형태로 바꾸어 놓은 것으로, 특히 품질속성으로 불리는 요구사항들은 아키텍처에 영향을 미치면서 고객의 도움 없이는 개발자 단독으로 검증 가능한 형태로 바꾸기 어려운 유형의 요구사항들이다.

 

3. 문제분석

요구사항들이 어떠한 문제의 해결을 요청하는 것인지 분석한다.

 

4. 컴포넌트와 커넥터

컴포넌트는 처리, 저장, 전달을 수행하는 소프트웨어 시스템의 구성 요소이며 커넥터는 컴포넌트를 연결하는 연결자를 말한다.

 

5. 아키텍처 스타일

아키텍처 스타일은 아키텍처의 유형을 말한다. 적절한 아키텍처 스타일의 선택은 대상시스템의 개발을 효율적이고 효과적으로 만들 수 있다.

 

6. 소프트웨어 아키텍처를 보는 관점관계

 아키텍처 스타일에 따라 적합한 관점체계가 서로 다를 수 있다.

J2EE 기반의 응용, BPMS 기반의 SOA 응용, 내장소프트웨어, Web 응용 등의 아키텍처 스타일에 적절한 관점체계가 모두 동일 하지는 않다.

 

7. 설계의 일반원리

소프트웨어 아키텍처에 적용되는 보편적인 원칙이다.

 

8. 아키텍처 설계 절차

아키텍처를 결정하는 요구사항들로 부터 먼저 어떤 아키텍처적인 설계의 선택들이 있는가를 판단한다.

 

9. 아키텍처 패턴

반복적으로 발생하는 문제에 대해 미리 만들어진 솔루션이다.

 

10. 품질속성 설계전술

단일 품질속성 응답을 제어하는데 영향력 있는 설계의 결정이다.

 

11. 아키텍처의 분석

주어진 아키텍처가 적절한지 판단하기 위한 분석이다.

 

12. 아키텍처의 평가

평가는 완결된 설계를 대안과 비교함으로써 그 결과에 따라 설계라는 큰 과정을 다시 수행할 것을 요구할 수도 있는 활동이다.

 

3.3 소프트웨어 아키텍처 프래임워크(ISO/IEC/IEEE 42010)

JEEE 1471는 소프트웨어 구조에 대한 기술을 규정한 IEEE 표준이다.

IEEE 42010는 시스템 및 SW 엔지니어링 아키텍처 기술 과 관련된 용어와 개념을 정의한 국제 표준이다.

 

3.4 SW 아키텍처 4+1 View의 개요

시스템의 여러가지 측면을 고려하기 위한 다양한 관점을 바탕으로 정의되며 UML의 4+1 View가 표준이다.

고객 요구사항을 중심으로 4가지 관점으로 소프트웨어 아키텍처를 설계하는 기법이다.

구분	설명
사용사례관점	시스템의 외부 사용자 관점에서 사용 사례들 간의 관계를 정의한다.
논리관점	상위 수준에서 시스템의 논리적인 구조/행위를 클래스 인터페이스, 협력관계로 정의한다.
구현관점	독립적으로 실행되는 컴포넌트와 이들 간 관계를 정의한다.
프로세스관점	시스템의 병렬처리 및 동기화 처리를 위한 스레드와 프로세스를 정의한다.
배치관점	실행되는 시스템 하드웨어와 소프트웨어 관계를 정의한다.

---

오답풀이

 

다음 중 설계모델링에 대한 설명으로 옳지 않은 것은?

1. 구조 모델링은 소프트웨어를 구성하는 컴포넌트들의 유형, 인터페이스, 내부 설계 구조 및 이들의 상호 연결 구조를 모델링한다.

2. 행위 모델링은 소프트웨어의 구성요소들의 기능들과 이들이 언제, 어떠한 순서로 기능을 수행하고 상호작용하는지를 모델링한다.

3. 인터페이스, 데이터 구조, 알고리즘 구조 모델 중 시스템 구조에 해당한다.(정답)

4. 설계모델링은 소프트웨어에 요구되는 기능과 성능 조건들을 만족하는 소프트웨어의 내부 기능외에 구조 및 동적 행위들을 모델링하여 표현, 분석, 검증하는 과정이다.

 

인터페이스, 데이터 구조, 알고리즘 구조는 구조 모델중 컴포넌트 구조에 해당한다. 구조 모델중 시스템 구조는 구성요소, 컴포넌트 연결 구조 등이 해당된다.

 

다음 중 소프트웨어 설계모델의 분류와 구성요소가 옳지 않은 것은?

1. 구조모델-시스템구조-구성요소, 컴포넌트 연결구성

2. 구조모델-컴포넌트구조-인터페이스, 데이터구조, 알고리즘

3. 행위모델-시스템행위-구성요소들의 배열, 결합관계, 인터페이스(정답)

4. 행위모델-컴포넌트행위-계산, 실행제어, 상호작용

 

행위모델-시스템행위-시스템기능, 컴포넌트 제어