01-02 공통 모듈 구현하기

01 공통 모듈에 대한 이해.

공통 모듈은 정보 시스템 구축 시 자주 사용하는 기능들로서 재사용이 가능하게 패키지로 제공하는 독립된 모듈을 의미한다.

 

02 공통 모듈의 재사용

1) 재사용의 범위.

목표 시스템의 개발 시간 및 비용 절감을 위하여 검증된 기능을 파악하고 재구성하여 시스템에 응용하기 위한 최적화 작업이다.

 

재사용 범위에 따른 분류

분류	설명
함수와 객체 재사용	클래스나 함수 단위로 구현한 소스코드를 재사용한다
컴포넌트 재사용	컴포넌트 단위로 재사용하며, 컴포넌트의 인터페이스를 통해 통신한다
애플리케이션 재사용	공통된 기능을 제공하도록 구현 된 애플리케이션과의 통신으로 기능을 공유하여 재사용한다

 2) 재사용의 유형

편의적 재사용

프로젝트를 시작할 때 재사용 가능한 컴포넌트가 있는지를 찾아보고 재사용한다.

 

내부 재사용

팀 내에서 만든 컴포넌트를 재사용한다.

편의상이며 계획적인 것이 아니기 때문에 인터페이스의 조정 등에 추가적인 비용이 발행할 수 있다.

 

외부 재사용

서드파티에서 만든 컴포넌트를 구하여 사용한다.

유상인 경우, 조달비용을 자신이 직접 개발할 때 드는 비용의 20% 이하로 잡는 것이 일반적이다. 또한 조달한 컴포넌트를 학습하여 활용하는데 걸리는 시간도 고려해야한다.

 

계획적 재사용

컴포넌트를 차후에 재사용 가능하도록 전략적으로 설계해 나간다.

 

3)재사용의 사례

소프트웨어 라이브러리

코드 재사용의 매우 일반적인 예로서 라이브러리를 사용한다.

각종 형식으로 정보의 변환, 외부 기억 장치 액세스, 외부 프로그램과의 인터페이스, 정보 (수,단어,이름,위치,날짜 등)의 조작과 같이 일반적인 조작은 많은 프로그램에 필요하게 된다.

새로운 프로그램을 쓸 때 라이브러리의 코드를 사용하여 작업을 실행하도록 할 수 있으므로 같은 조작을 실행하는 프로그램을 다시 만들어 쓸 필요는 없다.

결점은 성능 향상이나 출력 형식을 바꾸고자 할 때 세부사항을 조절할 수 없는 점과 라이브러리를 취득 , 학습, 설정하는데 시간과 비용이 든다는 점이다.

 

디자인 패턴

디자인 패턴은 비슷한 문제를 풀기 위한 범용적인 해법이다.

디자인 패턴은 개념적이고, 개발 문제의 필요에 따라서 수정 가능하다.

추상 클래스와 인터페이스는 특정의 패턴에 재사용 가능하다.

 

프레임워크

개발자는 일반적으로 타사 응용 프로그램 및 프레임워크를 통해 많은 소프트웨어를 재사용한다.

 

4) 재사용의 이점

개발 시간과 비용을 단축시킨다.

품질을 향상시킨다.

개발의 생산성을 향상시킨다

프로젝트 실패의 위험을 감소시킨다

시스템 구축 방법에 대한 지식을 공유하게 된다

시스템 명세, 설계, 코드 등 문서를 공유하게 된다

 

03 소프트웨어 모듈 응집도

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

 

1) 응집도의 개념

정보은닉 개념의 확장개념으로 하나의 모듈은 하나의 기능을 수행하는 집적성을 지칭한다.

모듈의 독립성을 나타내는 개념으로 모듈 내부 구성원간의 연관도이다.

 

2) 응집도의 특징

클래스 목적에 부합하는 같은 기능 영역의 함수들로 구성되어 있다.

함수의 개수가 상대적으로 적으며 오로지 자신만이 할 수 있는 책임을 부여받는다.

하나의 함수에 많은 기능을 부여하지 않고 다른 함수와 협력한다.

 

3) 응집도의 유형 Cohesion

 

기능적 응집도 (Funtional Cohesion)	모듈 내부의 모든 기능이 단일한 목적을 위해 수행되는 경우이다. 구조도 최하위 모듈에서 많이 발견된다.
순차적 응집도 (Sequential Cohesion)	모듈 내에서 한 활동으로부터 나온 출력값을 다른 활동의 입력값으로 사용하는 경우이다.
통신적 응집도 (Communication Cohesion)	동일한 입력과 출력을 사용하여 다른 기능을 수행하는 활동들이 모여 있을 경우이다. 같은 입력 자료를 사용하여 a를 계산한 후 b를 계산
절차적 응집도 (Procedural Cohesion)	모듈이 다수의 관련기능을 가질때 모듈 안의 구성요소들이 그 기능을 순차적으로 수행할 경우이다 restart 루틴: 총계 출력하고 화면을 지우고 메뉴를 표시
시간적 응집도 (Temporal Cohesion)	연관된 기능이라기보다는 특정 시간에 처리되어야 하는 활동들을 한 모듈에서 처리하는 경우이다 초기값 설정, 종료 처리 등
논리적 응집도 (Logical Cohesion)	유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들이 한 모듈에서처리되는 경우이다. 매개변수에 따라 처리하는 내용이나 경로가 달라진다 오류 처리 : 자판기의 잔액 부족, 음료수 부족 출력 처리 : 직원 인사정보 출력, 회계정보 출력
우연적 응집도 (Coincedental Cohesion)	모듈 내부의 각 구성요소들이 연관이 없을 경우이다. 모듈화 장점이 없다. 유지보수 작업이 어렵다.

 

4) 응집도와 품질

목표 시스템의 기준에 따라 모듈을 구성할 수 있으나, 품질 측면에서는 응집도의 유형 중 기능적 응집도가 가장 높고 우연적 응집도가 가장 낮다.

 

04 소프트웨어 모듈 결합도 Coupling

1) 결합도의 개요 Coupling

 결합도는 모듈과 모듈 간의 관련성 정도를 나타낸 것으로, 관련이 적을수록 모듈의 독립성이 높아져 모듈 간 영향이 적어지게 된다.

 

2) 결합도의 특징

모듈에 의해 호출되어 처리상 연관성이 없는 서로 다른 기능으로 수행한다.

자료 전달이 인터페이스를 통과하므로 인터페이스 복잡성에 의존적이다.

가능한 낮은 결합도 Loosely Coupled가 복잡성을 감소시킨다.

에러발생시 오류가 전파되어 다른 오류의 원인이 되는 리플Ripple 효과를 최소화해야 한다.

 

3) 결합도의 유형

결합도 유형

자료 결합도 Data Coupling	모듈간의 인터페이스로 전달되는 파라미터를 통해서만 모듈간의 상효작용이 일어나는 경우이다. 제곱근을 계산하는 함수로 하나의 정수를 전달  실인수와 기인수가 독립, 단일 파일, 동종 테이블, 데이터를 넘겨주고 결과를 되돌려 받는 유형이다.
스탬프 결합도 Stamp Coupling	모듈 간의 인터페이스로 배열이나 오브젝트, 스트럭쳐등이 전달되는 경우이다. 배열이나 레코드, 자료 구조 조회, 포맷이나 구조 변화의 영향을받는 유형이다.
제어 결합도 Control Coupling	단순 처리할 대상인 값만 전달되는게 아니라 어떻게 처리를 해야한다는 제어 요소가 전달되는 경우이다. 논리 조직을 제어하기 위한 목적, 상위 모듈에게 처리 명령을 부여하는 권리 전도 현상이다.
외부 결합도 External Coupling	다수의 모듈이 모듈 밖에서 도입된 데이터 , 프로토콜, 인터페이스 등을 공유할 떄 발생하는 경우이다. 참조되는 데이터의 범위를 각 모듈에서 제한할 수 있다.
공통 결합도 Common Coupling	파라미터가 아닌 모듈 밖에 선언되어 있는 전역 변수를 참조하고 전역변수를 갱신하는 식으로 상호작용하는 경우이다. 전역변수
내용 결합도 Content Coupling	다른 모듈 내부에 있는 변수나 기능을 다른 모듈에서 사용하는 경우이다. 한 모듈에서 다른모듈의 내부로 제어가 이동하는 경우에도 내용 결합도에 해당된다

4) 결합도와 품질

목표 시스템의 환경에 따라 모듈 구성의 결합정도를 결정할 수 있다.

결합도 낮음					결합도 높음
자료 결합도	스탬프 결합도	제어 결합도	외부 결합도	공통 결합도	내용 결합도

 

05 소프트웨어의 모듈화

1) 모듈의 개념

프로그램을 구성하는 구성요소의 일부로 관련된 데이터와 함수들이 묶여서 모듈을 형성한다. 

 

2) 모듈화의 원리

정보 은폐 (Information Hiding)  : 어렵거나 변경 가능성이 있는 모듈을 타모듈로부터 은폐한다

자료 추상화 (Data Abstraction) : 각각 모듈 자료 구조를 액세스하고 수정하는 함수 내에 자료구조의 표현 내역을 은폐한다

모듈의 독립성 ( Module Independence) : 낮은 결합도와 높은 응집도를 가진다

분할과 지배 (Devide and Conquer) : 복잡한 문제를 분해, 모듈 단위로 문제를 해결한다.

 

3)모듈화의 종류

설계측면

모듈 (Module) : 설계 시 관련이 있는 기능을 모아 한 부분에 모아 놓은 라이브러리 형태로 사용된다.

컴포넌트 ( Component ) : 바이너리 형태의 재사용 가능한 형태로 인터페이스에 의해 조직을 수행할 수 있는 모듈 단위를 말한다.

서비스 (Service) : 기존 컴포넌트보다는 Loosely-Coupled한 형태의 기능을 제공하는 모듈 단위이다.

 

구현측면

매크로 (Macro) : 프로그램 구현 시 반복되는 부분을 특정 이름을 부여하고 이름을 호출하여 실행할 수 있도록 하는 프로그래밍 기법이다.

주의 ! 전처리기는 매크로가 사용된 모든 곳에 코드를 대체해 놓는다.

함수 (Function) : 프로그램 구현시 커다란 프로그램의 일부 코드로 특정한 작업을 수해하고 상대적으로 다른 코드에 비해 독립적인 모듈이다.

인라인 (inline) : 프로그램 구현 시 반복되는 부분에 특정 이름을 부여해놓고 이름을 호출하여 실행할 수 있도록 하는 프로그램 기법이다. 

주의 ! 컴파일러는 인라인이 사용된 모든 곳에 코드를 복사한다.

 

06 공통 모듈 수행하기

1) 공통 모듈의 상세 설계를 기반으로 작성해야할 공통 모듈을 확인한다

애플리케이션 설계 단계에서 작성한 공통 모듈 관리대장을 통해 작성해야 할 공통 모듈들을 확인하고 공통 모듈별 프로그램 설계서를 확인한다.

 

공통 모듈 관리대장 확인

모듈 담당자 항목에서 담당해야 할 공통 모듈을 확인한다.

 

공통 모듈의 기능을 확인한다.

 

공통 모듈 프로그램 설계서를 확인한다.

공통 모듈 관리대장 산출물에서의 ID와 일치하는 프로그램 설계서 산출물에서의 프로그램 ID를 확인한다.

2) 공통 모듈의 상세 설계를 기반으로 공통 모듈을 구현한다.

공통 모듈을 구현하기 위한 I/O 오브젝트 (DTO/VO) 를 정의한다.

공통 코드 조회를 위해 필요한 변수들을 정의하여 계층 간 데이터 교환을 위해 사용한다.

DTO(Data Transfer Object)또는 VO(Value Object)라고 명칭한다.

 

공통 모듈을 구현하기 위한 SQL을 작성한다.

데이터 접근 객체(DAO :Data Access Object)를 구현한다

DAO에서는 SQL문을 구현한 XML파일에서의 해당 ID값을 호출하여 데이터를 조회하거나 조작한다.

 

서비스 클래스를 구현한다

동일한 시스템 내에서 사용되는 결합도가 낮은 공통 모듈 구현하기 위해 스탬프 결합도 수준의 서비스를 구현한다

컨트롤러 클래스를 구현한다

시스템 내부 및 외부에서 사용할 수 있도록 REST API를 통한 공통 모듈 구현 사례이다

 

07 공통 모듈 테스트

1) 테스트 케이스

2) 테스트 프로세스 

테스트 프로세스는 테스트 수행과 관련된 활동들이 의도된 테스트 목적과 조건을 달성할 수 있도록 도와주는 역할을 한다

단계	테스트 프로세스	설명
1단계	계획 / 제어	테스트의 목표와 목적을 당성하기 위해 필요한활동을 계획하고 계획에 준수하여 진행되고 있는지 지속적인 제어 활동을 하는 단계이다
2단계	분석 / 설계	다일반적이고 추상적인 테스트의 목적을 구체화하여 테스트 시나리오와 테스트 케이스로 변환하는 활동 단계이다
3단계	구현 / 실행	다테스트를 효과적이고 효율적으로 수행하기 위해 테스트 케이스들을 조합하고 테스트 수행시 필요한 정보들을 포함하는 테스트 프로시저를 명세하는 활동 단계이다
4단계	평가	다계획 단계에서 정의하였던 테스트 목표에 맞게 테스트가 수행되었는지를 평가하고 진행 상황을 기록하는 활동 단계이다
5단계	완료	테스트 수행 시 명세했던 조건들을 수집하고 테스트 수행 시 발생했던 사항 및 경험들을 축정하는 활동 단계이다

3) 공통 모듈 테스트 수행하기

단위 테스트 케이스 작성을 위한 참조 문서를 수집한다

공통 모듈 상세 설계 산출물과 요구사항 정의서, 요구사항 명세서 등 분석 및 설계서를 수집한다

단위 테스트 케이스를 작성한다

단위 테스트 방식을 결정한다

실행해보는 동적 테스트/ 수동 또는 자동화 도구를 사용하여 검토하는 정적 테스트 등

단위 테스트의 범위를 결정한다

공통 모듈의 범위 및 상위 요구사항의 범위에 따라 테스트 범위를 판단한다

테스트 수행 횟수를 결정한다

테스트의 결과를 검증하기 위한 결과값 산출 방식을 결정한다

단위 테스트의 방식과 범위에 따라 테스트 케이스를 작성한다

테스트 단계명, 작성자, 작성일, 승인자, 문서 버전 등의 항목을 작성한다.

단위 테스트, 통합 테스트, 시스템 테스트 등 테스트의 단계와 작성자, 승인자, 문서 버전, 테스트 범위, 테스트 조직 등 공통 항목을 작성한다

테스트 케이스			프로젝트명	인사 관리 웹 애플리케이션 시스템 구축
			대상 시스템	인사관리 시스템
단계	단위 테스트	작성자	홍길동	승인자	김인자	문서 상태	최초 작성
작성일	2019-05-01	버전	v2.0	테스트 범위	공통 모듈	테스트 조직	개발팀
테스트ID	TM-CMM-001			테스트 일자	2019-08-10
테스트 목적	공통 코드 테스트
테스트 기능	구분 및부모 코드를 기준으로 공통 코드 조회검증
입력 값	구분, 부모 코드
테스트 단계	테스트 케이스	예상 값	중요도	성공/실패	비고
	구분 값없이 구분 공통코드 조회 함수를 호출한다	204코드 출력
	부모 코드 값 없이 부모 공통코드 조회 함수를 호출한다	204코드 출력
	존재하지 않는부모 코드 값으로 부모코드 공통 코드조회 함수를 호출한다	204 코드 출력
	존재하는 구분값으로 구분 공통 코드조회 함수를 호출한다	204 코드 출력
테스트 환경	개발 서버, 형상 관리서버
전체 조건	공통 코드 테이블에 공통 코드들을 입력해야 함
성공/실패 기준	예상 값이 정상적으로 출력되면 성공
특수 절차

 

 

작성된 단위 테스트 케이스를 내부 검토한다

작성된 단위 테스트 케이스를 고객에게 승인을 획득한다

테스트를 명세하기 위한 테스트 도구를 설정한다

테스트 구문을 작성한다

테스트 도구를 실행한다

테스트 결과를 명세화한다