---

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

---

소프트웨어의 위기를 극복하기 위한 방안 연구

방법론, 도구관리 기법 등을 통해 소프트웨어 품질과 생산성 향상 목적

1. 현대적인 프로그래밍 기술 적용
2. 개발된 소프트웨어의 품지 유지 및 검증
3. 소프트웨어 개발 관련 사항 및 결과에 대한 명확한 기록 유지

---

각 단계를 확실히 매듭짓고 그 결과를 철저히 검토하여 승인 과정을 거친 후 다음 단계로 진행하는 모형

---

폭포수 모형의 장점에 위험 분석 기능을 추가한 모형 - 보햄(Boehm)이 제안

---

고객의 요구사항 변화에 유연하게 대응하기 위해 개발된 모형 - 기업 활동 전반에 걸쳐 사용됨

• 스크럼, 익스트림 프로그래밍(XP), 칸반, lean, 크리스털, DSDM 등

1. 개인과 상호작용
   : 프로세스와 도구보다 개인과의 상호작용을 중시
2. 작동하는 소프트웨어
   : 문서보다 작동하는 소프트웨어를 우선
3. 고객과의 협력
   : 계약 협상보다 고객과의 협력을 중시
4. 변화에 대응
   : 계획을 따르기보다 변화에 대응하기를 중시

팀이 중심이 되어

개발의 효율을 높인다는 방법론

• 팀원 스스로가
  스크럼 팀을 구성
  (self-organizing)하고, 스스로가 일정을 관리하고, 스스로가 문제를 해결
• 스크럼 팀: 스크럼 마스터, 제품 책임자, 개발팀으로 구성

• 제품에 대한 이해도 높고, 요구사항 책임 및
  의사결정권자
• 주로 개발 의뢰자나 사용자가 담당
• 이해관계자들의 의견을 종합하여 요구사항 작성 주체
• 제품 테스트 수행 및 요구사항 우선순위 결정

• 스크럼 팀이 스크럼을 잘 수행하도록 도와주는
  가이드
  역할
• 스크럼 회의 주관, 진행사항 점검, 장애물 공론화 및 제거

• 제품 책임자와 스크럼 마스터를 제외한 나머지
  팀원
• 최대 인원은 7~8명이 적당

프로세스	설명
제품 백로그 작성	제품 책임자가 제품의 요구사항을 우선순위에 따라 작성
스프린트 계획 회의	스크럼 팀이 스프린트(단기 일정) 목표와 작업 항목을 선정
스프린트	2주~1개월 정도의 개발 기간
일일 스크럼	매일 15분 정도 짧은 회의를 통해 진행 상황 공유
스프린트 검토 회의	스프린트 결과물을 검토하고 테스트 수행, 피드백을 받음
스프린트 회고	스프린트 진행 과정을 점검하고 개선 방안을 도출

수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 개발된 방법론

• 짧고 반복적 개발주기, 단순한 설계, 고객의 적극적 참여
• 릴리즈 기간을 짧게 반복
• XP의 5가지 핵심 가치
  : 의사소통, 단순성, 용기, 존중, 피드백

실천 방법	설명
Pair Programming	두 명이 한 컴퓨터에서 작업하여 코드 품질 향상
Collective Ownership	모든 팀원이 코드에 대한 소유권을 공유
Test-Driven Development	테스트 케이스를 먼저 작성하고, 테스트를 통과하는 코드 작성
Whole Team	개발팀 전체가 프로젝트에 참여
Continuous Integration	코드 변경 시 자동으로 빌드 및 테스트 수행
Design Improvement	설계 개선을 위해 지속적으로 리팩토링 수행
Small Releases	짧은 주기로 릴리즈 수행

---

• 1단계
  • 시스템 구성 파악: 주요 업무와 지원 업무로 구분
  • 시스템 기능 파악: 현재 기능들을 주요 기능, 하부 기능, 세부 기능으로 구분 -> 계층형
  • 시스템 인터페이스 파악: 단위 업무 간의 연계 및 데이터 종류, 연계 유형, 주기 파악
• 2단계
  • 아키텍쳐 구성 파악: 최상위 수준에서 계층별 아키텍쳐 구성도 작성
  • 소프트웨어 구성 파악: 소프트웨어의 제품명, 용도, 라이선스 등 명시
• 3단계
  • 하드웨어 구성 파악: 시스템 운용되는 서버 사양, 이중화 적용 여부 명시
  • 네트워크 구성 파악: 서버의 위치, 네트워크 구성도 명시

---

• 고려사항: 가용성, 성능, 기술 지원, 주변 기기, 구축 비용

---

• 고려사항: 가용성, 성능, 기술 지원, 상호 호환성, 구축 비용

---

정적인 콘텐츠를 처리하는 웹 서버와 달리

동적인 콘텐츠

를 처리하는 미들웨어

• 데이터 접근, 세션 관리, 트랜잭션 관리, 보안 기능 제공
• 주로 DBMS와 연동하여 데이터 처리

---

시스템이

무엇

을 하는지,

어떤 기능

을 하는지에 대한 사항

시스템이

어떻게

동작해야 하는지에 대한 사항

• 시스템 장비 구성 요구사항: 서버, 네트워크, DBMS 등
• 성능 요구사항: 응답시간, 처리량, 가용성 등
• 인터페이스 요구사항: 사용자 인터페이스, 하드웨어 인터페이스 등
• 데이터 요구사항: 데이터 크기, 데이터 보관 기간 등
• 테스트 요구사항: 테스트 계획, 테스트 케이스 등
• 보안 요구사항: 접근 제어, 인증, 암호화 등
• 품질 요구사항: 신뢰성, 유지보수성, 이식성 등
• 제약사항: 법적, 기술적, 경제적 제약사항
• 관리 요구사항: 개발, 유지보수, 운영 등의 관리 요구사항
• 지원 요구사항: 사용자 교육, 기술 지원, 문서화 등

개발 대상에 대한 요구사항을 체계적으로 도출, 분석, 명세, 확인, 검증하는 과정

• 요구사항이 어디에 있는지, 어떻게 수집할 것인지 식별
• 주요 기법에는 인터뷰, 설문, 워크샵, 프로토타이핑, 스토리보드, 유즈케이스 등

• 사용자의 요구사항 중 명확하지 않거나 모호한 부분을 식별하고 걸러내는 과정
• 자료 흐름도(DFD), 자료 사전(DD) 등의 도구 사용됨

• 분석된 요구사항 바탕으로 모델을 작성하고 문서화
• 구체적인 명세를 위해 소단위 명세서(Mini-Spec)사용

• 개발 자원을 요구사항에 할당하기 전에 요구사항이 정확하고 완전한지 검증

구분	정형 명세 기법	비정형 명세 기법
기법	수학적 원리 기반, 모델 기반	상태/기능/객체 중심
작성 방법	수학적 기호, 정형화 된 표기법	일반 명사, 동사 등의 자연어 를 기반으로 서술 or 다이어그램
특징	요구사항을 정확하고 간결하게 표현할 수 있다 요구사항에 대한 결과 완전성 검증 가능 표기법이 어려움	자연어의 사용으로 인해 일관성이 떨어짐 내용의 이해가 쉬워 의사소통 용이
종류	VDM, Z, Petri-net, CSP 등	FSM, Decision Table, ER모델링, State Chart(SADT) 등

소프트웨어 개발의 실제적인 첫 단계로, 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화

• 사용자 요구의 타당성을 조사하고 비용과 일정에 대한 제약 설정
• 사용자의 요구를 정확하게 추출하여
  목표 설정
  -> 해결방안 도출
• 요구사항 분석 결과는
  일관성 있게 문서화
  할 것
• 요구사항 분석을 위해 UML, DFD, DD, ERD 등의 도구 사용

요구사항 분석에서 자료의 흐름 및 변환 과정과 기능을 도형 중심으로 기술하는 방법: 자료 흐름 그래프, 버블 차트라고도 함

• 자료 흐름도의 구성 요소
  • 프로세스 (Process): 자료의 처리를 수행하는 기능 -> 원이나 둥근 사각형
  • 자료 흐름 (Data Flow): 프로세스 간에 전달되는 자료의 흐름 -> 화살표 위에 자료의 이름 기입
  • 자료 저장소 (Data Store): 자료의 저장소 -> 도형 안에 자료 저장소 이름을 기입
  • 외부 개체 (External Entity): 시스템 외부와의 상호작용을 나타내는 요소 -> 도형 안에 이름 기입

자료 흐름도에 있는 자료를 정의하고 설명하는 목적으로 사용되는 도구

기호	의미
=	자료의 정의 : ~로 구성되어 있다(is composed of)
+	자료의 연결 : 그리고(and)
()	자료의 생략 : 생략 가능한 자료(Optional)
[|]	자료의 선택 : 또는(or)
{}	자료의 반복 {}n: n번 이상 반복 {}n: 최대로 n번 반복 {}nm: m이상 n이하로 반복
* *	자료의 설명 : 주석(Comment)

요구사항을 자동으로 분석하고, 분석 명세서를 기술하는 도구

• SADT(Structured Analysis and Design Technique): 자료 흐름도, 자료 사전을 사용하여 시스템을 분석
• SREM(Software Requirements Engineering Method): 요구사항 분석을 위한 방법론
  • RSL(Requirement Specification Language): 요구사항 명세서 작성을 위한 언어
  • REVS(Requirement Engineering Verification System): 요구사항 검증을 위한 시스템
• PSL/PSA(Problem Statement Language/Problem Statement Analyzer): 문제 상태 분석을 위한 언어 및 분석기
• TAGS(Technology for Automated Generation of Software): 소프트웨어 자동 생성을 위한 기술

---

시스템의

분석 및 설계

,

문서화

를 위해 사용되는 방법론

• 기본 시스템 모델: 계층적 구조로 시스템의 입력, 처리, 출력을 표현
• 체계적 문서 관리
• 기호, 도표 등을 사용
• 기능과 자료의 의존 관계를 동시에 표현 불가
• 변경, 유지보수 용이
• 시스템의 기능을 여러 개의 고유 모듈로 분할하여 이들 간의 인터페이스를 계층 구조로 표현 -> HIPO 차트

• 가시적 도표(도식 목차)
  : 시스템의 전체적인 구조를 표현하는 계층(Tree) 구조도
• 총체적 도표(총괄도표, 개요 도표)
  : 프로그램을 구성하는 기능을 기술한 것
  • 입력, 처리, 출력, 저장소로 구성
• 세부적 도표(상세도표)
  : 총체적 도표의 각 기능을 세부적으로 기술한 것

---

시스템 분석, 설계, 구현 등 시스템 개발 과정에서 시스템 개발자와 고객 또는 개발자 간의 의사소통을 위해 사용되는 표준화된 모델링 언어

• 시스템의 구조를 표현하는 6개의 구조 다이어그램
• 시스템의 동작을 표현하는 7개의 행위 다이어그램
• 각각의 다이어그램은 사물과 사물 간의 관계를 용도에 맞게 표현
• 구성용소:
  사물
  ,
  관계
  ,
  다이어그램

UML에서 사물과 사물 간의 관계를 표현하는 방법

• 연관 관계 (Association)
  : 사물 간의 연결 관계
• 집합 관계 (Aggregation)
  : 전체와 부분 사이의 관계
• 포함 관계 (Composition)
  : 전체와 부분 사이의 강한 관계
• 일반화 관계 (Generalization)
  : 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지를 표현
• 의존 관계 (Dependency)
  : 사물 사이에 연관은 있으나 서로에게 영향을 주는 짧은 시간만 연관을 유지
• 실체화 관계 (Realization)
  : 인터페이스와 구현 클래스 사이의 관계

UML에서 시스템의 구조와 동작을 표현하는 도표

• 구조적 다이어그램의 종류

구조적 다이어그램	설명
클래스 다이어그램 (Class Diagram)	시스템의 클래스 구조를 표현
객체 다이어그램 (Object Diagram)	클래스 다이어그램의 인스턴스를 표현
컴포넌트 다이어그램 (Component Diagram)	시스템의 물리적인 구조를 표현
배치 다이어그램 (Deployment Diagram)	시스템의 물리적인 배치를 표현
복합체 구조 다이어그램 (Composite Structure Diagram)	클래스나 컴포넌트의 내부 구조를 표현
패키지 다이어그램 (Package Diagram)	패키지 간의 관계를 표현

• 행위적 다이어그램의 종류

행위적 다이어그램	설명
유스케이스 다이어그램 (Use Case Diagram)	시스템의 기능적 요구사항을 표현
시퀀스 다이어그램 (Sequence Diagram)	객체 간의 상호작용을 표현
커뮤니케이션 다이어그램 (Communication Diagram)	객체 간의 상호작용을 표현
상태 다이어그램 (State Diagram)	객체의 상태 변화를 표현
활동 다이어그램 (Activity Diagram)	시스템의 동작 흐름을 표현
상호작용 개요 다이어그램 (Interaction Overview Diagram)	다른 다이어그램을 통합하여 표현
타이밍 다이어그램 (Timing Diagram)	객체 간의 시간적인 관계를 표현

UML에서 사물의 특성을 표현하기 위해 사용되는 키워드

• <<stereotype>> 형태로 표현

스테레오 타입	설명
<<include>>	유스케이스 간의 포함 관계를 표현
<<extend>>	유스케이스 간의 확장 관계를 표현
<<interface>>	인터페이스를 표현
<<exception>>	예외를 표현
<<constructor>>	생성자를 표현

구성요소	설명
시스템/시스템 범위	시스템 내부에서 수행되는 기능의 범위를 표현
액터(Actor)	시스템과 상호작용하는 외부 개체
유스케이스(Use Case)	시스템이 제공하는 기능
관계(Relationship)	액터와 유스케이스 간의 관계를 표현

구성요소	설명
클래스(Class)	시스템을 구성하는 객체의 특성과 행위를 표현
제약조건(Constraint)	클래스에 대한 제약사항을 표현
관계(Relationship)	클래스 간의 관계를 표현

구성요소	설명
액터(Actor)	객체의 상호작용에 참여하는 사용자
객체(Object)	상호작용하는 객체
생명선(Lifeline)	객체의 생존 기간을 표현
실행 상자(Active Box)	객체의 상태를 표현
메시지(Message)	객체 간의 상호작용을 표현

---

• 사용자의 만족도에 가장 큰 영향을 미치는 요소
• 사용자 중심 설계
• 정보 제공자와 공급자 간 매개 역할

• CLI(Command Line Interface):
  명령어
  를 통해 사용자와 시스템이 상호작용
• GUI(Graphical User Interface):
  그래픽 요소
  를 사용하여 사용자와 시스템이 상호작용
• NUI(Natural User Interface): 사용자의 자연스러운
  동작
  을 인식하여 상호작용
• VUI(Voice User Interface):
  음성
  을 통해 사용자와 시스템이 상호작용
• OUI(Organic User Interface): 모든 사물과 사용자 간의 상호작용(사물인터넷, 가상현실)

• 직관성
  : 사용자가 쉽게 이해하고 사용할 수 있어야 함
• 유효성
  : 사용자가 목적을 달성하는 데 효과적이어야 함
• 학습성
  : 사용자가 쉽게 학습할 수 있어야 함
• 유연성
  : 사용자의 요구사항을 다양하게 수용할 수 있어야 함

• 사용자 중심: 사용자가 이해하고 편리하게 사용할 수 있는 환경 제공
• 사용성: 사용자가 소프트웨어를 얼마나 빠르고 쉽게 이해할 수 있는지
• 심미성: 디자인적으로 높은 완성도
• 오류 발생 해결: 오류가 발생 시 사용자가 쉽게 인지하고 해결할 수 있도록

UI의 화면 구조나 화면 배치 등을 설계하는 도구

• 와이어프레임(Wireframe): 기획 초기 단계에 UI의 구조와 레이아웃을 설계하는 도구
• 목업(Mockup):
  와이어프레임
  을 바탕으로 실제 화면과 유사하게 디자인한 것
• 스토리보드(Storyboard): UI의
  흐름
  을 시각적으로 표현한 것
• 프로토타입(Prototype): 실제 화면과 유사하게 제작한 것
• 유스케이스(Use Case): 사용자의 요구사항을 기반으로 수행할 내용을 기술

• ISO/IEC 9126: 소프트웨어 품질 특성과 평가를 위한 표준 지침 - 국제 표준으로 널리 사용됨
• ISO/IEC 25010: 소프트웨어 제품 품질 모델 - ISO/IEC 9126을 대체하는 표준
• ISO/IEC 12119: ISO/IEC 9126을 준수, 테스트 절차 포함
• ISO/IEC 14598: 개발자, 구매자, 평가자 별로 수행해야 할 제품 평가 활동을 정의

품질 특성	설명
기능성(Functionality)	시스템이 제공하는 기능의 완전성, 정확성, 상호운용성
신뢰성(Reliability)	시스템이 정확하게 동작하고, 오류가 발생하지 않는 정도
사용성(Usability)	시스템을 사용하는 사용자의 만족도, 학습성, 이해도
효율성(Efficiency)	시스템이 자원을 효율적으로 사용하는 정도
유지보수성(Maintainability)	시스템을 변경하거나 수정할 수 있는 정도
이식성(Portability)	시스템을 다른 환경으로 이전할 수 있는 정도

• 체크 박스(Check Box): 사용자가 선택할 수 있는 항목을 표시할
• 라디오 버튼(Radio Button): 여러 개의 항목 중 하나만 선택할 수 있는 버튼
• 텍스트 상자(Text Box): 사용자가 텍스트를 입력할 수 있는 상자
• 콤보 박스(Combo Box): 여러 항목 중 하나를 선택할 수 있는 상자
• 목록 상자(List Box): 여러 항목 중 하나 이상을 선택할 수 있는 상자

---

구분	상위 설계	하위 설계
별칭	아키텍쳐 설계, 예비 설계	모듈 설계, 상세 설계
설계 대상	시스템 전체 구조	모듈 단위의 구조
세부 목록	DB, 구조, 인터페이스	컴포넌트, 자료구조, 알고리즘

원리	설명
모듈화(Modularity)	시스템을 여러 개의 모듈로 분할하여 설계
추상화(Abstraction)	시스템의 복잡성을 숨기고 필요한 정보만 표현
단계적 분해(Stepwise Refinement)	시스템을 계층적으로 분해하여 설계
정보 은닉(Information Hiding)	모듈 간의 인터페이스를 통해 상세 정보를 숨김

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

1. 설계 목표 설정: 시스템의 개발 방향 명확히 설정
2. 시스템 타입 결정: 시스템과 서브시스템의 타입 결정
3. 아키텍쳐 패턴 적용: 시스템의 표준 아키텍쳐 설계
4. 서브시스템 구체화: 서브시스템의 기능 및 서브시스템 간의 상호작용을 위한 동작과 인터페이스 정의
5. 아키텍쳐 설계 검토: 아키텍쳐 설계의 정확성과 완전성 검토

컴포넌트를 설계할 때, 컴포넌트 간의 상호작용을 정의하는 것

구분	협약
선행 조건(Precondition)	컴포넌트가 실행되기 전에 만족해야 하는 조건
결과 조건(Postcondition)	컴포넌트가 실행된 후에 만족해야 하는 조건
불변 조건(Invariant)	컴포넌트가 실행되는 동안 항상 참이어야 하는 조건

데이터 스트림의 각 단계를

필터

로 캡슐화하여

파이프

를 통해 데이터 전송

• 필터 컴포넌트는 재사용성이 좋고, 추가가 쉬워 확장성 좋음
• 데이터 변환, 버퍼링, 동기화 등에 주로 사용됨
• UNIX의 Shell이 있다
  Source -> Filter1 -> Filter2 -> Sink

소프트웨어를 세 가지 요소로 구성하여 사용자 인터페이스와 비즈니스 로직을 분리하는 패턴

• 모델(Model)
  : 데이터와 데이터를 처리하는 로직을 담당
• 뷰(View)
  : 사용자에게 데이터를 표시하고 사용자의 입력을 받는 역할
• 컨트롤러(Controller)
  : 사용자의 입력을 받아 모델을 업데이트하고 뷰를 업데이트하는 역할
  
  이미지 출처:MVC-MDN Web Docs↗

패턴	설명
마스터-슬레이브 패턴(Master-Slave Pattern)	하나의 마스터가 여러 개의 슬레이브를 제어하는 패턴
브로커 패턴(Broker Pattern)	클라이언트와 서버 간의 중개자 역할을 하는 패턴
피어-투-피어 패턴(Peer-to-Peer Pattern)	서로 동등한 관계로 통신하는 패턴
이벤트-버스 패턴(Event-Bus Pattern)	특정 채널이 이벤트 메시지를 발행하면 각 채널을 구독한 리스너들이 메시지를 받는 패턴
블랙보드 패턴(Blackboard Pattern)	모든 컴포넌트들이 블랙보드에서 원하는 데이터를 찾을 수 있는 패턴
인터프리터 패턴(Interpreter Pattern)	문법 규칙을 해석하는 패턴

---

데이터와 데이터를 처리하는

함수

를 묶어놓은 모듈

• 데이터: 객체가 가지고 있는 정보로 속성, 상태, 분류 등을 나타냄
• 함수: 객체가 수행하는 동작으로 메서드, 오퍼레이션, 함수 등으로 불림

• 독립적으로 식별할 수 있는 이름을 가진다
• 상태
  를 가지며 상태를 변경할 수 있다.
• 객체는 상호 연관성에 의한 관계가 형성된다

공통된 속성과 연산을 가진 객체들의 집합으로, 객체의 일반적인

타입

을 의미

• 각각의 객체들이 갖는 속성과 연산을 정의
• 클래스는 객체지향 프로그래밍에서 데이터를
  추상화
  하는 단위
• 클래스에 속한 객체를
  인스턴스
  라고 함

데이터와 데이터를 처리하는 함수(객체)를 하나로 묶고, 외부에서 접근을 제어하는 것

• 캡슐화된 객체는 인터페이스를 제외한 내부 구현을 숨김 $\rightarrow$
  정보 은닉
  , 외부 모듈의 변경 영향 적음
• 재사용이 용이함
• 객체들 간 메시지를 주고받을 때 인터페이스가 단순해짐

기존 클래스(부모 클래스)의 속성과 연산을 그대로 물려받아 새로운 클래스(자식 클래스)를 정의하는 것

• 상위 클래스로붵 상속받은 속성과 연산 외에 새로운 속성과 연산을 추가할 수 있음
• 코드의 중복을 줄이고 유지보수성을 높임

메시지에 의해 객체(클래스)가 연산을 수행하게 될 때

하나의 메시지에 대해

각각의 객체(클래스)가 가지고 있는

고유한 연산

을 수행하는 능력

• 객체(클래스)들은 동일한 메소드명을 사용하여 같은 의믜의 응답을 함
• ex) '+' 연산자는 정수, 실수, 문자열 등 다양한 데이터 타입에 대해 다르게 동작
• 오버로딩(Overloading): 메소드의 이름은 같지만 매개변수의 타입이나 개수가 다른 경우
• 오버라이딩(Overriding): 상위 클래스의 메소드를 하위 클래스에서 재정의

두 개 이상의 객체(클래스)가 상호 참조하는 관계

종류	의미	특징
is member of	연관화(Association)	2개 이상의 객체가 상호 관련되어있음
is a instance of	분류화(Classification)	동일한 형의 특성을 객체들을 모아 구성
is a part of	집단화(Aggregation)	관련 있는 객체들을 묶어 하나의 상위 객체 구성
is a	일반화(Generalization)	공통적인 성질들로 추상화한 상위 객체 구성
"	특수화/상세화(Specialization)	상위 객체를 구체화한 하위 객체 구성

• Rumbaugh 방법론
  : 가장 일반적으로 사용되는 객체지향 방법론,
  객체 모델링 기법
  (OMT)라고도 불림
  분석 활동을
  객체 모델
  ,
  동적 모델
  ,
  기능 모델
  로 구분하여 순차적으로 수행

  모델	설명
  객체 모델링(Object Model)	시스템을 구성하는 객체들과 객체들 간의 관계를 표현
  동적 모델링(Dynamic Model)	객체들 간의 상호작용을 표현
  기능 모델링(Functional Model)	시스템이 제공하는 기능을 표현

• Booch 방법론: 미시적(Micro) 개발 프로세스와 거시적(Macro) 개발 프로세스로 구분하여 객체지향 분석과 설계를 수행
• Jacobson 방법론: Use Case를 중심으로 객체지향 분석과 설계를 수행
• Coad와 Yourdon 방법론: E-R 다이어그램을 사용하여 객체지향 분석과 설계를 수행
• Wirfs-Brock 방법론: 분석과 설계 간의 구분이 없고, 설계 작업까지 연속적 수행

시스템 변경이나 확장에 유연한 설계를 위해 객체지향 설계 원칙을 준수 -

SOLID

원칙

원칙	설명
단일 책임 원칙(Single Responsibility Principle, SRP)	객체는 하나의 책임만 가져야 함
개방-폐쇄 원칙(Open-Closed Principle, OCP)	확장에 대해 열려 있고, 수정에 대해 닫혀 있어야 함
리스코프 치환 원칙(Liskov Substitution Principle, LSP)	상위 타입의 객체를 하위 타입의 객체로 대체할 수 있어야 함
인터페이스 분리 원칙(Interface Segregation Principle, ISP)	클라이언트가 사용하지 않는 메서드에 의존하지 않아야 함
의존 역전 원칙(Dependency Inversion Principle, DIP)	고수준 모듈은 저수준 모듈에 의존하면 안되며, 추상화에 의존해야 함

모듈 간의 상호 의존 정도

• 다양한 결합으로 모듈을 구성할 수 있음
• 결합도가 낮을수록 품질이 낮아짐
• 결합도가 높을수록 모듈 간의 의존성이 높아져 유지보수성이 낮아짐

종류	설명
자료 결합도(Data Coupling)	모듈 간의 인터페이스가 자료 요소로만 구성될 때의 결합도
스탬프 결합도(Stamp Coupling)	모듈 간의 데이터를 전체를 주고받는 정도
제어 결합도(Control Coupling)	모듈 간의 제어 정보를 주고받는 정도
외부 결합도(Global Coupling)	모듈 간의 전역 변수를 주고받는 정도
내용 결합도(Content Coupling)	모듈 간의 내부 구현을 직접 참조하는 정도

정보 은닉 개념을 확장한 것으로, 명령어나 호출문 등 모듈 내부 요소들이 서로 관련되어 있는 정도

• 다양한 기준으로 모듈을 구성 가능하나 응집도가 강할수록 품질이 높음

종류	설명
기능적 응집도(Functional Cohesion)	모듈 내부의 모든 요소가 하나의 기능을 수행하는 정도
순차적 응집도(Sequential Cohesion)	모듈 내부의 요소가 순차적으로 연결되어 있는 정도 모듈 내 하나의 활동으로 나온 출력 데이터를 그 다음 활동의 입력 데이터로 사용
통신적 응집도(Communicational Cohesion)	모듈 내부의 요소가 동일한 입력이나 출력을 공유하는 정도
절차적 응집도(Procedural Cohesion)	모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성 요소들이 그 기능을 순차 수행하는 정도
시간적 응집도(Temporal Cohesion)	특정 시간에 처리되는 몇 개의 기능을 모아 하나의 모듈로 작성할 경우
논리적 응집도(Logical Cohesion)	유사한 성격을 갖거나
우연적 응집도(Coincidental Cohesion)	모듈 내부의 요소가 무작위로 모여 있는 정도

• 팬 인(Fan In)

  : 어떤 모듈을 제어하는 모듈의 수
  시스템 구조도에서 상위 모듈의 개수(화살표 받는 개수)
• 팬 아웃(Fan Out)

  : 어떤 모듈에 의해 제어되는 모듈의 수
  시스템 구조도에서 하위 모듈의 개수(화살표 보내는 개수)

---

논리의 기술

에 중점을 둔 도형을 이용한 표현 방법.

박스 다이어그램, Chapin 차트라고도 함

• 연속, 선택 및 다중 선택, 반복 등의 제어 논리 구조 표현
• GOTO나 화살표 사용 안함
• 조건이 복합되어 있는 곳의 처리를 시각적으로 명확히 식별
• 선택, 반복 구조를 시각적으로 표현
• 이해하기 쉽고, 코드 변환에 용이

---

여러 프로그램에서 공통으로 사용되는 모듈

• 자주 사용되는 계산식, 사용자 인증 같은 기능을 공통 모듈로 구성
• 재사용성 확보, 중복 개발 회피

명세 기법	설명
정확성	해당 기능이 필요하다는 것을 알 수 있도록 정확히 작성해야 함
명확성	기능이 중의적으로 해석되지 않도록 명확하게 작성되어야 함
완전성	구현을 위해 필요한 모든 것 기술
일관성	공통 기능 간 상호 충돌이 발생하지 않도록 해야 함
추적성	기능에 대한 요구사항의 출처, 관계를 파악할 수 있어야 함

비용과 시간을 절약하기 위해 이미 개발된 기능들을 파악하고 재구성하여 새로운 시스템 또는 기능 개발에 활용하는 것

• 누구나 이해할 수 있고 사용이 가능하도록 사용법 공개
• 재사용되는 대상은 외부 모듈과의 결합도는 낮고, 응집도는 높게 설계

분류	설명
함수와 객체	클래스나 메소드 단위의 소스 코드 재사용
컴포넌트	독립적인 업무 또는 기능을 수행하는 실행 코드 기반 컴포넌트 자체에 대한 수정 없이 인터페이스를 통해 통신
애플리케이션	공통된 기능들을 제공하는 애플리케이션을 재사용

• 결합도는 줄이고 응집도는 높이는 설계
• 모듈의 제어 영역 안에서 그 모듈의 영향 영역 유지
• 복잡도와 중복성을 줄이고 일관성 유지
• 유지보수 용이하게 설계

---

컴퓨터를 이용하여 자료를 처리하는 과정에서 분류, 조합, 집계를 용이하게 하고 특정 자료의 추출을 쉽게 하기 위해 사용하는 기호

• 신속, 정확, 명료해야 함

기능	설명
식별 기능	데이터 간의 성격에 따라 구분 가능함
분류 기능	특정 기준이나 동일한 유형에 따라 그룹화
배열 기능	의미를 부여하여 나열
표준화 기능	일정한 형식으로 표현
간소화 기능	불필요한 정보를 제거하고 필요한 정보만 표현

종류	설명
순차 코드	일정 기준에 따라 차례로 일련번호를 부여하는 방법
블록 코드	공통성이 있는 것끼리 블록으로 구분, 블록 내에서 일련번호 부여
10진 코드	항목을 0~9까지 10진 분할 후 다시 그 각각에 대하여 10진 분할, 반복
그룹 분류 코드	항목을 대분류, 중분류, 소분류로 구분하여 그 안에서 각각 일련번호 부여
연상 코드	항목의 특성을 나타내는 문자나 숫자를 이용하여 부여
표의 숫자 코드	항목의 성질을 그대로 코드에 적용. 길이, 넓이, 부피 등
합성 코드	2개 이상의 코드를 결합하여 부여

---

코드를 작성하는 세부적인 구현 방안 설계 시 참조 가능한 전형적인 해결 방식

• 문제 및 배경, 실제 적용된 사례, 재사용이 가능한 샘플 코드로 구성됨
• 개발 과정 중 문제가 발생했을 때 문제에 해다하는 디자인 패턴을 참조할 수 있음

• 장점
  • 범용적인 코딩 스타일로 구조 파악이 용이
  • 객체지향 설계 및 구현의 생산성 향상
  • 개발자 간의 원할한 의사소통 가능
  • 실제 변경 요청에 대한 유연한 대처 가능
• 단점
  • 초기 투자 비용이 높음
  • 객체지향을 기반으로 한 설계와 구현을 전제로 하기에 다른 패러다임에 적용하기 어려움

객체 생성과 관련된 패턴

패턴	설명
추상 팩토리(Abstract Factory)	인터페이스를 통해 서로 연관된 객체를 생성하는 패턴
빌더(Builder)	작게 분리된 인스턴스를 조합하여 생성
팩토리 메서드(Factory Method)	객체 생성을 서브 클래스로 분리하는 패턴
프로토타입(Prototype)	객체를 복사하여 생성하는 패턴
싱글톤(Singleton)	객체를 하나만 생성하는 패턴

클래스나 객체를 조합해 더 큰 구조를 만드는 패턴

패턴	설명
어댑터(Adapter)	호환성이 없는 클래스들의 인터페이스를 다른 클래스가 이용하도록 변환하는 패턴
브릿지(Bridge)	구현부와 추상부를 분리하여 독립적으로 변형할 수 있게 하는 패턴
컴포지트(Composite)	여러 객체를 가진 복합 객체와 단일 객체를 구분 없이 다루고자 할 때 사용하는 패턴
데코레이터(Decorator)	객체 간의 결합을 통해 능동적으로 기능들을 확정할 수 있는 패턴
퍼사드(Facade)	복잡한 서브시스템을 단순화하여 더 상위에 인터페이스를 구성
플라이웨이트(Flyweight)	객체를 공유하여 메모리 사용량을 줄이는 패턴
프록시(Proxy)	다른 객체에 대한 접근을 제어하는 패턴

객체나 클래스 사이의 알고리즘과 책임 분배에 관련된 패턴

패턴	설명
책임 연쇄(Chain of Responsibility)	요청을 처리할 수 있는 객체를 만날 때까지 객체를 순차적으로 전달하는 패턴
커맨드(Command)	요청을 객체로 캡슐화하여 요청을 매개변수화, 큐나 로그에 저장하거나 되돌릴 수 있도록 하는 패턴
방향자(Interpreter)	문법 규칙을 해석하는 패턴
반복자(Iterator)	컬렉션의 요소를 순차적으로 접근할 수 있는 패턴
중재자(Mediator)	객체 간의 상호작용을 캡슐화하여 객체 간의 직접적인 상호작용을 방지하는 패턴
메멘토(Memento)	객체의 상태를 저장하고 복원하는 패턴
관찰자(Observer)	한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들이 통보받아 자동으로 갱신되는 패턴
상태(State)	객체의 상태에 따라 행동을 변경하는 패턴
전략(Strategy)	객체의 행위를 동적으로 변경할 수 있도록 하는 패턴
템플릿 메서드(Template Method)	알고리즘의 구조를 메서드에 정의하고 하위 클래스에서 알고리즘 구조를 변경하지 않고 알고리즘을 재정의할 수 있도록 하는 패턴
방문자(Visitor)	객체 구조를 변경하지 않고 기능을 추가하는 패턴

---

• 요구사항 검토: 요구사항 명세서를 검토하여 오류를 발견하는 방법

  종류	설명
  동료검토(Peer Review)	팀원들이 서로 요구사항 명세서를 검토
  워크스루(Walkthrough)	요구사항 명세서를 작성한 사람이 요구사항을 설명하고 다른 팀원들이 질문하고 의견을 제시하는 방법
  인스펙션(Inspection)	검토자들이 요구사항 명세서를 검토하고 오류를 찾아내는 방법

• 프로토타이핑: 사용자의 요구사항을 정확히 파악하기 위해 실제 개발될 소프트웨어에 대한 프로토타입을 만들어 최종 결과물 예측
• 테스트 설계: 요구사항은 테스트할 수 있도록 작성되어야 하며, 테스트 케이스를 작성하여 요구사항을 검증
• CASE 도구 활용: 일관성 분석(Consistency Analysis)을 통해 요구사항 변경사항의 추적, 분석, 관리

---

종류	설명
DB Link	DB에서 제공하는 DB Link 객체를 이용하는 방식
API/Open API	송신 시스템의 DB에서 데이터를 읽어와 제공하는 어플리케이션 프로그래밍 인터페이스 프로그램
연계 솔루션	EAI 서버와 송,수신 시스템에 설치되는 클라이언트를 이용하는 방식
Socket	서버는 통신을 위한 소켓을 생성하여 포트를 할당하고 클라이언트는 서버에 접속하여 데이터를 송수신하는 네트워크 기술
웹 서비스	웹 서비스에서 WSDL과 UDDI, SOAP 프로토콜을 이용하여 서비스를 제공하는 방식

---

• 송신 시스템
  : 연계 프로그램으로부터 생성된 데이터를 형식에 맞게 변환 후 송신
• 수신 시스템
  : 수신한 인터페이스 테이블이나 파일을 프로그램이 처리할 수 있는 형식으로 변환 후 연계 프로그램에 반영하는 시스템
• 연계 서버
  : 송신 시스템과 수신 시스템 사이에 위치하여 데이터 송수신 현황을 모니터링하고 관리하는 시스템

---

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

종류	설명
DB(Database)	데이터베이스 서버와 클라이언트 사이에서 데이터베이스 연결을 제공하는 소프트웨어
RPC(Remote Procedure Call)	원격 프로시저 호출을 지원하는 소프트웨어
MOM(Message Oriented Middleware)	메시지 지향 미들웨어로 메시지를 전달하는 소프트웨어
TP Monitor(Transaction Processing Monitor)	트랜잭션 처리를 지원하는 소프트웨어
ORB(Object Request Broker)	객체 지향 시스템에서 객체 간의 통신을 지원하는 소프트웨어
WAS(Web Application Server)	웹 애플리케이션을 개발하고 실행하는 데 필요한 기능을 제공하는 소프트웨어

---

---

1. 빌드 검증
2. 동료 검토
3. 워크 스루
4. 개발자 검토

1. 메소드
2. 클래스
3. 상속성
4. 메시지

1. Builder
2. Visitor
3. Prototype
4. Bridge

1. RPC
2. ORB
3. TP monitor
4. HUB

1. 객체 모형→동적 모형→기능 모형
2. 객체 모형→기능 모형→동적 모형
3. 기능 모형→동적 모형→객체 모형
4. 기능 모형→객체 모형→동적 모형

1. 일반화
2. 추상화
3. 캡슐화
4. 집단화

1. Coad와 Yourdon 방법
2. Booch 방법
3. Jacobson 방법
4. Wirfs-Brocks 방법