[정보처리기사 필기] 1과목 :: 소프트웨어 설계 요약

참고로 필자는 이미 정처기가 있지만 취준을 하다보면 정처리를 다시 봐야하는 순간들이 꼭 온다.

그래서 두구두구두구두구두구두구🥁 볼겸 정리해보려한다.

 

---

 

📍  소프트웨어 생명주기(SW Life Cycle)

폭포수 모형 (Waterfall Model)

• - 가장 오래되고 가장 폭넓게 사용된 고전적 생명주기 모형
• - 개발 중간에 요구사항의 변경이 용이하지 않음
• - 단계별 정의 및 산출물 명확
• - 한 단계가 끝나야 다음 단계로 이동, 선형 순차적 모형

나선형 모형(Spiral)

• - 점진적 개발 과정 반복으로 요구사항 추가 가능
• - 정밀하고 유지보수과정 필요 없음
• - 계획 및 정의 -> 위험 분석 -> 공학적 개발 -> 고객평가

애자일 모형(Agile Model)

• - 변화에 유연하게 대응
• - 일정한 주기(sprint)를 반복하며 개발
• - 절차와 도구보다 고객과의 소통에 초점 
• - ex: XP (익스트림 프로그래밍), 스크럼, 칸반, 크리스탈, 린

 

📍  UML

UML 이란? 의사소통이 원활하게 이루어지도록 표준화한 객체 지향 모델링

UML 구성요소 :

•  사물 : 구조, 행동, 그룹, 주해 사물
• 관계: 연관(-), 집합(◇), 포함(◆), 일반화(ㅡ▷), 의존(-->), 실체화(--▷) {관계}
• 다이어그램:
  • 구조적(정적) 다이어그램 : 
    • - 클래스(Class)
      - 객체(Object)
      - 컴포넌트(Component)
      - 배치(Deployment),
      - 복합체 구조(Composite Structure)
      - 패키지(Package) {다이어그램(Diagram)}
  • 행위적(동적) 다이어그램
    • - 유스케이스(Use Case, 사용사례)
      - 시퀀스(Sequence, 순차),
      - 커뮤니케이션(Communication, 협업)
      - 상태(State)
      - 활동(Activity),
      - 상호작용 개요(Interaction Overview)
      - 타이밍(Timing) {다이어그램(Diagram)} 

---

📍  UI  설계 원칙

• 직관성 : 누구나 쉽게 이해하고 사용할 수 있어야 한다.
• 유효성 : 사용자 목적을 정확히 달성할 수 있어야 한다.
• 학습성 : 누구나 쉽게 배우고 익힐 수 있어야 한다.
• 유연성 : 사용자의 요구에 최대한 수용하고 오류를 최소화 해야한다.

UI 종류

• CLI(Command Line Interface): 텍스트 형태로 이뤄진 인터페이스
• GUI(Graphical User Interface): 마우스로 선택해 작업을 하는 그래픽 환경의 인터페이스
• NUI(Natural User Interface): 사용자의 말이나 행동으로 기기를 조작하는 인터페이스
• VUI(Voice User Interface): 사람의 음성으로 기기를 조작하는 인터페이스
•  OUI(Organic User Interface): 모든 사물과 사용자 간의 상호작용을 위한 인터페이스

UI 설계 도구 

• 와이어프레임(Wireframe) : 기획 단계에서 제작, 레이아웃이나 뼈대 설계
• Mockup : 실제 화면과 유사하게 만든 정적 형태의 모형
• Prototype : 실제 구현된 것처럼 테스트 가능한 동적 형태의 모형
• Storyboard : 와이어프레임에 콘텐츠에 대한 설명, 페이지 간 이동 흐름 등을 추가한 문서
• Use Case : 사용자의 요구사항을 기능 단위로 표현한 것
  - 유스케이스 다이어그램이 완성되면, 각각의 유스케이스에 대해 유스케이스 명세서를 작성한다.

 

📍 품질 요구 사항

• ISO/IEC 9126: 국제 표준(SW 품질 표준 지침)
• ISO/IEC 25010: 9126 개정, 제품에 대한 국제 표준
• ISO/IEC 12119: 9126 + 테스트
• ISO/IEC 14598: 개발자, 구매자, 평가자 별 수행활동 규정

- 요소

• 기능성(functionality): 요구사항 만족 여부
• 신뢰성(reliability): 요구된 기능을 일관적으로 오류 없이 수행
• 사용성(usability): 사용자가 정확히 이해하고 사용하는지, 또 쓰고 싶은지
• 효율성(efficiency): 빨리 처리
• 유지보수성(maintainablity): 분석성, 변경성, 안정성, 시험성
• 이식성(portablity): 다른 환경에서 적용 가능한지

 

📍 요구사항 

요구사항 분석 유형

• 기능적 요구사항 입력, 출력, DB, 통신 기능 등
• 비기능적 요구사항 보안, 성능, 품질, 안정 등
• 시스템 요구사항 : 개발자 관점
• 사용자 요구사항 : 사용자 관점

요구사항 개발 프로세스: 도출/추출 -> 분석 -> 명세 -> 확인/검토(검증)

요구사항 검토 방법(Requirements Review)

• 동료 검토(Peer Review): 요구사항 명세서 작성자가 내용을 직접 설명하고 동료들이 이를 들으면서 결함을 발견하는 검토
• 워크 스루(Walk Through): 검토회의 전에 요구사항 명세서를 미리 배포하여 사전 검토한 후, 짧은 검토 회의를 통해 결함을
  발견하는 검토
• 인스펙션(Inspection): 요구사항 명세서 작성자를 제외한 다른 검토 전문가들이 확인하면서 결함을 발견하는 검토 방법

 

📍 CASE(자동화 도구)

CASE(Computer-Aided Software Engineering) 도구의 분류 

• 상위 CASE: 계획수립, 요구분석, 기본설계 단계를 다이어그램으로 표현
  # 모순 검사, 오류 검증, 자료흐름도 작성 지원
• 중위 CASE
  # 상세 설계 작업, 화면 출력 작성 지원
•  하위 CASE
  # 시스템 명세서, 소스 코드 생성 지원

 

📍HIPO(Hierarchy Input Process Output)

• 시스템 분석/설계/문서화에 사용되는 기법
• 시스템 실행 과정인 입력-처리-출력 기능을 나타냄

 

📍 미들웨어 솔루션 명세

- 운영체제(OS)와 해당 운영체제에서 실행되는 응용 프로그램 사이에서 운영체제가 제공하는
서비스 이외에 추가적인 서비스를 제공하는 소프트웨어

1) DB(Database)
- 클라이언트에서 원격의 데이터베이스와 연결하기 위한 미들웨어, 2-Tier 아키텍처
# ODBC(마이크로소프트), IDAPI(볼랜드), Glue(오라클)

2) RPC(Remote Procedure Call, 원격 프로시저 호출)
- 응용 프로그램의 프로시저를 사용해 원격 프로시저를 로컬 프로시저처럼 호출하는 방식의
미들웨어
# Entera(이큐브시스템스), ONC/RPC(OSF)

3) MOM(Message Oriented Middleware, 메시지 지향 미들웨어) 
- 메시지 기반의 비동기형 메시지를 전달하는 방식의 미들웨어
# MQ(IBM), Message Q(오라클), JMS(JCP)

4) TP-Monitor(Transaction Processing Monitor, 트랜잭션 처리 모니터) 
- 항공기나 철도 예약 업무 등과 같은 온라인 트랜잭션 업무에서 트랜잭션을 처리 및 감시하는
미들웨어
- 사용자 수가 증가해도 빠른 응답 속도를 유지해야 하는 업무에 주로 사용됨

5)웹 애플리케이션 서버(WAS)

• 동적인 콘텐츠 처리를 위해 사용되는 미들웨어 cf) WS
• 데이터 접근, 세션 관리, 트랜잭션 관리 라이브러리 제공
• 주로 DB와 연동해서 사용
• 톰캣, GlassFish, JBoss, Jetty, JEUS, Resin, WebLogic, WebSphere 

 

📍 데이터베이스 관리 시스템(DBMS; Database Management System)

• 사용자와 데이터베이스(DB) 사이에서 정보를 생성하고 DB 를 관리하는 소프트웨어
• 데이터베이스(DB)의 구성, 접근 방법, 유지관리에 대한 모든 책임을 짐
• JDBC(Java Database Connectivity, 자바), ODBC(Open Database Connectivity, 응용 프로그램)
• Oracle, MySQL, SQLite, MongoDB, Redis 등등
• 가용성, 성능 | 기술 지원, 구축 비용, 상호 호환

 

---

📍 객체지향

1) 객체(Object)

• 독립적으로 식별 가능한 이름을 갖고 있음
• 객체가 가질 수 있는 조건인 상태(State)는 일반적으로 시간에 따라 변함
• 객체와 객체는 상호 연관성에 의한 관계가 형성됨
• 객체가 반응할 수 있는 메시지의 집합을 행위(연산)라고 함
• 객체는 일정한 기억장소를 갖고 있음

2) 클래스(Class) 

• 하나 이상의 유사한 객체들을 묶어서 하나의 공통된 특성을 표현한 것
• 공통된 속성과 연산(행위)를 갖는 객체의 집합
• 객체지향 프로그램에서 데이터를 추상화하는 단위
• 각각의 객체들이 갖는 속성과 연산(Method)을 정의하고 있는 틀
• 슈퍼 클래스(Super Class)는 특정 클래스의 상위(부모) 클래스
• 서브 클래스(Sub Class)는 특정 클래스의 하위(자식) 클래스

3) 캡슐화(encapsulation) 

• 데이터(속성)와 데이터를 처리하는 함수를 하나로 묶는 것
• 인터페이스를 제외한 세부 내용이 은폐(정보 은닉)되어 외부 접근이 제한됨
• 정보 은닉 측면과 가장 밀접한 관계가 있음
•  외부 모듈의 변경으로 인한 파급 효과가 적음
• 재사용 용이, 인터페이스 단순해짐
• 결합도 Down / 응집도 Up

4) 상속(Inheritance)

•  이미 정의된 상위(부모) 클래스의 모든 속성과 연산을 하위(자식) 클래스가 물려받는 것
• 소프트웨어의 재사용(Reuse)을 높이는 중요한 개념

5) 다형성(Polymorphism)

• 하나의 메시지에 대해 각각의 객체(클래스)가 가지고 있는 고유한 방법(특성)으로 응답할 수
  있는 능력 ex) ‘+’ 연산자의 경우 숫자 클래스에서는 덧셈, 문자 클래스에서는 문자열의 연결 기능
• 오버로딩: 같은 이름, 다른 파라미터 타입/개수
• 오버라이딩: 상위 클래스 메소드 재정의

 

📍 객체지향 설계 원칙(SOLID)

• 단일 책임(SRP, Single Responsibility Principle)
• 개방 폐쇄(OCP, Open-Closed P): 기존 코드 변경 없이 기능 추가 가능해야
• 리스코프 치환(LSP, Liskov Substitution): 자식 클래스는 최소한 부모가 할 수 있는 일은 할 줄 알아야 함
• 인터페이스 분리(ISP, Interface Segregation): 사용X 인터페이스와 관계, 영향X
• 의존역전(DIP, Dependency Inversion): 추상성 높은 클래스와 의존

 

📍모듈 

1) 결합도(Coupling)

• 모듈 간에 상호 의존하는 정도 또는 두 모듈 사이의 연관 관계를 의미
• 결합도는 낮을수록(↓) Good = 독립적인 모듈
  • (아래로 내려갈 수록, Good -> Bad)
  • 자료 결합도: 인터페이스가 자료 요소로만 구성
  • 스탬프 결합도: 자료구조 요소로만 구성
  • 제어 결합도: 제어신호, 제어요소(function, switch, tag, flag)
  • 외부 결합도: 한 모듈의 데이터(변수)를 다른 모듈에서 참조
  • 공통(공유) 결합도: 공통 데이터 영역을 여러 모듈이 사용
  • 내용 결합도: 다른 모듈의 기능, 자료를 직접 참조

2) 응집도(Cohesion)

• 모듈의 내부 요소들의 서로 관련되어 있는 정도
• 응집도는 높을수록(↑) Good = 독립적인 모듈
  • (아래로 내려갈 수록, Good -> Bad)
  • 기능적 응집도: 모든 기능이 단일 문제 연관
  • 순차적 응집도: A모듈의 출력이 B모듈의 입력
  • 교환(통신)적: 동일 입출력으로 서로 다른 기능
  • 절차적: 모듈이 다수 기능 가질 때, 구성요소가 그 기능을 순차적 수행
  • 시간적: 특정 시간에 처리되는 몇 기능을 묶은 하나의 모듈
  • 논리적: 유사 성격/형태의 요소로 모듈 구성
  • 우연적: 관련 없는 요소

 

---

📍 디자인 패턴

- 아키텍처 패턴이 디자인 패턴보다 상위 수준의 설계에 사용됨
- 서브시스템에 속하는 컴포넌트들과 그 관계를 설계하기 위한 참조 모델

1) 생성 패턴(Creational Pattern) 

•  추상 팩토리(Abstract Factory): 서로 연관, 의존하는 객체들을 그룹으로 생성해 추상적으로 표현
• 빌더(Builder): 객체의 생성 과정과 표현 방법 분리 → 동일한 객체 생성에도 서로 다른 결과
• 팩토리 메소드(Factory Method): 객체를 생성하기 위한 인터페이스를 정의하여, 어떤 클래스가 인스턴스화 될 것인지는 서브클래스가 결정하도록 하는 것(Virtual-Constructor 패턴)
• 프로토타입(Prototype): 원본 객체를 복제하는 방법
• 싱글톤(Singleton): 하나의 객체를 여러 프로세스가 동시에 참조할 수 없음

2) 구조 패턴(Structural Pattern) 

• 어댑터(Adapter): 호환성이 없는 클래스 인터페이스를 이용할 수 있도록 변환해주는 패턴
• 브리지(Bridge): 구현부에서 추상층을 분리하여, 독립적으로 확장 및 다양성을 가지는 패턴
• 컴포지트(Composite): 여러 객체를 가진 복합, 단일 객체를 구분 없이 다룰 때 사용하는 패턴
• 데코레이터(Decorator): 상속을 사용하지 않고도 객체의 기능을 동적으로 확장해주는 패턴
• 퍼싸드(Façade): 서브 클래스들의 기능을 간편하게 사용할 수 있도록 하는 패턴; ex) 리모컨
•  플라이웨이트(Flyweight): 공유해서 사용함으로써 메모리를 절약하는 패턴
•  프록시(Proxy): 접근이 어려운 객체를 연결해주는 인터페이스 역할을 수행하는 패턴

 

💡 생성 패턴과 구조 패턴에 해당 안되면 행위 패턴

3) 행위 패턴(Behavioral Pattern)

• 책임 연쇄(Chain of Responsibility): 한 객체가 처리하지 못하면 다음 객체로 넘어가는 패턴
• 커맨드(Command): 요청에 사용되는 각종 명령어들을 추상, 구체 클래스로 분리하여 단순화함
• 인터프리터(Interpreter): 언어에 문법 표현을 정의하는 패턴
• 반복자(Iterator): 동일한 인터페이스를 사용하도록 하는 패턴
• 중재자(Mediator): 서로의 존재를 모르는 상태에서도 협력할 수 있게 하는 패턴
• 메멘토(Memento): 요청에 따라 객체를 해당 시점의 상태로 돌릴 수 있는 기능을 제공하는 패턴
• 옵서버(Observer): 관찰대상의 변화를 탐지하는 패턴
• 상태(State): 객체의 상태에 따라 동일한 동작을 다르게 처리해야 할 때 사용하는 패턴
•  전략(Strategy): 클라이언트에 영향을 받지 않는 독립적인 알고리즘을 선택하는 패턴
• 템플릿 메소드(Template Method): 유사한 서브 클래스를 묶어 공통된 내용을 상위 클래스에 정의하는 패턴
• 방문자(Visitor): 필요할 때마다 해당 클래스에 방문해서 처리하는 패턴

 

---

📍 애플리케이션 설계

- 아키텍처 패턴

• 파이프 필터 패턴
• MVC패턴
• 기타 패턴
  • 마스터-슬레이브 패턴 
    • 마스터 컴포넌트가 슬레이브한테 작업 분할해주면 슬레이브가 돌려줌
    • 장애 허용 시스템, 병렬 컴퓨팅 시스템
  • 브로커 패턴 
    • 브로커가 요청에 맞는 컴포넌트 찾아서 유저와 연결
    • 분산 환경 시스템
  • 피어 투 피어 패턴: 피어가 클라이언트가 될 수도 있고 서버가 될 수도
  • 이벤트-버스 패턴
  • 블랙보드 패턴
  • 인터프리터 패턴

 

 

 

---

 

 

참고: https://velog.io/@stringbuckwheat/%EC%A0%95%EB%B3%B4%EC%B2%98%EB%A6%AC%EA%B8%B0%EC%82%AC-%ED%95%84%EA%B8%B0-1%EA%B3%BC%EB%AA%A9-%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EC%84%A4%EA%B3%84-%EC%9A%94%EC%95%BD