1-14. 모듈 구현

CHAPTER 5. 서버 프로그램 구현
Section 3. 모듈 구현

1. 단위 모듈 구현

⑴ 단위 모듈 구현의 개념
- 소프트웨어를 기능 단위로 분해하여 구현하는 기법
- 서브시스템, 서브루틴, 작업 단위 등으로 나누어 각 모듈이 독립적으로 활용될 수 있게 구현
- 모듈의 크기는 작고, 하나의 일만을 수행
- 모듈의 크기가 작으면 읽기 쉽고, 구현하기 쉬우며, 테스트 부담이 적어진다.

⑵ 단위 모듈 구현 시 장점
- 프로그램의 효율적인 관리 및 성능이 향상
- 전체적인 소프트웨어 복잡성 감소 및 이해성 증대
- 테스트, 모듈 통합, 변경 용이성 쉬움
- 기능의 분리가 가능하고 인터페이스가 단순해짐
- 오류의 파급효과 최소화
- 모듈의 재사용으로 개발과 유지보수가 용이

⑶ 효과적인 모듈화
- 결합도를 줄이고 응집도를 높여 모듈의 독립성을 높임
- FAN-OUT 최소화, FAN-IN 증가
- 모듈 인터페이스를 평가하여 복잡성과 중복성을 줄이고 일관성을 높인다.
- 기능 예측이 가능한 모듈을 정의
- 하나의 입력과 하나의 출력을 유지

⑷ 단위 모듈 설계의 원리
■ 단계적 분해
- 처음엔 간단히 작성하고, 점점 세밀하게 작성

■ 추상화
- 복잡한 문제를 일반화하여, 쉽게 이해할 수 있도록 한다.
■ 독립성
- 모듈은 응집도는 높이고 결합도는 낮춰 독립성을 가져야 한다.
■ 정보은닉
- 모듈 내부의 데이터를 외부에 은폐
■ 분할과 정복
- 큰 문제를 작게 나누어 하나씩 해결

 

⑸ 단위 모듈 작성 원칙
■ 정확성 (Correctness)
- 해당 기능이 실제 시스템 구현 시 필요한지 여부를 알 수 있도록 정확하게 작성
■ 명확성 (Clarity)
- 해당 기능에 대해 일관되게 이해되고 한 가지로 해석될 수 있도록 작성
■ 완전성 (Completeness)
- 시스템이 구현될 때 필요하고 요구되는 모든 것을 기술
■ 일관성 (Consistency)
- 공통 기능들 간에 상호 충돌이 없도록 작성
■ 추적성 (Traceability)
- 공통 기능에 대한 요구사항 출처와 관련 시스템 등의 유기적 관계에 대한 식별이 가능하도록 작성

 

2. 결합도

⑴ 결합도(Coupling)의 개념
- 어떤 모듈이 다른 모듈에 의존하는 정도
- 두 모듈 사이의 연관 관계
- 결합도가 낮을수록 잘 설계된 모듈이다.

⑵ 결합도 유형
자료 결합도(Data Coupling)
모듈 간의 인터페이스로 값이 전달되는 경우

스탬프 결합도(Stamp Coupling)
모듈 간의 인터페이스로 배열이나 오브젝트, 스트럭처 등이 전달되는 경우

제어 결합도(Control Coupling)
단순 처리할 대상인 값만 전달되는 게 아니라 어떻게 처리를 해야 한다는
제어 요소가 전달되는 경우

외부 결합도(External Coupling)
어떤 모듈에서 선언한 데이터(변수)를 외부의 다른 모듈에서 참조하는 경우

공통 결합도(Common Coupling)
파라미터가 아닌 모듈 밖에 선언되어 있는 전역 변수를 참조하고 전역 변수를 갱신하는 식으로 상호 작용하는 경우

 

내용 결합도(Content Coupling)
다른 모듈 내부에 있는 변수나 기능을 다른 모듈에서 사용하는 경우

 

3. 응집도

⑴ 응집도(Cohesion)의 개념
- 모듈의 독립성을 나타내는 개념으로, 모듈 내부 구성요소 간 연관 정도
- 정보 은닉 개념의 확장개념으로, 하나의 모듈은 하나의 기능을 수행하는 것을 의미
- 응집도는 높을수록 좋고 결합도는 낮을수록 이상적

⑵ 응집도 유형
기능적 응집도(Functional Cohesion)
모듈 내부의 모든 기능이 단일한 목적을 위해 수행되는 경우

순차적 응집도(Sequential Cohesion)
모듈 내에서 한 활동으로부터 나온 출력값을 다른 활동이 사용할 경우

통신적 응집도(Communication Cohesion)
동일한 입력과 출력을 사용하여 다른 기능을 수행하는 활동들이 모여 있을 경우

절차적 응집도(Procedural Cohesion)
모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성 요소들이 그 기능을 순차적으로 수행할 경우

시간적 응집도(Temporal Cohesion)
연관된 기능이라기보다는 특정 시간에 처리되어야 하는 활동들을 한 모듈에서 처리할 경우

논리적 응집도(Logical Cohesion)
유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들이 한 모듈에서 처리되는 경우

우연적 응집도(Coincidental Cohesion)
모듈 내부의 각 구성 요소들이 연관이 없을 경우

4. 팬인(Fan-in), 팬아웃(Fan-out)

⑴ 팬인(Fan-in), 팬아웃(Fan-out)의 개념
- 소프트웨어의 구성요소인 모듈을 계층적으로 분석하기 위해 활용
- 팬인과 팬아웃 분석을 통해 시스템의 복잡도를 측정
- 시스템 복잡도를 최적화하기 위해서는 팬인은 높게, 팬 아웃은 낮게 설계
구분
설명
- 얼마나 많은 모듈들이 현재 모듈을 호출하는지를 나타낸다.

팬인 (Fan-in)
- 해당 모듈로 들어오는 상위 모듈 수
팬아웃 (Fan-out)
- 해당 모듈에서 호출하는 하위 모듈 수

 

⑵ 팬인/팬아웃 계산법
모듈
팬인(Fan-in)
팬아웃(Fan-out)
A
0
3
B
1
2
C
1
2
D
1
1
E
1
1
F
1
0
G
1
1
H
2
0
I
2
0
J
1
1

 

5. 공통 모듈 구현

⑴ 공통 모듈 구현 순서
공통 모듈 상세 설계 확인
공통 모듈 관리 대장 확인
상세 설계서 확인
화면 설계서 등
공통 모듈 담당자 확인
공통 모듈 기능 확인
→
프로그램 설계서 확인
참조 문서 확인
↕
공통 모듈 상세 문서와 매핑된 공통 모듈 구현
↕
공통 모듈 구현
DTO/VO
SQL문
DAO
Service
Controller
필요시
→
→
→
→
구현
구현
구현
구현
구현
화면 구현

⑵ 공통 모듈 구현요소
DTO(Data Transfer Object)
- 프로세스 사이에서 데이터를 전송하는 객체
- Getter, Setter 메서드만 포함한다.

VO(Value Object)
- 도메인에서 속성들을 묶어서 특정 값을 나타내는 객체
- DTO와 동일한 개념이나 차이점은 Read­Only 속성 객체이다

DAO(Data Access Object)
- 실질적으로 DB에 접근하는 객체
- DataBase에 접근하기 위한 로직 & 비지니스 로직을 분리하기 위해 사용

 

Service
- DAO 클래스를 호출하는 객체

 

Controller
- 비즈니스 로직을 수행하는 객체

 

⑶ 공통 모듈 구현
① DTO/VO 구현
package com.njob.vo;
public class CodeVo{
private String code;
private String name;
public String getCode(){
return this.code;
}
public void setCode(String code){
this.code = code;
}
public String getName(){
return this.name;
}
public void setCode(String name){
this.name = name;
}
}
② SQL 문 구현
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE
mapper
PUBLIC
"-//ibatis.apache.org//DTD
Mapper
3.0//EN"
"http://ibatis.apache.org/dtd/ibatis-3-mapper.dtd">
<mapper namespace="com.njob.sql">
<select id="getCodeList" resultType="com.njob.vo.CodeVo"> SELECT
code, name
FROM tb_code
</select>
<update id="updateCodeInfo" parameterType="com.njob.vo.CodeVo"> UPDATE tb_code
SET
name = #{name, jdbcType=CHAR}
WHERE code = #{code, jdbcType=INTEGER}
</update>
</mapper>

 

③ DAO 구현
package com.njob.dao;
import com.njob.vo.CodeVO;
@Repository(“codeDao”)
public class CodeDao{
@Autowired
private SqlSession sqlSession;
public List<CodeVO> getCodeList() throws Exception {
return sqlSession.selectList(“com.njob.sql.getCodeList”);
}
public int updateCodeIsUse(CodeVo code) {
return sqlSession.update("com.njob.sql.updateCodeInfo", code);
}
}
④ Service 구현
package com.njob.service;
import com.njob.vo.CodeVO;
import com.njob.dao.CodeDao;
@Service(“codeService”)
public class CodeService{
@Resource(name=“codeDao“)
private CodeDao codeDao;
public List<CodeVO> getCodeList() throws Exception {
return codeDao.getCodeList();
}
public int updateCodeIsUse(CodeDao codeDao) throws Exception {
return codeDao.updateCodeIsUse(codeDao);
}
}

 

⑤ Controller 구현
package com.njob.controller;
import com.njob.vo.CodeVO;
import com.njob.dao.CodeDao;
import com.njob.service.CodeService;
@Controller
public class CodeController{
@Autowired
private CodeService codeService
@RequestMapping(value = "/code/list")
public ResponseEntity<List<CodeVO>> list(){
try{
List<CodeVO> list = codeService.getCodeList();
if( list != null ){
return new ResponseEntity<List<CodeVO>>(list, HttpStatus.OK);
}
else{
return new ResponseEntity<List<CodeVO>>(list, HttpStatus.NO_CONTENT);
}
}
catch(Exception e){
logger.error(e.getMessage());
}
}
}

 

⑷ Annotation
① Annotation 개념
Ÿ 사전적으로는 "주석"이라는 의미를 가지고 있다.

Ÿ 자바코드에 주석처럼 달아 특수한 의미를 부여한다.

Ÿ 컴파일 또는 런타임에 해석된다.

② Annotation 종류
종류
설명
@Controller
- 스프링 MVC의 컨트롤러 객체임을 명시
@RequestMapping
- 특정 URI 에 매칭되는 클래스나 메소드임을 명시
@RequestParam
- 요청(request)에서 특정한 파라미터 값을 찾아낼 때 사용하는 어노테이션
@RequestHeader
- 요청(request)에서 특정 HTTP 헤더 정보를 추출할 때 사용
@PathVariable
- 현재 URI에서 원하는 정보를 추출할 때 사용
@CookieValue
- 현재 사용자의 쿠키값을 추출할 때 사용
@ModelAttribute
- 자동으로 해당 객체를 뷰까지 전달하도록 한다.

@ResponseBody
- 리턴 타입이 HTTP의 응답 메시지로 전송
@RequestBody
- 요청 문자열이 그대로 파라미터로 전달
@Repository
- DAO 객체
@Service
- 서비스 객체
@Scheduled
- 스프링에서 지원하는 배치 어노테이션