[자격증] 정보처리기사 실기 : 10강 서버 프로그램 (공통 모듈 구현하기)

 정보

• 업무명     : 정보처리기사 실기 : 10강 서버 프로그램 (공통 모듈 구현하기)

• 작성자     : 이상호

• 작성일     : 2020-05-09

• 설   명      :

• 수정이력 :

 

 

 내용

[공통 모듈 구현]

[1] 공통 모듈 구현 

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

• 1. 재사용(Reuse) 
  

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

 

• 2. 공통 모듈의 종류 

   

  • 목표 시스템을 구축하기 위하여 구현하는 공통 모듈들은 공통 모듈의 설계를 기반으로 프로그래밍 언어와 도구를 활용하여 작성한다.

 

 

[2] 소프트웨어 모듈 응집도

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

   

• 1. 응집도의 유형 

   

  • 한 모듈 안의 기능들의 연관성 정도를 나타낸다.

     

  • 1) 기능적 응집도 (Functional Cohesion) 

     

    • 모듈 내부의 모든 기능이 단일한 목적을 위해 수행되는 경우이다. 구조도 최하위 모듈에서 많이 발견된다. 

       

  • 2) 순차적 응집도 (Sequential Cohesion) 

     

    • 모듈 내에서 한 활동으로부터 나온 출력값을 다른 활동의 입력값 으로 사용하는 경우이다. 예) 행렬 입력 후 그 행렬의 역행렬을 구해서 이를 출력.

       

  • 3) 통신적 응집도 (Communication Cohesion) 

     

    • 동일한 입력과 출력을 사용하여 다른 기능을 수행하는 활동들이 모여 있을 경우이다. 예) 같은 입력 자료를 사용하여 A를 계산한 후 B를 계산

  • 절차적 응집도 (Procedural Cohesion) 

     

    • 모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성 요소들이 그 기능을 순차적으로 수행할 경우이다. 예) Restart루틴: 총계 출력하고 화면을 지우고 메뉴를 표시 

       

  • 시간적 응집도 (Temporal Cohesion) 

     

    • 연관된 기능이라기보다는 특정 시간에 처리되어야 하는 활동들을 한 모듈에서 처리하는 경우이다. 예) 초기치 설정, 종료 처리 등 

       

  • 논리적 응집도 (Logical Cohesion) 

     

    • 유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들이 한 모듈에서 처리되는 경우이다. 예) 오류 처리: 자판기의 잔액 부족, 음료수 부족 출력 처리: 직원 인사 정보 출력, 회계 정보 출력 

       

  • 우연적 응집도 (Coincidental Cohesion) 

     

    • 모듈 내부의 각 구성 요소들이 연관이 없을 경우이다. 모듈화 장점이 없다. 유지 보수 작업이 어렵다.

 

• 2. 응집도와 품질 

   

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

 

[3] 소프트웨어 모듈 결합도

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

   

• 1. 결합도의 유형

   

  • 자료 결합도 (Data Coupling) 

     

    • 모듈 간의 인터페이스로 전달되는 파라미터를 통해서만 모듈 간의 상호 작용이 일어나는 경우이다. 예) 제곱근을 계산하는 함수로 하나의 정수를 전달.

       

  • 스탬프 결합도 (Stamp Coupling) 

     

    • 모듈 간의 인터페이스로 배열이나 오브젝트(Object), 스트럭처 (Structure) 등이 전달되는 경우이다. 

       

  • 제어 결합도 (Control Coupling) 

     

    • 단순 처리할 대상인 값만 전달되는 게 아니라 어떻게 처리를 해야 한다는 제어 요소가 전달되는 경우이다.

  • 외부 결합도 (External Coupling) 

     

    • 다수의 모듈이 모듈 밖에서 도입된 데이터, 프로토콜, 인터페이스 등을 공유할 때 발생하는 경우이다. 

       

  • 공통 결합도 (Common Coupling) 

     

    • 파라미터가 아닌 모듈 밖에 선언되어 있는 전역 변수를 참조하고 전역 변수를 갱신하는 식으로 상호 작용하는 경우이다. 예) 전역 변수 

       

  • 내용 결합도 (Content Coupling) 

     

    • 다른 모듈 내부에 있는 변수나 기능을 다른 모듈에서 사용하는 경우이다.

 

• 2. 결합도와 품질 

   

  • 목표 시스템의 환경에 따라 모듈 구성의 결합 정도를 결정할 수 있으나, 품질 측면에서 결합도의 유형 중 자료 결합도의 품질이 가장 높고, 내용 결합도의 품질이 가장 낮다.

 

[수행]

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

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

 

• 1. 공통 모듈 관리 대장을 확인한다. 

   

  • 공통 모듈 관리 대장은 설계 단계에서 작성된 구현해야 할 전체 시스템의 공통 모듈 목록 산출물이다. 

     

  • (1) 모듈 담당자 항목에서 담당해야 할 공통 모듈을 확인한다. 아래 예시는 김길동 담당자가 작성해야 할 공통 모듈을 확인한 예시이다

 

• (2) 공통 모듈의 기능을 확인한다. 

   

• 작성해야 할 공통 모듈의 기능을 확인하고 상세 설계 산출물을 확인하기 위해 ID를 확인한다

 

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

   

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

 

[2] 공통 모듈의 상세 설계 산출물을 기반으로 공통 모듈을 구현한다.

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

   

  • 공통 코드 조회를 위해 필요한 변수들을 정의하여 계층 간 데이터 교환을 위해 사용한다. DTO(Data Transfer Object) 또는 VO(Value Object)라고 명칭한다.

 

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

   

  • 공통 코드 조회를 위한 SQL 쿼리문을 마이바티스(Mybatis) XML 파일로 구현한 예제이다.

 

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

   

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

 

• 4. 서비스(Service) 클래스를 구현한다. 

   

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

 

• 5. 컨트롤러(Controller) 클래스를 구현한다. 

   

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

 

[공통 모듈 테스트]

[1] 테스트 케이스의 이해

• 1. 테스트 케이스(Test Case)의 개념 

   

  • 테스트 케이스란 요구 사항을 준수하는지 검증하기 위하여 테스트 조건, 입력 값, 예상 출력 값 및 수행한 결과 등 테스트 조건을 명세한 것이다. 

• 2. 테스트 케이스의 구성 요소

 

[2] 테스트 프로세스

• 테스트 프로세스는 테스트 수행과 관련된 활동들이 의도된 테스트 목적과 조건을 달성할 수 있도록 도와주는 역할을 한다. 
  1. 테스트 프로세스의 구성 테스트 프로세스는 계획 및 제어, 분석 및 설계, 구현 및 실행, 평가, 완료 단계로 구성 된다.
  

 

• 2. 테스트 프로세스의 단계 

   

  • (1) 계획 및 제어 테스트의 목표와 목적을 달성하기 위해 필요한 활동을 계획하고, 계획에 준수하여 진행되고 있는지 지속적인 제어 활동을 하는 단계이다. 

     

  • (2) 분석 및 설계 일반적이고 추상적인 테스트의 목적을 구체화하여 테스트 시나리오와 테스트 케이스로 변환하는 활동 단계이다. 

     

  • (3) 구현 및 실행 테스트를 효과적이고 효율적으로 수행하기 위해 테스트 케이스들을 조합하고 테스트 수행 시 필요한 정보들을 포함하는 테스트 프러시저를 명세하는 활동 단계이다. 

     

  • (4) 평가 계획 단계에서 정의하였던 테스트 목표에 맞게 테스트가 수행되었는지를 평가하고 진행 상황을 기록하는 활동 단계이다. 

     

  • (5) 완료 테스트 수행 시 명세했던 조건들을 수집하고 테스트 수행 시 발생했던 사항 및 경험 들을 축적하는 활동 단계이다.

 

[수행]

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

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

 

[2] 단위 테스트 케이스를 작성한다.

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

   

  • 개발된 공통 모듈을 실행하여 테스트하는 동적 테스트와 수동 또는 자동화 도구를 사용하여 검토하는 정적 테스트 중 적절한 테스트 방식을 결정한다. 

 

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

   

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

     

  • (2) 테스트 수행 횟수를 결정한다. 

     

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

 

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

   

  • (1) 테스트 케이스 작성에 필요한 항목을 작성한다. 

     

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

       

    • (나) 테스트 ID를 작성한다. 테스트 케이스를 식별하기 위한 고유한 테스트 ID를 작성한다. 

       

    • (다) 테스트의 목적 및 기능을 요약하여 작성한다. 테스트 수행의 목적과 기능을 간략하게 요약하여 작성한다. 

       

    • (라) 입력값을 작성한다. 테스트 수행 시 입력할 데이터를 작성한다. 

       

    • (마) 예상 결괏값을 작성한다. 테스트 수행 후 기대되는 결과 데이터(값, 메시지, 화면 등)를 작성한다. 

       

    • (바) 테스트를 수행할 환경을 작성한다. 테스트를 수행하는 물리적, 논리적 환경을 작성한다.

    • (사) 테스트를 수행하기 위한 전제 조건을 작성한다. 

       

      • 테스트 케이스 간의 의존성 및 선행 조건 등 고려 사항을 작성한다. 

         

    • (아) 성공/실패 기준을 정의한다. 

       

      • 테스트의 성공과 실패를 결정하는 조건을 명확하게 작성한다. 

         

    • (자) 테스트 수행 시 필요한 특수 절차를 작성한다. 

       

      • 테스트를 수행 시 사용자의 요구 사항이나 필요한 특수한 절차를 작성한다.

  • (2) 정의된 항목 요소를 바탕으로 테스트 케이스를 작성한다

 

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

• 1. 단위 테스트 케이스의 적정성을 검토한다. 

   

  • PM(Project Manager), 아키텍처, 기획자, 개발자, 테스트 담당자 등 내부 이해관계자들이 작성된 테스트 케이스의 적정성을 검토한다. 

     

• 2. 요구 사항에 충족할 수 있는 테스트 범위인지 검토한다. 

   

  • 단위 테스트 케이스가 요구 사항에 충족할 수 있도록 작성되었는가에 대한 테스트 범위를 검토한다. 

     

• 3. 공통 모듈은 다른 모듈에서 활용되므로 활용성이나 영향도 등을 고려하여 검토한다.

 

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

• 작성된 테스트 케이스를 고객 및 PM 등 이해관계자들에게 승인을 획득한다. 

 

[5] 테스트를 명세하기 위한 테스트 도구를 설정한다.

[6] 테스트 결과를 명세화 한다. 테스트의 결과를 확인하여 테스트 케이스에 성공/실패 결과 및 필요 항목을 기록한다

 

[연습문제]

• 응집도는 모듈 내부에서 구성 요소 간에 밀접한 관계를 맺고 있는 정도로 평가된다. 다음 중 응집도에 대한 설명이 틀린 것은?
  

  • 1) 기능적 응집도 (Functional Cohesion) 
    

    • 모듈 내부의 모든 기능이 단일한 목적을 위해 수행되는 경우이다. 구조도 최하위 모듈에서 많이 발견된다. 
      

  • 2) 순차적 응집도 (Sequential Cohesion) 
    

    • 모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성 요소들이 그 기능을 순차적으로 수행할 경우이다. 예) Restart루틴: 총계 출력하고 화면을 지우고 메뉴를 표시 
      

  • 3) 통신적 응집도 (Communication Cohesion) 
    

    • 동일한 입력과 출력을 사용하여 다른 기능을 수행하는 활동들이 모여 있을 경우이다. 예) 같은 입력 자료를 사용하여 A를 계산한 후 B를 계산
      

  • 4) 시간적 응집도 (Temporal Cohesion) 
    

    • 연관된 기능이라기보다는 특정 시간에 처리되어야 하는 활동들을 한 모듈에서 처리하는 경우이다. 예) 초기치 설정, 종료 처리 등 
      

 

• 결합도는 모듈과 모듈 간의 관련성 정도를 나타낸다. 다음 중 설명이 틀린 것은?
  

  • 1) 자료 결합도 (Data Coupling) 
    

    • 모듈 간의 인터페이스로 전달되는 파라미터를 통해서만 모듈 간의 상호 작용이 일어나는 경우이다. 예) 제곱근을 계산하는 함수로 하나의 정수를 전달.
      

  • 2) 스탬프 결합도 (Stamp Coupling) 
    

    • 모듈 간의 인터페이스로 배열이나 오브젝트(Object), 스트럭처 (Structure) 등이 전달되는 경우이다. 
      

  • 3) 제어 결합도 (Control Coupling) 
    

    • 단순 처리할 대상인 값만 전달되는 게 아니라 어떻게 처리를 해야 한다는 제어 요소가 전달되는 경우이다.
      

  • 4) 외부 결합도 (External Coupling) 

    • 파라미터가 아닌 모듈 밖에 선언되어 있는 전역 변수를 참조하고 전역 변수를 갱신하는 식으로 상호 작용하는 경우이다. 예) 전역 변수 

 

 참고 문헌

[논문]

• 없음

[보고서]

• 없음

[URL]

• 없음

 

 문의사항

[기상학/프로그래밍 언어]

• sangho.lee.1990@gmail.com

[해양학/천문학/빅데이터]

• saimang0804@gmail.com

 

 

 

 

 

 

 

본 블로그는 파트너스 활동을 통해 일정액의 수수료를 제공받을 수 있음