[정처기 필기] 과목 1. 소프트웨어 설계
출처 : 이기적 영진닷컴 https://youtu.be/JhKOsZuMDWs?si=tcKH-nfbH1U7qkjm
노랑색은 정처기에서 중요한 파트 표시한것
하늘색은 기술면접에서 중요한 파트 표시한것
혼제되어 있는 것은 어디서나 중요한 것
<소프트웨어 위기>
하드웨어 비용 초과하는 개발 비용 증가
개발 기간 지연
개발 인력 부족 및 인건비 상승
성능 신뢰성 부족
유지보수 어려움, 비용
<소프트웨어 공학 기본 원칙>
현대적인 프로그래밍 기술 계속 적용
높은 신뢰성
소프트웨어 품질 유지를 위해 지속적으로 검증
소프트웨어 개발 사항, 결과에 대한 명확한 기록
<재공학>
분석 → 구성 → 역공학 → 이식
+ 역공학 = 재문서화하여 쓸만한 곳에서 다시 쓴다.
<CASE>
(computer aided software engineering)
소프트웨어 개발 자동화 도구
비용 절약, 개발 기간 단축, 생산성 향상
CASE 주요 기능
- 소프트웨어 생명주기 전 단계의 연결,
- 다양한 소프트웨어 개발 모형 지원
- 그래픽 지원 (시스템 문서화 및 명세화를 위한)
- 과정 자동화
- 오류 검증
- 모델들 사이 모순검사
CASE 분류
- 상위 CASE : 요구분석 및 설계 단계 지원
- 하위 CASE : 실제 코딩, 소스 코드 작성, 테스트, 문서화 과정
- 통합 CASE : 소프트웨어 개발 주기 전체 과정 지원
요구사항 분석을 위한 CASE
- SADT : SoftTech사에서 개발. 구조적 분석 및 설계 도구, 블록 다이어그램 채택
- SREM : TRW사 개발
- PSL/PSA : 미시간 대학 개발
- TAGS : 시스템 공학 방법 응용에 대한 자동 접근 방법
<소프트웨어 생명 주기>
타당성 검토 → 개발 계획 → 요구사항 분석 → 설계 → 구현 → 테스트 → 운용 → 유지보수
<폭포수 모형>
고전적. 거꾸로 안된다. 정확하게 계획하고 빠르게 개발
<나선형 모형 Spiral>
Boehm이 제시, 반복적인 작업 수행하는 점증적 생명주기 모형
계획 수립 → 위험 분석 → 개발 및 검증(프로토타입 개발) → 고객 평가 → (계획 수립부터 반복)
<애자일 모형 Agile Model>
고객 요구사항 변화에 유연하게 대응. 일정 주기 반복하며 개발과정 진행
고객 소통에 초점
<하향식 상향식 설계>
하향식 설계 = 상위에서 시작해서 하위 기능으로 나눠가며 설계
상향식 설계 = 기본적인 컴포넌트 먼저 설계한 다음 상위 수준 컴포넌트 설계
<HIPO>
계층적 입력 처리 출력. 시스템 분석 및 설계 시스템 문서화 용 기법
하향식 소프트웨어 개발을 위한 문서화 도구
보기 쉽고 유지보수 쉽다.
기능과 자료 의존 관계 동시에 표현 가능
차트 = 가시적 도표, 총체적 도표, 세부적 도표
<V-모델>
폭포수 모형에 시스템 검증과 테스트 작업 강조한 모델
+ 인수 테스트 = 고객에게 전달하고 확인받음
<XP(eXtreme Programming)>
= 아주 빠르게 양질의 소프트웨어 개발
XP 5가지 가치
- 의사소통
- 단순성
- Feedback
- 용기 = 고객 요구사항 변화에 능동적으로 대응
- 존중 = 개발 팀원 간의 상호 존중 기본
XP 12가지 실천사항
- Pair Programming = 한사람 개발 한사람 테스트
- Planning Game = 규칙 목표 두고 개발
- Test Driven Development = 단위 테스트부터 작성, 수행하여 기반을 코드
- Whole Team = 고객을 프로젝트 팀원으로 상주
- Continuous Integration = 지속적인 통합
- Design Improvement
- Small Release = 짧은 주기로 실제 사용가능한 것 릴리즈
- Coding Standards = 표준 코딩기법
- Collective Code Ownership = 소스코드는 누구든지 수정가능
- Simple Design = 최대한 간결하게
- System Metaphor
- Sustainable Pace = 너무 과도한 업무 주지 않는다
<효과적인 프로젝트 관리를 위한 3대 요소>
People, Problem, Process (3P)
<Scrum>
=요구사항 빠르게 적용해서 빠르고 정확하게 개발
스크럼 과정 = 스프린트(2~4주 진행)가 반복. 진행사항 확인, 소멸차트 사용
- 제품 책임자 = 개발 의뢰자, 사용자가 담당, 개발 목표에 이해도 높다, 우선순위 갱신, 스프린트부터는 빠진다
- 스크럼 마스터 = 개발팀의 마스터
- 스크럼 팀 = 위의 둘 제외한 모든 팀원, 간단하게 회의 함
<현행 시스템 분석>
- 1단계 : 시스템 구성 파악 - 시스템 기능 파악 - 시스템 인터페이스 현황 파악
- 2단계 : 아키텍처 파악 - 소프트웨어 구성 파악
- 3단계 : 하드웨어 파악 - 네트워크 구성 파악
<시스템 아키텍처>
= 시스템 상위, 하위 시스템이 어떤 관계로 상호작용하는지 각각 동작 원리와 구성을 표현
단위 업무 시스템별로 아키텍처 다른 경우 핵심기간 업무 처리 시스템을 기준으로 한다.
전체 구조, 행위, 어떻게 작동하는지 설명하는 틀
<EAI>
Enterprise Application Integration
기업 어플리케이션 통합
<플랫폼>
= 애플리케이션 작동하게 할 기반. 운영체제
플랫폼 성능 특성 분석에 사용되는 측정 항목
=응답시간(response time), 가용성(availability), 사용률(utilization)
플랫폼 성능 특성 분석 방법
=기능 테스트, 사용자 인터뷰, 문서 점검
<DBMS>
= 데이터베이스 관리, 종속성 중복성 문제 해결
DBMS 분석시 고려사항 = 가용성, 성능, 기술지원, 상호 호환성, 구축 비용
<요구사항>
= 소프트웨어가 문제 해결하기 위해 제공하는 서비스. 정상 운영되는데 필요한 제약조건
- 기능 요구사항 = 시스템이 수행하는 기능, 제공받기 원하는 것, 실제로 어떻게 작동하는지
- 비기능 요구사항 = 동작하기 위한 성능 보안 품질 안정성 등 보조적인 요구사항
장비 구성 요구사항, 성능 요구사항, 인터페이스 데이터 테스트 보안 품질 요구사항, 제약 사항, 프로젝트 관리 요구사항, 프로젝트 지원 요구사항
요구사항 개발 프로세스
= 요구사항 추출 → 요구사항 분석 → 요구사항 명세 → 요구사항 검증 → 요구사항 관리
(추출, 분석, 명세, 검증, 관리)
요구사항 명세 기법
- 정형 명세 기법 = 수학적 기반, 모델 기반, 낮은 이해도
- 비정형 명세 기법 = 상태 기능 객체 중심 명세
요구사항 분석
= 사용자 요구사항 이해하고 문서화(명세화) 하는 활동
분석을 위해 UML,DFD,DD,소단위 명세서, ERD,STD 제어 명세서 등의 도구 이용한다.
- 타당성 조사
- 비용, 일정 제약 설정
- 목표 설정
- 요구사항 정의 문서화
- 요구사항 분석 단계
요구사항 분석에 필요한 기술
- 사용자 의견 청취
- 사용자 인터뷰
- 문서 분석과 중재
- 관찰 및 모델 작성
- 설문 조사로 의견 수렴
요구사항 분석 수행
문제 인식 → 전개 → 평가와 종합 → 검토 → 문서화
요구사항 명세 속성
정확성, 명확성, 완전성, 일관성, 수정 용이성, 추적성
<객체지향 분석의 방법론>
- 럼바우 방법
- 부치 Booch 방법 = 미시적 개발 프로세스와 거시적 개발 프로세스를 모두 사용하는 분석 방법
- Jacobson 방법 = Use Case 강조하여 상조
- Coad와 Yourdon 방법 = E-R 다이어그램을 사용하여 객체 행위 모델링
- Wirfs-Brock 방법 = 분석 설계 구분이 없다.
<럼바우(Rumbaugh)>
- 객체 모델링 = 객체간의 관계 규정, 객체 다이어그램으로 표시
- 동적 모델링 = 상호작용, 동작 순서 등의 상태를 상태 다이어그램으로 표시
- 기능 모델링 = 자료 흐름 표시DFD, 데이터 입력하여 어떤 결과 가져올 수 있을지 표현
<UML>
= 객체지향 모델링 언어. 개발 과정에서 요구사항 이해 쉽도록 모델링
UML 소프트웨어에 대한 관점
- 기능적 관점 = 사용자 측면에서 본 소프트웨어 기능 UseCase Diagram
- 정적 관점 = 객체사이의 구조. 소프트웨어 내부 구성 요소 사이의 구조적 관계 Class diagram
- 동적 관점 = 실제 내부 동작 Sequence Diagram, State Diagram, Activity Diagram
UML 구성 요소 = 사물, 관계, 다이어그램
UML 관계 = 사물 사이의 연관성.
(일반화 관계 자주 나옴!)
다이어그램
=사물과 관계를 도형으로 표현, 시스템을 가시화한 view 제공.
구조적 다이어그램 (정적)
- Class Diagram = 정적 구조로 표현, 객체들이 집합, 요약해서 객체 관계 표시
- Object Diagram = 객체 정보 보여준다
- Composite Structure Diagram
- Deployment Diagram
- Package Diagram
- Component Diagram
행위 다이어그램 (동적, 실제 내부 동작)
- Use Case Diagram
- Activity Diagram
- State diagram
- Interaction Overview Diagram
- Timing Diagram
- Sequence Diagram = 구성=-액터, 객체, 생명선, 실행상자, 메시지
- Communication Diagram
Use Case Diagram
= 사용자가 개발된 시스템으로 할 수 있는 기능. 사용자 관점(view)에서 표현
구성 - 시스템/시스템 범위, 액처, 유스 케이스, 관계
작성 단계 - 액터식별, use case 식별, 관계정의, 구조화
스테레오 타입
= UML에서 제공하는 기본 요소 외에 추가적인 확장 요소 표현 <<>>
UML 접근 제어자
= Public + Private - Protected # Package ~
<UI>
= 편리성 가독성 동선축약
UI 환경 분석
= 사용자 경향 분석, 기능 설계 분석
(기능 조작성 분석, 오류 방지 분석, 최소한 조작으로 업무 처리 가능한 형태 분석, 정보 전달력)
요구사항 요소 = 데이터 요구, 기능요구, 제약사항, 제품 서비스 품질
정황 시나리오 작성 = 개발 모형. 사용자가 어떻게 움직이는지에 대해 육하원칙으로 정리
UI분야
= 표현, 정보제공, 기능 분야
UI설계 원칙
= 직관성, 유효성, 학습성, 유연성
UI설계 지침
사용자 중심 (실사용자 이해를 바탕으로 쉽게 이해하고)
일관성, 단순성, 가시성, 표준화, 접근성, 결과예측 가능
명확성, 오류 발생 해결
UX(User experience)
=사용자가 경험하고 느끼는것
UI설계 단계
- 문제 정의 : 시스템 목적과 해결해야할 문제 정의
- 사용자 모델 정의
- 작업 분석
- 컴퓨터 오브젝트 및 기능 정의
- 사용자 인터페이스 정의
- 디자인 평가 (GOMS, Heuristics…)
UI상세 설계 단계
- UI메뉴 구조 설계
- 내/외부 화면과 폼 설계
- UI검토 수행
UI설계 도구
- 와이어 프레임 = 선으로 대략적 작성
- 목업 = 실물과 흡사한 정적인 모형
- 프로토타입 = 실제 작동하는 모형
- 스토리보드 = 프로세스 등이 모두 포함된 설계 문서
UI프로토타입
= 시제품 제작하여 확인받음
<감성 공학 접근 방법>
1류 : 감성 어휘로 표현
2류 : 생활양식 추가
3류 : 감각척도로 표현
<HCI>
= 인간과 컴퓨터 상호작용 연구하여 인간이 컴퓨터 쉽게 사용할 수 있게 하는것
<감성 공학 요소 기술>
= 기초 기술, 구현기술, 응용기술
<소프트웨어 설계 모델링>
= (상위 하위 설계 구분하는 문제 나옴)
상위 설계
=뼈대 세운다
=아키텍처 설계 -- 데이터 설계 -- 인터페이스 정의 -- 사용자 인터페이스 설계
하위 설계
=상세 설계
=모듈 설계 -- 자료 구조 설계 -- 알고리즘 설계
소프트웨어 설계 대상
구조 모델링 = 컴포넌트(모듈의 집합) 인터페이스 등 구조 모델링
행위 모델링 = 구성요소 기능적 특성 모델링
<소프트웨어 구조도>
- Fan-in 한 모듈 제어하는 상위 모듈 수
- Fan-out 한 모듈이 제어하는 하위 모듈 수
- Depth 깊이
- Width 같은 등급 모듈 수
- Super ordinate 제어하는 모듈
- Subordinate 제어 되는 모듈
Fan in 이 높은 경우 = 재사용 용이, 단일 장애 발생 방지를 위해 중점 관리 필요
Fan out이 높은 경우 = 불필요한 타 모듈 호출 여부 확인
<코드>
코드의 기본 기능 =표준화 기능, 간소화 기능
코드 3대 기능 = 분류,식별,배열 기능
코드 부가적 기능= 암호화, 연상 기능, 오류 검출 기능
코드 설계 목적 및 특성
=고유성, 분류 편리성 등….
코드의 종류
- 순차 코드 = 순서대로 1,2,3…. 일련번호
- 블록 코드 = 공통적인 것 블록으로 구분 후 블록 내 번호 부여
- 그룹 분류식 코드 = 대중소 분류
- 10진 분류 코드 = 도서 분류 코드
- 표의 숫자 코드 = 의미를 가지는 수치를 코드에 적용
- 연상 코드 = 명칭, 약호와 관계된 기호 이용
코드의 오류
- 필사 오류
- 전위 오류
- 이중 오류
- 생략 오류
- 추가 오류
- 임의 오류
<구조적 개발 방법론>
구조적 분석 = 자료 흐름 처리로 일관성 파악, 자료흐름도, 자료사전, 소단위 명세서 사용
구조적 분석 도구
- 자료 흐름도(DFD)
= 입출력 인지하고 작성
process, data flow, data store, terminator
- 소단위 명세서
= 세분화된 자료 흐름도. 최하위 단계 프로세스 처리 절차 설명 (프로세서 명세서) - 자료 사전(DD)
=시스템 자료 명세와 자료 속성 파악하는 도구, 자료 흐름도의 모든 자료 정의 기술
| = | 정의 |
| + | 연결 |
| ( ) | 생략 |
| [ | ] | 선택 |
| { } | 반복 |
| ** | 주석 |
<모듈>
=하나의 기능하는 작은 프로그램(코드의 집합)
재사용 가능, 자체적으로 컴파일 가능
모듈의 독립성 높이기 위해 결합도 약하게, 응집도 강하게, 모듈 크기 작게
결합도(Coupling)
= 두 모듈간의 상호 의존도, 두 모듈의 유사성 정도
결합도는 낮을수록 좋고 모듈 독립성 향상된다
결합도 낮음에서 높은순으로 정리
- 자료 결합도 data coupling = 모듈간 공유할 일 없는
- 스탬프 결합도 stamp = 같은 자료구조
- 제어 결합도 control = 어떤 모듈이 다른 모듈 내부의 논리적인 흐름 제어하기 위해 제어 신호를 이용하여 통신하거나 제어 요소 전달하는 결합도
- 외부 결합도 external = 변수 공통 사용
- 공통 결합도 common = 공유되는 공통 데이터 영역을 여러 모듈이 사용할 때의 결합도
- 내용 결합도 content = 한 모듈이 다른 모듈의 내부 기능 및 그 내부 자료를 직접 참조하거나 수정할 때 결합도
응집도(Cohesion)
=모듈안의 코드들이 얼마나 관련도 높은것들끼리 모여있는지
응집도 높은것은 필요한 요소들이 모여있는것이라 좋음
응집도 강함에서 낮은 순서로
- 기능적 응집도 functional
- 순차적 응집도 sequential
- 교한적 응집도 communicational
- 절차적 응집도 procedural
- 시간적 응집도 temporal
- 논리적 응집도 logical
- 우연적 응집도 coincidental
모듈 vs 컴포넌트
모듈 = 코드의 집합
컴포넌트 = 하나의 기능을하고 더 큰 컴포넌트와 연결된다.
재사용 규모에 따른 구분
- 함수와 객체 = 클래스, 메소드 단위로 소스코드 등을 재사용
- 애플리케이션 = 공통 업무 처리할 수 있게 구현된 어플리케이션 고용하여 재사용
- 컴포넌트 = 자체 수정 없이 인터페이스 통하여 컴포넌트 단위로 재사용
공통 모듈 = 어디서든 공통으로 사용하는 모듈 ex) GPS
<소프트웨어 아키텍처>
=소트프웨어 뼈대 만들기
특성 = 간략성, 추상화, 가시성, 복잡도 관리
- Structure Frame
- Non Structural Frame
아키텍처프레임워크 구성요소
- AD(Architecture Description) = 아키텍처 기록
- 이해관계자(stakeholder)
- 관심사(Concerns)
- 관점(ViewPoint)
소프트웨어 아키텍처 설계 원리
- 단순성, 효율성, 분할 계층화, 추상화, 모듈화
소프트웨어 아키텍처 평가 방법론
- SAAM, ATAM, CBAM
<소프트웨어 아키텍처 패턴>
=아키텍처 설계를 위해 미리 만들어 놓은 패턴, 일반화되고 재사용 가능한 솔루션
- 계층 패턴 = 소프트웨어를 계층 단위로 분할
- MVC 패턴 = model view controller pattern. 모델, 뷰, 컨트롤러로 구성
- 클라이언트 서버 패턴 = 하나의 서버에 다수의 클라이언트
- 파이프 필터(pipe filters)
= 데이터 흐름 생성하고 처리하는 시스템을 위한 구조, 처리과정은 필터 컴포넌트에서 데이터는 파이프를 통해 흐른다. 노드와 간선으로 이루어짐 - Peer to Peer = 동등 연결, 분산 컴퓨팅에 사용
- Broker
- Black Board = 결정적인 해결 전략 존재하지 않는 문제 해결
- Event bus= 이벤트 처리 방식
- Interpreter = 특정 언어로 작성된 프로그램 해석
<객체 지향 설계>
구조적 프로그래밍 = 이해 쉽고 디버깅 쉽다. 한개 입구와 한개 출구
절차적 프로그래밍 = 순서대로 진행, 함수 기반 프로그래밍 (C)
객체지향 프로그래밍 = 주고받는 메시지로 연결 (C#,java...)
객체지향 분석 = 개체는 속성과 메소드로 구성. 개체로 표현(모델링), 효과적인 표현방법
- 클래스 Class = 공통된 속성과 연산을 가지는 객체의 집합.
객체가 가지는 속성과 연산 정의하는 틀.
데이터 추상화 단위, 유사한 객체 묶음의 상위클래스 - 인스턴스 = 클래스에 속한 각 객체. 기능을 하는 실제 주체 (인스턴스화 = 클래스로 새로운 객체 생성)
- 객체 Object = 데이터, 데이터 처리 함수 묶은 소프트웨어 모듈
- 메소드 = 객체의 행위
- 메시지 = 객체간 주고받는 통신
- 상태 = 객체가 가질 수 있는 조건
- 데이터 = 객체가 가진 정보(Attribute, 상태, 변수, 상수, 자료구조)
- 함수 = 객체가 수행하는 기능. 데이터 처리하는 알고리즘 (Method, Service, 연산)
객체지향 5가지 특징
- 캡슐화 = 관련성 높은 데이터와 기능 묶는다, 결합도 낮아지고 재사용 높아진다., 정보은닉 가능
- 정보은닉 = 객체 내부 속성 메소드 숨기고 공개된 인터페이스로만 메시지 주고받으면 된다. side effect줄인다
- 추상화 = 시스템 내 공통 성질 추출한 뒤 추상 클래스 설정. - 기능 추상화, 제어 추상화, 자료 추상화
- 상속성 = 상위 클래스(추상적 성질)의 모든것을 하위클래스(구체적 성질)가 물려받는것
- 다형성 = 객체별로 다른 기능을 가지는 것.
오퍼레이션이나 속성 이름이 하나 이상의 클래스에서 정의되고 각 클래스에서 다른 형태로 구현될 수 있는 개념
객체지향 기법 연관성
= 2개 이상의 객체들이 상호 참조하는 관계
- is member of = 연관화 / 2개이상의 객체가 상호관련
- is instance of = 분류화/동일한 형의 특성 갖는 객체 모아 구성
- is part of = 집단화/관련 객체들을 묶어 하나의 상위 객체 구성
- is a = 일반화/공통 성질로 추상화한 상위 객체 구성
특수화 상세화/상위 객체를 구체화하여 하위 객체 구성
오버로딩, 오버라이딩
- 오버로딩 = 한 클래스에 같은 이름의 메소드 사용
- 오버라이딩 = 상속에서 사용. 덮어쓰기. 하위클래스에서 재정의
| 구분 | 오버로딩 Overloading | 오버라이딩 Overriding |
| 메소드 이름 | 한 클래스 내에서 같다 | 상속 관계의 두 클래스간 같다 |
| 매개변수 개수/매개변수 타입 | 매개 변수 타입 또는 개수가 달라야함 |
반드시 같아야함 |
| 접근 제한 | 무관하다 | 범위 같거나 커야함 |
| 사용 | 같은 이름으로 메소드 중복 정의 | 자식 클래스에서 부모 클래스의 메소드 재정의 |
객체지향 설계 원칙 (SOLID원칙)
=시스템 변경이나 확장에 유연한 시스템 설계를 위한 원칙
- 단일 책임 원칙(SRP) = 객체는 하나의 책임만 가져야한다
- 개방-폐쇄 원칙(OCP) = 확장에는 개방, 수정에는 폐쇄
- 리스코프 치환 원칙(LSP) = 자식 클래스는 최소한 자신의 부모 클래스에서 가능한 행위는 수행할 수 있어야 한다는 원칙. 상속에서 참고하는 원칙
- 인터페이스 분리 원칙(ISP) = 사용하지 않는 인터페이스와 의존 관계 맺거나 영향 받지 않아야 한다
- 의존 역전 원칙(DIP) = 각 객체들 간 의존관계 성립될 때, 추상성 높은 클래스와 의존 관계 맺어야 한다.
<협약에 의한 설계>
= 컴포넌트 설계할 때 클래스에 대한 여러 가정 공유할 수 있도록 명세
선행조건, 결과 조건, 불변 조건 포함
<디자인 패턴>
=설계 형태를 정형화하여 템플릿을 만들어 둠
객체지향 설계 구현 생산성 높인다.
GoF디자인 패턴
1. 생성 패턴
= 객체 생성과 참조과정을 캡슐화.
- Factory Method = 객체 생성을 서브 클래스가 결정
- Singleton = 클래스 내 인스턴스가 하나임을 보장하며 불필요한 메모리 낭비 최소화
- Prototype = 원본 객체 복제
- builder = 인스턴스 조합하여 객체 생성
- Abstraction factory method = 인터페이스 통해 서로 연관되는 객체들의 그룹으로 생성
2. 구조패턴
= 객체 조합하여 더 큰 구조로 만드는 패턴
- Adapter = (원활한 연결) 인터페이스 일치 하지 않을때도 클래스 이용할 수 있게
- Bridge = 구현부에서 추상층 분리, 서로 독립적으로 확장할 수 있게 구성
- Composite = 복합 객체와 단일 객체 구분없이 다루고자 할때 사용
- Decorator = 객체간 결합으로 능동적으로 기능 확장
- Facade = 서브 클래스들 사이의 통합 인터페이스 제공하는 wrapper객체 필요
- Flyweight = 인스턴스 가능한 공유해서 사용, 다수의 유사한 객체 생성에 유용
- Proxy = 접근이 어려운 객체와 여기에 연결하려는 객체 사이에서 인터페이스 역할
3. 행위패턴
=클래스나 객체가 서로 상호작용하는 방법, 책임 분배 방법
- Chain of responsibility = 한 객체가 처리 못하면 다음 객체로 넘어감
- Iterator = 언어에 문법 표현 정의
- Command = 요청을 객체 형태로 캡슐화하여 재이용하거나 취소
- Interpreter = 언어 문법 표현 정의, SQL이나 통신 프로토콜 개발에 사용
- Memento = 객체 내부 상태를 객체화, 되돌리기 가능 Ctrl+Z
- Observer = 한 객체 상태 변하면 상속된 다른 객체들에게 변화된 상태 전달
- State = 객체 상태따라 동일한 동작 다르게 처리, 객체 상태 캡슐화하고 참조
- Strategy = 알고리즘 개별 캡슐화, 상호교환할 수 있게 정의
- visitor = 처리 기능을 별도의 클래스로 구성, 각 클래스를 방문하여 수행
- Template Method = 상위클래스 골격정의, 하위 클래스 세부처리 구체화
- Mediator = 많은 객체 간의 복잡한 상호작용 캡슐화하여 객체로 정의. 객체 사이 의존성, 결합도 감소
<인터페이스>
인터페이스 요구사항 검증 절차 순서
- 검토 계획 수립 → 검토 오류 수정 → 베이스라인 설정
인터페이스 요구사항 검증 방법
- 프로토타이핑
- 테스트 설계 = 미리만든 테스트케이스로 검사
- 요구사항 검토
- 동료 검토 = 요구사항 명세서 동료에게 설명
- 워크스루 = 명세서 미리 배포 → 짧은 검토 회의
- 인스펙션 = 전문가가 검사
인터페이스 대상 식별
- Interface system process = 송신 시스템, 중계 시스템, 수신 시스템
인터페이스 연계 기술
- DB Link
- DB Connection = 웹 어플리케이션 연결
- API = 소스 제공받음
- JDBC = 수신 시스템
- Hyper Link
- Socket = 소켓 생성
- Web service= 프로토콜 이용
- 연계 솔루션 = EAI 어플리케이션 통합
시스템 연계 기술
- API
- WSDL
- UDDI = 비즈니스 목록에 자신 등재하기 위한 확장성 생성 언어
- SOAP = 웹서비스를 실제로 이용하기 위한 객체간의 통신 유형
<미들웨어>
= 클라이언트와 서버간 통신 담당. 중간에서 연결해주는 역할
- 데이터 베이스
- TP-Monitor = 트랜잭션 감시
- ORB = 객체간 메시지 전달
- RPC = 원격 호출
- MOM = 메시지 기반
- WAS = 웹을 통해 어플리케이션 연결 (HTTP를 통해)
- OTM = 객체 트랜잭션 모니터
미들웨어 솔루션 분류
DB 미들웨어(애플리케이션 -TO-데이터방식)
ODBC, IDAP, DRDA, OLEDB