[1] 소프트웨어 생명 주기: 소프트웨어 제품을 계획할 때부터 시작하여 운용 및 유지보수에 이르기까지 변화의 전 과정
- 폭포수 모델: 가장 오래된 모델, 순차적으로 한단계씩 진행
- 애자일 모델: 변경에 유연하고 기민하게 대응하여 생산성과 품질 향상을 목표로 하는 협력적인 모델
- 개인과 상호작용, 작동하는 소프트웨어, 고객과의 협력, 변화에 대응하기를 가치 있게 여김
- 종류: 스크럼, 익스트림 프로그래밍, 린, 칸반, 기능 주도 개발 방법론(FDD), DAD
- 스크럼(Scrum): 매일 정해진 시간에 정해진 장소, 30일 단위의 짧은 개발 기간, 스프린트 중심
- 익스트림 프로그래밍(XP): 고객 만족을 강조, 테스트와 우선 개발을 특징으로 하는 방법
- 짧고 반복적, 단순 설계, 적극적인 참여, 핵심가치(단순성, 의사소통, 용기, 피드백, 존경(피존 사용단)
[2] 요구공학
- 프로세스: 요구사항 도출 > 요구사항 분석 > 요구사항 명세 > 요구사항 확인(검증)
- 분류: 기능적(시스템이 수행해야 하는 작업), 비기능적(조건과 제약사항에 관한 요구사항)
- 요구사항 명세 기법
- 비정형 명세 기법: 자연어를 기반으로 서술, 작업흐름도와 같은 다이어그램으로도 작성
- 정형 명세 기법: 수학적 원리와 표기법, 사용자의 요구를 정확하고 간결하게 표현
- 요구사항 확인: 분석가가 요구사항을 이해했는지 확인, 요구사항 문서가 회사의 표준에 적합하고 이해 가능하며 일관성이 있고 완전한기 검증
- 정형 기술 검토: 요구사항의 일치 여부 및 결함 발생 여부를 검토하는 정적 분석 기법
- 동료 검토
- 워크스루(Walkthrough): 검토 회의 전에 요구사항 명세서를 미리 배포하여 사전 검토한 후, 짧은 검토 회의를 통해 결함을 발견하는 검토 방법, 오류 검출에 초점
- 인스펙션(Inspection): 요구사항 명세서 작성자를 제외한 다른 검토 전문가들이 명세서를 확인하면서 결함 발견, 해결책 제시
- 정형 기술 검토: 요구사항의 일치 여부 및 결함 발생 여부를 검토하는 정적 분석 기법
- 모델링: 현실 세계를 추상화, 단순화, 명확화하기 위해 일정한 표기법으로 표현하는 기법
- 모델링 언어: 요구사항의 정의, 분석, 설계의 결과물을 다양한 다이어그램으로 표현하는 표기법
- 자료사전(데이터사전): {} 반복, [|] 선택, () 생략
- 자료흐름도: □ 개체, ○ 프로세스, ||(이중선) 자료저장소, → 자료의 흐름
- 소단위 명세서: 최하위 단계의 처리 절차 기술
- 모델링 언어: 요구사항의 정의, 분석, 설계의 결과물을 다양한 다이어그램으로 표현하는 표기법
- CASE(Computer Aided Software Engineering): 소프트웨어 개발 과정 일부 또는 전체를 자동화하기 위한 도구
- 상위 CASE: 모델들 사이의 모순 검사, 모델의 오류검증, 자료 흐름도 작성 등 지원
- 하위 CASE: 코드의 작성과 테스트, 문서화하는 과정 지원
- 통합 CASE: 소프트웨어 생명 주기 전체 과정 지원
- CASE의 원천 기술: 구조적 기법, 프로토타이핑 기술, 자동 프로그래밍 기술, 정보저장소 기술, 분산처리 기술
- CASE 도구의 기능 및 효과: 그래픽 지원, 소프트웨어 생명 주기 전 단계의 연결, 다양한 소프트웨어 개발 모형 지원, 소프트웨어 모듈의 재사용성 향상, 소프트웨어 품질 향상, 소프트웨어 유지보수 간편하게 수행가능
- HIPO(Hierarchy Input Process Output): 시스템 분석, 설계, 문서화에 사용되는 도구
- 기본 시스템 모델은 입력, 처리, 출력으로 구성
- 하향식 소프트웨어 개발을 위한 문서화 도구
- 종류: 가시적 도표, 충체적 다이어그램, 세부적 다이어그램
- N-S Chart(Nassi-Shneiderman Chart): 논리 기술에 중점을 두고 상자 도형을 이용한 도형식 설계 도구
- 박스 다이어그램
- 순차, 반복, 선택, 다중 선택의 제어 구조를 표현하는 도구
- 화살표 사용 불가
[3] UML: 모델링 기술과 방법론을 통합하여 만든 표준화된 범용 모델링 언어, 객동기
- 구성요소: 사물, 관계, 다이어그램
- 구조 다이어그램 - 클래스, 객체, 패키지, 컴포넌트, 복합 구조, 배치, 프로필
- 행위 다이어그램 - 유스케이스, 활동, 상태, 시퀀스(순차), 통신, 타이밍, 상호작용 개요
- 유스케이스: 시스템이 액터에게 제공해야 하는 기능, 시스템의 요구사항(연관,포함,확장,일반화)
- 액터: 대상 시스템과 상호작용하는 사람이나 다른 시스템에 의한 역할
- UML을 이용한 모델링
- 기능모델링: 시스템이 제공할 기능 표현, 사용자 관점 // 종류: 유스케이스, 활동
- 정적모델링: 시스템 내부 구성 요소 표현, 개발자 관점 // 종류: 클래스, 패키지
- 동적모델링: 시간의 흐름에 따라 변화하는 과정, 상호작용 표현 // 종류: 상태, 시퀀스, 통신
[4] 객체 지향: 현실 세계의 실체를 속성과 메소드가 결합된 독립적인 형태의 객체로 표현
- 객체: 현실 세계에 존재하는 실체
- 클래스: 하나 이상의 유사한 객체들을 묶어 공통된 특성을 표현한 데이터(데이터 추상화)
- 특징: 캡슐화(데이터와 메소드를 하나로 묶어 객체로 구성하는 것), 정보은폐, 추상화, 상속, 다형성(객체에 따라 다른 방법으로 응답, 동일한 메소드명을 사용하여 같은 의미의 응답을 할 수 있음)
- 객체 지향 설계 원칙(SOLID)
- 단일 책임 원칙(SRP; Single Responsibility Principle): 클래스를 변경해야 하는 이유는 오직 하나, 한가지 기능만
- 개방 폐쇄의 원칙(OCP; Open Closed Principle): 확장에는 열려있고, 변경에는 닫혀있어
- 리스코프 교체의 원칙(LSP; Liskov Substitution Principle): 상위클래스는 하위클래스로 대체할 수 있어야 함
- 인터페이스 분리의 원칙(ISP; Interface Segregation Principle): 구체적인 여러개의 인터페이스
- 의존 관계 역전의 원칙(DIP; Dependency Inversion Principle): 추상 클래스에 의존
- 객체 지향 분석 방법론
- 럼바우(Rumbaugh)의 분석 방법: 그래픽 표기법
- 활동 순서: 객체(객체 다이어그램) > 동적(상태 다이어그램) > 기능(자료 흐름도)
- 객체(Object) 모델링 : 정보모델링, 시스템에서 요구되는 객체를 찾아내어 속성과 연산 식별 및 객체들 간의 관계를 규정, 객체 다이어그램으로 표시
- 동적(Dynamic) 모델링 : 상태도(상태 다이어그램)을 이용하여 시스템의 행위를 기술, 제어, 흐름, 동작
- 기능(Functional) 모델링 : 자료 흐름도를 이용하여 다수의 프로세스들 간의 자료 흐름을 중심으로 처리 과정 표현, DFD
- 럼바우(Rumbaugh)의 분석 방법: 그래픽 표기법
[5] 소프트웨어 아키텍처 패턴
- MVC 구조: 사용자 인터페이스와 비즈니스 로직을 서로 분리하여 개발하는 방법
- 구성요소: Model(사용자 요청을 처리해 사용자에게 출력할 데이터를 만듬), View(모델이 처리한 결과를 화면에 보여주는 요소), Controller(사용자 요청을 받아 그 요청을 처리할 모델을 호출하는 요소)
[6] 디자인 패턴: 어떤 분야에서 반복적으로 나타나는 문제점들에 대한 전문가들의 경험을 정리하여 해결방안을 제시한 패턴
- 생성패턴
- 팩토리메소드: 어떤 객체를 생성할지를 서브 클래스가 결정하도록 하고 책임을 위임
- 추상팩토리: 상세화된 서브 클래스를 정의하지 않고도 서로 관령성 있거나 의존적인 여러 객체 그룹을 생성하여 추상적으로 표현
- 빌더
- 프로토타입: 원본 객체를 복사하여 새 객체를 생성할 수 있도록
- 싱글톤
- 구조패턴
- 어댑터: 기존에 구현되어 있는 클래스에 기능 발생 시 기존 클래스를 재사용할 수 있도록 중간에서 맞춰주는 역할
- 브리지: 구현부에서 추상층을 분리하여 각자 독립적으로 확장할 수 있게 하여 결합도를 낮춤
- 컴포지트
- 데코레이터
- 퍼사드
- 플라이웨이트
- 프록시: 객체의 대리자를 이용하여 원래 객체의 작업을 대신 처리
- 행위패턴
- 인터프리터: 언어 규칙 클래스를 이용
- 템플릿 메소드
- 책임연쇄
- 커맨드: 요청을 캡슐화할 수 있으며, 매개변수를 써서 여러가지 다른 요청을 추가할 수 있는 패턴
- 이터레이터
- 미디에이터
- 메멘토
- 옵저버: 한 객체의 상태 변화가 일어났을 때 그 객체에 의존하는 다른 객체들에게 알리고, 자동으로 내용이 갱신, 일 대 다 의존성을 가짐
- 스테이트
- 스트레티지
- 비지터
[7] 모듈 설계
- 모듈: 소프트웨어 구조를 이루는 기본적인 단위
- 모듈화: 소프트웨어 기능들을 모듈 단위로 분해
- 측정 척도: 응집도, 결합도
- 응집도: 모듈 안의 요소들이 서로 관련되어 있는 정도, 독립적인 모듈이 되기 위해서는 응집도가 강해야해!!
- 순서(약 > 강): 우연적 - 논리적 - 시간적 - 절차적 - 통신적 - 순차적 - 기능적 / 우연적(Coincidental)응집도 < 논리적(Logical) 응집도 < 시간적 응집도(Temporal) < 절차적(Procedural) 응집도 < 교환적(Communication) 응집도 < 순차적(Sequential) 응집도 < 기능적(Functional)
- 결합도: 모듈간의 상호의존도
- 순서(약 > 강): 자료 - 스탬프 - 제어 - 외부 - 공통 - 내용
- 응집도: 모듈 안의 요소들이 서로 관련되어 있는 정도, 독립적인 모듈이 되기 위해서는 응집도가 강해야해!!
- 측정 척도: 응집도, 결합도
[8] 인터페이스 상세 설계
- 직접 연계 방식: 중간 매개체 없음, 종류: DB Link, API, 화면 링크, DB Connection Pool, JDBC
- 간접 연계 방식: 중간 매개체 있음,종류 : EAI, ESB, 웹 서비스, 소켓
- EAI 구축 유형: PPP(Point to Point), Hub&Spoke, Message Bus(애플리케이션 사이에 미들웨어를 두어 처리하는 방식), Hybrid
[9] 미들웨어(Middleware): 운영체제와 응용프로그램 사이에 위치하는 컴퓨터 소프트웨어
- RPC(Remote Procedure Call): 원격 프로시저를 로컬 프로시처럼 호출
- MOM(Message Oriented Middleware): 메시지 지향 미들웨어, 즉각적인 응답이 아니라 느리고 안정적인 응답을 필요로 할때
- TP-Moniter(Transaction Processing Monitor): 트랜잭션을 감시하여 일관성 있게 보관 및 유지, 트랜잭션 관리 미들웨어
- ORB(Object Request Broker): 객체 지향 미들웨어, CORBA 표준 스펙을 구현
- WAS(Web Application Server): 사용자또는 사용자 요청에 따라 결과값이 변하는 동적 콘텐츠를 처리하기 위한 웹 환경을 구현하는데 사용
[10] 코드 설계
- 연상코드: 명칭이나 약호와 관계있는 숫자나 문자, 기호를 이용
- 블록코드(구분코드): 공통성이 있는 것끼리 블록으로 구분하고, 일련번호를 부여하는 방법
- 표의 숫자 코드(유효숫자코드): 성질, 물리적 수치를 그대로 코드에 적용시키는 방법
- 순차코드: 일정 기준에 따라 최초의 자료부터 순차적으로 일련번호를 부여하는 방법
'정보처리기사' 카테고리의 다른 글
정보처리기사(실기) - 데이터 저장소 (0) | 2024.04.07 |
---|---|
정보처리기사 - 4과목 (0) | 2024.02.25 |
정보처리기사 - 3과목 (0) | 2024.02.25 |
정보처리기사 - 2과목 (1) | 2024.02.24 |
정보처리기사 - 5과목 (0) | 2024.02.22 |