곰돌이연구실

소프트웨어 설계 / 구현 / 소프트웨어 테스트

1. UI 설계 원칙

  1) 직관성 : 누구나 큰 노력없이 쉽게 이해하고 사용 가능해야 함

  2) 유효성 : 사용자의 목적이 정확하고 완벽하게 달성될 수 있어야 함

  3) 학습성 : 초보와 숙력자 모두 쉽게 배우고 익힐 수 있어야 함

  4) 유연성 : 사용자의 요구사항을 최대한 수용하고 오류를 최소화할 수 있어야 함

2. UI 품질 요구사항 (ISO/ISE 9126)

  1) 기능성 : 실제 수행 결과와 품질요구사항간의 차이를 분석, 정확하지 않은 결과 발생율 등과 관련한 동작 관찰.

  2) 신뢰성 : 시스템이 일정 시간 또는 작동되는 시간 동안 의도하는 기능을 수행하는것을 보장

  3) 사용성 : 사용자와 컴퓨터 사이에 발생하는 행위를 정확하고 쉽게 인지 가능

  4) 효율성 : 할당된 시간에 한정된 자원으로 얼마나 빨리 처리하는가

  5) 유지보수성 : 요구사항을 개선하고 확장하는 데 있어 얼마나 용이한가

  6) 이식성 : 다른 플랫폼에서도 많은 추가 작업 없이 얼마나 쉽게 적용이 가능한가.

3. UI 요구사항

  1) 기능적 요구사항

    (1) 시스템의 입력 / 출력으로 무엇이 포함되어야 하는가

    (2) 시스템이 어떤 데이터를 저장해야하는가

    (3) 시스템이 어떤 연산을 수행해야 하는가

  2) 비기능적 요구사항

    (1) 기능적인 부분 이외의 요구사항

    (2) 사용성, 효율성, 신뢰성, 유지보수성, 재사용 성 등 품질에 관한 요구사항

    (3) 플랫폼, 사용 기술 등 시스템 환경에 관한 요구사항

    (4) 비용 일정 등 프로젝트 계획에 관한 요구사항

4. 네트워크 : OSI 7계층

  7) 응용 계층 : HTTP, FTP 등

  6) 표현 계층 :

  5) 세션 계층 :

  4) 전송 계층 : TCP, UDP

  3) 네트워크 계층 : IP

  2) 데이터링크 계층

  1) 물리 계층 : RS232C

5. TCP/IP 4계층

  4) 응용 계층 (5~7) : TCP/UDP 기반의 응용 프로그램 구축.

  3) 전송 계층 (= 4) : 연결 제어, 데이터 전송, TCP, UDP

  2) 인터넷 계층 (= 3)  : 통신 노드간의 패킷 전송, 라우팅, IP, ARP, RARP 등

  1) 네트워크 엑세스 (1~2) : 물리적 주소, MAC 등, LAN 패킷망 등에 사용

6. 라우팅 프로토콜

  1) RIP : 최초의 라우팅 프로토콜, 거리 벡터 알고리즘 활용, 30초 주기 갱신, 라우팅 루프 발생 가능.

  2) IGRP : RIP 개선, 네트워크 상태 고려

  3) OSPF : 링크 상태 알고리즘 사용, 변경 정보에 대해 RIP보다 빠른 업데이트. 토폴로지 정보가 전체 라우터에 동일하게 유지

  4) BGP : 규모가 큰 네트워크 (ISP 등)의 상호연결

7. 소프트웨어 테스트 프로세스

  1) 테스트 계획 : 목적 범위 정의, 대상시스템 구조 파악, 테스트 일정 / 종료 조건 정의 등

  2) 테스트 분석 및 디자인 : 테스트 목적 / 원칙 검토, 요구사항 분석, 데이터 및 환경 준비

  3) 테스트 케이스 및 시나리오 작성 : 테스트케이스 작성 및 검토, 테스트 시나리오 작성

  4) 테스트 수행

  5) 테스트 결과 평가 및 리포팅 : 테스트 결과 정리, 결과 평가, 리포팅

8. 소프트웨어 테스트 산출물

  1) 테스트 계획서 : 테스트 활동의 범위, 접근법, 자원, 일정, 업무 배정, 환경, 리스크 식별

  2) 테스트 케이스 : 테스트를 위한 설계 산출물, 테스트 케이스의 집합을 명세화.

  3) 테스트 시나리오 : 테스트 실행을 위한 동작 순서 기술

  4) 테스트 결과서 : 테스트 결과를 정리한 문서. 결과 평가 및 리포팅

9. 소프트웨어 테스트 원리 및 특성

  1) 테스팅은 결함이 존재함을 밝히는 활동 : 결함이 발견되지 않더라도 결함이 없다는것을 증명할 수 없음.

    따라서 소프트웨어 테스팅은 시스템에 결함이 존재함을 증명하는 것.  

  2) 완벽한 테스팅은 불가능하다. : 모든 것을 테스팅하는것은 불가능. (무한 경로/입력값/타이밍 이슈 존재)

    리스크 분석과 우선순위를 토대로 한 테스트에 노력을 집중하는것이 좋음.

  3) 조기 테스팅 (Early Testing)으로 시간 절약 가능 :

    수명 초기부터 테스팅을 함으로써 나중에 큰 비용이 동반되는 수정을 줄이거나 없엘 수 있음.

  4) 결함 집중 : 대부분의 결함은 소수의 모듈에 집중되어 발생된다. 80 / 20 법칙

  5) 살충제 페러독스 : 같은 테스트 연속 반복시에는 추가적인 결함 발견이 불가능하다.

  6) 테스트는 정황 (Context)에 의존한다. : 테스트는 환경 및 구조에 따라 다르게 진행해야한다.

  + 오류-부재의 궤변 : 개발된 시스템이 요구사항을 만족시키지 못하거나 사용성이 낮다면 오류를 발견하고 제거해도 품질이 높다고 할 수 없음.

10. 테스트 커버리지

  1) 기능 기반 커버리지 : 테스트 대상의 전체 기능을 모수로 설정, 실제 테스트가 수행된 기능의 수를 측정

    일반적으로 100% 달성을 목표로 하며, UI가 많은 경우 화면 수를 모수로 사용.

  2) 라인 커버리지 : 전체 소스코드의 Line 수를 모수로, 테스트 시나리오가 수행한 Line 수를 측정.

    단위 테스트에서는 라인 커버리지를 척도로 삼는다.

  3) 코드 커버리지 : 프로그램의 소스코드가 얼마나 테스트되었는가를 나타냄.

    소스코드의 구문, 조건, 결정 등의 구조 코드 자체의 테스트 정도를 측정.

    (1) 구문 커버리지 : 코드 구조내의 모든 구문에 대해 한번 이상 수행.

      100% 구문 커버리지 = 모든 구문에 대해 1회 이상 테스트 수행

    (2) 조건 커버리지 : 결정 포인트 내의 모든 개별 조건식에 대해 수행

    (3) 결정 커버리지 : 결정 포인트 내의 모든 분기문에 대해 수행

    (4) 변형 조건/결정 커버리지 : 각 개별 조건식이 다른 개별 조건식에 영향을 받지 않고, 독립적으로 영향을 줌.

11. 테스트 유형

  1) 프로그램 실행 여부 :

    (1) 정적 테스트 : 소프트웨어의 실행없이 명세 또는 구현, 개발 단계에서 컴포넌트나 시스템 테스트

    (2) 동적 테스트 : 컴포넌트나 소프트웨어를 실행하면서 수행하는 테스트. 블랙박스/화이트박스 등

  2) 테스트 기법

    (1) 블랙박스 테스트 : 적절한 테스트 베이스 (공식 요구사항 문서, 명세서, 유스케이스 등)에 대한 분석을 통해

    '구현된 기능'을 위주로 테스트

    (2) 화이트박스 테스트 : 프로그램의 내부구조나 구현을 기반으로 테스트 도출.

      코드, 아키텍쳐, 워크/데이터플로우 분석 

  3) 테스트 시각

    (1) 검증 : 명세된 요구사항이 충족되었는지를 조사 혹은 객관적인 증거로 확인. 제품의 생산과정 테스트

    (2) 확인 : 요구사항이 컴포넌트나 시스템을 의도적으로 사용/활용 충족여부. 정상동작 테스트

  4) 테스트 목적

    (1) 회복 테스트 : 시스템에 고의로 실패/오류를 유도한 뒤 정상적으로 복귀하는지 여부

    (2) 안전 테스트 : 소프트웨어의 보안 결함 테스트

    (3) 강도 테스트 : 시스템에 과다 정보량을 부과하여 과부화 시킨 뒤 정상 작동 검증

    (4) 성능 테스트 : 응답시간, 업무량, 반응속도 등 테스트

    (5) 구조 테스트 : 시스템 내부의 논리 경로, 소스코드의 복잡도 테스트

    (6) 회귀 테스트 : 이전에 정상 작동중이던 소프트웨어의 변경/수정에 대해 새로운 결함 발견 여부 테스트

    (7) 병행 테스트 : 기존 시스템과 변경된 시스템에 동일한 테스트 케이스를 이용하여 비교

  5) 테스트 종류

    (1) 명세 기반 테스트 : 명세를 바탕으로 테스트 케이스를 도출. TC를 통해 결함없음 보장. 블랙박스 테스트

    (2) 구조 기반 테스트 : 소프트웨어나 시스템의 구조, 논리 흐름에 따라 테스트 케이스 작성. 화이트박스 테스트

    (3) 경험 기반 테스트 : 유사 애플리케이션이나 기술에서의 경험,직관,테스터의 기술 능력으로부터 TC 추출

12. 애플리케이션 성능 지표

  1) 처리량 : 주어진 시간에 처리 가능한 트랜젝션의 수 / 시간당 페이지 수

  2) 응답 시간 : 입력이 끝난 후 애플리케이션의 응답 출력까지의 시간

  3) 경과 시간 : 요구를 입력한 시점부터 결과 출력시까지의 시간

  4) 자원 사용률 : CPU/메모리 사용량 등

13. 사용자 중심 모듈 패키징 순서

  1) 기능 식별

  2) 모듈화

  3) 빌드 진행

  4) 사용자 환경 분석

  5) 패키징 적용 시험

  6) 패키징 변경 개선

14. 제품 릴리즈 노트 작성 수행 순서

  1) 모듈 식별

  2) 릴리즈 정보 확인

  3) 릴리즈 노트 개요 작성

  4) 영향도 체크

  5) 정식 릴리즈 노트 작성

  6) 추가 개선 항목 식별

15. 패키징 도구를 활용한 설치 및 배포 수행 순서

  1) 빌드 내용 식별

  2) 패키징 도구 식별

  3) 패키징 수행

  4) 패키징 도구 설치

  5) 배포 작업

  6) 정상 배포 확인

DB / SQL 관련

작성중

1. DB의 특징

  1) 무결성 : 동일 내용에 대해 서로 다른 데이터가 저장되는것을 허용하지 않음

    (1) 개체 무결성

    (2) 참조 무결성

    (3) 도메인 무결성

  2) 일관성 : 삽입, 삭제, 갱신, 생성 후에도 저장된 데이터가 변함없이 일정

  3) 회복성 : 장애 발생 시 특정 상태로 복구

  4) 보안성 : 불법적인 노출, 변경, 손실로부터 보호

  5) 효율성 : 응답시간, 저장공간 활용 등이 최적화되어 사용자 소프트웨어, 시스템 등의 요구 조건 만족

2. 정규화

  1) 제 1 정규화 : 도메인 원자값

    반복되는 속성 제거, 결정자 찾기

  2) 제 2 정규화 : 부분적 함수 종속

    부분함수 종속성 제거 (X,Y->Z일때 X->Z or Y->Z인 경우 부분함수 종속)

  3) 제 3 정규화 : 이행적 종속

    이행함수 종속성 제거 (X->Y, Y->Z 일때 X->Z를 만족하는 경우)

  4) BCNF (보이스/코드) : 3차 정규화 + 모든 결정자가 후보키 집합에 속함.

    결정자 함수 종속성 제거 : 결정자에서 FD(조인 종속) 관계가 있다면 테이블 분리

  5) 제 4 정규화 : 다치 종속

    다중값 종속성 제거 : 상호 관계 없는 Entity는 Entity별로 분리

  6) 제 5 정규화 : 조인 종속

    조인 종속 제거 : 후보키를 통하지 않은 조인 종속 제거

  7) 정규화 효과 : 데이터 간 중복성 / 불일치 제거, 이상현상 제거, 데이터 무결성 확보. 

3. 명령어

  1) 권한 / Role 부여 - GRNAT <> 회수 - REVOKE

  2) 기본 연산

    (1) Insert : 데이터 추가

    (2) Select : 데이터 불러오기 (선택)

    (3) Update : 저장된 데이터 수정

    (4) Delete : 테이블 내 데이터 삭제

  3) 테이블

    (1) Create : 테이블 구성, 기본키 / 외래키 지정

    (2) Alter : 테이블 제약조건, 속성 수정

    (3) Drop : 테이블 삭제

5. 트랜젝션 4가지 특성

  1) 원자성 : 작업은 더이상 쪼개질 수 없음. 정상적으로 수행되거나 전혀 수행되지 않아야 함.

  2) 일관성 : 트랜젝션 수행이 DB의 일관성을 보존해야 함. 데이터 불일치 발생해서는 안됨

  3) 독립성 : 트랜젝션 수행은 독립적으로 수행되어야 함.

  4) 지속성 : 트랜젝션이 성공한 이후에는 변경전까지 데이터가 보존되어야 함.

6. 프로시저

  1) 개념 : 절차형 SQL을 활용, 특정 기능 수행 트랜젝션. 데이터 조작어 (DML) 수행이 일반적.

  2) 구성 

    (1) Declare : 프로시저의 명칭, 변수/인수, 데이터 타입 정의

    (2) Begin/End : 프로시저의 시작과 종료. Begin - End 쌍으로 'Block'을 구성.

    (3) Control : 특정 비교 조건에 따라 조건에 맞는 Block 혹은 문장 실행 (if - else와 유사)

    (4) SQL : Select / Insert / Update / Delete 등을 사용.

    (5) Exception : 예외 처리 부

    (6) Transaction : 수행된 내역의 DBMS 적용/ 취소 (Commit / RollBack) 여부 결정. 완료 처리.

7. SQL 사용자 정의 함수

  1) 개념

    (1) 프로시저와 동일하게 절차형 SQL을 사용. 연산 결과를 단일값으로 반환 가능

    (2) DBMS 공통 함수 외의 사용자 직접 정의

    (3) 사용자 정의 함수의 호출을 통해 실행. 반환 단일값을 조회 / 삽입 / 수정 작업에 이용 가능

    (4) 프로시저와 유사하나 '종료 시 단일값 반환' 이 가장 큰 차이점.

  2) 명령어

    (1) Create : 사용자 정의 함수 생성

    (1+) Or Replace : 이미 동일 명칭의 함수가 있다면 새로 작성한 함수로 교체

    (2) Return : 결과값 반환

야매임.

사실상 혼자보려고 만든거니까 참고정도로만 쓰세여

SQL쪽은 따로 정리 예정

* 소프트웨어 설계 / 공학 계열

1. 현행 시스템 파악 3단계

  1) 구성/기능/인터페이스 파악 : 시스템 구성 현황, 기능, 인터페이스 현황 파악

    (1) 현행 시스템 구성 현황 : 기간업무와 지원 업무로 구분. 기간 업무 - 주요 업무, 지원 업무 - 기간 업무 지원

    (2) 기능 현황 : 단위 업무 시스템의 현 기능 기술

    (3) 인터페이스 현황 : 데이터의 종류, 형식, 프로토콜, 유형, 주기 등을 명시.

    데이터 타입 (XML 등)과 통신규약 (TCP/IP 등)에 대한 현황 파악

  2) 아키텍쳐 및 소프트웨어 구성 파악

  3) 하드웨어 및 네트워크 구성 파악

2. 요구사항 보장 프로세스

  1) 상세요구사항

  2) 요구 분석

  3) 분할 발주

  4) 보증 활동

  5) 감리 시행

  6) 요구사항보장

2-2. 요구사항 개발 프로세스

  1) 요구사항 도출 : 소프트웨어가 해결해야 할 일을 이해. 요구사항 정보 수집.

  2) 요구사항 분석 : 상충되는 요구사항 해결, 소프트웨어 범위 파악, 환경과의 상호작용 이해

  3) 요구사항 명세 : 검토 / 평가 / 승인 될 수 있는 문서 작성, 시스템 정의, 시스템 요구사항, 소프트웨어 요구사항 작성

  4) 요구사항 확인 (검증) : 분석가가 요구사항을 이해했는지 확인, 일관성과 완전성이 충족되는지 검증.

3. 연계 데이터 식별 및 표준화 절차

  1) 연계 범위 및 항목 정의

  2) 연계 코드 매핑 및 정의

  3) 변경된 데이터 구분 방식 정의

  4) 데이터 연계 (표현) 방식 정의

4. UML 특성 4가지

  1) 가시화 언어 : 개념 모델 작성, 오류 없이 전달, 의사소통 용이

  2) 구축 언어 : 다양한 프로그램 / 언어와 연결, 왕복 공학 가능, 실행 시스템 예측 가능

  3) 명세화 언어 : 정확한 모델 제시, 완전한 모델 작성, 분석 설계의 결정 표현

  4) 문서화 언어 : 시스템에 대한 통제 / 평가 / 의사소통의 문서화

4+. UML 4+1 모델

  : 고객 요구사항 중심, 설계자, 시스템 통합자, 개발자, 시스템 엔지니어의 관점으로 SW Architecture 구축

    다양한 이해 관계자들이 SW Architecture를 바라보는 View의 관점 간 관계 정의

5. 웹 서비스 기본 구조

[Web server Consumer] <Bind(SOAP)> [Web server provider [WSDL] [Service] ] <Publish (SOAP)>

<Publish (SOAP)> [UDDI Registry [WSDL] ] <Find(SOAP)> [Web server Consumer]

적당히 세가지 항목이 삼각형으로 연결되어있다고 보시면 됩니당.

  1) SOAP 

    (1) 필요한 서비스를 찾을 수 있는 웹 서비스 레지스트리 / 서비스 등록, 검색

    (2) 웹 서비스의 비즈니스 발행 / 검색하기 위한 기술적 스펙

  2) UDDI 

    (1) 웹 서비스를 표현하고 기술하는 언어 (= 서비스 표현)

    (2) 플랫폼 독립적인 단순 XML, 기반 포맷.

6. 애플리케이션 통합 솔루션

  1) EAI

    (1) 기업에서 운영하는 서로 다른 애플리케이션을 Backend 소프트웨어에 관계없이 비즈니스 프로세스 차원에서 통합

    (2) 이질적인 정보 시스템들의 데이터 연계 / 통합을 위한 소프트웨어 및 시스템 아키텍쳐 프레임워크

  2) EAI 구축 유형

    (1) Point to Point : 복수 앱 간 1:1 통합, 단순 구조

    (2) Hub & Spoke : 중앙 집중식 방식, 연동 Adapter를 통한 시스템 연계, 확장성 및 유지보수 편리

    (3) Bus : 동적 업무 프로세스 통합, 서비스 중심으로 하나의 업무 프로세스 진행, 데이터 병목 최소화

  3) ESB

    (1) 메시징과 웹 서비스, 데이터 변형, 인텔리전트 라우팅을 결합. 다양한 애플리케이션 간 상호작용을

      트랜젝션 무결성으로 연결 및 조절.

  5) EAI / ESB (이기적 정보처리기사 실기 1-117 페이지 참조) 

7. 서버 환경 구성

  1) 웹 서버 : 정적 데이터 처리 (HTML, CSS 등)

  2) 웹 애플리케이션 서버 : 동적 웹 서비스, Tomcat 등 WAS과 관련된 애플리케이션이 설치됨

  3) 데이터베이스 서버 : MySQL 등 DBMS 가 설치되는 하드웨어

  4) 파일 서버 : 서비스 제공을 위한 파일들을 저장하는 하드웨어

8. 형상 관리 4단계

  1) 형상 식별 : 이름, 관리번호 부여, 계층 구조로 구분하여 수정 및 추적이 용이하도록 작업

  2) 형상 통제 : 형상 항목의 변경 요구를 적절히 통제.

  3) 형상 감사 : 베이스라인의 무결성을 평가하기 위해 확인, 검증 과정을 통해 공식적 승인

  4) 형상 기록 (보고) : 베이스라인 현재 상태 및 변경사항 반영 여부 보고.

    형상의 식별, 통제, 감사 결과를 기록 및 관리, 보고서 작성.

9. 산업 범용 소프트웨어

  1) 시스템 소프트웨어 : 응용 소프트웨어를 실행하기 위한 플랫폼 제공. 운영체제, DBMS 등

  2) 미들 웨어 : 응용 소프트웨어가 운영체제로부터 제공받는 서비스 외의 서비스를 제공.

    WAS, 네트워크 관리, 시스템 관리, 클라우드 서비스 등

  3) 응용 소프트웨어 : 그 외 운영체제에서 실행되는 모든 소프트웨어. 일반적인 소프트웨어 해당.

10. 서비스 제공 소프트웨어

  1) 신규 개발 소프트웨어 : 새로운 서비스 제공을 목적으로 개발

  2) 기능 개선 소프트웨어 : 기존 서비스 기능에서 사용자 편의성, UI 개선, 업무 프로세스 개선 등

  3) 추가 개발 소프트웨어 : 기존 서비스 제공  시스템에 새로운 기능을 추가 개발

  4) 시스템 통합 소프트웨어 : 별도의 시스템들을 One-Stop 서비스를 위해 기능 및 데이터 통합개발

11. 정보보안 세가지 요소

  1) 기밀성 : 인가된 사용자만 필요성에 근거하여 접근

  2) 무결성 : 송수신되는 정보고 불법적으로 생성,변경,삭제되지 않아야 함

  3) 가용성 : 시스템의 지체없는 동작, 합법적 사용자가 사용을 거절당하지 않도록 함.

12. 주요 보안 약점

  1) 입력 데이터 검증

    (1) SQL Injection (삽입)

    (2) 경로 조작 / 자원 삽입

    (3) 크로스사이트 스크립트 : 입력값 검증없이 동적웹페이지 생성에 활용시 악성스크립트가 클라이언트에서 실행가능

    (4) 운영체제 명령어 삽입

    (5) 위험한 형식 파일 업로드

    (6) 신뢰되지 않는 URL 주소로 Redirection

    (7) XQuery Injection

    (8) XPath Injection

    (9) LDAP Injection : 외부 입력을 통한 의도되지 않은 Lightweigth Directory Access Protocol 명령어 수행

    (10) 크로스사이트 요청 위조

    (11) HTTP 응답 분할

    (12) 정수형 오버플로우

    (13) 메모리 버퍼 오버플로우

    (14) 부적절한 입력값 입력을 통한 보호매커니즘 우회

    (15) Format String Injection

  2) 보안 기능

    (1) 적절한 인증 없는 중요 기능 허용

    (2) 부적절한 인가

    (3) 중요 자원 권한 설정 오류

    (4) 취약한 암호화 알고리즘 사용

    (5) 중요 정보 평문 저장 / 전송

    (6) 하드코딩 된 비밀번호

    (7) 취약한 비밀번호 허용

    (8) 쿠키를 통한 정보 노출

    (9) 주석문 안에 포함된 시스템 주요 정보

    (10) 솔트 없는 일방향 해시함수 사용

    (11) 무결성 검사 없는 코드 다운로드

    (12) 반복된 인정서 제한 기능 부재

  3) 코드 오류

    (1) Null Pointer 역참조

    (2) 부적절한 자원 해제

    (3) 해제된 자원 사용

    (4) 초기화되지 않은 변수 사용

  4) 캡슐화

    (1) 잘못된 세션에 대한 데이터 노출

    (2) 제거되지 않고 남은 디버그 코드

    (3) 시스템 데이터 정보 노출

    (4) Public 메소드로부터 반환된 Private 배열

    (5) Private 배열에 Public 데이터 할당

  5) API 오용

    (1) DNS lookup에 의존한 보안 결정

    (2) 취약한 API 사용  

13. 소프트웨어 개발보안 계획 수립 단계

  1) 시작 단계 : 개발 목적, 계획, 전략 수렴, 보안 정책 검토, 보안 계획 수립

  2) 분석 단계 : 사용자 요구사항 정의, 보안 요구사항 정의

  3) 설계 단계 : 상세 요구사항 명세서 작성, 보안 요구사항 반영 -> 상세 기능 정의

  4) 구현 단계 : 환경 / 개발 보안 요건

  5) 시험 단계 : 프로그램 통합 시험. 보안성 평가, 보안 인증

14. 응집도 (위 -> 아래순으로 높아짐)

  1) 우연적 응집도 : 관련 없는 작업을 한 모듈에 모은 경우

  2) 논리적 응집도 : 유사한 성격을 같거나 특정 형태로 분류되는 처리요소들의 모임 (오류 / 출력 처리 등)

  3) 시간적 응집도 : 같은 시 간대에 처리되어야 하는 활동들의 모임

  4) 절차적 응집도 : 모듈 안의 기능들이 순차적으로 수행될 경우

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

  6) 순차적 응집도 : 모듈 내에서 한 활동으로 나온 결과물이 다른 모듈의 입력값으로 사용

  7) 기능적 응집도 : 하나의 기능만 수행하는 모듈.

15. 결합도 (위 -> 아래 순으로 높아짐)

  1) 자료 결합도 : 모듈들이 변수 파라미터를 교환하여 모듈간의 상호작용이 일어남

  2) 스탬프 결합도 : 모듈간의 인터페이스로 배열이나 오브젝트, 스트럭쳐 등을 교환

  3) 제어 결합도 : 단순 처리 값 뿐만 아니라 제어 신호를 주고받는 경우

  4) 외부 결합도 : 다수의 모듈이 밖에서 도입된 데이터, 프로토콜, 인터페이스 등을 공유

  5) 공통 결합도 : 모듈 밖의 전역변수를 참조 / 갱신하는 식으로 상호작용

  6) 내용 결합도 : 모듈 내부의 변수나 제어정보를 다른 모듈에서 사용

 * 결합도는 최대한 낮게, 응집도는 높게 될 수록 유지보수성이 좋음.

16. 소프트웨어 프레임워크

  1) 프레임워크의 정의 : 기능구현에 집중하여 빠르게 개발할 수 있도록 기본적으로 필요한 기능을 갖춤

    ex : Java - Spring / Python - Django 등

  2) 프레임워크의 특징

    (1) 모듈화 : 구현을 인터페이스 뒤에 감추는 캡슐화를 통해 모듈화를 강화, 설계 / 구현 변화 영향 최소화

    (2) 재사용성 : 프레임워크 인터페이스는 반복적으로 사용할 수 있는 컴포넌트를 정의하여 재사용성을 높임

    (3) 확장성 : 다형성을 통해 애플리케이션이 프레임워크의 인터페이스를 확장할 수 있게 함

      애플리케이션 서비스와 특성을 커스터마이징 하는것을 보장하는데 필수적인 사항. 재사용성의 이점을 얻음

    (4) 제어의역흐름 : 보통은 애플리케이션에서 프레임워크로 진행되나, 프레임워크가 전체애플리케이션의 처리흐름을

      제어하여 특정 이벤트시 애플리케이션이 확장한 메소드를 호출, 제어가 프레임워크에서 애플리케이션으로 거꾸로        진행하게 함