1. 요구사항 확인

1) 소프트웨어 생명 주기

운용/유지보수 등의 과정을 각 단계별로 나눈 것

• 소프트웨어 개발 단계, 각 단계별 주요 활동, 산출물로 표현
• 소프트웨어 생명 주기 모형: 소프트웨어 생명 주기를 표현하는 형태
  • aka 소프트웨어 프로세스 모형, 소프트웨어 공학 패러다임

2) 소프트웨어 공학

소프트웨어 위기 극복 방안으로 연구된 학문

- 기본 원칙

• 현대적 기술
• 지속적 검증
• 기록 유지

3) 폭포수 모형

• 회귀X, 선형순차적
• 고전적 생명주기 모형 → 경험, 성공사례 많음
• 각 단계 끝에 산출물
• 타당성 검토 → 계획 → 요구 분석 → 설계 → 구현(코딩) → 시험(검사) → 유지보수

4) 나선형 모형

• 보헴
• 폭포수, 프로토타입의 장점 + 위험 분석 기능
• 나선을 따라 돌듯 여러번의 SW 개발과정 반복
• 계획 → 위험 분석 → 개발/검증 → 고객평가 (→ 계획 ...)

5) 애자일 모형

민첩한, 기민한

• 요구사항 변동에 대응하기 쉽도록 일정 주기 반복
• 고객 소통에 초점, 기업활동 전반적 사용
• ex) 스크럼, XP, 칸반, Lean, 크리스탈, ASD, 기능 중심 개발(FDD)

- 4가지 핵심 가치

상호작용, 실행되는 SW, 고객 협업, 변화

• 프로세스, 도구 < 개인과 상호작용
• 문서 < 실행되는 SW
• 계약, 협상 < 고객과 협업
• 계획 < 변화

- 스크럼

• 팀 중심으로 개발 효율↑
• self-organizing, cross-functional

> 스크럼 팀 구성

• 제품 책임자(PO, Project Owner)
  • 이해 관계자 중 제품 이해도 높고 의사 결정할 사람 → 주로 개발 의뢰자, 사용자
  • 요구사항 작성 주체
  • 테스트 수행 → 요구사항 우선순위 갱신
• 스크럼 마스터(SM)
  • 스크럼 팀 조언, 가이드(통제X)
  • 일일 스크럼 회의 주관 → 진행사항 점검, 장애요소 처리
• 개발팀(DT)
  • 위에 두 명 빼고 다. 개발자 + 디자이너 + 테스터
  • 최대 7~8명

> 스크럼 개발 프로세스

• 제품 백로그(Product Backlog)
  • 요구사항(User Story) 우선순위에 따라 나열
• 스프린트 계획 회의
  • 백로그 중 이번 스프린트 작업 대상 단기 계획
• 스프린트
  • 실제 개발(2~4주), 백로그 테스트 대상으로 속도 추정, 담당자 할당
• 일일 스크럼 회의
  • 15분간 진행상황 점검, 서서 진행, 남은 작업 시간은 소멸차트에(Burn-down Chart)
• 스프린트 검토 회의
  • 사용자가 포함된 참석자 앞에서 테스트
• 스프린트 회고

- XP

eXtreme Programming

• 요구사항에 대한 유연한 대처를 위해 고객 참여, 개발 과정 반복 극대화
• 목적: 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적 참여 → 빠른 개발
• 릴리즈 기간 짧게 반복 → 요구사항 반영 가시성
• 핵심 가치: 1) 의사소통 2) 단순성 3) 용기 4) 존중 5) 피드백

> 주요 실천 방법

• 짝 프로그래밍
• 공동 코드 소유(Collective Ownership)
• TDD: 테스트 우선 작성, 테스트 자동화 도구
• 전체 팀: 구성원(고객 포함) 모두 역할, 책임 가짐
• CI: 모듈 개발 → 지속적 통합
• Design Improving/Refactoring
• Small Release

6) 현행 시스템 파악

- 1단계: 시스템

• 시스템 구성 파악: 기간 업무(주요 업무), 지원 업무 구분
• 시스템 기능 파악: 주요, 하부, 세부 기능으로 계층화
• 시스템 인터페이스 파악: 단위 업무 시스템 간 데이터 종류/형식/프로토콜/연계유형/주기

- 2단계: SW

• 아키텍처 구성 파악: 최상위 수준에서 계층별로 아키텍처 구성도 작성
• 소프트웨어 구성 파악: 제품명, 용도, 라이센스 등

- 3단계: HW

• 하드웨어 구성 파악: 서버 사양, 수, 이중화 여부
• 네트워크 구성 파악: 네트워크 구성도(서버 위치, 연결 등)

7) 운영체제(OS)

• 컴퓨터 시스템 자원 관리, 유저의 효율적/편리한 사용 환경 제공 SW
• 사용자 - 하드웨어 간 인터페이스로 동작하는 시스템 SW → 다른 응용프로그램 환경 제공
• OS관련 요구사항 식별 시 고려사항: 1) 가용성 2) 성능 3) 기술지원 4) 주변 기기 5) 구축 비용

8) 데이터베이스 관리시스템(DBMS)

• 사용자-DB 간(유저 요구에 따라) 정보 생성, DB 관리 SW
• 기존 파일 시스템이 갖는 데이터 종속성/중복성 문제 해결 → 모든 응용 프로그램이 DB 공용
• DB 구성, 접근 방법, 유지관리 책임짐
• DB 요구사항 식별 시 고려사항: 1) 가용성 2) 성능 3) 기술 지원 4) 상호호환성 5) 구축 비용

9) 웹 애플리케이션 서버(WAS)

• 동적인 콘텐츠 처리를 위해 사용되는 미들웨어 cf) WS
• 데이터 접근, 세션 관리, 트랜잭션 관리 라이브러리 제공
• 주로 DB와 연동해서 사용
• 톰캣, GlassFish, JBoss, Jetty, JEUS, Resin, WebLogic, WebSphere ...

10) 요구사항

- 요구사항 정의

서비스 설명, 정상 운영을 위한 제약 조건

> 기능 요구사항

• 입출력 무엇 포함, 시스템이 무엇을 저장하고 연산을 수행할지
• 시스템이 반드시 수행해야 하는 기능, 사용자가 원하는 기능

> 비기능 요구사항

• 시스템 장비 구성: HW, SW, 네트워크 등
• 성능: 처리 속도, 시간, 양, 동/정적 사용량, 가용성
• 인터페이스: 시스템/사용자 인터페이스 요구사항
  • 정보 교환 시 사용되는 프로토콜과의 연계도 포함하여 기술
• 데이터: 초기 자료, 변환, 보안 등
• 테스트: 장비 성능, 정상적 운영 여부
• 보안
• 품질
• 제약 사항: 기술, 표준, 업무, 법/제도
• 프로젝트 관리: 수행 관리 방법
• 프로젝트 지원: 수행 지원

- 요구사항 개발 프로세스

도출(Eliciation) → 분석(analysis) → 명세(specification) → 확인(validation)

• 도출: 요구사항 수집(인터뷰, 설문, 브레인스토밍, 프로토타이핑, 유스케이스...)
• 분석: 모호한 부분 필터링 → 자료흐름도(DFD), 자료사전(DD)
• 명세: 문서화
• 확인(검증)

- 요구사항 명세 기법

> 정형 명세 기법

• 수학적 기호, 정형화된 표기법
• 특징: 간결한 표현, 작성자 독립적 결과(완전성 검증 가능), 표기법 어려움
• VDM, Z, Petri-net, CSP

> 비정형 명세 기법

• 상태, 기능, 객체 중심 → 자연어, 다이어그램 작성
• 특징: 자연어라 일관성↓, 의사소통 용이
• FSM, Decision Table, ER 모델링, State Chart(SADT)

- 요구사항 분석

• 유저 요구사항 이해, 타당성 조사 → 비용, 일정 제약
• 목표, 해결방법 결정
• 도구: UML(Unified Modeling Language), 자료흐름도(DFD), 자료 사전(DD), 소단위 명세서, ERD(개체 관계도), 상태 전이도(STD), 제어 명세서

> 자료 흐름도(Data Flow Diagram)

자료 흐름, 변환, 기능을 도형으로 기술
aka 자료 흐름 그래프, 버블 차트

기본 기호

• 프로세스(process): 자료 변환 시스템의 한 부분 (처리, 기능, 변환, 버블)
• 자료 흐름(data flow): 자료 이동, 연관관계
• 자료 저장소(data store): 파일, DD 등
• 단말(terminator): 시스템과 교신하는 외부 개체

> 자료 사전

자료 흐름도에 있는 자료를 더 정확히 정의 (=메타 데이터)

• =: 정의
• +: and
• (): 생략
• [|]: 선택(or)
• {}: 반복
• **: 주석

11) 요구사항 분석을 위한 CASE(자동화 도구)

• SADT
  • Structured Analysis & Design Technique
  • SoftTech사, 시스템 정의/요구사항 분석, 설계, popular
• SREM
  • Software Requirement Engineering Methodology
  • RSL/REVS 사용
    • RSL: 요구사항 기술 언어
    • REUS: RSL 분석해서 명세서 만듦
  • TRW사, 우주국방 시스템 그룹 요구사항 목적으로 개발
• PSL/PSA: 미시간 대학
• TAGS: 개발주기 전과정에서 이용 가능한 통합 자동화 도구

12) HIPO

Hierarchy Input Process Output

시스템 분석/설계/문서화에 사용되는 기법
시스템 실행 과정인 입력-처리-출력 기능을 나타냄

- 특징

• 기본 시스템 모델: 입력-처리-출력
• 하향식 소프트웨어 개발 문서화 도구
• 체계적 문서관리 가능
• 기호, 도표 사용 → 가독성, 이해↑
• 기능/자료 의존 단계 동시에 표현
• 변경, 유지보수 용이

- HIPO Chart

시스템을 여러개 모듈로 분할 → 이들간의 인터페이스를 계층 구조로 표현

> 종류

• 가시적 도표(도식 목차): 시스템 전체 기능, 흐름을 Tree 구조로
• 총체적 도표(총괄 도표, 개요 도포): 프로그램 구성 기능 (입-처-출 overall)
• 세부적 도표(상세 도포): detail

13) UML

Unified Modeling Language
시스템 개발 과정의 의사소통을 위해 만든, 대표적인 객체지향 모델링 언어

• Rumbaugh(OMT), Booch, Jacobson의 객체지향 방법론의 장점 통합
• OMG(객체 기술에 관한 국제 표준화 기구)에서 표준으로 지정
• 6개의 구조 다이어그램과 7개의 행위 다이어그램
• 각 다이어그램은 사물간 관계를 용도에 맞게 표현
• 구성요소: 사물(things), 관계, 다이어그램

- 관계(Relationship)

• 연관(Association)
• 집합(Aggregation): 2개 이상의 사물이 서로 포함
• 포함(Composition): 특수한 집합, 포함하는 사물의 변화가 포함되는 사물에게 영향
• 일반화(Generalization): A가 B보다 더 일반적인지, 구체적인지
• 의존(Dependency): 필요한 만큼만 연관 유지(오퍼레이션 매개변수)
• 실체화(Realization): 행위, 인터페이스로 서로 그룹화 할 수 있는 관계

- 다이어그램(Diagram)

> 개념

사물과 관계를 도형으로 표현

• 시스템을 가시화한 뷰 제공 → 의사소통
• 정적 모델링 = 구조적 다이어그램
• 동적 모델링 = 행위 다이어그램

> 구조적 다이어그램

• 클래스 다이어그램: 클래스 간 관계, 시스템 구조 파악, 문제점 도출 가능
• 객체 다이어그램: 인스턴스, 럼바우 객체모델링에서 사용
• 컴포넌트 다이어그램: 컴포넌트간 관계/인터페이스, 구현단계에서 사용
• 배치 다이어그램: Deployment, 노드와 의사소통 경로, 물리적 요소의 위치
• 복합체 구조 다이어그램: 클래스, 컴포넌트가 복합 구조를 갖는 경우 그 내부
• 패키지 다이어그램: 유스케이스, 클래스 등 모델 요소를 그룹화한 패키지 관계

> 행위 다이어그램

• 유스케이스 다이어그램: 유저 요구 분석, 사용자/사용 사례로 구성, 사례간 관계로 이루어짐
• 순차 다이어그램: 상호작용하는 시스템/객체간 주고받는 메시지
• 커뮤니케이션 다이어그램: 메시지 + 객체 간 연관
• 상태 다이어그램: 한 객체가 상호작용에 따라 어떻게 변화하는지 (럼바우 객체지향 분석기법의 동적 모델링)
• 활동 다이어그램: 로직 처리 흐름
• 상호작용 개요 다이어그램: 상호작용 다이어그램 간 제어흐름
• 타이밍 다이어그램: 상태변화와 시간 제약을 표현

> 유스케이스 다이어그램 (행위)

사용자 관점에서 사용자가 할 수 있는 것 표현

구성요소

• 시스템, 시스템 범위: 시스템 내부의 유스케이스를 사각형으로 묶어 외부 시스템과 구분
• 액터: 시스템과 상호작용하는 대상들
  • 주 액터: 이득을 얻는 대상 ex) 사람
  • 부 액터: 주액터의 목적 달성을 위해 서비스를 제공하는 외부 시스템 ex) 조직, 기관
• 유스케이스: 제공 기능
• 관계: 액-유, 유-유 사이에서 나타남 → 연관, 포함, 확장, 일반화

> 클래스 다이어그램(구조적)

클래스, 속성과 오퍼레이션, 제약조건, 클래스간 관계 표현

구성요소

• 클래스: 이름, 속성, 오퍼레이션 표기
• 제약조건
• 관계: 연관, 집합, 포함, 일반화, 의존

> 순차 다이어그램 (행위)

시스템-객체가 메시지를 주고받으며 상호작용하는 과정을 그림으로

구성요소

• 액터
• 객체: 메시지 주고받는 주체
• 생명선(lifeline): 객체가 메모리에 존재하는 구간(점선)
• 실행상자(active box): 객체가 메시지를 주고받으며 구동중
• 메시지

> 스테레오타입

UML 기본 기능 외 추가 기능 표현
<< >> → 길러멧

• <<include>>: 포함
• <<extend>>: 확장
• <<interface>>
• <<exception>>
• <<constructor>>

2. 화면 설계

1) 사용자 인터페이스의 특징

• 사용자 만족도에 가장 큰 영향 → 변경 잦음
• 유저 편리성, 가독성 높여서 작업시간 단축, 업무 이해도 ↑
• 최소 노력으로 결과 내게끔
• 사용자 중심 설계, 상호작용
• 수행결과 오류 줄이기
• 정보제공자, 공급자간 매개 역할
• 설계 시 소프트웨어 아키텍처 숙지 필요

2) UI 구분

• CLI(Command Line Interface): 명령, 출력, 테스트
• GUI
• NUI(Natural): 유저의 말, 행동
• VUI(Voice): 음성
• OUI(Organic): 모든 사물-사용자간 상호작용, HW → IoT, VR, 증강현실, 혼합현실

3) 기본 원칙

• 직관성
• 유효성: 사용자의 목적을 달성
• 학습성: 러닝커브 낮추기
• 유연성: 요구사항 최대한 수용 및 실수 최소화

4) 설계 지침

• 사용자 중심
• 사용성: 학습 쉽고 효율적이게 → 가장 우선적 고려사항
• 심미성
• 오류 발생 해결: 사용자의 오류 인지 쉽도록

5) 기능

입력 검증, 에러 처리 및 메시지 표시, 도움/프롬프트 제공

6) 설계 도구

- 와이어프레임

기획 초기 개략적인 레이아웃
손그림, ppt, 키노트, 스케치, 일러스트, 포토샵

- 목업

와이어프레임보다 실제 화면에 가깝지만 정적인 모형(구현 X)
파워 목업, 발사믹 목업

- 스토리보드

와이어프레임 + 콘텐츠 설명 + 페이지간 이동 흐름
디자이너, 개발자의 초종 참고본 → 정책, 프로세스, 콘텐츠 구성, 와이어프레임, 기능정의
ppt, 키노트, 스케치, Axure

- 프로토타입

와이어프레임/스토리보드 + 인터렉션 → 테스트 가능, 동적 모형
사용성 테스트, 작업자간 서비스 이해를 위해 작성

- 유스케이스

사용자 측면의 요구사항, 사용자 목표 달성을 위해 수행할 내용
프로젝트 초기에 기능적 요구 결정, 결과 문서화 가능

7) 품질 요구 사항

사용자 요구사항 충족으로 확립

• ISO/IEC 9126: 국제 표준(SW 품질 표준 지침)
• ISO/IEC 25010: 9126 개정, 제품에 대한 국제 표준
• ISO/IEC 12119: 9126 + 테스트
• ISO/IEC 14598: 개발자, 구매자, 평가자 별 수행활동 규정

- 요소

• 기능성(functionality): 요구사항 만족 여부
• 신뢰성(reliability): 요구된 기능을 일관적으로 오류 없이 수행
• 사용성(usability): 사용자가 정확히 이해하고 사용하는지, 또 쓰고 싶은지
• 효율성(efficiency): 빨리 처리
• 유지보수성(maintainablity): 분석성, 변경성, 안정성, 시험성
• 이식성(portablity): 다른 환경에서 적용 가능한지

8) UI 요소

• 체크박스: 다중다선택
• 라디오 버튼: 다중일
• 텍스트박스
• 콤보박스: 지정된 목록 + 새 입력
• 목록 상자: 입력X

3. 애플리케이션 설계

1) 상위 설계, 하위 설계

상위설계	하위설계
아키텍서 설계, 예비 설계	모듈 설계, 상세 설계
시스템의 전체적 구조	시스템 내부 구조, 행위
구조, DB, 인터페이스	컴포넌트, 자료구조, 알고리즘

2) 소프트웨어 아키텍처 설계

- 기본 원리

• 모듈화: 성능 향상, 수정, 재사용, 유지관리
• 추상화: 전체적 설계 → 세분화/구체화 → 추상화
• 단계적 분해: 하향식 설계 전략 (상위 중요 개념 → 하위개념)
• 정보 은닉: 다른 모듈 접근, 변경X

- 품질 속성

품질 평가 요소를 세 측면으로 나누어 구체화시킨 것

• 시스템 측면: 성능, 보안, 가능성, 기능성, 사용성, 변경 용이성 ...
• 비즈니스 측면: 시장적시성, 비용/혜택, 예상 시스템 수명
• 아키텍처 측면: 개념적 무결성, 정확성, 완결성, ...

- 설계 과정

• 설계 목표 설정
• 시스템 타입 결정: 시스템/서브시스템 타입, 아키텍처 패턴...
• 아키텍처 패턴 적용: 시스템 표준 아키텍처 설계
• 서브 시스템 구체화
• 검토

3) 협약(Contract)에 의한 설계

컴포넌트 설계 시 클래스에 대한 여러 가정을 공유할 수 있도록 명세

• 선행조건: 오퍼레이션 호출 전 true여야 할 조건
• 결과조건: 오퍼레이션 수행 후 만족해야 할 조건
• 불변조건: 오퍼레이션 실행동안 항상 만족되어야 할 조건

4) 아키텍처 패턴

- 파이프 필터 패턴

데이터스트림 각 단계를 필터로 캡슐화, 파이프를 통해 전송

• 필터 재사용성 ↑, 추가 쉬움 → 확장성
• 필터 컴포넌트 재배치하여 다양한 파이프라인 구축 가능
• 데이터 변환, 버퍼링, 동기화에 사용
• ex) UNIX Shell
• Source --Pipe1--> Filter1 --Pipe2--> Filter2 --Pipe3--> Sink

- MVC

서브 시스템을 3개로 구조화하는 패턴

• Model: 서브시스템 핵심 기능 + 데이터 보관
• View
• Controller: 사용자 입력값 처리를 위해 모델에게 명령

- 기타 패턴

• 마스터-슬레이브 패턴
  • 마스터 컴포넌트가 슬레이브한테 작업 분할해주면 슬레이브가 돌려줌
  • 장애 허용 시스템, 병렬 컴퓨팅 시스템
• 브로커 패턴
  • 브로커가 요청에 맞는 컴포넌트 찾아서 유저와 연결
  • 분산 환경 시스템
• 피어 투 피어 패턴
  • 피어가 클라이언트가 될 수도 있고 서버가 될 수도
• 이벤트-버스 패턴
  • publish-subscribe
• 블랙보드 패턴
  • 모든 컴포넌트가 공유데이터, 블랙보드 컴포넌트에 접근 가능
  • 음성인식, 차량 식별, 신호해석
• 인터프리터 패턴
  • 코드 각 라인 수행방법 지정 → 기호마다 클래스를 갖도록 구성

5) 객체지향

- 객체

> 개념

소프트웨어 모듈. 데이터 + 함수

• 데이터
  • 객체가 가진 정보 → 속성, 상태, 분류
  • aka 속성, 상태, 변수, 상수, 자료구조
• 함수
  • 객체가 수행하는 기능 → 데이터 처리 알고리즘
  • aka 메소드, 서비스, 동작(Operation), 연산

> 특성

• 독립적으로 식별 가능한 이름
• 상태(state)는 시간에 따라 변함
• 객체간 상호 연관성에 의한 관계
• 행위: 객체가 반응할 수 있는 메시지의 집합 → 객체는 행위의 특징을 나타낼 수 있다
• 일정한 기억장소를 가짐

메소드는 다른 객체로부터 메시지를 받았을 때 정해진 기능을 수행

- 클래스

공통된 속성, 연산을 갖는 객체의 집합 / 객체의 일반적인 타입

• 객체의 속성, 연산을 정의하는 틀
• 객체지향 프로그램에서 데이터를 추상화하는 단위
• 인스턴스, 인스턴스화

- 캡슐화(Encapsulation)

데이터와 함수를 하나로 묶는 것

• 캡슐화된 객체는 인터페이스를 제외한 디테일이 은폐(정보은닉) → 외부 접근 제한 → 외부 변경에 의한 파급↓
• 재사용 용이
• 메시지 주고 받을 때 상대 객체의 디테일은 몰라도 됨 → simple interface, 결합도 ↓

- 상속(Inheritance)

부모클래스의 모든 속성/연산을 자식클래스가 물려받음

• 자신만의 속성/연산 추가 가능

- 다형성

메시지에 의해 객체가 연산 수행 시, 각 객체가 고유한 방법으로 응답할 수 있는 능력

• 객체는 동일한 메소드명으로 같은 응답 가능
• 한 함수/연산자로 둘 이상의 다른 클래스의 인스턴스가 같은 인스턴스처럼 수행할 수 있게
  • +: 숫자 클래스 == 덧셈, 문자열 클래스 == 결합
  • 오버로딩: 같은 이름, 다른 파라미터 타입/개수
  • 오버라이딩: 상위 클래스 메소드 재정의

- 연관성

둘 이상의 객체가 상호참조하는 관계

종류

• is member of(연관화, association): 상호 관련
• is instance of(분류화, classification): 동일한 형의 특성 모으기
• is part of(집단화, aggregation): 객체 모아 하나의 상위 객체
• is a (특수화, 상세화, specification): 상위 구체화 → 하위 객체

2) 객체지향 분석 및 설계

- 객체지향 분석의 방법론

• 럼바우: 가장 일반적으로 사용 / 객체, 동적, 기능 모델로 분석
• 부치: 미시, 거시 개발 프로세스
• 제이콥슨: 유스케이스
• Coad/Yourdon: ERD
• Wirfs/Brock: 분석, 설계 구분 X, 명세서 중심

- 럼바우의 분석 기법

SW 구성요소를 그래픽 표기법으로 모델링
객체 모델링 표기법(OMT, Object-Modeling Technique)

• 순서: 객체 모델링 → 동적 모델링 → 기능 모델링
  • 객체 모델링: 정보 모델링, 객체를 ERD로
  • 동적 모델링: 상태다이어그램으로 시간에 따른 객체 행위 모델링
  • 기능 모델링: 자료흐름도(DFD)로 자료 흐름/처리과정 모델링

- 객체지향 설계 원칙(SOLID)

• 단일 책임(SRP, Single Responsibility Principle)
• 개방 폐쇄(OCP, Open-Closed P): 기존 코드 변경 없이 기능 추가 가능해야
• 리스코프 치환(LSP, Liskov Substitution): 자식 클래스는 최소한 부모가 할 수 있는 일은 할 줄 알아야 함
• 인터페이스 분리(ISP, Interface Segregation): 사용X 인터페이스와 관계, 영향X
• 의존역전(DIP, Dependency Inversion): 추상성 높은 클래스와 의존

3) 모듈

- 결합도(Coupling)

모듈 간 상호의존 하는 정도, 모듈간 연관관계
약할수록 품질이 높고, 강할수록 구현, 유지보수성 낮아짐

> 종류(약한 순)

• 자료 결합도: 인터페이스가 자료 요소로만 구성
• 스탬프 결합도: 자료구조 요소로만 구성
• 제어 결합도: 제어신호, 제어요소(function, switch, tag, flag)
• 외부 결합도: 한 모듈의 데이터(변수)를 다른 모듈에서 참조
• 공통(공유) 결합도: 공통 데이터 영역을 여러 모듈이 사용
• 내용 결합도: 다른 모듈의 기능, 자료를 직접 참조

- 응집도(Cohesion)

모듈이 독립된 정도 → 강할수록 품질 좋음

> 종류 (강한 순)

• 기능적 응집도: 모든 기능이 단일 문제 연관
• 순차적 응집도: A모듈의 출력이 B모듈의 입력
• 교환(통신)적: 동일 입출력으로 서로 다른 기능
• 절차적: 모듈이 다수 기능 가질 때, 구성요소가 그 기능을 순차적 수행
• 시간적: 특정 시간에 처리되는 몇 기능을 묶은 하나의 모듈
• 논리적: 유사 성격/형태의 요소로 모듈 구성
• 우연적: 관련 없는 요소

- 팬인/팬아웃

팬인(제어, 호출하는 모듈의 수), 팬아웃(호출되는 모듈의 수)

- N-S 차트

Nassi-Scheneiderman Chart

논리 기술 중점, 도형으로 표현
박스 다이어그램, Chapin Chart

• 제어 논리 구조 표현: 연속, 선택/다중석택, 반복 등
• GOTO, 화살표 사용 X
• 복합 조건의 처리, 선택, 반복 구조를 시각적으로 명확히 표현 가능
• 단일 입구, 단일 출구
• 이해하기 쉽고 코드 변환 용이 / 작성 어렵고 임의적 제어선이 없음, 총체적 구조나 인터페이스 표현 난해

4) 공통 모듈

- 개념

자주 쓰는 계산식, 매번 필요한 사용자 인증 등
설계 과정에서 공통부분 식별, 명세 작성 필요

> 명세 기법

정확성, 명확성, 완전성, 일관성, 추적성

- 재사용

이미 개발된 기능으로 새 시스템, 기능 개발 재구성

• 사용법 공개: 누구나 쓰기 쉽도록
• 결합도는 낮게, 응집도는 높게

> 규모에 따른 분류

• 함수, 객체: 냅다 갖다씀
• 컴포넌트
  • 독립적 기능을 수행하는 코드 기반으로 작성된 모듈
  • 컴포넌트 수정 없이 인터페이스 사용해 통신
• 애플리케이션: 공통 기능 애플리케이션 공유

- 설계 방안

• 결합도는 낮게 응집도는 높게
• 모듈의 제어영역 안에서 영향영역 유지
• 복잡도, 중복성 낮게, 일관성 유지
• 모듈의 기능은 예층 가능해야하고, 지나치게 제한적이면 안됨
• 유지보수성
• 시스템 전반적인 기능/구조를 이해하기 쉬운 크기로 분리
• 모듈간 계층관계 자료 필요

5) 코드

- 개요

자료 처리 과정, 자료 추출을 용이하게 하려고 쓰는 기호

• 정보를 신속, 명확, 정확하게 전달할 수 있게
• 주민등록번호, 학번, 전화번호

주요 기능: 식별, 분류, 배열(의미 부여해서 나열 가능), 표준화(다양한 데이터를 기준에 맞게 표현), 간소화

- 종류

• 순차코드: auto_increment
• 블록코드: 공통성 블록으로 묶고 그 안에서 auto_increment
• 10진 코드: 도서관
• 그룹 분류 코드: 1-01-001 == 총무부
• 연상코드: TV-40
• 표의 숫자 코드: 120-720-1500
• 합성코드: Ke-711 대한항공 711

6) 디자인 패턴

- 개요

설계 시 참조할만한 전형적인 해결방식

• 문제/배경, 사례, 샘플코드
• Don't reinvent the wheel
• GoF의 디자인 패턴: 생성(5), 구조(7), 행위(11) → 총 23

- 장단점

• 범용성 높고 구조 파악 용이
• 객체지향 설계, 생산력 증대
• 이미 검증됨 → 개발 시간, 비용 단축
• 초기 투자비용 높음
• 개발자간 의사소통 용이
• 설계 변경 요청 대처 가능
• 객체지향 아니면 곤란

- 생성 패턴(Creational Pattern)

객체의 생성, 참조과정 캡슐화 → 객체 생성/변경 시 영향 낮춤 → 프로그램 유연성 증대

> 추상팩토리

• 구체적 클래스가 아니라 인터페이스를 통해 연관객체 그룹으로 생성
• 서브클래스 통째로 교체 가능

> 빌더

생성, 표현 분리

> 팩토리 메소드

• 객체 생성을 서브클래스로 분리
• 상위 클래스에선 인터페이스만 정의
• 가상생성자 패턴

> 프로토타입

• 원본 객체 복제
• 일반적 방법으로 생성, 비용이 큰 경우 사용

> 싱글톤

• 생성된 객체를 어디서든 참조 가능, 여러 프로세스 동시 참조 불가
• 메모리 낭비 X. 하나의 인스턴스 보장

- 구조 패턴

클래스 조합해서 더 큰 구조로

> 어댑터

• 호환성이 없는 클래스들의 인터페이스를 다른 클래스가 이용할 수 있게
• 기존 클래스 쓰고 싶은데 인터페이스가 다를 때

> 브릿지

• 추상층 분리, 독립적 확장
• 기능과 구현을 두 개의 별도 클래스로

> 컴포지트

• 여러 객체를 가진 복합객체와 단일 객체를 구분없이 다루고자 할 때
• 객체들을 트리구조로 구성 → 복합 객체 안에 복합객체

> 데코레이터

• 객체간 결합으로 기능 확장
• 부가 기능 추가를 위해 다른 객체 덧붙이기

> 퍼싸드

• 복잡한 서브클래스를 피해 더 상위에 인터페이스 구현, 서브클래스들 간편하게 사용
• 서브 클래스 간 통합 인터페이스로서의 Wrapper 객체 필요

> 플라이웨이트

• 인스턴스를 가능한 한 공유해서 메모리 절약
• 다수의 유사객체 필요시 유용

> 프록시

• 접근 어려운 객체와 얘한테 연결하려는 객체 간 인터페이스
• 네트워크 연결, 메모리 대용량 객체로의 접근 시

- 행위 패턴

객체간 상호작용, 책임 분배 방법 정의
하나의 객체로 수행할 수 없는 작업을 다른 객체로 분배하여 결합도 낮춤

> 책임 연쇄(Chain of Responsibility)

• 요청처리 객체가 둘 이상일 때, 한 객체가 처리 못하면 다음 객체 줌
• 객체간 고리로 연결 - 요청 해결까지 고리 따라감

> 커맨드

• 요청을 객체로 캡슐화 → 재이용, 취소 가능하도록 정보 저장/로그 남김
• 요청에 사용되는 각종 명령어를 추상/구체 클래스로 분리하여 단순화

> 인터프리터

• 언어에 문법 표현을 정의
• SQL, 통신 프로토콜

> 반복자

• 자료구조와 같이 접근이 잦은 객체에 동일한 인터페이스 사용
• 내부 노출 없이 순차적 접근 가능

> 중재자

• 객체간 복잡한 상호작용을 캡슐화하여 객체로 정의
• 객체간 의존성 줄여 결합도 감소

> 메멘토

• 특정 시점에서의 객체 내부를 객체화 → ctrl z

> 옵서버

• 객체 - 상속된 다른 객체 간 publish-subscribe

> 상태

• 객체 상태에 따라 동일 동작 다르게 처리할 때
• 객체 상태를 캡슐화, 이를 참조

> 전략

• 유사 알고리즘 개별적 캡슐화 → 상호 교환 가능하도록 정의
• 클라이언트는 독립적으로 원하는 알고리즘 선택 가능, 클라이언트에 영향 없이 알고리즘 변경 가능

> 템플릿 메소드

• 상위 클래스에서 골격을, 하위 클래스에서 구체화
• 유사한 서브 클래스를 묶어 공통된 내용을 상위 클래스에서 정의 → 코드 양 줄이고 유지보수성 높임

> 방문자

• 각 클래스의 데이터 구조에서 처리기능을 분리하여 별도의 클래스로
• 분리된 처리 기능은 각 클래스를 방문하여 수행

4. 인터페이스 설계

1) 시스템 인터페이스 요구사항

- 검증 방법

> 요구사항 검토(Requirements Review)

명세서 오류, 결함을 담당자들이 수작업으로 분석

• 동료 검토: 작성자가 발표하면 동료가 들어보면서 결함 찾기
• 워크스루: 명세서 배포 후 검토 회의
• 인스펙션: 검토 전문가들이 확인

> 프로토타이핑

견본품(prototype)을 만들어 최종 결과물 예측

> 테스트 설계

테스트 케이스 생성

> CASE 도구 활용

일관성 분석을 통해 확인

2) 시스템 연계 기술

• DB Link: DB가 제공하는 DB Link 객체를 이용
• API/Open API: 송신시스템 DB에서 데이터 제공하는 애플리케이션 프로그래밍 인터페이스 프로그램
• 연계 솔루션: EAI 서버와 송수신 시스템의 클라이언트 이용
• Socket: 서버는 소켓 생성, 포트 할당 → 클라이언트 요청 시 연결하여 통신하는 네트워크 기술
• Web Service: WSDL, UDDI, SOAP 프로토콜

3) 연계 매커니즘 구성 요소

• 송신 시스템
  • 연계 프로그램에서 온 데이터를 형식에 맞게 인터페이스 테이블, 파일 등으로 변환 후 송신하는 시스템
• 수신 시스템
  • 수신한 인터페이스 테이블, 파일을 연계 프로그램에서 처리할 수 있는 형식으로 변환
• 연계 서버
  • 송/수신 시스템 사이에서 현황 모니터링

4) 미들웨어

운영체제와 응용 프로그램, 서버와 클라이언트 사이에서 다양한 서비스를 제공하는 SW

• DB
  • DB 클라이언트-원격DB 연결용 미들웨어
  • 2-Tier 아키텍처: DB를 사용하여 시스템 구축
• RPC
  • Remote Procedure Call, 원격 프로시저 호출
  • 원격 프로시저를 로컬처럼 호출
• MOM
  • Message Oriented Middleware, 메시지 지향 미들웨어
  • 비동기형 메시지 전달 방식
  • 온라인 업무보다는 이기종 분산 데이터 시스템의 데이터 동기를 위해 사용
• TP-Monitor
  • Transaction Processing Monitor, 트랜잭션 처리 모니터
  • 항공기, 철도 예약 업무 등 온라인 트랜잭션 업무에서 트랜잭션 처리, 감시 미들웨어
  • 사용자가 증가해도 빠른 응답 속도를 유지해야 하는 업무
• ORB
  • Object Request Broker, 객체 요청 브로커
  • 객체 지향, 코바(CORBA) 표준 스펙 구현
  • 최근에는 TP-Monitor의 장점인 트랜잭션 처리, 모니터링 추가 구현 제품도 있음
• WAS
  • Web Application Server
  • 동적인 콘텐츠 처리를 위한 미들웨어
  • 클라이언트-서버 환겨보다는 웹 환경을 구현하기 위한 미들웨어