과목별 요약 › 정보처리기사 › 소프트웨어 설계정보처리기사 소프트웨어 설계 핵심 요약 정리
정보처리기사 필기 소프트웨어 설계의 시험에 자주 나오는 쟁점을 요약 카드 26개로 정리했어요. 형광펜 은 시험에 나오는 핵심 낱말이에요. 소프트웨어 생명주기 모델, 애자일 방법론: XP와 스크럼, 요구사항의 분류와 요구공학 프로세스, 요구사항 명세와 검증, 구조적 분석: DFD와 자료 사전, 현행 시스템 분석과 분석 도구 등.
소프트웨어 설계 요약을 빈칸 암기 로 외우고, OX·객관식 문제 와 실전 모의고사 로 확인해 보세요. 틀린 문제는 1·3·7·14·30일 간격으로 다시 나와요. 회원가입 없이 무료예요.
자격공부노트에서 정보처리기사 공부하기 요구사항 확인
소프트웨어 생명주기 모델 ★ 빈출
폭포수 모형: 각 단계를 끝내야 다음 단계로 가는 순차적 모형. 가장 오래되고 널리 쓰임. 앞 단계로 돌아가기 어려움. 요구사항 변경에 약함프로토타입 모형: 실제 개발될 시스템의 견본(시제품) 을 만들어 사용자 요구를 정확히 파악. 요구 변경에 유연나선형 모형: 보헴 (Boehm)이 제안. 여러 번 반복하며 점진적으로 개발. 위험 분석 을 강조순서: 계획 및 정의 → 위험 분석 → 공학적 개발 → 고객 평가 반복적 모형: 시스템을 여러 번 나누어 릴리스 (증분형, 진화형)생명주기 단계: 계획 → 요구 분석 → 설계 → 구현 → 테스트 → 유지보수 (유지보수 비용이 가장 큼) 애자일 방법론: XP와 스크럼 ★ 빈출
애자일 선언의 가치 프로세스와 도구보다 개인과 상호작용 포괄적인 문서보다 작동하는 소프트웨어 계약 협상보다 고객과의 협력 계획을 따르기보다 변화에 대응 XP (eXtreme Programming): 짧은 반복, 고객 참여5가지 가치: 용기 , 단순성 , 의사소통 , 피드백 , 존중 실천: 짝 프로그래밍 , 공동 코드 소유, 테스트 주도 개발 (TDD), 전체 팀, 지속적인 통합, 리팩토링, 소규모 릴리스 고객 요구는 사용자 스토리 (User Story)로 표현. 문서보다 소스 코드 중심, 소규모 팀에 적합 스크럼 : 팀 중심 반복 개발제품 책임자(PO): 백로그 작성·우선순위 결정 / 스크럼 마스터 (SM): 팀이 잘 일하도록 돕는 촉진자 / 개발팀 제품 백로그 → 스프린트 계획 → 스프린트 (보통 2~4주) → 일일 스크럼 (매일 15분) → 스프린트 검토 → 스프린트 회고번다운 차트 : 남은 작업량을 시간에 따라 표시속도(Velocity): 한 스프린트에서 팀이 처리할 수 있는 제품 백로그 양의 추정치 그 밖의 애자일: 칸반, 크리스탈, FDD(기능 중심 개발), 린(Lean) 스프린트 보통 2~4주 일일 스크럼 매일 약 15분
요구사항의 분류와 요구공학 프로세스 ★ 빈출
기능 요구사항: 시스템이 무엇을 하는지 (입출력, 처리, 연산 등)비기능 요구사항: 시스템이 어떻게 동작해야 하는지 — 성능 , 보안 , 품질, 신뢰성, 제약 사항요구사항 개발 프로세스 : 도출 → 분석 → 명세 → 확인(검증) 도출: 이해관계자에게서 요구를 모음 — 인터뷰, 브레인스토밍, 설문, 관찰, 프로토타이핑, 유스케이스 분석: 모순·누락을 찾고 범위를 정함 명세: 문서로 체계적으로 작성 확인: 요구사항이 정확히 기술됐는지 검토 요구사항 관리: 변경을 추적·통제 (CASE 도구 활용) 요구사항 관리 도구가 필요한 이유: 변경에 따른 비용 편익 분석 , 변경 추적 , 변경에 따른 영향 평가 개발 영역을 결정하는 요소: 기능, 성능, 제약 조건, 인터페이스 (다른 하드웨어·소프트웨어와의 외부 연결) 요구 분석은 소프트웨어 개발의 실질적인 첫 단계 . 요구 분석이 어려운 이유: 사용자와 개발자의 지식·표현 차이, 요구가 모호하고 계속 바뀜 요구사항 명세와 검증 헷갈림
명세 기법 정형 명세: 수학적 원리·기호로 표현 (Z, VDM, Petri-net, CSP). 간결하고 일관성이 높지만 이해하기 어려움비정형 명세: 자연어 ·다이어그램으로 표현. 이해하기 쉽지만 일관성이 떨어지고 해석이 달라질 수 있음요구사항 검토(검증) 방법 동료 검토 (Peer Review): 작성자가 설명하고 동료들이 결함을 찾음워크스루 (Walk Through): 검토 자료를 미리 배포 하고 짧은 회의로 결함을 찾음인스펙션 (Inspection): 작성자를 뺀 전문가 가 명세서를 확인하며 결함을 찾는 공식적인 검토요구사항 명세서 품질: 정확성, 명확성, 완전성, 일관성, 수정 용이성, 추적성 구조적 분석: DFD와 자료 사전 ★ 빈출 · 헷갈림
구조적 분석 도구: 자료 흐름도 (DFD), 자료 사전 (DD), 소단위 명세서(Mini-Spec), 개체 관계도(ERD), 상태 전이도(STD) DFD 구성 요소 프로세스 (Process): 원 — 자료를 처리자료 흐름 (Data Flow): 화살표 자료 저장소 (Data Store): 평행선 (위아래 두 줄)단말 (Terminator): 사각형 — 시스템과 교신하는 외부 개체DFD는 자료의 흐름을 나타내며 버블 차트 라고도 함. 단계적으로 세분화(레벨 0, 1, 2 …) 자료 사전 기호 = 정의(구성), + 연결, [ | ] 선택, { } 반복, ( ) 생략 가능, ** ** 주석현행 시스템 분석과 분석 도구
현행 시스템 파악 순서 : 구성·기능·인터페이스 파악 → 아키텍처·소프트웨어 구성 파악 → 하드웨어·네트워크 구성 파악운영체제 선정 시 고려 : 신뢰도 , 성능, 기술 지원, 주변 기기, 구축 비용 (TCO: 총 소유 비용)DBMS 선정 시 고려 : 가용성 , 성능, 상호 호환성 , 기술 지원, 구축 비용플랫폼 성능 특성 분석 항목 : 응답 시간 , 가용성 , 사용률 (서버 튜닝은 측정 항목이 아님)미들웨어 분석 : WAS(웹 애플리케이션 서버) 등요구사항 분석 CASE 도구 : SADT(구조적 분석·설계, SoftTech 사), SREM(TRW 사, RSL·REVS), PSL/PSA(미시간대), TAGSHIPO : 하향식 개발을 위한 문서화 도구. 가시적 도표(도식 목차), 총체적 도표, 세부적 도표CASE 도구 ★ 빈출
CASE (Computer Aided Software Engineering): 소프트웨어 개발 과정의 일부 또는 전체를 자동화 하는 도구주요 기능 : 소프트웨어 생명주기 전 단계의 연결 , 그래픽 지원, 다양한 개발 모형 지원 (언어 번역은 CASE의 기능이 아님)원천 기술 : 구조적 기법 , 프로토타이핑 기술, 정보 저장소 기술 (일괄 처리 기술은 아님)효과: 표준화된 개발 환경, 문서 자동화, 작업자 간 의사소통 증대, 품질·생산성·재사용성 향상, 유지보수 간편 상위 CASE: 요구 분석·설계 지원 — 모델 사이의 모순 검사 , 모델의 오류 검증 , 자료 흐름도 작성하위 CASE: 구현 지원 — 소스 코드 생성 , 테스트, 문서화1980년대에 소개되었고, 구조적 기법과 객체지향 모두에 활용 UML
UML 구성 요소와 관계 ★ 빈출 · 헷갈림
UML: 객체지향 모델링 표준 언어 (OMG 표준). 구성 요소: 사물 (Things), 관계 (Relationships), 다이어그램 (Diagrams) 관계 연관 (Association): 서로 관련됨 — 실선 집합 (Aggregation, 집단화 ): 전체와 부분(part-whole, is-a-part-of), 부분이 독립적 으로 존재 가능 — 빈 마름모(◇)포함 (Composition): 전체와 부분, 부분이 전체와 생명주기를 함께 함 — 채운 마름모(◆)일반화 (Generalization): 상위·하위(상속) 관계 — 실선 + 빈 삼각형 화살표의존 (Dependency): 짧은 시간 동안만 사용하는 관계. 한 사물의 명세가 바뀌면 다른 사물에 영향 (예: 다른 클래스를 연산의 매개변수 로 사용) — 점선 화살표실체화 (Realization): 인터페이스를 구현. 한 객체가 다른 객체에게 오퍼레이션을 수행하도록 지정 하는 의미적 관계 — 점선 + 빈 삼각형 화살표스테레오타입 : UML 기본 요소를 확장해 새 의미를 표현 — 길러멧 << >> 사용 (예: <<include>>, <<interface>>)UML 다이어그램의 종류 ★ 빈출
구조적(정적) 다이어그램 클래스 다이어그램: 클래스의 속성·연산과 클래스 사이의 관계객체 다이어그램, 컴포넌트 다이어그램(구현 모듈), 배치 다이어그램(물리적 노드에 배치), 복합체 구조 다이어그램, 패키지 다이어그램 행위적(동적) 다이어그램 유스케이스 다이어그램: 사용자 관점에서 시스템이 제공하는 기능시퀀스 다이어그램: 객체 사이에 주고받는 메시지를 시간 순서 로 표현커뮤니케이션 다이어그램: 메시지와 객체 사이의 연관 까지 표현 상태 다이어그램: 객체가 이벤트에 따라 상태가 바뀌는 과정활동 다이어그램: 처리 흐름을 순서대로 표현상호작용 개요 다이어그램, 타이밍 다이어그램 유스케이스 다이어그램과 시퀀스 다이어그램
유스케이스 다이어그램 구성 시스템 범위 : 사각형으로 시스템 경계 표시액터 : 시스템과 상호작용하는 외부 존재. 사용자 액터(주액터, 사람), 시스템 액터 (부액터, 본 시스템과 데이터를 주고받는 연동 외부 시스템)유스케이스: 사용자가 보는 시스템의 기능 (타원) 유스케이스 관계 : 연관, 포함, 확장, 일반화연관 (association): 액터와 유스케이스가 상호작용함포함 (include): 유스케이스를 실행할 때 반드시 함께 실행 (예: 주문 → 로그인)확장 (extend): 특정 조건 에서만 추가로 실행일반화: 유사한 유스케이스·액터를 묶음 시퀀스(순차) 다이어그램 구성 : 액터, 객체, 생명선 (Lifeline, 점선), 실행 상자 (활성 상자), 메시지, 회귀 메시지(Self-Message), 제어 블록객체 간 동적 상호작용을 시간 중심으로 표현. 세로 방향이 시간의 흐름. 상호작용(교류) 다이어그램의 한 종류 화면 설계
UI의 종류와 설계 원칙 ★ 빈출
UI 종류 CLI : 명령어를 글자로 입력 / GUI : 마우스·그래픽 / NUI : 말·손동작 같은 자연스러운 움직임 / OUI : 모든 사물과 사용자가 상호작용 (유기적)UI 설계 원칙 직관성 : 누구나 쉽게 이해하고 사용유효성 : 사용자의 목적을 정확하고 완벽하게 달성학습성 : 누구나 쉽게 배우고 익힘유연성 : 사용자의 요구를 최대한 수용하고 실수를 최소화UX(사용자 경험)의 특징: 주관성, 정황성, 총체성 UI 설계 지침: 사용자 중심, 일관성, 단순성, 결과 예측 가능, 접근성, 명확성, 오류 발생 해결. 심미성 보다 사용성 을 우선 오류 메시지: 이해하기 쉽게, 회복 방법을 구체적으로, 부정적인 영향도 사용자에게 알림. 소리·색 등 다양한 수단 활용 가능 피드백 : 시스템 상태와 명령 결과를 보여 줘 사용자가 진행 상황을 해석하게 함UI 품질 요구사항(ISO/IEC 9126 기준): 기능성, 신뢰성, 사용성, 효율성, 유지보수성, 이식성 UI 설계 도구 ★ 빈출
와이어프레임 : 화면 단위의 레이아웃 을 선으로 그린 뼈대. 이해관계자와 초기에 화면 구성을 협의목업 (Mockup): 실제 화면과 비슷하게 만든 정적인 모형. 기능은 동작하지 않음스토리보드 : 와이어프레임에 콘텐츠 설명, 페이지 이동 흐름 등을 추가한 문서. 디자이너와 개발자가 최종적으로 참고하는 작업 지침서 프로토타입 : 와이어프레임·스토리보드에 인터랙션 을 넣어 실제처럼 동작하게 만든 모형유스케이스 : 사용자 측면의 요구사항과 목표를 다이어그램으로 표현프로토타입 작성 방법: 페이퍼 프로토타입(종이에 손으로), 디지털 프로토타입(도구 사용) 애플리케이션 설계
설계의 기본: 상위·하위 설계와 설계 방식 ★ 빈출
상위 설계 (아키텍처 설계, 예비 설계): 아키텍처 설계, 데이터 설계, 인터페이스 정의 , 사용자 인터페이스 설계하위 설계 (모듈 설계, 상세 설계): 모듈 설계, 자료 구조 설계, 알고리즘 설계하향식 설계: 최상위 기능(main user function)에서 시작해 하위 기능으로 분할 하며 설계. 통합할 때 인터페이스가 이미 정의되어 있어 통합이 간단상향식 설계: 최하위 모듈을 먼저 설계·완성한 뒤 결합. 인터페이스가 먼저 성립되어 있어야 기능 추가가 쉬움바람직한 설계 지침 : 모듈 크기를 적당하게, 모듈의 기능을 예측할 수 있게, 결합도는 낮추고 응집도는 높이게, 복잡도와 중복을 줄임, 이식성 고려, 계층적 자료 조직 제시시스템의 구성 요소 : 입력, 처리(Process), 출력, 제어(Control), 피드백 (Feedback)모델링: 개발 대상을 추상화해 기호·그림으로 표현. 이해도와 의사소통을 높이고 개발될 시스템을 유추할 수 있게 함 (모든 단계에서 활용) 코드 설계 ★ 빈출
코드의 기능 : 식별 , 분류 , 배열 , 표준화 , 간소화 (복잡성은 아님)코드의 종류 순차 코드 : 일정한 일련번호 를 차례로 부여 (예: 1, 2, 3 …)블록 코드 : 공통 특성별로 블록을 나누고 블록 안에서 일련번호 부여 (구분 코드)10진 코드 : 0~9로 10진 분할 (도서 분류)그룹 분류 코드 : 대·중·소분류 등으로 나눠 각 그룹 안에서 일련번호연상 코드 : 명칭이나 약호를 섞어 보면 연상되게 (예: TV-40)표의 숫자 코드 : 대상의 길이·무게·면적·용량 같은 물리적 수치 를 그대로 코드로 사용 (유효 숫자 코드)합성 코드: 두 가지 이상 코드를 조합 코드 오류 : 사본 오류 (Transcription, 한 자리를 잘못 기록: 12536 → 12936), 전위 오류 (Transposition, 자리가 바뀜: 12536 → 12563), 생략 오류(Omission), 추가 오류(Addition), 이중 오류, 임의 오류객체지향의 구성 요소와 특징 ★ 빈출
구성 요소 : 객체 (데이터+함수), 클래스 (공통 속성과 연산을 가진 객체들의 틀), 메시지 (객체에 동작을 요청)특징 캡슐화 : 데이터와 함수를 하나로 묶음. 외부에서 내부를 몰라도 됨 → 정보 은닉 , 결합도 낮아짐, 재사용 쉬움상속 : 상위 클래스의 속성과 연산을 하위 클래스가 물려받음다형성 : 같은 메시지에 객체마다 다르게 응답 — 오버로딩 (같은 이름, 다른 매개변수), 오버라이딩 (상위 메서드를 하위에서 재정의)추상화 : 불필요한 부분은 빼고 핵심만 표현 (자료 추상화, 과정 추상화, 제어 추상화)인스턴스: 클래스에 속한 실제 객체 객체지향 분석 방법론 ★ 빈출
럼바우 (Rumbaugh) OMT: 분석 활동을 세 가지 모델링으로 — 순서 객체 모델링 → 동적 모델링 → 기능 모델링 ("객·동·기")객체 모델링(정보 모델링 ): 객체 다이어그램 으로 객체를 찾아 속성·연산과 관계를 표시 동적 모델링: 상태 다이어그램 으로 시간에 따른 제어 흐름 기능 모델링: 자료 흐름도 (DFD)로 자료 흐름과 처리 부치 (Booch): 미시적·거시적 개발 프로세스를 모두 사용제이콥슨 (Jacobson): 유스케이스 를 강조코드-요돈(Coad-Yourdon): E-R 다이어그램 으로 객체의 행위를 모델링. 객체 식별 → 구조 식별 → 주체 정의 → 속성·관계 정의 → 서비스 정의 워프스-브록(Wirfs-Brock): 분석과 설계 구분 없이, 고객 명세서를 평가해 설계까지 연속 수행 객체지향 설계 원칙 (SOLID) ★ 빈출
SRP 단일 책임 원칙: 클래스는 하나의 책임 만 가져야 함OCP 개방-폐쇄 원칙: 확장 에는 열려 있고 수정 에는 닫혀 있어야 함LSP 리스코프 치환 원칙: 자식 클래스는 언제나 부모 클래스 를 대체할 수 있어야 함ISP 인터페이스 분리 원칙: 자신이 사용하지 않는 인터페이스와 의존 관계를 맺지 않아야 함DIP 의존 역전 원칙: 구체적인 것이 아니라 추상화 된 것에 의존해야 함모듈화: 결합도와 응집도 ★ 빈출 · 헷갈림
좋은 설계: 결합도는 낮게 , 응집도는 높게 (모듈의 독립성↑) 결합도 (모듈 사이의 관련 정도) — 약함 → 강함자료 < 스탬프 < 제어 < 외부 < 공통 < 내용 자료: 매개변수로 자료만 주고받음 / 스탬프: 배열·레코드 같은 자료 구조 를 넘김 / 제어: 논리적 흐름을 제어하는 제어 신호 (플래그)를 넘김 / 외부: 외부에 선언된 데이터 참조 / 공통: 전역 변수 공유 / 내용: 다른 모듈의 내부 를 직접 참조·수정 응집도 (모듈 안의 요소가 서로 관련된 정도) — 강함 → 약함기능적 > 순차적 > 교환(통신)적 > 절차적 > 시간적 > 논리적 > 우연적 팬인 (Fan-In): 이 모듈을 호출하는 상위 모듈 수 / 팬아웃 (Fan-Out): 이 모듈이 호출하는 하위 모듈 수디자인 패턴(GoF) 분류 ★ 빈출
GoF(Gang of Four)의 디자인 패턴 23 가지: 생성 5, 구조 7, 행위 11 생성 패턴 (객체 생성): 추상 팩토리 , 빌더 , 팩토리 메서드 , 프로토타입 , 싱글톤 구조 패턴 (클래스·객체 조합): 어댑터 , 브리지 , 컴포지트 , 데코레이터 , 퍼사드 , 플라이웨이트 , 프록시 디자인 패턴: 자주 생기는 설계 문제에 대한 일반적이고 반복적인 해결 방법. 구성 요소: 패턴 이름, 문제 및 배경, 해결, 사례, 결과, 샘플 코드 장점: 구조 파악 쉬움, 객체지향 설계·구현의 생산성 향상, 개발자 간 의사소통 원활 (절차형 언어와는 잘 맞지 않음) 행위 패턴 (객체 간 상호작용·책임 분배): 책임 연쇄, 커맨드, 인터프리터, 반복자(Iterator), 중재자(Mediator), 메멘토, 옵서버 , 상태, 전략 , 템플릿 메서드, 방문자 GoF 디자인 패턴 23가지 (생성 5, 구조 7, 행위 11)
주요 디자인 패턴의 의미 ★ 빈출 · 헷갈림
싱글톤 : 클래스의 인스턴스를 하나만 만들고 어디서든 그것을 참조팩토리 메서드 : 상위 클래스에서 객체 생성 인터페이스를 정하고, 실제 생성은 서브클래스 가 결정 (가상 생성자)어댑터 : 호환되지 않는 인터페이스를 가진 클래스들을 함께 쓸 수 있게 변환프록시 : 대리 객체 를 두어 실제 객체에 대한 접근을 제어데코레이터 : 객체에 기능을 동적으로 추가퍼사드 : 복잡한 서브시스템 앞에 단순한 통합 인터페이스 를 제공컴포지트 : 객체를 트리 구조 로 구성해 부분과 전체를 같은 방식으로 다룸옵서버 : 한 객체의 상태가 바뀌면 의존하는 다른 객체들에게 자동으로 알림 전략 : 알고리즘을 캡슐화해 교체 해서 쓸 수 있게 함방문자 : 자료 구조와 처리 기능을 분리 / 반복자: 내부 구조를 노출하지 않고 순차 접근중재자 (Mediator): 객체 사이의 통제·지시를 맡는 중재자를 둠 / 프로토타입 : 원본을 먼저 만들고 복제 해서 사용 / 브리지 : 구현부와 추상부를 분리소프트웨어 아키텍처 패턴 ★ 빈출
계층화 (Layers): 시스템을 계층으로 나눔. 각 계층은 바로 위 계층에 서비스 제공 (예: OSI 7계층)클라이언트-서버 : 하나의 서버와 여러 클라이언트파이프-필터 : 데이터 스트림을 여러 단계(필터)로 처리하고 파이프로 단방향 전달 (예: UNIX 쉘)MVC : 모델 (데이터·핵심 로직), 뷰 (사용자에게 표시), 컨트롤러 (입력을 받아 모델·뷰를 제어)마스터-슬레이브 : 마스터가 연산·통신·조정을 맡고 작업을 슬레이브에 나눠 결과를 모음. 주로 실시간 시스템, 장애 허용, 병렬 처리브로커: 분산 컴포넌트 사이의 통신을 중개 / 피어 투 피어: 각 피어가 클라이언트이자 서버 이벤트-버스: 이벤트를 채널로 전달 / 블랙보드: 공유 데이터로 해답을 찾음 (음성 인식 등) 아키텍처 설계 과정: 설계 목표 설정 → 시스템 타입 결정 → 스타일 적용·커스터마이즈 → 서브시스템 기능·인터페이스 작성 → 아키텍처 설계 검토 아키텍처 품질 속성: 시스템(가용성, 성능, 보안, 사용성 …), 비즈니스(시장 적시성, 비용 …), 아키텍처(정확성, 완전성, 일관성) 공통 모듈과 재사용
공통 모듈 : 여러 프로그램에서 공통으로 쓰는 기능을 모듈로 만든 것 (예: 날짜 처리, 로그인)공통 모듈 명세 원칙 : 정확성 , 명확성 , 완전성 , 일관성 , 추적성 정확성: 실제 시스템 구현에 필요한지 정확히 / 명확성: 하나의 의미로만 해석 / 완전성: 필요한 것을 빠짐없이 / 일관성: 다른 기능과 충돌 없이 / 추적성: 요구사항 출처를 추적 가능 재사용 규모 : 함수와 객체 → 컴포넌트 → 애플리케이션재사용의 이점: 개발 기간·비용 감소, 품질 향상, 생산성 향상 코드의 인터페이스 만 알면 내부 구현을 몰라도 쓸 수 있도록 설계 컴포넌트 : 독립적으로 존재할 수 있고 재사용되는 단위. 인터페이스 를 통해서만 접근협약에 의한 설계 (Design by Contract): 컴포넌트 명세에 선행 조건 (사용 전 참), 결과 조건 (사용 후 만족), 불변 조건 (실행 중 항상 만족)을 포함인터페이스 설계
인터페이스 요구사항과 검증
인터페이스: 서로 다른 두 시스템·장치·소프트웨어를 연결해 상호작용하게 하는 접점 시스템 인터페이스 구성 : 송신 시스템, 수신 시스템, 중계 서버 인터페이스 요구사항 검증 방법 : 요구사항 검토 (동료 검토, 워크스루, 인스펙션), 프로토타이핑 , 테스트 설계 , CASE 도구 활용검증 항목: 완전성, 일관성, 명확성, 기능성, 검증 가능성, 추적 가능성, 변경 용이성 인터페이스 대상 식별: 송·수신 시스템과 주고받는 데이터를 식별해 인터페이스 정의서 로 작성 데이터 교환 형식: JSON (속성-값 쌍), XML , CSV 등 EAI와 ESB ★ 빈출
EAI (기업 애플리케이션 통합): 기업 안의 여러 애플리케이션을 연계·통합하는 솔루션EAI 구축 유형 포인트 투 포인트 : 애플리케이션을 1:1 로 직접 연결. 변경·재사용이 어려움허브 앤 스포크 : 중앙 허브 를 거쳐 연결. 확장·유지보수 쉬움. 허브에 장애가 나면 전체 에 영향메시지 버스 : 애플리케이션 사이에 미들웨어(버스)를 둠. 뛰어난 확장성 , 대용량 처리하이브리드 : 그룹 안은 허브 앤 스포크, 그룹 사이는 메시지 버스ESB (엔터프라이즈 서비스 버스): 애플리케이션이 아니라 서비스 중심 통합. 표준 기반, 느슨한 결합(SOA 기반)미들웨어의 종류 ★ 빈출
미들웨어 : 운영체제와 응용 프로그램, 또는 클라이언트와 서버 사이에서 통신을 중개하는 소프트웨어DB 미들웨어: 애플리케이션과 원격 DB를 연결 (ODBC, IDAPI 등)RPC (원격 프로시저 호출): 원격 프로시저를 로컬 프로시저처럼 호출MOM (메시지 지향 미들웨어): 메시지 기반 비동기 통신. 이기종 분산 시스템 연결에 적합. 즉각 응답보다 느리고 안정적인 처리에 씀TP-Monitor (트랜잭션 처리 모니터): 온라인 트랜잭션을 처리·감시. 항공·철도 예약, 은행 업무처럼 사용자 수가 많고 빠른 응답이 필요한 곳ORB (객체 요청 브로커): 객체지향 미들웨어. CORBA 표준WAS (웹 애플리케이션 서버): 동적 웹 콘텐츠를 처리 (Tomcat, JEUS, WebLogic, WebSphere)인터페이스 상세 설계와 연계 기술
인터페이스 연계 방식 직접 연계 : 중계 서버 없이 송·수신 시스템이 직접 연결 (DB 링크, DB 연결, API, JDBC 등). 연계·통합이 단순하고 빠르지만 결합도가 높음간접 연계 : 중계 서버 나 솔루션(EAI, ESB, 웹 서비스)을 거침. 다양한 환경 연계, 장애 대응이 쉬우나 성능 저하·개발 비용 발생연계 기술 : DB Link, DB Connection, API /Open API, JDBC, 소켓 (Socket), 웹 서비스 (SOAP, WSDL, UDDI)웹 서비스 구성: SOAP (XML 기반 메시지 교환 프로토콜), WSDL (서비스를 설명하는 XML 문서), UDDI (서비스 정보를 등록·검색하는 저장소) 인터페이스 오류 처리: 화면에 오류 표시, 오류 로그 작성, 관련 테이블에 오류 기록 FEP (전위 처리기): 입력 데이터를 프로세서가 처리하기 전에 미리 처리해 처리 시간을 줄여 주는 프로그램·하드웨어소프트웨어 설계 OX 예시 문제 눌러서 정답과 해설을 확인하세요. 앱에는 소프트웨어 설계 연습문제가 133개 있어요.
폭포수 모형은 이전 단계로 되돌아가기 쉬워 요구사항 변경에 유연하다. 정답 X · 폭포수 모형은 순차적이라 앞 단계로 돌아가기 어렵고 요구사항 변경에 약해요.
프로토타입 모형은 견본(시제품)을 만들어 사용자의 요구를 정확히 파악하는 모형이다. 정답 O · 견본을 보여 주고 피드백을 받아 요구를 확정해요.
소프트웨어 생명주기 중 비용이 가장 많이 드는 단계는 유지보수 단계이다. 정답 O · 개발이 끝난 뒤 수정·개선하는 유지보수 비용이 가장 커요.
애자일 선언은 계획을 따르는 것보다 변화에 대응하는 것을 더 가치 있게 여긴다. 정답 O · 애자일 선언의 네 번째 가치예요.
XP에서는 두 사람이 한 컴퓨터에서 함께 코드를 작성하는 짝 프로그래밍을 실천한다. 정답 O · 짝 프로그래밍은 XP의 대표 실천 방법이에요.
기능 요구사항은 시스템의 성능, 보안, 품질처럼 시스템이 어떻게 동작해야 하는지에 대한 요구이다. 정답 X · 그것은 비기능 요구사항이에요. 기능 요구사항은 시스템이 무엇을 하는지예요.
인터뷰, 브레인스토밍, 설문은 요구사항 도출 기법이다. 정답 O · 이해관계자에게서 요구를 끌어내는 기법이에요.
인스펙션은 요구사항 명세서 작성자를 제외한 다른 전문가들이 명세서를 확인하면서 결함을 찾는 방법이다. 정답 O · 작성자를 빼고 전문가가 공식적으로 검토해요.
비정형 명세 기법은 수학적 기호를 사용하므로 사용자가 이해하기 어렵다. 정답 X · 이해하기 어려운 것은 정형 명세예요. 비정형은 자연어라 이해하기 쉬워요.
DFD에서 프로세스는 원(버블)으로 표시하며, DFD를 버블 차트라고도 한다. 정답 O · 프로세스를 원으로 그려서 버블 차트라고도 해요.
소프트웨어 설계 요약을 빈칸 암기 로 외우고, OX·객관식 문제 와 실전 모의고사 로 확인해 보세요. 틀린 문제는 1·3·7·14·30일 간격으로 다시 나와요. 회원가입 없이 무료예요.
자격공부노트에서 정보처리기사 공부하기 정보처리기사 다른 과목