영웅은 죽지 않는다

소프트웨어 설계 (정보처리기사 필기 1과목) 본문

Programming/Certificate

소프트웨어 설계 (정보처리기사 필기 1과목)

YoungWoong Park 2022. 4. 11. 22:05

정처기 1과목이 다른 과목에 비해 암기가 많아서,, 여러 블로그나 영상 참고해서 정리한

내가 공부하려고 쓴 필기 메모장

 

 

요구사항 확인

01 소프트웨어 생명 주기

  • 폭포수 모형
    • 폭포에서 한번 떨어진 물을 거슬러 올라갈 수 없듯이 소프트웨어 개발도 이전 단계로 돌아갈 수 없음
    • 가장 오래되고 가장 폭넓게 사용된 고전적 생명 주기 모형
    • 개발 과정의 한 단계가 끝나야만 다음 단계로 넘어가는 선형 순차적 모형
    • 단계별 정의 및 산출물이 명확
    • 개발 중간 요구사항 변경이 용이하지 않음
    • 타당성 검토 → 계획 → 요구 분석 → 설계 → 구현(코딩) → 시험(검사) → 유지보수 (분설구테유)
  • 프로토 타입 모형 (원형 모형) **
    • 사용자 요구사항 정확히 파악하기 위해 견본(시제)품을 만들어 최종 결과물을 예측
    • 인터페이스 중점 두어 개발
    • 개발 중간 요구사항 변경 용이
    • 요구 수집 → 빠른 설계 → 프로토타입 구축 → 고객 평가 → 프로토타입 조정 → 구현
  • 나선형 모형 (점진적 모형)
    • 폭포수 모형 + 프로토타입 모형 + 위험 분석 기능
    • 점진적 개발 과정 반복 → 요구사항 추가 기능
    • 정밀, 위험 최소화, 유지보수 과정 필요 없음
    • 계획 및 정의 → 위험 분석 → 공학적 개발 → 고객 평가 (계위개고)
  • 애자일 모형 ***
    • 애자일 : 민첩함, 기민함
    • 개발 과정에서 일정한 주기 반복 → 요구사항 변화에 유연하게 대응
    • 절차와 도구보다 고객과의 소통에 초점.
    • 소프트웨어 개발 모형
      • 스크럼
      • XP
      • 칸반
      • Lean, 크리스탈
      • ASD 등
    • 핵심 가치
      • 프로세스와 도구보다는 개인과 상호작용에 더 가치를 둔다.
      • 방대한 문서보다는 실행되는 SW에 더 가치를 둔다.
      • 계약 협상보다는 고객과 협업에 더 가치를 둔다.
      • 계획을 따르기보다는 변화에 반응하는 것에 더 가치를 둔다.

02 스크럼 기법

  • 스크럼
    • 팀원 스스로가 스크럼 팀 구성
    • 팀이 중심이 되어 개발의 효율성을 높임
    • 개발 작업에 관한 모든 것을 스스로 해결
  1. 제품 책임자 (PO, Product Owner)
    1. 제품에 대한 이해도가 높고, 요구사항 책임지고 의사결정
    2. 요구사항이 담긴 백로그(Backlog) 작성 및 우선순위 지정 (백로그 : 제품 개발에 필요한 요구사항 모두 모아 우선순위 부여한 목록)
  2. 스크럼 마스터 (SM, Scrum Master)
    1. 일일 스크럼 회의 주관
    2. 스크럼 잘 수행할 수 있도록 객관적인 시각에서 조언, 가이드 역할
    3. 진행 사항 점검, 장애 요소 공론화해 처리
    4. 팀원 통제하는 것이 목표가 아님
  3. 개발팀 (DT, Development Team)
    1. PO와 SM을 제외한 모든 팀원
    2. 백로그에 작성되는 요구사항 추가 가능, 우선순위 지정 불가
    3. 최대 인원 7-8명
  • 개발 프로세스
    1. 제품 백로그 (Product Backlog)
      1. 제품 개발에 필요한 요구사항 우선순위에 따라 나열한 목록
      2. 사용자 스토리 기반 릴리즈 계획(전체 일정 계획)
    2. 스프린트 계획 회의
    3. 스프린트
    4. 일일 스크럼 회의
    5. 스프린트 검토 회의
    6. 스프린트 회고
    계스일검회

03 XP (eXtream Programming)

  • XP : 수시로 발생하는 요구사항에 유연하게 대응하기 위해 고객 참여, 개발과정의 반복 극대화 → 개발 생산성 향상
  • 핵심 가치
    • 용기
    • 단순성
    • 의사소통
    • 피드백
    • 존중
    용단의피존
  • 개발 프로세스
    • 사용자 스토리 : 고객 요구사항을 간단한 시나리오로 표현
    • 릴리즈 계획 수립 : 부분적으로 기능이 완료된 제품을 제공
    • 스파이크 : 요구사항 신뢰성 높이고 위험 감소하기 위해 만드는 간단한 프로그램
    • 주기 : 하나의 릴리즈를 더 세분화
    • 승인 검사 : 릴리즈 단위 부분 완료 제품이 구현되면 수행하는 테스트
    • 소규모 릴리즈 : 릴리즈를 더욱 소규모로 하여 고객 반응 기능별 확인, 요구사항에 유연하게 대응
  • 기본 원리 및 주요 실천 방법
    • Whole Team (전체 팀)
    • Small Releases (소규모 릴리즈)
    • Test-Driven Development (테스트 주도 개발)
    • Continuous Integration (계속적인 통합)
    • Collective Ownership (공동 소유권)
    • Pair Programming (짝코딩)
    • Design Improvement (디자인 개선) or Refactoring (리팩토링)

04 현행 시스템 파악 절차

  • 1단계 : 시스템 구성 파악, 시스템 기능 파악, 시스템 인터페이스 파악
  • 2단계 : 아키텍처 구성 파악, 소프트웨어 구성 파악
  • 3단계 : 하드웨어 구성 파악, 네트워크 구성 파악

05 개발 기술 환경 파악

  1. 운영체제
    1. 컴퓨터 시스템의 자원 효율적으로 관리 및 사용자가 컴퓨터를 편리하고 효율적으로 사용할 수 있도록 환경 제공
    2. 하드웨어가 아닌 소프트웨어
    3. 요구사항 식별 시 고려 사항
      1. 가용성
      2. 성능
      3. 기술지원
      4. 주변기기
      5. 구축비용
    4. Windows, UNIX, Linux, Mac OS, iOS, Android 등
  2. 미들웨어
    1. 운영체제와 응용 프로그램 사이에서 운영체제가 제공하는 서비스 이외에 추가적인 서비스를 제공하는 소프트웨어
  3. 오픈 소스
    1. 누구나 별다른 제한 없이 사용할 수 있도록 소스 코드를 공개, 무료 사용
    2. 요구사항 식별 시 고려사항
      1. 라이선스의 종류
      2. 사용자 수
      3. 기술의 지속 가능성
  4. 총 소유 비용(T0C) : 자산을 획득하려고 할 때 지정된 기간 동안 발생할 수 있는 모든 직간접 비용
  5. 데이터베이스 관리 시스템 (DBMS)
    1. 사용자와 데이터베이스 사이에서 사용자의 요구에 따라 정보 생성, DB 관리
    2. 기존 파일 시스템이 갖는 데이터 종속성, 중복성 문제 해결하기 위해 제안된 시스템
    3. JDBC : 자바와 DB 연결해주는 인터페이스
    4. ODBC : 응용 프로그램과 DB 연결해주는 인터페이스
    5. Oracle, IBM, MySQL, SQLite, MongoDB, Redis 등
    6. 요구사항 식별 시 고려사항
      1. 가용성
      2. 성능
      3. 기술지원
      4. 상호 호환성
      5. 구축 비용
  6. 웹 애플리케이션 서버 (WAS : Web Application Server)
    1. 정적 콘테츠 처리하는 웹 서버와 반대
    2. 사용자의 요구에 따라 변하는 동적인 콘텐츠 처리하기 위해 사용되는 미들웨어(소프트웨어)
    3. 데이터 접근, 세션 관리, 트랜잭션 관리 등을 위한 라이브러리 제공
    4. Tomcat, JEUS, WebLogic 등
    5. 요구사항 식별 시 고려사항
      1. 가용성
      2. 성능
      3. 기술지원
      4. 구축 비용

06 요구사항 정의

  • 어떠한 문제를 해결하기 위해 필요한 조건이나 제약사항 요구하는 것
  • 유형
    • 기능 요구사항
      • 기능, 입력, 출력, 저장, 연산 수행
    • 비기능 요구사항
      • 구성, 성능, 인터페이스, 데이터, 보안, 품질, 제약 사항
    • 사용자 요구사항
    • 시스템 요구사항
  • 요구사항 개발 프로세스
    • 도출(추출) → 분석 → 명세 → 확인(검증)
    • 도분명확

07 요구사항 분석 기법

  • 요구사항 분류
  • 개념 모델링 (UML)
  • 요구사항 할당
  • 요구사항 협상
  • 정형분석

08 요구사항 확인 기법

  • 요구사항 검토
  • 프로토타이핑
  • 모델 검증
  • 인수 테스트 (알파 테스트, 베타 테스트)

09 UML (Unified Modeling Language)

  • 개발자와 고객 또는 개발자 상호 간의 의사소통이 원활하게 이루어지도록 표준화한 대표적인 객체지향 모델링 언어
  • 구성 요소
    1. 사물
      1. 모델을 구성하는 가장 중요한 기본 요소
      2. 구조, 행동, 그룹, 주해(사물) (구행그주)
    2. 관계
      1. 사물과 사물 사이의 연관성 표현
      2. 연관, 집합, 포함, 일반화, 의존, 실체화 (연집포 일의실)
    3. 다이어그램
      1. 사물과 관계를 도형으로 표현
      2. 구조적 다이어그램 (정적)
        1. 클래스 : 클래스, 속성, 관계 표현
        2. 객체
        3. 컴포넌트 : 구현 단계에서 사용
        4. 배치 : 구현 단계에서 사용, 물리적 요소 위치 표현
        5. 복합체 구조
        6. 패키지
      3. 행위 다이어그램 (동적)
        1. 유스케이스 : 모델링 작업에서 사용
        2. 시퀀스 : 시스템, 메시지 고현
        3. 커뮤니케이션 : 메시지, 연관 표현
        4. 상태
        5. 활동
        6. 상호작용 개요
        7. 타이밍
      4. 시퀀스 다이어그램
        1. 액터
        2. 활성 객체
        3. 라이프라인(생명선)
        4. 메세지
        5. 제어 삼각형
화면 설계

10. 사용자 인터페이스 (UI, User Interface)

  • 사용자와 시스템 간의 상호작용이 원활하게 이루어지도록 하는 장치
  • 소프트웨어
  • 물리적 제어, 기능, 콘텐츠의 상세 표현과 전체적 구성에 관한 분야로 이루어짐
  • 특징
    • 소프트웨어 영역 중 변경이 가장 많이 발생
    • 사용자 만족도에 가장 큰 영향
    • 수행 결과 오류를 줄임
    • 작업 시간 단축 및 업무 이해도 높임
    • 편리성과 가독성 높임
    • 소프트웨어 아키텍처 숙지 필요
  • 사용자 인터페이스 구분
    • CLI (Command Line Inferface) : 명령과 출력이 텍스트 형태로 이뤄짐
    • GUI (Graphical User Interface) : 아이콘, 메뉴를 마우스로 선택하여 작업을 하는 그래픽 환경
    • NUI (Natural User Interface) : 사용자의 말이나 행동으로 기기를 조작
    • VUI (Voice User Interface) : 사용자의 음성으로 기기 조작
    • OUI (Organic User Interface) : 모든 사물과 사용자 간의 상호작용
  • 사용자 인터페이스 기본 원칙
    • 직관성 : 누구나 쉽게 이해
    • 유효성 : 사용자 목적을 정확하고 완벽하게 달성
    • 학습성 : 누구나 쉽게 배우고 익힘
    • 유연성 : 사용자의 요구사항 최대한 수용, 실수 최소화

11. 사용자 인터페이스 표준 및 지침

  • 웹의 3요소
    • 웹 표준
    • 웹 접근성
    • 웹 호환성
  • UI 표준 및 지침을 토대로 웹의 3대 요소가 고려되었는지 확인

12. UI 설계 도구

사용자의 요구사항에 맞게 UI의 화면 구조, 배치 등을 설계할 때 사용하는 도구

  1. 와이어프레임 (Wireframe) : 페이지의 레이아웃, UI 요소 등의 뼈대 협의, 설계
  2. 목업 (Mockup) : 실제 화면과 유사하게 만든 정적인 모형
  3. 스토리보드 (Story Board) : 최종적으로 참고하는 작업 지침서, 와이어프레임에 대한 설명과 페이지 간 이동 흐름 등 추가
  4. 프로토타입 (Prototype) : 와이어프레임, 스토리보드 등에 인터랙션 적용 → 구현된 것처럼 테스트 가능한 동적 형태의 모형
  5. 유스케이스 (Use Case) : 사용자 측면에서의 요구사항을 다이어그램 형식으로 묘사
  • UI 프로토타입
    1. 장점 : 사용자를 설득하고 이해시키기 쉬움
    2. 단점 : 작업시간 증가 및 자원 소모, 부분적인 프로토타이핑으로 인한 중요한 작업 생략 가능성
    • 프로토타이핑 종류
      • 페이퍼 프로토타입
      • 디지털 프로토타입
    • 제작 단계
      • 1단계 : 사용자의 요구사항 분석
      • 2단계 : 요구사항 충족하는 프로토타입 작성
      • 3단계 : 작성된 프로로타입이 요구사항 잘 수행하고 있는지 사용자가 직접 확인
      • 4단계 : 작성된 프로토타입 기반한 수정과 합의

13. UI 요구사항 확인 ***

  1. 목표 정의
  2. 활동 사항 정의
  3. UI 요구사항 작성
  • UI 시나리오 문서 요건
    • 이해성
    • 완전성
    • 일관성
    • 가독성
    • 수정 용이성
    • 추적 용이성

14. UI 설계서 작성 순서

  1. UI 설계서 표지 작성
  2. UI 설계서 개정 이력 작성
  3. UI 요구사항 정의서 작성
  4. 시스템 구조 작성
  5. 사이트 맵 작성
  6. 프로세스 정의서 작성
  7. 화면 설계

15. UI 시나리오 문서

  • 문서 요건
    • 완전성, 일관성, 이해성, 가독성, 수정 용이성, 추적 용이성

16. HCI / UX / 감성공학

  • HCI(Human Computer Interaction or Interface)
    • 사람과 컴퓨터의 상호작용 연구하여 최적의 사용자 경험(UX)을 만듦
    • 시스템을 보다 편리하고 안전하게 사용하도록 만드는 학문
  • UX(User Experience)
    • 사용자가 시스템이나 서비스를 이용하면서 느끼고 생각하는 총체적인 경험
    • 주관성, 정황성, 총체성
  • 감성공학
    • 제품이나 작업환경을 사용자의 감성에 알맞도록 설계 및 제작하는 기술
    • 인간의 감성, 심리적 기능, 공학적 및 수학적 모델
    • 기반 기술, 구현 기술, 응용 기술

17. 품질 요구사항

  • 소프트웨어의 품질 : 기능, 성능, 만족도 등 소프트웨어 요구사항이 얼마나 충족하는가를 나타내는 특성의 총체
  • 국제 제품 품질 표준 및 제시하는 요구사항
    1. ISO/IEC 9126
      1. 기능성
        1. 사용자의 요구사항을 정확하게 만족하는 기능 제공하는지 여부
        2. 적절성(적합성), 정확성, 상호 운용성, 보안성, 호환성
      2. 신뢰성
        1. 소프트웨어가 요구된 기능을 정확하고 일관되게 오류 없이 수행할 수 있는 정도
        2. 성숙성, 결함 허용성, 회복성
      3. 사용성
        1. 사용자가 정확하게 이해하고 사용하며 향후 다시 사용하고 싶은 정도
        2. 이해성, 학습성, 운용성, 친밀성
      4. 효율성
        1. 할당된 시간 동안 한정된 자원으로 사용자가 요구하는 기능을 얼마나 빨리 처리하는지 정도
        2. 분석성, 변경성, 안전성, 시험성
      5. 유지 보수성
        1. 환경의 변화에 소프트웨어를 쉽게 개선, 확장, 수정할 수 있는지 정도
        2. 분석성, 변경성, 안정성, 시험성
      6. 이식성
        1. 소프트웨어가 다른 환경에서도 얼마나 쉽게 적응할 수 있는지 정도
        2. 적용성, 설치성, 대체성, 공존성
    2. ISO/IEC 14598
      1. 반복성
      2. 재현성
      3. 공정성
      4. 객관성
    3. ISO/IEC 25000 : SW 품질 평가 통합 모델, SQuaRE
애플리케이션 설계

18. 소프트웨어 아키텍처

  • 사용자의 비기능적 요구사항으로 나타난 제약 반영
  • 기능적 요구사항을 구현하는 방법을 찾는 해결 과정
  1. 모듈화
    1. 소프트웨어 성능을 향상시커거나 시스템의 성능 및 재사용성을 향상시키기 위해 시스템의 기능들을 모듈 단위로 나누는 것
    2. 모듈의 크기를 너무 크게 하면 → 모듈의 개수가 적어져 모듈 하나의 개발 비용이 많이 듦
    3. 모듈의 크기를 너무 작게 하면 → 모듈의 개수가 많아져 모듈 간의 통합 비용이 많이 듦
  2. 추상화
    1. 전체적이고 포괄적인 개념을 설계한 후 차례로 세분화하여 구체화시키는 것
    2. 불필요한 부분은 생략하고 필요한 부분을 강조해 모델화
    3. 유형
      1. 과정 추상화 : 자세한 수행 과정 정의 x, 전반적 흐름만 파악
      2. 데이터 추상화 : 데이터의 세부적인 속성이나 용도 정의 x, 데이터 구조를 대표하는 표현으로 대체
      3. 제어 추상화 : 이벤트 발생의 정확한 절차나 방법 정의 x, 대표하는 표현으로 대체
      (과데제)
  3. 단계적 분해
    1. 하향식 설계 전략
    2. 추상화의 반복에 의해 세분화
    3. 상세한 내역은 가능한 뒤로 미루어 진행
  4. 정보 은닉
    1. 한 모듈 내부에 포함된 절차와 자료들의 정보가 감추어져, 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법
    2. 모듈 변경 시 영향을 받지 않고 독립적 → 수정, 시험 , 유지보수 용이
  • 소프트웨어 아키텍처 품질 속성
    • 시스템 측면 : 성능, 보안, 가용성, 기능성 등
    • 비즈니스 측면 : 시장 적시정, 비용과 혜택 등
    • 아키텍처 측면 : 개념적 무결성, 정확성, 완결성 등
  • 소프트웨어 아키텍처 설계 과정
    1. 설계 목표 설정
    2. 시스템 타입 결정
    3. 아키텍처 패턴 적용
    4. 서브시스템 구체화
    5. 검토

19. 아키텍처 패턴

  • 아키텍처를 설계할 때 참조할 수 있는 전형적인 해결 방식, 예제
    • 장점 : 시행착오 줄임, 예측 가능, 안정적 개발
  • 종류
    1. 레이어 패턴
      1. 시스템 계층으로 구분해 구성하는 고전적인 방법
      2. OSI 참조 모델 **
    2. 클라이언트-서버 패턴
      1. 하나의 서버 컴포넌트와 다수의 클라이언트 컴포넌트로 구성되는 패턴
        1. 컴포넌트 : 아키텍처 패턴, 독립적인 업무 또는 기능을 수행하는 실행코드 기반 작성된 모듈
      2. 클라이언트는 서버 요청, 응답을 받기 위해 서로 독립, 항상 대기 상태 유지
    3. 파이프-필터 패턴
      1. 데이터 스트림 절차의 각 단계를 필터 컴포넌트로 캡슐화하여 파이프를 통해 데이터 전송
      2. 재사용성 좋고 확장 용이
      3. 필터 컴포넌트 재배치 가능 → 다양한 파이프라인 구축 가능
      4. UNIX의 쉘(Shell)
    4. 모델-뷰-컨트롤러 패턴 ***
      1. 서브시스템을 3개의 부분으로 구조화 (MVC)
        1. 모델 (Model) : 서브시스템의 핵심 기능과 데이터를 보관
        2. 뷰 (View) : 사용자에게 정보를 표시
        3. 컨트롤러 (Controller) : 사용자로부터 받은 입력 처리
      2. 각 부분은 별도의 컴포넌트로 분리 → 서로 영향받지 않음
      3. 대화형 애플리케이션에 적합
    5. 기타 패턴
      1. 마스터-슬레이브 패턴 : 마스터 컴포넌트에서 슬레이브 컴포넌트로 작업 분할, 슬레이브 컴포넌트에서 처리된 결과물 다시 돌려받음
      2. 브로커 패턴 : 컴포넌트와 사용자를 연결
      3. 피어-투-피어 패턴 : 피어를 하나의 컴포넌트로 간주
      4. 이벤트-버스 패턴 : 소스가 특정 채널에 이벤트 메시지를 발생하면, 해당 채널을 구독한 리스너들이 메시지를 받아 이벤트 처리
      5. 블랙보드 패턴 : 검색을 통해 원하는 데이터 찾음. 해결책 명확하지 않은 문제 해결
      6. 인터프리터 패턴 : 특정 언어로 작성된 프로그램 코드 해석하는 컴포넌트 설계 시 사용

20. 객체지향

  • 객체지향
    • 현실 세계의 객체를 기계 부품처럼 하나의 객체로 만들어 부품들을 조립해 제품을 만드는 것
    • 소프트웨어 재사용 및 확장 용이, 유지보수 쉬움
    • 단계적 계층적
    • 구성요소 : 객체, 클래스, 캡슐화, 상속, 다형성 등
  1. 객체 (Object)
    1. 데이터와 데이터를 처리하는 함수를 묶어 놓은 하나의 소프트웨어 모듈
    2. 객체와 객체는 상호 연관성에 의한 관계가 형성됨
    3. 독립적으로 식별 가능한 이름 가짐
    4. 연산(Method)
      1. 객체가 반응할 수 있는 메시지의 집합
      2. 클래스로부터 생성된 객체를 사용하는 방법
    5. 상태(State) : 객체가 가질 수 있는 조건
  2. 클래스 (Class) **
    1. 하나 이상의 유사한 객체들을 묶어서 하나의 공통된 특성을 표현한 것
    2. 공통된 속성과 연산(행위)을 갖는 객체의 일반적인 타입
    3. 객체지향 프로그래밍에서 데이터를 추상화하는 단위
    4. 각각의 객체들이 갖는 속성과 연산을 정의하고 있는 틀
    5. 인스턴스 : 클래스에 속한 각각의 객체
    6. 슈퍼(상위) 클래스, 서브(하위) 클래스
  3. 캡슐화 **
    1. 데이터(속성)와 데이터를 처리하는 함수를 하나로 묶는 것
    2. 인터페이스 제외한 세부 내용이 정보은닉되어 외부 접근 제한
    3. 파급 효과 적고, 불필요한 기능 최소화
    4. 재사용 용이, 개발 비용 절감 및 개발 속도 향상
    5. 인터페이스 단순해짐
  4. 상속
    1. 상위 클래스의 모든 속성과 연산을 하위 클래스가 물려받는 것
    2. 소프트웨어의 재사용을 높임
  5. 다형성
    1. 하나의 메시지에 대해 각각의 객체(클래스)가 가지고 있는 특성으로 여러 가지 형태의 응답하는 것

21. 결합도, 모듈

  • 모듈
    • 모듈화를 통해 분리된 시스템의 각 기능
    • 모듈의 독립성은 결합도와 응집도에 의해 측정됨
    • 결합도 낮을수록, 응집도 강할수록, 모듈의 크기가 작을수록 → 독립성이 높음
    • 독립성이 높을수록 → 수정 시 다른 모듈에 영향 적고 오류 발생해도 쉽게 해결 가능
  • 결합도
    • 모듈 간 상호 의존하는 정도
    • 두 모듈 사이의 연관관계
    • 결합도 낮으면 → 유지보수 쉬움, 독립적
    • 종류 (결합도 강(Bad)→ 약(Good) 순) **
      1. 내용 결합도
        1. 한 모듈이 다른 모듈의 내부 기능 및 그 내부 자료를 직접 참조하거나 수정할 때의 결합도
      2. 공통 결합도
        1. 공유되는 공통의 영역을 여러 모듈이 사용할 때의 결합도 (전역 변수)
      3. 외부 결합도
        1. 어떤 모듈에서 선언한 데이터(변수)를 외부의 다른 모듈에서 참조할 때의 결합도
      4. 제어 결합도
        1. 어떤 모듈이 다른 모듈 내부의 논리적인 흐름을 제어하기 위해, 제어 신호를 이용해 통신하거나 제어 요소를 전달하는 결합도
      5. 스탬프 결합도
        1. 모듈 간의 인터페이스로 배열이나 레코드 등의 자료 구조가 전달될 때의 결합도
      6. 자료 결합도
        1. 다른 모듈 호출 시 매개 변수(파라미터)나 인수로 데이터 넘겨줌
        2. 호출받은 모듈은 받은 데이터에 대한 처리 결과를 다시 돌려줌
      (내공외제스자)
  • 응집도
    • 모듈의 내부 요소들의 서로 관련되어 있는 정도
    • 정보 은닉 개념을 확장한 것
    • 응집도 높으면 → 품질 높음, 독립적
    • 종류 (응집도 약(Bad) → 강(Good) 순)
      1. 우연적 응집도
        1. 모듈 내부의 각 구성 요소들이 서로 관련 없는 요소로만 구성된 경우
      2. 논리적 응집도
        1. 유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들로 하나의 모듈이 형성되는 경우의 응집도
      3. 시간적 응집도
        1. 특정 시간에 처리되는 몇 개의 기능을 모아 하나의 모듈로 작성할 경우의 응집도
      4. 절차적 응집도
        1. 모듈이 다수의 관련 기능을 가질 때, 모듈 안의 구성 요소들이 그 기능을 순차적으로 수행할 경우의 응집도
      5. 통신(교환)적 응집도
        1. 동일한 입력과 출력을 사용하여, 서로 다른 기능을 수행하는 구성 요소들이 모였을 경우의 응집도
      6. 순차적 응집도
        1. 모듈 내 하나의 활동으로부터 나온 출력 데이터를 그 다음 활동의 입력 데이터로 사용할 경우의 응집도
      7. 기능적 응집도
        1. 모듈 내부의 모든 기능 요소들이 단일 문제와 연관되어 수행될 경우의 응집도

22. 공통 모듈

  • 여러 프로그램에서 공통적으로 사용할 수 있는 모듈
  • 명세 기법
    1. 정확성 : 시스템 구현 시 해당 기능이 필요하다는 것을 알 수 있도록 정확히 작성
    2. 명확성 : 해당 기능에 대해 일관되게 이해하고, 한 가지로 해석되고 중의적으로 해석되지 않도록 명확하게 작성
    3. 완전성 : 시스템 구현을 위해 필요한 모든 것을 기술
    4. 일관성 : 공통 기능들 간 상호 충돌이 발생하지 않도록 작성
    5. 추적성 : 기능에 대한 요구사항의 출처, 관련 시스템 등의 관계를 파악할 수 있도록 작성
  • 재사용
    • 비용과 개발 시간을 절약하기 위해 이미 개발된 기능 파악 및 재구성
    • 새로운 시스템 또는 기능 개발에 사용하기 적합하도록 최적화
    • 규모에 따라 분류 → 함수와 객체, 컴포넌트, 애플리케이션
  • 효과적인 모듈 설계
    • 결합도 줄이고 응집도 높임
    • 복잡도와 중복성 줄이고 일관성 유지
    • 유지보수 용이
    • 모듈 인터페이스 설계

23. 코드

  • 종류
    • 순차(순서) 코드 : 일정 기준에 따라 최초의 자료부터 차례로 일련번호 부여
    • 블록 코드 : 공통성이 있는 것끼리 블록으로 구분, 각 블록 내에서 일련번호 부여
    • 10진 코드 : 10진 분할, 다시 각각에 대해 10진 분할 → 필요한 만큼 반복
    • 그룹 분류 코드 : 일정 기준에 따라 대분류, 중분류, 소분류 등으로 구분, 각 그룹 안에서 일련번호 부여
    • 연상 코드 : 항목의 명칭이나 약호와 관계있는 숫자, 문자, 기호 등 이용하여 코드 부여
    • 표의 숫자 코드 : 항목의 물리적 수치(길이, 넓이, 부피 등)를 그대로 코드에 적용
    • 합성 코드 : 2개 이상의 코드를 조합
  • 코드 부여 체계
    • 이름만으로 개체의 용도와 적용 범위를 알 수 있도록 코드를 부여하는 방식
    • 각 객체에 유일한 코드 부여하여 개체들의 식별 및 추출을 용이하게 함
    • 코드 부여하기 전, 각 단위 시스템의 고유한 코드와 개체를 나타내는 코드가 정의되어야 함

24. 디자인 패턴

  • 각 모듈의 세분화된 역할이나 구현 방안을 설계할 때 참조할 수 있는 해결 방식
  • 아키텍처 패턴이 디자인 패턴보다 상위 수준의 설계에 사용됨
    • 아키텍처 패턴 : 전체 시스템의 구조를 설계하기 위한 참조 모델
    • 디자인 패턴 : 서브시스템에 속하는 컴포넌트들과 그 관계를 설명하기 위한 참조 모델
  1. 생성 패턴
    1. 객체의 생성과 참조 과정을 캡슐화 → 객체가 생성/변경되어도 프로그램 구조에 영향을 크게 받지 않도록 해줌
    2. 추상 팩토리 : 서로 연관, 의존하는 객체들을 그룹으로 생성 → 추상적으로 표현
    3. 빌더 : 객체의 생성 과정과 표현 방법을 분리 → 이를 조합하여 새로운 객체 생성
    4. 팩토리 메소드 : 객체를 생성하기 위한 인터페이스 정의, 객체 생성 및 인스턴스화를 서브 클래스에 처리하도록 분리
    5. 프로토타입 : 원본 객체를 복제, 객체를 생성
    6. 싱글톤 : 하나의 객체를 여러 프로세스가 동시에 참조할 수 없음
  2. 구조 패턴
    1. 클래스나 객체들을 조합하여 더 큰 구조로 만들 수 있게 해주는 패턴
    2. 어댑터 : 호환성이 없는 클래스를 변환
    3. 브리지 : 구현부에서 추상층을 분리하여 독립적으로 확장
    4. 컴포지트 : 여러 객체를 가진 복합, 단일 객체를 구분 없이 다룰 때 사용
    5. 데코레이터 : 상속을 사용하지 않고도 객체 기능을 능동적으로 확장
    6. 퍼싸드 : 서브 클래스들의 기능을 간편하게 사용
    7. 플라이웨이트 : 공유해서 사용함으로써 메모리를 절약
    8. 프록시 : 접근이 어려운 객체를 연결 -> 인터페이스 역할 수행
  3. 행위 패턴
    1. 하나의 객체로 수행할 수 없는 작업을 여러 객체로 분배 → 결합도 최소화
    2. 책임 연쇄 : 한 객체 처리 못하면 다음 객체로 넘어감
    3. 커맨드 : 요청에 사용되는 각종 명령어들을 분리하여 단순화, 캡슐화
    4. 인터프리터 : 언어에 문법 표현 정의
    5. 반복자 : 동일한 인터페이스 사용
    6. 중재자 : 복잡한 상호작용 캡슐화
    7. 메멘토 : 객체를 해당 시점의 상태로 돌림
    8. 옵서버 : 관찰 대상의 변화 탐지. 상태 전달
    9. 상태 : 상태에 따라 동일한 동작을 다르게 처리해야 할 때
    10. 전략 : 동일한 계열의 알고리즘을 개별적으로 캡슐화
    11. 템플릿 메소드 : 상위 클래스에서 공통된 내용(골격) 정의, 하위 클래스에서 세부 처리 구체화
    12. 방문자 : 필요할 때마다 해당 클래스에 방문해서 처리
인터페이스 설계

25. 시스템 인터페이스 요구사항 분석

  • 독립적으로 떨어져 있는 시스템들끼리 서로 연동하여 상호작용하기 위한 접속 방법이나 규칙
  • 인터페이스 요구 사항 검토 계획 수립 → 검토 및 오류 수정 → 베이스라인 설정
  • 요구사항 검증 방법
    1. 동료 검토
      1. 요구사항 명세서 작성자가 내용을 직접 설명하고 동료들이 이를 들으면서 결함 발견
    2. 워크 스루
      1. 검토회의 전에 요구사항 명세서를 미리 배포하여 사전 검토 후, 짧은 검토 회의를 통해 결함 발견
    3. 인스펙션
      1. 요구사항 명세서 작성자를 제외한 다른 검토 전문가들이 확인하면서 결함 발견
    4. 프로토타이핑
      1. 실제 개발될 소프트웨어에 대한 견본품을 만들어 최종 결과물 예측
    5. 테스트 설계
      1. 테스트 케이스를 생성해 이후에 요구사항이 현실적으로 테스트 가능한지 검토
    6. CASE 도구 활용
      1. 일관된 분석을 통해 요구사항 변경사항의 추적, 분석, 관리, 표준 준수 여부 확인
  • 요구사항 검증 주요 항목
    • 기능성
    • 완전성
    • 일관성
    • 명확성
    • 검증 가능성
    • 추적 가능성
    • 변경 용이성

26. 인터페이스 시스템 식별

  1. 인터페이스 식별
    1. 인터페이스 요구사항 명세서, 목록 기반으로 개발할 시스템과 이와 연계할 내/외부 시스템 사이의 인터페이스를 식별하고 인터페이스 목록 작성
  2. 인터페이스 시스템 식별
    1. 인터페이스에 참여하는 시스템들을 송수신 시스템으로 구분하여 작성
  • 송수신 데이터 식별
    • 송수신 시스템 사이에서 교환되는 데이터
    • 규격화된 표준 형식에 따라 전송됨
    • 교환되는 데이터 종류
      1. 인터페이스 표준 항목
        1. 시스템 공통부 : 시스템 간 연동 시 필요한 공통 정보
          1. 인터페이스 ID, 전송 시스템 정보, 서비스 코드 정보, 장애 정보 등
        2. 거래 공통부 : 시스템들이 연동된 후 송수신 데이터 처리할 때 필요한 정보
          1. 직원 정보, 승인자 정보, 기기 정보, 매체 정보 등
      2. 송수신 데이터 항목
      3. 공통 코드

27. 인터페이스 방법 명세화

  • 내외부 시스템이 연계하여 작동할 때 데이터를 주고받는 방법, 주고 받는 데이터의 종류, 에러 발생 시 처리해야 할 내용들을 문서로 명확하게 정리하는 것
  1. 시스템 연계 기술
    1. 직접 연결 방식
      1. DB 링크 : 수신 시스템에서 DB Link를 생성하고 송신 시스템에서 해당 DB Link를 직접 참조하는 방식
      2. API/Open API : 송신 시스템의 DB에서 데이터를 읽어와 제공하는 Application Programming Interface Program
    2. 간접 연결 방식
      1. 소켓(Socket) : 서버는 통신을 위한 소켓을 생성해 포트를 할당, 통신 요청 시 클라이언트와 연결
      2. 웹 서비스
  2. 인터페이스 통신 유형
    1. 단방향 : 시스템에서 거래 요청만 하고 응답이 없는 방식
    2. 동기 : 시스템에서 거래 요청하고 응답이 올 때까지 대기하는 방식
    3. 비동기 : 시스템에서 거래 요청하고 다른 작업을 수행하다 응답이 오면 처리하는 방식
  3. 인터페이스 처리 유형
    1. 실시간 방식 : 사용자가 요청한 내용을 바로 처리해야 할 때
    2. 지연 처리 방식 : 매건 단위 처리로 비용이 많이 발생할 때
    3. 배치 방식 : 대량의 데이터를 처리할 때
  4. 인터페이스 발생 주기
    1. 개발할 시스템과 내외부 시스템 간 송수신 데이터가 전송되어 인터페이스가 사용되는 주기
    2. 매일, 수시, 주 1회 등

28. 미들웨어 솔루션 명세

  • 운영체제와 해당 운영체제에서 실행되는 응용 프로그램 사이에서 운영체제가 제공하는 서비스 이외에 추가적인 서비스를 제공하는 소프트웨어
  • 클라이언트와 서버 간 통신을 효율적으로 수행하도록 도와줌
  1. DB(Database)
    • 클라이언트에서 원격의 데이터베이스와 연결하기 위한 미들웨어
  2. RPC (Remote Procedure Call, 원격 프로시저 호출)
    • 응용 프로그램의 프로시저를 사용, 원격 프로시저를 로컬 프로시저처럼 호출하는 방식의 미들웨어
  3. MOM (Message Oriented Middleware, 메시지 지향 미들웨어)
    • 메시지 기반 비동기형 메시지를 전달하는 방식의 미들웨어
  4. TP-Monitor (Transaction Processing Monitor, 트랜잭션 처리 모니터)
    • 항공기, 철도 예약 업무 등의 온라인 트랜잭션 업무에서 트랜잭션을 처리/감시하는 미들웨어
    • 사용자 수 증가해도 빠른 응답 속도를 유지해야 하는 업무에서 사용
  5. ORB (Object Request Broker, 객체 요청 브로커)
    • 객체 지향 미들웨어로 코바 표준 스펙을 구현한 미들웨어
  6. WAS (Web Applcation Server, 앱 애플리케이션 서버
    • 사용자의 요구에 따라 변하는 동적인 콘텐츠를 처리하기 위해 사용되는 미들웨어
    • 클라이언트/서버 환경보다는 웹 환경을 구현하기 위한 미들웨어
  • 미들웨어 솔루션 식별
    • 개발 및 운영 환경에 사용될 미들웨어 솔루션을 확인하고 목록을 작성하는 것
    • 시스템, 구분, 솔루션명, 버전 제조사 등의 정보를 정리한 솔루션 목록 작성
  • 미들웨어 솔루션 명세서 작성
    • 미들웨어 솔루션 목록의 미들웨어 솔루션별로 관련 정보들을 상세하게 기술
    • 상세 정보, 제공 기능, 특징, 시스템 구성 환경 등 제약사항 정리 및 솔루션 명세서 작성

 

참고

https://powerdev.tistory.com/32?category=874228 

 

2020 정보처리기사 필기 정리

※ 본 정리 글은 시나공 정보처리기사 필기책과 학교특강을 참고하여 작성했습니다. → 책정보 확인하기 학교특강을 들으며 중요한 내용들만 추려 정리했습니다. 반드시 외워야 할 부분들은

powerdev.tistory.com

https://blog.naver.com/wook2124/222102990691

 

2022 정보처리기사 필기 총정리 (시나공, 수제비)

<정보처리기사 필기, 공부 가이드라인 by. 세현님> 본 정리 글은 정보처리기사 시나공과 수제비 필기...

blog.naver.com

 

https://www.youtube.com/watch?v=O4eSv1NttBs&t=523s