[12] 서버 프로그램 구현 (개발 환경, 형상 관리, 모듈)

개발 도구의 분류 (빌/구/테/형)

• 빌드 도구: 작성한 코드의 빌드 및 배포를 수행하는 도구
• 구현 도구: 개발자의 코드 작성과 디버깅, 수정 등과 같은 작업을 지원하는 도구 
• 테스트 도구: 코드의 기능 검증과 전체의 품질을 높이기 위해 사용하는 도구
• 형상 관리 도구: 개발자들이 작성한 코드와 리소스 등 산출물에 대한 버전 관리를 위한 도구

서버 하드웨어 개발환경

구분	설명
웹 서버	HTTP를 이용한 요청/응답을 처리 웹 상의 정적 콘텐츠(CSS, Javascript, Image)를 처리
웹 애플리케이션 서버	동적 콘텐츠(Servlet, JSP)를 처리하기 위해 사용 주요 제품으로 Tomcat, Weblogic, Jeus, Resin 등 존재
데이터베이스 서버	데이터의 수집, 저장을 위한 용도로 사용 연계되는 주요 DBMS로 MySql, Oracle, MS-SQL, DB2등 존재
파일 서버	파일 저장 하드웨어로 물리 저장장치를 활용한 서버 대용량 HDD, SSD등의 장치가 존재

형상 관리: 소프트웨어 개발을 위한 전체 과정에서 발생하는 모든 항목의 변경 사항을 관리하기 위한 활동이다.

형상 관리의 목적: 프로젝트 생명주기 동안 제품의 묵셜성과 변경에 대한 추적성을 확보할 수 있다; 프로젝트 변경이 발생 했을 되었을 때 처리하는 메커니즘을 제공한다; 대표적인 메커니즘으로 형상 관리대상 파악, 베이스라인 지정, 형상관리, 접근제어 등이 있다.

형상 관리의 절차 (식/통/감/기)

• 형상 식별: 형상 관리 대상을 정의 및 식별하는 활동
• 형상 통제: 형상 항목의 버전 관리를 위한 형상통제위원회 운영
• 형상 감사: 소프트웨어 베이스라인의 무결성 평가
• 형상 기록: 소프트웨어 형상 및 변경관리에 대한 각종 수행결과를 기록

소프트웨어 형상 관리 도구 유형 (공/클/분)

• 공유 폴더 방식(RCS, SCCS)
  • 매일 개발이 완료된 파일은 약속된 위치의 공유 폴더에 복사하는 방식
• 클라이언트/서버 방식(CVS, SVN)
  • 중앙에 버전 관리 시스템을 항시 동작시키는 방식
  • 개발자들의 현재 작업 내용과 이전 작업내용 추적에 용이
  • 서로 다른 개발자가 같은 파일을 작업했을 때 경고 메시지 출력
• 분산 저장소 방식(GIT)
  • 로컬 저장소와 원격 저장소로 분리되어 분산 저장하는 방식
  • 중앙의 저장소에서 로컬 파일을 복사 한 순간 개발자 자신만의 로컬 저장소에 생성

소프트웨어 형상 관리 도구별 특징

형상 관리 도구	설명
CVS(Concurrent Versions System)	서버와 클라이언트로 구성되어있고, 다수의 인원이 동시에 범용적인 운영체제로 접근 가능한 형상 관리 도구
SVN(Subversion)	하나의 서버에서 소스를 쉽고 유용하게 관리할 수 있게 도와주는 도구 저장소를 만들어 그곳에 소스를 저장해 소스 중복이나 여러 문제를 해결하기 위한 도구
RCS(Revision Control System)	CVS와 달리 소스파일의 수정을 한 사람만으로 제한하여 다수의 사람이 파일을 수정을 동시에 할 수 없도록 파일 잠금 방식으로 형상을 관리하는 도구
Bitkeeper	SVN과 비슷한 중앙 통제 방식으로 대규모 프로젝트에서 빠른 속도를 내도록 개발된 형상 관리 도구
Git	Git의 속도에 중점을 둔 분산형 버전 관리 시스템이며, 대형 프로젝트에서 효과적이고 유용
Clear Case	복수 서버, 복수 클라이언트 구조이며 서버가 부족할 때 필요한 서버를 하나씩 추가하여 확장성을 기할 수 있음

형상 통제: 형상항목의 형상관리를 위해 형상통제위원회(CCB)를 운영하며, 소프트웨어 변경의 요구, 평가, 승인이 이루어진다.

---

모듈(Module): 모듈은 그 자체로 하나의 완전한 기능을 수행할 수 있는 독립된 실체이다.

모듈화(Modularity): 모듈화는 소프트웨어의 성능을 향상시키거나 복잡한 시스템의 수정, 재사용, 유지관리 등이 용이하도록 기능 단위의 모듈로 분해하는 설계 및 구현 기법이다.

모듈화 기법

• 루틴(Routine): 소프트웨어에서 특정 동작을 수행하는 일련의 코드로 기능을 가진 명령들의 모임
• 메인 루틴(Main Routine): 프로그램의 주요한 부분이며, 전체의 개략적인 동작 절차를 표시하도록 만들어진 루틴; 메인루틴은 서브 루틴을 호출
• 서브 루틴(Subroutine): 메인 루틴에 의해 필요할 때마다 호출되는 루틴

공통 모듈 구현: 소프트웨어 개발에 있어 기능을 분할하고 추상화하여 성능을 향상시키고 유지보수를 효과적으로 하기위한 공통 컴포넌트 구현 기법이다. 모듈간의 결합도는 줄이고 응집도는 높인 공통 모듈 구현을 권장.

응집도(Cohesion): 응집도는 모듈의 독립성을 나타내는 정도로, 모듈 내부 구성요소 간 연관 정도이다; 하나의 모듈은 하나의 기능을 수행할수록 응집도가 높다.

응집도 유형 (우/논/시/절/통/순/기)

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

우연적 응집도(응집도 낮음: 나쁜 품질) ------------------------------------------->기능적 응집도(응집도 높음: 좋은 품질)

결합도(Coupling): 모듈 내부가 아닌 외부의 모듈과의 연관도 또는 모듈 간의 상호의존성이다. 소프트웨어 구조에서 모듈 간의 관련성을 측정하는 척도이다.

결합도 유형 (내/공/ 외/제/ 스/자)

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

내용 결합도(결합도 높음: 나쁜 품질) ------------------------------------------------>자료 결합도(결합도 낮음: 좋은 품질)

MVC패턴 역할

• 모델(Model): 애플리케이션이 무엇을 할 것인지를 정의
• 뷰(View): 화면에 무엇인가를 보여주기 위한 역할
• 컨트롤러(Controller): 모델이 어떻게 처리할지를 알려주는 역할

팬인(Fan-In) 및 팬아웃(Fan-Out)

구분	팬인(Fain-In)	팬아웃(Fan-Out)
개념	어떤 모듈을 제어하는 모듈의 수	어떤 모듈에 의해 제어되는 모듈의 수
모듈 숫자 계산	모듈 자신을 기준으로 모듈에 들어오면 팬인(Fan-In)	모듈 자신을 기준으로 모듈에서 나가면 팬아웃(Fan-Out)
고려사항	팬인이 높으면 재사용 측면에서 설계가 잘되었지만 단일 장애점 발생 가능 팬인이 높으면 관리비용 및 테스트 비용증가	팬아웃이 높을 경우는 불필요한 모듈 호출 여부 검토 필요 팬아웃이 높을 경우는 단순화 여부 검토 필요

시스템 복잡도를 최적화하기 위해서는 팬인은 높게, 팬아웃은 낮게 설계해야 한다.

공통 모듈 테스트

• 공통 모듈 테스트를 위해 IDE도구를 활용하여 개별 공통 모듈에 대한 디버깅을 수행한다.
• 공통 모듈 테스트는 화이트박스 기법을 활용한다.
• 대표적인 단위테스트 도구인 JUnit을 활용하여 테스트 코드를 구현한다.

공통 모듈 테스트의 종류

종류	설명
화이트박스 테스트	응용 프로그램의 내부 구조와 동작을 검사하는 소프트웨어 테스트 방식 소스 코드를 보면서 테스트케이스를 다양하게 만들어 테스트를 수행
메서드 기반 테스트	공통 모듈의 외부에 공개된 메서드 기반의 테스트 메서드에 서로 다른 파라미터 값을 호출하면서 다양한 테스트를 수행
화면 기반 테스트	사용자용 화면이 있는 경우, 각각의 화면단위로 단위 모듈을 개발 후에 화면에 직접 데이터를 입력하여 테스트를 수행
테스트 드라이버(Driver)/테스트 스텁(Stub)	기능을 테스트할 수 있는 화면 또는 하위 모듈이 구현되지 않은 경우 테스트 드라이버, 테스트 스텁을 통해 테스트를 수행 테스트 드라이버: 하위 모듈은 있지만 상위 모듈은 없는 경우 사용하는 기법 테스트 스텁: 상위 모듈은 있지만 하위 모듈은 없는 경우 사용하는 기법