정보처리기사 2020 필기 1,2회 01~20번 문제
Technique정보처리기사 2020 필기 1,2회 01~20번 문제 해설
- 수제비 2020 정보처리기사 필기 도서와 수제비 카페 자료를 통해 작성
1. GoF(Gang of Four)의 디자인 패턴(Design Pattern)
어떤 분야에서 반복적으로 나타나는 문제점들에 대해 전문가들의 경험을 정리하여 해결 방안을 제시한 패턴
목적
- 축적된 경험: 전문가들의 설계 노하우를 이해하고 적용
- 좋은 SW: 확장성, 재사용성, 유지보수 성이 좋은 SW 설계
- 고품질 SW: 안정적이고 고품질 개발을 위한 설계 탬플릿
특징
- 확장성: 필요에 따른 소프트웨어의 손쉬운 Scale UP/Down
- 재사용성: 재사용을 가능하게 하는 설계를 선택. 재사용을 방해하는 설계 배제
- 유지보수성: 프로그램의 확장성 및 재사용성을 통하여 유지보수에 활용
| 범위 \ 목적 | 생성 | 구조 | 행동 |
|---|---|---|---|
| 클래스 | 팩토리 메서드(Factory Method) | 어댑터(Adapter) | 인터프리터(Interpreter) 템플릿 메서드(Template Method) |
| 객체 | 추상팩토리(Abstract Factory) 빌더(Builder) 프로토타입(Prototype) 싱글톤(Singleton) | 브릿지(Bridge) 컴포지트(Composite) 데코레이터(Decorator) 퍼사드(Facade) 플라이웨이트(Flyweight) 프록시(Proxy) | 책임 연쇄(Chain of Responsibility) 커맨드(Command) 이터레이터(Iterator) 미디에이터(Mediator) 메멘토(Memento) 옵저버(Observer) 상태(State) 전략(Strategy) 비지터(Visitor) |
- 팩토리 메서드(Factory Method): 객체를 생성하기 위한 인터페이스를 정의하여 어떤 클래스가 인스턴스화 될 것인지는 서브 클래스가 결정하도록 함. Virtual-Constructor 패턴이라고도 함
| 구성요소 | 설명 |
|---|---|
| 패턴의 이름과 구분 | 디자인 패턴을 부를 때 사용하는 이름과 디자인 패턴의 유형 |
| 문제 및 배경 | 디자인 패턴이 사용되는 분야 또는 배경, 해결하는 문제를 의미 |
| 솔루션 | 디자인 패턴을 이루는 요소들, 관계, 협동(Collaboration) 과정 |
| 사례 | 디자인 패턴의 간단한 적용 사례 |
| 결과 | 디자인 패턴을 사용하면 얻게 되는 이점이나 영향 |
| 샘플 코드 | 디자인 패턴이 적용된 원시코드 |
2,4,14. 객체지향(Object Oriented)
| 기법 | 설명 |
|---|---|
| 클래스 (Class) | 객체지향 프로그램에서 데이터를 추상화하는 단위 하나 이상의 유사한 객체들을 묶어서 하나의 공통된 특성을 표현 같은 종류의 집단에 속하는 속성과 행위를 정의 속성은 변수의 형태로, 행위는 메서드 형태로 선언 객체지향 프로그램의 기본적인 사용자 정의 데이터형 |
| 객체 (Object) | 객체의 행위는 클래스에 정의된 행위에 대한 정의를 공유함으로써 메모리를 경제적으로 사용 객체마다 각각의 상태와 식별성을 가짐 |
| 메서드 (Method) | 클래스로부터 생성된 객체를 사용하는 방법 전통적 시스템의 함수(Function) 또는 프로시저(Procedure)에 해당하는 연산 기능 |
| 메시지 (Message) | 객체에게 어떤 행위를 하도록 지시하기 위한 방법 |
| 인스턴스 (Instance) | 객체지향 기법에서 클래스에 속한 각각의 객체 실제로 메모리상에 할당 |
| 속성 (Property) | 한 클래스 내에 속한 객체들이 가지고 있는 데이터 값들을 단위별로 정의 성질, 분류, 식별, 수량, 현재 상태 등에 대한 표현 값 |
| 기법 | 설명 |
|---|---|
| Encapsulation (캡슐화) | 서로 관련성이 많은 데이터와 이와 관련된 함수들을 한 묶음으로 처리하는 기법 결합도가 낮아지고 재사용이 용이 인터페이스가 단순해짐 정보은닉과 관계가 깊음 변경 발생 시 오류의 파급효과가 적음 |
| Inheritance (상속성) | 상위 클래스의 속성과 메서드를 하위 클래스에서 재정의 없이 물려받아 사용하는 기법 |
| Polymorphism (다형성) | 하나의 메시지에 대해 각 객체가 가지고 있는 고유한 방법으로 응답할 수 있는 능력 오버로딩, 오버라이딩이 대표적 |
| Abstraction (추상화) | 공통 성질을 추출하여 추상 클래스를 설정하는 기법 기능 추상화, 자료 추상화, 제어 추상화 |
| Information Hiding (정보은닉) | 코드 내부 데이터와 메서드를 숨기고 공개 인터페이스를 통해서만 접근이 가능하도록 하는 코드 보안 기술 특정 모듈의 정보를 필요로 하지 않는 모듈이 접근하지 못하도록 세부 내용을 은폐하고 설계하는 기법 다른 모듈의 접근을 막고, 세부 내용을 은폐함으로써 고려되지 않은 영향(Side-Effect)들을 최소화함 |
| 방법론 | 설명 | 특징 |
|---|---|---|
| Rumbaugh | OMT(Object Modeling Technology) 가장 일반적으로 사용되는 방법 객체지향 분석, 시스템 설계, 오브젝트 설계, 구현의 4단계 구성 분석 활동을 '객체 모델, 동적 모델, 기능 모델'로 나누어 수행하는 방법 - 객체 모델링: 시스템의 정적 구조 표현 - 동적 모델링: 객체의 제어 흐름/상호 반응 표현 - 기능 모델링: 데이터 값의 변화 과정 표현 - 절차: 객체 모형 → 동적 모형 → 기능 모형 | 복잡한 대형 프로젝트에 유용 기업 업무의 모델링 편리 및 사용자와 의사소통 편리 |
| Booch | OOD(Object Oriented Design)로 '설계 부분만 존재' '미시적(Micro)' 개발 프로세스와 '거시적(Macro)' 개발 프로세스를 모두 사용하는 분석 방법 | 분석과 설계를 분리할 수 없음 분석하는 데 이용된 객체 모델의 설계시 적용 |
| Jacobson | OOSE(Object Oriented Software Engineering) 'Use Case'를 강조하여 사용하는 분석 방법 Use Case에 의한 접근 방법으로 Use Case를 모든 모델의 근간으로 활용 | 분석, 설계, 구현 단계로 구성 기능적 요구사항 중심의 시스템 |
| Wirfs-Brock | 분석과 설계간의 구분이 없고, 고객 '명세서를 평가'해서 설계 작업까지 연속적으로 수행하는 기법 | |
| Coad와 Yourdon | E-R 다이어그램을 사용하여 객체의 행위를 모델링하며, 객체 식별, 구조 식별, 주체 정의, 속성 및 관계 정의, 서비스 정의 등의 과정으로 구성 |
| 설계 원칙 | 설명 |
|---|---|
| 단일 책임의 원칙 | 모든 클래스는 하나의 책임만 가지며 클래스는 그 책임을 완전히 캡슐화 해야 한다는 원칙 |
| 개방 폐쇄의 원칙 | 소프트웨어 개체(클래스, 모듈, 함수 등)는 확장에 대해 열려 있고 수정에 대해서는 닫혀 있어야 한다는 원칙 |
| 리스코프 치환의 원칙 | 상위 타입의 객체를 하위 타입의 객체로 치환 가능하다는 원칙 |
| 인터페이스 분리의 원칙 | 구현체 스스로가 사용하지 않는 기능에 영향 받지 않아야 한다는 원칙 자신이 사용하지 않는 메서드와 의존관계를 맺으면 안됨 |
| 의존성 역전의 원칙 | 고수준 모듈은 저수준 모듈에 직접 의존해서는 안된다는 원칙 |
3. 관계성(Relationship)
객체와 클래스 사이 또는 클래스들 사이의 상호 참조하는 관계를 표현하는 방식
| 관계성 | 용어 | 설명 |
|---|---|---|
| is member of | 연관성(Association) | 클래스와 객체의 참조 및 이용관계 같은 계층에 속하는 클래스들 사이의 상호 의존성을 보여주는 비계층적 관계성을 나타냄 |
| is part of
part-whole | 집단화(Aggregation) | 객체 간의 구조적인 집약관계
하나의 클래스가 여러 개의 다른 클래스들로 구성되는 is part of 관계를 나타냄 서로 관련 있는 여러 개의 객체를 묶어 한 개의 상위 객체를 만든다 일반화와 달리 상위 클래스의 성질들이 하위 클래스로 상속되지는 않음 |
| is a | 일반화(Generalization) 특수화(Specialization) | 일반화: 클래스들 간의 개념적인 포함 관계. 상위 클래스의 특성을 하위 클래스가 상속받는다 특수화: 상위 클래스의 특성들을 상속받으면서 하위 클래스에서 나름대로 수정을 가하고 자기 자신의 고유한 특성을 갖는 관계 |
5. 코드 설계
| 종류 | 설명 |
|---|---|
| 연상 코드 | 코드화 대상 항목의 명칭이나 약호와 관계있는 숫자나 문자 기호를 이용하여 코드를 부여하는 방법 |
| 블록 코드 | 코드와 대상 항목 중에서 공통성이 있는 것끼리 블록으로 구분하고 각 블록 내에서 일련번호를 부여하는 방법으로 구분 코드라고도 한다. |
| 순차 코드 | 자료의 발생순서, 크기 순서 등 일정 기준에 따라서 최초의 자료부터 차례로 일정한 일련번호를 부여하는 방법 순서 코드 또는 일련 번호 코드라고 한다. |
| 표의 숫자 코드 | 코드와 대상 항목의 성질, 즉 길이, 넓이, 부피, 높이 등의 물리적 수치를 그대로 코드에 적용시키는 방법 유효숫자 코드라고도 한다 |
6. 플랫폼
| 항목 | 설명 |
|---|---|
| 처리량 (Throughput) | 주어진 시간에 처리할 수 있는 처리 건수, 단위 시간당 처리한 건수 |
| 응답시간 (Response Time) | 사용자 요청을 전달한 시간부터 요청이 응답을 받을 때까지 소요되는 시간 |
| 경과시간 (Turnaround Time) | 사용자가 요구를 입력한 시점부터 요청을 처리한 후 그 결과가 완료될 때까지 걸리는 시간 |
| 자원 사용률 (Resource Usage) | 사용자 요청을 처리하는 동안 사용하는 CPU 사용량, 메모리 사용량, 네트워크 사용량 |
- 가용성 (Availability), 사용률 (Utilization)
7. 자료 사전(DD, Data Dictionary)
- 자료 요소, 자료 요소들의 집합, 자료의 흐름, 자료 저장소의 의미와 그들간의 관계, 관계값, 범위, 단위들을 구체적으로 명시하는 사전
- 파일 혹은 데이터베이스에 있는 자료에 대한 자료 또는 각 자료 항목에 주어진 이름과 길이 그리고 서술과 같은 데이터를 포함하는 참조를 위한 작업
| 의미 | 기호(Symbol) | 설명 |
|---|---|---|
| 정의 (is composed of) | = | 주석을 사용하여 의미를 기술 자료흐름과 자료저장소에 대한 구성내역을 설명 자료원소에 대하여 값이나 단위를 나타냄 |
| 반복 (iteration of) | { } | 여러 번 반복되는 자료항목은 { }안에 기술 { }의 좌측에는 최소 반복 횟수를, 우측에는 최대 반복 횟수를 기록 반복횟수를 기록하지 않을 때는 기본값으로 최소는 0, 최대는 무한대를 나타냄 |
| 선택/택일 (choose only one of) | [ ] | [ | ]는 | 로 분리된 항목들 중 하나가 선택된다는 것을 표시 |
| 생략가능 (optional) | ( ) | 괄호 안의 자료항목이 기술될 수도, 생략될 수도 있음 |
| 주석 (comment) | ** | 자료의 설명 |
| 구성 (and, along with) | + | 자료의 연결 ex) 정의와 구성: 학생증 = 학과 + 학년 + 학번 + 이름 |
8,18. 요구공학(Requirements Engineering)
사용자의 요구가 반영된 시스템을 개발하기 위하여 사용자 요구사항에 대한 추출, 분석, 명세, 검증, 관리하는 구조화된 활동
| 프로세스 | 내용 | 기법/산출물 |
|---|---|---|
| 요구사항 추출/도출 (Elicitation) | 요구사항이 어디에 있고, 어떻게 수집할 것인지 파악하는 단계 고객으로부터 제시되는 추상적 요구에 대해 관련 정보를 식별하고 수집하여 구체적인 요구사항으로 표현하는 활동 - 고객 분석, 조직 환경 분석, 후보 요구사항 분류, 후보 요구사항 정제, 요구사항 소스 관리 | 인터뷰 브레인스토밍 델파이 기법 롤 플레이 워크숍 프로토타입 설문지 |
| 요구사항 분석 (Analysis) | 상충되는 요구사항을 해결하고, 소프트웨어의 범위 파악, 소프트웨어가 환경과 어떻게 상호 작용하는지 이해하는 단계 추출된 요구사항에 대해 충돌, 중복, 누락 등의 분석을 통해 완전성과 일관성을 확보하는 활동 - 후보 요구사항 모델링, 요구사항의 우선순위 부여, 해당 릴리즈에 수행할 요구사항 선정, 요구사항 협의 | 유스케이스 기반 분석 (UML, 모델링) |
| 요구사항 명세 (Specification) | 체계적으로 검토, 평가, 승인될 수 있는 문서를 작성하는 단계 동의한 요구사항을 하나 이상의 형태로 저장하여 정형화된 요구사항을 생성하는 활동 - 요구사항 명세 기준 정의, 요구사항 명세서 작성, 요구사항 추적 관련 정보 저장 | 요구사항 명세서 |
| 요구사항 검증/확인 (Validation) | 요구사항 문서가 표준에 적합하고 이해 가능하며 일관성이 있고 완전한지 검증하는 단계 요구사항 명세서에 사용자의 요구가 올바르게 기술되었는지에 대해 검토하고 베이스라인으로 설정하는 활동 - 요구사항 명세서 검토, 요구사항 용어 검증, 요구사항 베이스라인 수립 | 베이스라인 수립 요구사항 추적표 |
- 인터뷰(Interview): 이해관계자와 직접 대화를 통해 정보를 구하는 공식적, 비공식적 정보 수집 방법
- 델파이 기법(Delphi Method): 전문가의 경험적 지식을 통한 문제 해결 및 미래예측을 위한 기법
- 롤 플레이(Role Playing): 현실에 일어나는 장면을 설정하고 여러 사람이 각자가 맡은 역을 연기하여 요구사항을 분석하여 수집하는 방법
- UML(Unified Modeling Language): 객체지향 소프트웨어 개발과정에서 산출물을 명세화, 시각화, 문서화할 시 사용되는 모델링 기술과 방법론을 통합해 만든 표준화된 범용 모델링 언어
- 모델링(Modeling): 실세계의 물리현상을 특정한 목적에 대응하여 이용하기 쉬운 형식으로 표현하는 기법
- 요구사항 명세서(Requirement Specification): 소프트웨어 개발 프로세스의 시작인 소프트웨어의 요구사항을 분석하고 정의하는 단계에서 작성되는 최종 산출물
- 베이스라인(Baseline): 생명주기 내에서 공학적, 관리적, 획득적 측면을 고려하여 정한 하나의 분기점
- 요구사항 추적표: 요구사항 정의서를 기본으로 개발단계별 최종 산출물이 어떻게 반영되고, 변경되었는지 확인이 가능한 문서
| 유형 | 설명 |
|---|---|
| 워크스루 (Walk Through) | 검토 자료를 회의 전에 배포해서 사전검토한 후, 짧은 시간 동안 회의를 진행하는 형태 리뷰를 통해 오류를 검출하고 문서화하며 오류를 조기에 검출하는데 목적을 둔 검증 기법 |
| 동료검토 (Peer Review) | 2~3명이 진행하는 리뷰의 형태 요구사항 명세서 작성자가 요구사항 명세서를 설명하고 이해관계자들이 설명을 들으면서 결함을 발견하는 형태로 진행 |
| 인스펙션 (Inspection) | 소프트웨어 요구, 설계, 원시 코드 등의 저작자 외의 다른 전문가 또는 팀이 검사하여 오류를 찾아내는 공식적 검토 방법 |
| 구분 | 설명 |
|---|---|
| 프로토타이핑 활용 | 개발할 시스템에 대한 주요 기능이나 일부분을 약식으로 개발하여 최종 사용자나 고객을 대상으로 시연하면서 시스템이 작동하는 모습을 경험할 수 있게 하고 요구사항을 확인 |
| 테스트 케이스 활용 | 요구사항은 테스트할 수 있도록 작성되어야 함 이를 위해 테스트 케이스를 생성하여 추후 요구사항이 현실적으로 테스트 가능한지를 검토 |
| CASE 도구 활용 | 구조화된 요구사항 명세서에 대해서는 자동화된 일관성 분석을 제공하는 CASE 도구 활용 가능 대규모 개발 프로젝트에서는 다양한 이해관계자들이 요구사항 명세서 검토가 필요하기 때문에, 요구사항 명세서에 대한 형상 관리 수행이 가능한 CASE 도구 이용 |
9. CASE (Computer Aided Software Engineering, 분석 자동화 도구)
소프트웨어 생명주기(S/W Life Cycle)의 전체 단계를 연결해주고 자동화해주는 통합된 도구
소프트웨어, 하드웨어, 데이터베이스, 테스트 등을 통합하여 소프트웨어를 개발하는 환경을 조성
요구사항을 자동으로 분석하고, 요구사항 분석 명세서를 기술
다양한 소프트웨어 개발 모형 지원
그래픽 지원
- 소프트웨어 개발 과정의 일부 또는 전체를 자동화하기 위한 도구
- 표준화된 개발 환경 구축 및 문서 자동화 기능을 제공
- 작업 과정 및 데이터 공유를 통해 작업자 간의 커뮤니케이션을 증대
| 분류 | 설명 |
|---|---|
| 상위 CASE (Upper CASE) | 계획수립, 요구분석, 기본설계 단계를 다이어그램으로 표현 모델들 사이의 모순 검사 지원 모델의 오류 검증 지원 자료흐름도 작성 지원 |
| 중간 case (Middle CASE) | 상세 설계 작업 지원 화면 출력 등의 작성 지원 |
| 하위 CASE (Lower CASE) | 시스템 명세서 생성 지원 소스 코드 생성 지원 |
10. 애자일(Agile) 방법론
- 개인과 상호 작용 / 변화에 대응 / 동작하는 소프트웨어 / 고객과 협력
- 소프트웨어가 잘 실행되는 데 가치를 둠
- 기능 중심 개발
| 종류 | 내용 |
|---|---|
| XP (eXtreme Programming) | 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론 5가지 가치: 용기(Courage), 단순성(Simplicity), 의사소통(Communication), 피드백(Feedback), 존중(Respect) |
| 스크럼 (SCRUM) | 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론 - 스크럼 미팅(Scrum Meeting)/데일리 미팅: 매일 15분 정도 미팅으로 To-Do List 계획 수립 - 스프린트(Sprint): 2~4주의 짧은 개발 기간으로 반복적 수행으로 개발품질 향상 |
| 린 (LEAN) | 낭비 요소를 제거하여 품질을 향상시킨 방법론 7가지 원칙: 낭비제거, 품질 내재화, 지식 창출, 늦은 확정, 빠른 인도, 사람 존중, 전체 최적화 |
11. DBMS(Database Management System)
데이터베이스(DB: Database)라는 데이터의 집합을 만들고, 저장 및 관리할 수 있는 기능들을 제공하는 응용 프로그램
| 고려사항 | 설명 |
|---|---|
| 가용성 | 장기간 시스템을 운영할 때 장애 발생 가능성 백업 및 복구 편의성 DBMS 이중화 및 복제 지원 |
| 성능 | 대규모 데이터 처리 성능 대량 거래 처리 성능 다양한 튜닝 옵션 지원 여부 비용 기반 최적화 지원 및 설정의 최소화 |
| 상호 호환성 | 설치 가능한 운영체제 종류 다양한 운영체제에서 지원되는 JDBC, ODBC |
| 고려사항 | 설명 |
|---|---|
| 기술 지원 | 공급 업체들의 안정적인 기술 지원 다수의 사용자 간의 정보 공유 오픈 소스 여부 |
| 구축 비용 | 라이선스 정책 및 비용 유지 및 관리 비용 |
12. HIPO(Hierarchy Input Process Output)
시스템의 분석 및 설계나 문서화할 때 사용하는 기법
시스템 실행과정인 입력, 처리, 출력의 기능을 나타냄
- 기본 시스템 모델은 입력, 처리, 출력으로 구성되며, 하향식 소프트웨어 개발을 위한 문서화 도구
- 체계적인 문서 관리가 가능
- 기호, 도표 등을 사용해서 가시성이 있고 이해가 쉬움
- 기능과 자료의 의존 관계를 동시에 표현 가능
- 변경, 유지보수가 용이
- 시스템의 기능을 고유 모듈로 분할하여 이들간의 인터페이스를 계층 구조로 표현한 것을 HIPO CHART라고 함
| 명칭1 | 명칭2 | 설명 |
|---|---|---|
| 가시적 도표 (Virtual Table of Contents) | 도식 목차 | 시스템의 전체적인 기능과 흐름을 보여주는 계층(Tree) 구조도 |
| 총체적 도표 (Overview Diagram) | 총괄도표 개요도표 | 프로그램을 구성하는 기능을 기술한 것 입력, 처리, 출력에 대한 전반적인 정보를 제공하는 도표 |
| 세부적 도표 (Detail Diagram) | 상세 도표 | 총체적 도표에 표시된 기능을 구성하는 기본 요소들을 상세히 기술하는 도표 |
13. UI(User Interface)
| 설계 원칙 | 설명 | 부특성 |
|---|---|---|
| 직관성 (Intuitiveness) | 누구나 쉽게 이해하고, 쉽게 사용할 수 있어야 함 | 쉬운 검색 쉬운 사용성 일관성 |
| 유효성 (Efficiency) | 정확하고 완벽하게 사용자의 목표가 달성될 수 있도록 제작 | 쉬운 오류 처리 및 복구 |
| 학습성 (Learnability) | 초보와 숙련자 모두가 쉽게 배우고 사용할 수 있게 제작 | 쉽게 학습 쉬운 접근 쉽게 기억 |
| 유연성 (Flexibility) | 사용자의 인터랙션을 최대한 포용하고, 실수를 방지할 수 있도록 제작 | 오류 예방 실수 포용 오류 감지 |
15. 데이터 흐름도(DFD: Data Flow Diagram)
데이터가 각 프로세스를 따라 흐르면서 변환되는 모습을 나타낸 그림
시스템 분석과 설계에서 매우 유용하게 사용되는 다이어그램
시스템 모델링 도구로서 가장 보편적으로 사용
데이터에 비해 기능이 매우 복잡하고 중요할 경우에 매우 유용하게 사용 가능
- 그림으로 표현: 프로세스, 데이터 흐름, 데이터 저장소, 외부 엔티티 등으로 이루어지는 그림으로 표현
- 데이터(data)의 흐름에 중심을 두는 분석용 도구
- 제어(control)의 흐름은 중요하지 않다
| 요소 | 설명 | 표시 |
|---|---|---|
| Process (프로세스) | 입력된 데이터를 원하는 형태로 변환하여 출력하기 위한 과정 | 원 ○ |
| Data Flow (데이터 흐름) | 구성요소(프로세스, 데이터 저장소, 외부 엔티티)들 간의 오가는 데이터 흐름을 나타냄 | 화살표 → |
| Data Store (데이터 저장소) | 데이터가 저장되어 있는 장소 평행성 안에 데이터 저장소의 이름을 기입 | 평행선 = |
| External Entity (외부 엔티티) | 프로세스 처리 과정에서 데이터가 발생하는 시작과 종료를 나타냄 사각형 안에 외부 엔티티 이름을 기입 Terminator 라도고 한다. | 사각형 □ |
16,20. UML (Unified Modeling Language)
객체지향 소프트웨어 개발과정에서 산출물을 명세화, 시각화, 문서화할 시 사용되는 모델링 기술과 방법론을 통합해 만든 표준화된 범용 모델링 언어
| 구성요소 | 내용 |
|---|---|
| Things (사물) | 추상적인 개념 주제를 나타내는 요소 단어 관점에서 '명사' 또는 '동사'를 의미 |
| Relationships (관계) | 사물의 의미를 확장하고 명확히 하는 요소 사물과 사물을 연결하여 관계를 표현하는 요소 단어 관점에서 '형용사' 또는 '부사'를 의미 |
| Diagrams (다이어그램) | 사물과 관계를 모아 그림으로 표현한 형태 형식과 목적에 따라 9가지로 정의 |
| 다이어그램 | 설명 |
|---|---|
| Usecase (유스케이스) | 사용자 관점에서 시스템의 활동을 분석 유스케이스는 시스템의 기능적 요구 정의 |
| 다이어그램 | 설명 |
|---|---|
| Class (클래스) | 시스템 내 클래스의 정적 구조를 표현 속성(Attribute)과 동작(Behavior)으로 구성 |
| Object (객체) | 객체 인스턴스를 나타내는 대신 실제 클래스를 사용 연관된 모든 인스턴스를 표현 |
| Component (컴포넌트) | 코드 컴포넌트 기반의 물리적 구조 표현 실질적 프로그래밍 작업에 사용 |
| Deployment (배포) | 컴포넌트 사이의 종속성을 표현 |
- 그외: Composite, Structure, Package
| 다이어그램 | 설명 |
|---|---|
| State (상태) | 모든 가능한 상태와 전이를 표현 진입 조건, 탈출 조건, 상태 전이 등 기술 |
| Sequence (시퀀스) | 객체 간 상호작용을 메시지 흐름으로 표현 객체 사이 메시지를 보내는 시간을 표현 |
| Collaboration (협업) | 객체 간 연관성을 표현 |
| Activity (활동) | 활동의 순서대로 흐름을 표현 |
- 그외: Use case, Communication, Timing
| 유형 | 설명 |
|---|---|
| <<include>> | 하나의 유스케이스가 어떤 시점에 반드시 다른 유스케이스를 실행하는 포함 관계 반드시 실행 |
| <<extend>> | 하나의 유스케이스가 어떤 시점에 다른 유스케이스를 실행할 수도 있고 그렇지 않을 수도 있는 확장 단계 |
| <<interface>> | 모든 메서드가 추상 메서드이며 바로 인스턴스를 만들 수 없는 클래스 추상 메서드와 상수만으로 구성된 클래스 |
| <<entity>> | 일반적으로 정보 또는 오래 지속되는 연관된 행위를 형상화하는 클래스 유스케이스 처리 흐름이 수행되는 과정에서 기억 장치에 저장되어야 할 정보를 표현하는 클래스 |
| <<boundary>> | 시스템과 외부와의 경계에 걸쳐 있는 클래스 시스템 주변 환경과 시스템 내부간의 커뮤니케이션을 담당 |
| <<control>> | 어떤 특정 객체에 연간되지 않은 기능을 모델링, 여러 Entity 클래스의 오퍼레이션과 계산 수행, Boundary 클래스로의 결과 리턴 등의 Behavior 들로 구성된 기능 |
| <<enumeration>> | 열거형 타입 클래스 |
- '<< >>' 길러멧(guillemet) 기호를 사용하여 표현
| 관계 | 설명 | 표기법 |
|---|---|---|
| Generalization (일반화 관계) | 자식이 부모의 속성을 물려받음 상위 개념과 하위 개념의 관계를 나타냄 보다 일반적인 개념을 상위(부모), 보다 구체적인 개념을 하위(자식)이라고 함 객체지향 개념에서는 상속관계라고 함 한 클래스가 다른 클래스를 포함하는 상위 개념일 때 UML에서는 일반화 관계로 모델링 | ―――▷ |
| Aggregation (집합 관계) | 두 클래스가 연관관계를 가
지고 있으면서 전체/부분관계 전체 클래스 소멸 시 부분 클래 스는 사용가능 | ―――◇ |
| Composition (복합 연관 관계) | 집합 관계의 특수한 형태 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계를 표현 포함되는 쪽(부분)에서 포함하는 쪽(전체)으로 속이 채워진 마름모를 연결하여 표현 전체 클래스 소멸 시 부분 클래스도 소멸 | ―――◆ |
| Association (연관 관계) | 양방향 연관 관계 방향성 없는 실선 표기 상호 인지 다중성을 가짐(선 위에 가질 수 있는 객체 수 정의) 예) 1..*, 2..7, 1 | ――― |
| Direct (직접 연관 관계) | 단방향 연관 관계 참조하는 측만 인지 참조하는 쪽에서 참조되는 쪽으로 화살표를 연결하여 표현 다중성을 가짐(선 위에 가질 수 있는 객체 수 정의) 예) 1..*, 2..7, 1 | ―――＞ |
| Dependency (의존 관계) | 한 클래스가 변경되었을 때
이것을 사용하는 다른 클래스
에 영향이 미치는 관계
화살표는 의존하는 객체(사 물)를 향함 한 클래스의 메소드가 다른 클래스의 객체를 인자로 받아 사용(일반적) | - - - - - -＞ |
| Extend (확장 의존 관계) | 클래스 변화가 타클래스에 영향 참조를 유지하지 않음 선택적 확장하는 관계 | <<Extend>> - - - - - -＞ |
| Include (포함 의존 관계) | 클래스 변화가 타클래스에 영향 참조를 유지하지 않음 반드시 포함하는 관계 | <<include>>
- - - - - -＞ |
17. 미들웨어
클라이언트와 서버 간의 통신을 담당하는 시스템 소프트웨어
| 유형 | 설명 |
|---|---|
| RPC (Remote Procedure Call, 원격 프로시저 호출) | 응용 프로그램의 프로시저를 사용하여 원격 프로시저를 로컬 프로시저처럼 호출하는 방식의 미들웨어 |
| ORB (Object Request Brokers, 객체 기반) | 코바(CORBA) 표준 스펜을 구현한 객체지향 미들웨어 각기 다양한 기반으로 구축된 컴퓨터 간의 프로그램과 데이터의 교환 및 변환이 편리하게 이루어질 수 있도록 지원 |
| TP Monitor (Transaction Processing Monitor, 트랜잭션 처리 모니터) | 트랜잭션이 올바르게 처리되고 있는지 데이터를 감시하고 제어 분산 환경의 핵심 기술인 분산 트랜잭션을 처리하기 위한 미들웨어 주로 사용자가 많고 안정적이면서도 즉각적인 처리가 필요한 업무 프로그램의 개발에 많이 사용 |
| WAS (Web Application Server) | 웹 환경을 구현하기 위한 미들웨어 HTTP 세션 처리를 위한 웹 서버 기능뿐만 아니라 민감한 기업 업무까지 자바, 컴포넌트 기반으로 구현 가능 서버 계층에서 애플리케이션이 동작할 수 있는 환경을 제공하고 안정적인 트랜잭션 처리와 관리, 다른 이기종 시스템과의 애플리케이션 연동을 지원하는 미들웨어 |
| DB 미들웨어 | DB 솔루션 업체에서 제공하는 애플리케이션과 DB간에 통신을 원활하게 하는 것을 목적으로 하는 미들웨어 |
| MOM (Message-Oriented Middleware, 메시지 지향 미들웨어) | 메시지 기반의 비동기형 메시지 전달 방식 미들웨어 서로 다른 이기종 분산 DB 시스템의 데이터 동기를 위하여 주로 사용 |
| Legacyware (레거시웨어) | 기존의 애플리케이션이나 DB 기반에 새로운 업데이트된 기능을 덧붙이고자 할 때 사용되는 미들웨어 |
19. 공통 모듈 설계
전체 프로그램의 기능 중 특정 기능을 처리할 수 있는 실행 코드
여러 기능 및 프로그램에서 공통으로 사용할 수 있는 모듈
자체적으로 컴파일(Compile)이 가능하고, 다른 포로그램에서 재사용이 가능
| 원칙 | 설명 |
|---|---|
| Correctness (정확성) | 해당 기능이 실제 시스템 구현 시 필요한지 아닌지를 알 수 있도록 정확하게 작성 |
| Clarity (명확성) | 해당 기능에 대해 일관되게 이해되고 한 가지로 해석될 수있도록 작성 |
| Completeness (완전성) | 시스템이 구현될 때 필요하고 요구되는 모든 것을 기술 |
| Consistency (일관성) | 공통 기능 간에 상호 충돌이 없도록 작성 |
| Traceability (추적성) | 공통 기능에 대한 요구사항 출처와 관련 시스템 등의 유기적 관계에 대한 식별이 가능하도록 작성 |
