공통 모듈 구현

모듈(Module)

 

 - 모듈은 크게 독립된 하나의 소프트웨어 또는 하드웨어 단위를지칭하는 용어

 

 - 모듈화를 통해 분리된 시스템의 각 기능들로 서브프로그램, 서브 루틴, 소프트웨어 내의 단위 프로그램

 

   작업 단위 등과 같은 의미로 사용된다.

 

모듈의 특징

 

 - 각각의 모듈은 상대적으로 독립성을 갖고 있다.

 

 - 모듈 내부에는 그 모듈을 하나로 통합하는 수많은 조합이 존재 할 수 있다.

 

 - 모듈은 단독으로 컴파일 할 수 있으며, 재사용할 수 있다.

 

 - 독립성이 높은 모듈일 수록 모듈 수정 시에도 다른 모듈들에는 영향을 거의 미치지 않고, 오류 발생시에도 쉽게

 

   해결할 수 있다.

 

 - 모듈의 독립성은 결합도와 응집도에 의해 측정되며, 독립성을 높이려면 모듈의 결합도는 약하게, 응집도는 강하게 모듈의 크기는

 

   작게 만들어야 한다.

 

모듈화(Modularity)의 개념 및 방법

 

 - 소프트웽의 성능을 향상시키거나 복잡한 시스템의 수정, 재사용, 유지 관리 등이 용이하도록 기능 단위의 모듈로 분해하는

 

   설계 및 구현 기법

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

 

공통 모듈 구현의 개념

 

 - 소프트웨어 개발에 있어 기능을 분할하고 추상화하여 성능을 향상시키고 유지보수를 효과적으로 하기 위한 공통 컴포넌트 구현 기법

 

 - 인터페이스 모듈, 데이터베이스 접근 모듈 등 필요한 공통 모듈을 구현

 

 - 모듈 간의 결합도는 줄이고 응집도는 높인 공통 모듈 구현을 권장

 

응집도(Cohension)의 개넘

 

 - 모듈의 독립성을 나타내는 개념으로, 모듈 내부 구성요소 간 연관 정도

 

 - 정보은닉 개념의 확장개념으로, 하나의 모듈은 하나의 기능을 수행하는 것을 의미

 

응집도의 유형

 

 - 응집도의 유형에는 우연적, 논리적, 시간적, 절차적, 통신적, 기능적 응집도 순서로 응집도가 높아진다.

 

* 우논시절 통순기

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

 

소프트웨어 모듈 결합도

 

 결합도

  

  - 모듈 내부가 아닌 외부 모듈과의 연관도 또는 모듈간의 상호의존성이다.

 

 - 소프트웨어 구조에서 모듈 간의 관련성을 측정하는 척도

 

결합도의 유형

 

 - 결합도의 유형은 내용, 공통, 외부, 제어, 스탬프, 자료 결합도 순으로 결합도 낮아진다.

 

내공외제스자

 

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

- 결합도가 낮을수록 품질이 좋아진다.

 

 

공통 모듈 구현 대상

 

 - 공통 모듈 화면은 화면 모듈, 화면에서 입력받은 데이터 처리를 위한 서비스 컴포넌트, 비즈니스 트랜잭션 컴포넌트 등이 있다.

 

 

공통 모듈 구현 절차

 

 - DTO/VO -> SQL -> DAO -> Service -> Controller -> 화면 구현 순

 

 - 공통 모듈의 구현을 위해 절차에 구현되는 MVC 패턴의 개념을 이해한다.

 

* DAO(Data Access Object)

 

 - 특정 타입의 데이터베이스에 추상 인터페이스를 제공하는 객체로 세부 내용 노출 없이 데이터를 조작하는 객체

 

* VO(Value Object)

 

 - 간단한 엔티티를 의미하는 작은 가변 클래스인 DTO와는 달리 고정 클래스를 가지는 객체

 

* DTO(Data)

 

 - 프로세스 사이에서 데이터를 전송하는 객체로 데이터 저장,회수 외에 다른 기능이 없는 추상 객체

 

* 서비스(Service)

 

 - 사용자의 요청을 처리하는 기능을 제공하기 위한 로직을 구현하고 DAO 클래스를 통해서 DB연동을 처리하는 기능을 수행하는 클래스

 

 

공통 모듈 상세 설계 확인

 

 MVC 패턴 역할

구분	역할
모델(Model)	- 애플리케이션이 무엇을 할 것인지를 정의 - 내부 비즈니스 로직을 처리하기 위한 역할
뷰(View)	- 화면에 무엇인가를 보여주기 위한 역할 - 모델, 컨트롤러가 보여주려고 하는 것들을 화면에 처리
컨트롤러(Controller)	- 모델이 어떻게 처리할지를 알려주는 역할 - 뷰에 명령을 보내어 화면 요청 결과를 전달

 

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

 

팬인 및 팬아웃 개념

 

 - 소프트웨어의 구성요소인 모듈을 계층적으로 분석하기 위해서 팬인, 팬아웃을 활용한다.

 

 - 팬인과 팬아웃 분석을 통하여 시스템의 복잡도를 측정할 수 있다.

 

팬인 및 팬아웃

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

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