정보처리기사
요구사항 분석 기법
구조적 분석
: 하향식 접근 방식(폭포수 모형)
- 도형 중심의 분석용 도구
- DFD: 프로세스와 프로세스 간에 존재하는 상호작용 표현
- DD: 데이터 흐름도(Data Flow Diagram)에 기술된 자료들에 대해 정의
- Mini spec.: 자료 흐름도를 보완 설명
- ERD: 시스템에서 처리되는 개체와 속성 그리고 관계를 표현하여 개체를 모델화하는 도구
- STD(State Transition Diagram): 시스템의 상태와 변화를 모델링
객체지향적 분석
: 상향식 접근 방식
- Rumbaugh: 가장 일반적으로 사용되는 방법으로 분석 활동을 객체, 동적, 기능 모델로 나누어 수행
- 객체 모델링(Object Modeling): 클래스 다이어그램을 이용하여 시스템에서 요구되는 객체을 표현한 것
- 동적 모델링(Dynamic Modeling): 상태 다이어그램을 이용하여 시간의 흐름에 따른 객체들 사이의 동적인 행위를 표현한 것
- 기능 모델링(Functional Modeling): 자료 흐름도(DFD)를 이용하여 다수의 프로세스들 간의 자료 흐름을 중심으로 처리 과정을 표현한 것
- Booch: 미시적(Micro) 개발 프로세스와 거시적(Macro) 개발 프로세스를 모두 사용
- Jacobson: UseCase를 강조하여 사용
- Coad와 Yourdon: E-R다이어그램을 사용
- Wirfs-Brock: 분석과 설계간의 구분이 없음
UML 클래스 관계
- 일반화 관계(Generalization): 상속
- 실체화 관계(Realization): 구현
- 의존관계(Dependency): 참조, 매개변수, 일시성
- 연관관계(Association): 참조 긴밀성
- 직접 연관관계(Directional): 한쪽으로만 방향성이 있는 연관관계를 의미
- 집합 연관관계(Aggregation): 전체/부분 연관 관계, 전체가 삭제되더라도 부분은 삭제되지 않는 경우
- 합성 연관관계(Composition): 전체/부분 연관 관계, 전체가 삭제되면 부분도 삭제되는 경우
UML(Unified Modeling Language)
: 표준화된 모델링(개발하기 위한 그림을 그려주는) 언어
- 종류
구조적(정적) 다이어그램 - 객체: 객체 정보 - 클래스: 클래스의 속성, 함수, 변수 타입으로 구성 - 패키지: 클래스 다이어그램의 집합 - 컴포넌트: 컴포넌트끼리의 구조 관계를 표현 - 배치(Deployment): SW, HW 등을 포함한 시스템의 물리적 구조를 나타냄 행위적(동적) 다이어그램 - 유스케이스: 사용자 관점에서 바라본 시스템을 표현 - 구성요소(Component): System, Actor, Usecase, Relation - System: 만들고자 하는 프로그램 - Actor: 시스템의 외부에 있고 시스템과 상호작용을 하는 사람(시스템의 기능을 사용하는 사람), 시스템(시스템에 정보를 제공하는 또 다른 시스템) - UseCase: 사용자 입장에서 바라본 시스템의 기능 - Relation: 액터와 유스케이스 사이의 의미있는 관계 - 연관: 유스케이스와 액터간의 상호작용이 있음 - 확장: "글을 등록한다" 기능을 수행 할 때 "파일을 첨부한다" 기능을 선택적으로 수행 할 수 있다는 것 - 포함: "글을 등록한다" 기능을 동작하기 위해서 "로그인 한다" 기능이 반드시 동작되어야 한다는 것 - 일반화: 그룹을 만들어 이해도를 높이기 위한 관계, "글을 검색한다"를 "글쓴이로 검색한다"와 "날짜로 검색한다"로 좀더 구체화 한 것 - 활동:활동의 흐름 - 상태: 객체의 상태 변화 - 순차: 시간의 흐름에 따른 객체 사이의 상호 작용 - 커뮤니케이션 - 인터렉션 오버뷰 - 타이밍
애자일 방법론
- eXtreme Programming: 수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법
- 5가지 핵심 가치: 의사소통, 피드백, 존중, 용기, 단순성
- 12가지 기본 원리
- 짝 프로그래밍 Pair programming
- 공동 코드 소유 Collective Ownership: 시스템에 있는 코드는 누구든지 언제라도 수정 가능
- 지속적인 통합 Continuous Integration(CI): 매일 여러 번씩 소프트웨어를 통합하고 빌드
- 계획 세우기 Planning Process
- 작은 릴리즈 Small Release: 작은 시스템을 먼저 만들고, 짧은 단위로 업데이트
- 메타포어 Metaphor: 공통적인 이름 체계와 시스템 서술서를 통해 고객과 개발자 간의 의사소통을 원활하게 함
- 간단한 디자인 Simple Design: 현재의 요구사항에 적합한 가장 단순한 시스템을 설계
- 테스트 기반 개발 Test Driven Development(TDD): 테스트를 먼저 수행하고, 이 테스트를 통과할 수 있도록 코드를 작성
- 리팩토링 Refactoring: 프로그램의 기능을 바꾸지 않으면서 중복 제거, 단순화 등을 위해 시스템을 재구성
- 40시간 작업 40-Hour Work
- 고객 상주 On Site Customer
- 코드 표준 Coding Standard
- Scrum
- 짧은 단위시간(Sprint) 내 실행가능한 SW 개발
- 매일 15분 정도의 Scrum meeting 회의
- FDD(Feature-Driven Development): 기능주도 개발
- Crystal
- LEAN: 낭비 요소를 제거하여 품질 향상
추상화 기법
- 자료 추상화: 공통된 특징으로 묶어 이름을 붙이는 것(갤럭시 → 휴대폰으로 추상화)
- 제어 추상화: 해당 메소드의 작동방식과 같은 내부 로직을 숨기는 것
- 과정 추상화: 자세한 단계를 고려하지 않고 상위 수준에서 수행 흐름만 먼저 설계
아키텍쳐 패턴의 유형
- 계층화(Layers) 패턴: 시스템을 계층구조(Layer)로 쌓아둔 전형적 패턴
- 클라이언트-서버 패턴:
- 서버(=1, 항시대기): 자원 제공
- 클라이언트(=다수): 자원 요청, 연산 가능
- 마스터-슬레이브 패턴:
- Client-Server 구조와 유사하나, Slaves는 연산이 불가하며 데이터 수집 기능만 수행
- 피어 투 피어 패턴:
- 서버와 클라이언트가 서로 역할을 바꿀 수 있는 형태(torrent)
- 두 가지 일을 병렬로 수행하는 멀티스레딩(자원요청/제원제공)이 특징
- 파이프-필터 패턴: 데이터의 흐름(단방향)의 각 단계를 파이프와 필터로 연결
- 파이프: 각 단계명
- 필터: 각 파이프를 통해 넘어온 데이터를 처리하고 캡슐화
- 모델-뷰-컨트롤러 패턴(MVC)
- 이벤트-버스 패턴: 특정 이벤트를 발행하면 해당 채널(버스)를 구독하고 있는 리스너들이 이벤트를 받아서 처리하는 형식
- 블랙보드 패턴: 공유데이터를 관리하는 블랙보드에 접근하여 원하는 데이터를 찾는 형식
UI 설계 원칙
- 직관성: 누구나 쉽게 이해하고 사용할 수 있어야 함
- 유효성: 사용자의 목적을 정확히 달성해야 함
- 학습성: 누구나 쉽게 배울 수 있어야 함
- 유연성: 사용자의 요구사항을 최대한 수용해야 함
GoF(Gang of Four) 디자인 패턴(시험 직전에 확인)
: OOP에서 소스코드 형식을 미리 만들어두어 자주 발생하는 문제에 대해 일반적이고 반복적인 해결 방법
생성 패턴(Creational Patterns) 5 : 객체 생성에 대한 패턴
종류 | 설명 |
---|---|
Abstract Factory | 특정 그룹에 속하는 여러 객체들을 하나의 팩토리로 묶어서 생성할 수 있는 패턴 |
Builder | 복잡한 객체들을 단계별로 생성할 수 있도록 하는 생성 디자인 패턴 |
Factory Method | 클라이언트가 특정 객체의 생성을 직접 생성하지 않고 "팩토리" 역할을 하는 객체에 위임하는 패턴 |
Prototype | 원본 객체를 복사하여 새 객체를 생성 |
SingleTon | 오직 하나의 객체만들 생성 |
구조 패턴(Structural Patterns) 5 : 클래스나 객체를 조합해 더 큰 구조를 만드는 패턴
종류 | 설명 |
---|---|
Adapter | 호환되지 않는 인터페이스를 가진 객체들간의 기능을 변환 제공하여 호환성을 확보 |
Bridge | 추상화 클래스 계층과 구현 클래스 계층을 분리 |
Composite | 복잡한 객체구조를 표현하여 객체집합 속에 또 다른 객체집합을 갖음 |
Decorator | 새로운 기능이 추가될 때마다 새로운 객체를 만들고, 이전 객체의 기능은 새로운 객체내에서도 그대로 유지, 보장 |
Facade(퍼싸드) | 서브시스템이 복잡할 경우 간단한 인터페이스를 통해 서브시스템의 주요기능을 사용할 수 있도록 함 |
Fly weight | 인스턴스를 가능한 한 공유시켜 불필요한 생성을 하지않도록 함 |
Proxy | 원래 객체에 대한 접근을 제어하므로, 요청이 원래 객체에 전달되기 전 또는 후에 무언가를 수행할 수 있도록 함 |
행위 패턴(Behavioral Patterns) 11 : 반복적으로 사용되는 객체들의 상호작용을 패턴화
미들웨어
: 클라이언트와 서버 간의 통신을 담당하는 소프트웨어
- Remote Procedure Call: 원격 프로시저를 로컬 프로시저처럼 호출(원격 데스크톱 등)
- Message Oriented Middleware: 비동기형 메시지를 전달, 즉각적인 응답보다는 쌓아두고 시간이 있을 때 처리하는 방식
- Transaction Processing Monitor: 항공기나 철도 예약 업무 등과 같은 온라인 트랜잭션을 처리 및 감시, 빠른 응답속도를 유지해야 할 경우 주로 사용
- Web Application Server: 동적인 콘텐츠를 처리하기 위한 미들웨어로, 웹 환경을 구현하기 위해 사용
- Object Request Broker: 객체지향 미들웨어
- DataBase: 데이터베이스와 연결하기 위한 미들웨어(ODBC, JDBC 등)
투명성
- 분할 투명성: 하나의 데이터가 여러 장소에 저장
- 위치 투명성: 호출된 데이터의 위치
- 지역사상 투명성: 각 지역시스템 이름과 무관한 이름 사용 가능
- 중복 투명성: 자료의 중복
- 장애 투명성: 장애에 무관한 Transaction의 원자성 유지
- 병행 투명성: 다수 Transaction 동시 수행 시 결과의 일관성 유지
CLI(Command Line Interface) = CUI(Character User Interface)
참고 자료
'Certificate > 정보처리기사' 카테고리의 다른 글
[정보처리기사] 2021년 3회차 (3)데이터베이스 설계 (0) | 2023.07.11 |
---|---|
[정보처리기사] 2021년 3회차 (2)소프트웨어 개발 (0) | 2023.07.10 |
[정보처리기사] 2022년 1회차 (5)정보시스템 구축관리 (0) | 2023.07.09 |
[정보처리기사] 2022년 1회차 (4)프로그래밍 언어 활용 (0) | 2023.07.09 |
[정보처리기사] 2022년 1회차 (3)데이터베이스 설계 (0) | 2023.07.09 |