ABOUT ME

-

Today
-
Yesterday
-
Total
-
choco@desktop:~/tistory
$ 정보처리기사 요점정리
1과목 2과목 3과목 4과목 5과목 실기

$ Linux Kernel
Power Management DVFS
  • 정보처리기사 필기 1과목 - 소프트웨어 설계 (빈출 요점 정리)
    시험 요점정리 (꽃길)/정보처리기사 2021. 6. 21. 00:21

    정보처리기사 필기 빈출 개념과 기출문제를 정리하였습니다.

    공부할 시간이 부족할 경우 아래의 개념을 먼저 학습해보시고, 기출문제들을 최소 3회차를 풀어볼 것을 권장합니다.

    (기출문제: https://www.comcbt.com/xe/iz)

    (전체 목차 및 다른 과목 링크: https://computer-choco.tistory.com/437)

     

    정보처리기사20200926(해설집).hwp
    0.11MB
    정보처리기사20200822(해설집).hwp
    0.13MB
    정보처리기사20200606(해설집).hwp
    0.10MB

    (기출문제 출처는 위의 링크와 같습니다 - comcbt.com)

     

    정보처리기사 필기 1과목 - 소프트웨어 설계 빈출 개념 & 기출 문제

     

    1. 애자일

    2. UI 설계 원칙

    3. 요구사항 검토 방법

    4. CASE 도구

    5. 럼바우 객체지향 분석 기법

    6. 캡슐화

    7. 객체지향 설계 원칙

    8. 코드

    9. 자료 사전

    10. 자료 흐름도

     

    보너스. 디자인 패턴


    1. 애자일 ★★★

    교재 단원: 요구사항 확인

    정보처리기사 필기 (2020.06.06 ~ 2020.09.22) 의 3번의 시험 중 출제율 100%에 해당하는 애자일 & XP 개념입니다.

    애자일 기법은 소프트웨어 생명주기 모형 중 하나입니다.

    소프트웨어 생명주기 모형에서 애자일을 제외한 다른 모형들은 5과목 정보시스템 구축관리에 나오기 때문에 결국 외워야합니다.

    소프트웨어 생명주기 모형
    (1) 폭포수 모형
    (2) 프로토타입 모형
    (3) 나선형 모형
    (4) 애자일 모형

    [참고] 소프트웨어 생명주기 모형 참고: https://liveyourit.tistory.com/197

     

    소프트웨어 생명주기 모형은 소프트웨어 개발을 할 때 단계를 정리해놓은 모형들입니다. 그 중 애자일 모형은 고객의 요구사항 변화에 빠르게 대응할 수 있는 모형입니다. 애자일 (Agile) 의 사전적 뜻은 날렵한, 민첩한인데, 애자일 모형은 고객과 소통, 고객의 요구사항에 민첩하게 대응하는 모형을 말합니다

    네이버 사전 Agile 검색 결과

    개발 주기는 짧고 그 짧은 주기마다 도출된 결과에 대한 고객의 평가를 적극적으로 수용합니다.

    그럼 문제를 풀어보겠습니다.

    4. 애자일 기법에 대한 설명으로 맞지 않는 것은?
    (1) 절차와 도구보다 개인과 소통을 중요하게 생각한다.
    (2) 계획에 중점을 두어 변경 대응이 난해하다.
    (3) 소프트웨어가 잘 실행되는데 가치를 둔다.
    (4) 고객과의 피드백을 중요하게 생각한다.

    (2020.08.22 정보처리기사 필기 기출문제 - 출처: 전자문제집 CBT)

    (1) 번의 개인과의 소통이 중요하다 맞습니다. (2) 번 계획에 중점을 두어 변경 대응이 어렵다는 맞지 않습니다. 고객의 피드백을 적극적으로 수용하여 변경 대응을 잘 합니다. (3) 번 소프트웨어가 잘 실행되는 것에 가치를 둔다. 계획보다는 결과물에 중심을 둔다는 의미로 적은 것 같아 보입니다. 그러면 역시나 문제가 없고, (4)번 고객과의 피드백을 중요하게 생각하는 것은 당연합니다.

     

    애자일 모형을 기반으로 한 구체적인 소프트웨어 개발 모형으로는 스크럼, XP 등이 있습니다. 이 중에 시험에 많이 나오는 것은 XP (eXtreme Programming) 입니다. XP, 익스트림 프로그래밍은 애자일 모형을 기반으로 한 것이기 때문에 위에서 봤던 애자일 설명이 다 적용됩니다. 고객과의 의사소통을 중시한다는 특징이요. 시험을 위해 외울 것은 (사실 외울 필요도 없습니다. 보기로 나왔을 때 XP다 아니다 판별만 할 수 있으면 됩니다) 다음 XP의 5가지 가치입니다.

    XP 의 5가지 가치
    - 의사소통 (Communication): 개발자, 관리자, 고객 간의 원활한 의사소통
    - 단순성 (Simplicity): 부가적 기능, 사용되지 않는 구조와 알고리즘 배제
    - 용기 (Courage): 고객의 요구사항 변화에 능동적인 대처
    - 존중 (Respect): 모든 프로젝트 관리자는 팀원의 기여를 존중
    - 피드백 (Feedback): 지속적인 테스트와 반복적 결함 수정, 빠른 피드백

    [참고] XP에 대해 잘 정리된 글: http://blog.skby.net/xp-extreme-programming/

     

    의사소통, 단순성, 용기, 존중, 피드백입니다. 고객 등 사람들과의 의사소통을 생각했을 때, 의사소통, 용기, 존중, 피드백은 이해가 어렵지 않을 것 같습니다. 빨리 빨리 만들고 변경하기 위해 단순하게 만드는 것도 이해할 수 있을 것입니다. 그러면 다음의 문제를 가볍게 풀어보겠습니다.

     

    11. XP (eXtreme Programming) 의 5가지 가치로 거리가 먼 것은?
    (1) 용기
    (2) 의사소통
    (3) 정형분석
    (4) 피드백

    (2020.06.06 정보처리기사 필기 기출문제 - 출처: 전자문제집 CBT)

    답은 당연히 3번 정형분석입니다. 한 번 읽고 훑어보면 굳이 5가지 가치를 달달 외우지 않아도 해당하는 것과 아닌 것을 골라내실 수 있을 것 같습니다.

     


    2. UI 설계 원칙 ★★★

    교재 단원: 화면 설계 - UI 요구사항 확인

    정보처리기사 필기 (2020.06.06 ~ 2020.09.22) 의 3번의 시험 중 2번 출제된 문제입니다. 출제율 100%는 아니지만 실기 시험에서도 주관식 답으로 많이 출제되기 때문에 별 3개를 책정하였습니다.

     

    다음의 UI 설계 원칙 4가지는 반드시 암기해야합니다. (실기시험에서는 설명까지도 서술형 답으로 쓸 수 있어야합니다!!)

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

    [참고] UI 요구사항 확인 요약 정리: https://blog.dalso.org/it/gisa/12398

     

    User Interface, 즉 사용자가 접근하는 화면을 만들 때 필요한 것은 직관성, 유효성, 학습성, 유연성입니다. 핸드폰 화면 같은 걸 생각해보면 직관적으로 이 버튼이나 아이콘이 하는 일을 알 수 있어야하고 (직관성), 사용자의 목적을 정확하게 달성할 수 있어야하고 (유효성), 쉽게 배우고 익힐 수 있어야하고 (학습성), 사용자의 인터랙션을 최대한 포용해야합니다 (유연성).

     

    문제를 풀면 다음과 같습니다.

    10. UI 설계 원칙에서 누구나 쉽게 이해하고 사용할 수 있어야 한다는 것은?
    (1) 유효성
    (2) 직관성
    (3) 무결성
    (4) 유연성

    (2020.06.06 정보처리기사 필기 기출문제 - 출처: 전자문제집 CBT)

    UI 설계 원칙은 직관성, 유효성, 학습성, 유연성입니다. 이 중 누구나 보자마자 어떻게 쓰는지 이해할 수 있는 것은 직관성입니다. 답은 2번입니다.

     


    3. 요구사항 검토 방법 ★★

    교재 단원: 요구사항 확인

    정보처리기사 필기 (2020.06.06 ~ 2020.09.22) 의 3번의 시험 중 2번 출제된 문제입니다.

     

    요구사항 검토 방법은 다음과 같습니다.

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

    + 그 외 요구사항 검증 방법
    CASE (Computer Aided Software Engineering) 도구 활용

    [참고] 요구사항 검토 방법 요약: https://devinus.tistory.com/14

    [참고] 워크 스루 설명 (첫문단 참고): https://www.bridging-the-gap.com/requirements-review/

     

    요구사항 검증 방법 중 요구사항 검토 방법은 위와 같이 3가지가 있습니다. 필기 문제를 맞추기 위해서는 각 방법의 이름과 설명에 대해서 매칭이 가능하면 됩니다. 동료 검토는 2~3명 정도의 동료들이 설명을 들으며 결함을 찾아주는 방법입니다. 워크 스루는 햄버거 가게의 드라이브 스루 같은 느낌으로 슉 지나가는 방법입니다. 짧은 시간 동안 문서를 빠르게 검토하는 회의를 진행합니다. 인스펙션은 영어 사전에서 뜻을 확인하면 점검이나 순찰의 의미입니다. 검토 전문가들만 따로 모여서 꼼꼼히 점검하는 방법이라고 이해하시면 될 것 같습니다.

     

    문제를 풀어보겠습니다.

    1. 검토회의 전에 요구사항 명세서를 미리 배포하여 사전 검토한 후 짧은 검토회의를 통해 오류를 조기에 검출하는데 목적을 두는 요구 사항 검토 방법은?
    (1) 빌드 검증
    (2) 동료 검토
    (3) 워크 스루
    (4) 개발자 검토

    (2020.06.06 정보처리기사 필기 기출문제 - 출처: 전자문제집 CBT)

    짧은 검토회의를 거치는 건 요구사항 검토 방법 중 3번 워크 스루에 해당합니다. 보기를 보면 2번 동료 검토 말고는 올바른 요구사항 검토 방법도 아니네요.


    4. CASE 도구 ★★★

    교재 단원: 요구사항 확인

    정보처리기사 필기 (2020.06.06 ~ 2020.09.22) 의 3번의 시험 중 100% 출제된 문제입니다.

     

    CASE 도구는 요구사항 검증 방법으로 Computer 의 도움을 받는 방법입니다. CASE = Computer Aided Software Engineering) 입니다. 

     

    CASE 도구는 이렇게 생겼습니다.

    위키백과 CASE 도구 화면 예시

    차트와 다이어그램을 그릴 수 있는 프로그램으로, 자신이 생각하는 모형을 그려서 공유할 수 있으므로 개발자들끼리 서로 쉽게 협업할 수 있습니다.

     

    크게 어렵지 않습니다. 문제를 바로 보겠습니다.

    3. CASE (Computer Aided Software Engineering) 의 주요 기능으로 옳지 않은 것은?
    (1) S/W 라이프 사이클 전 단계의 연결
    (2) 그래픽 지원
    (3) 다양한 소프트웨어 개발 모형 지원
    (4) 언어 번역

    (2020.09.26 정보처리기사 필기 기출문제 - 출처: 전자문제집 CBT)

    (1) 번 개발 주기 전 단계를 아우를 수 있습니다. 저 프로그램에서 제공하는 것이 개발 주기 표현을 해주는 것이니까요. (2) 번 그래픽 지원. 사진처럼 당연히 화면이 보이는 프로그램입니다. (3) 다양한 개발 모형 지원. 폭포수 모형이든 애자일 모형이든 당연히 여러 모형을 지원합니다. (4) 언어 번역. 여기서 말하는 언어 번역은 사람의 언어를 컴퓨터 언어로 번역해주는 것을 말합니다. CASE 도구는 S/W 를 바로 생성하는 프로그램이 아니라 개발 모형을 공유하기 위한 것이므로 컴퓨터 언어로 번역해주지 않습니다. 그건 컴파일러나 인터프리터처럼 개발 언어 번역을 위한 프로그램을 사용해야합니다.

     


    5. 럼바우 객체 지향 분석 기법 ★★★

    교재 단원: 애플리케이션 설계

    정보처리기사 필기 (2020.06.06 ~ 2020.09.22) 의 3번의 시험 중 100% 출제된 문제입니다.

     

    럼바우 객체 지향 분석 기법은 자세한 내용보다는 기법에서 사용되는 3가지 단계가 주로 출제됩니다. (모든 소프트웨어 구성 요소를 그래픽 표기법을 이용하여 모델링하는 방법입니다.) 다음의 3가지 모델링을 순서대로 암기하면 됩니다.

    럼바우(Rumbaugh) 객체지향 분석 기법
    - 객체 모델링(Object Modeling): 객체 다이어그램, 정보 모델링이라고도 하며 시스템에서 요구하는 객체를 찾고 객체들 간의 관계를 정의, 가장 중요하며 선행되어야 함
    - 동적 모델링(Dynamic Modeling): 상태 다이어그램, 시간의 흐름에 따라 객체들 사이의 제어 흐름, 동작 순서 등의 동적인 행위를 표현
    - 기능 모델링(Functional Modeling): 자료 흐름도(DFD), 프로세스들의 자료 흐름을 중심으로 처리 과정 표현

    럼바우 객체지향 분석 기법의 절차는 객체 모델링 -> 동적 모델링 -> 기능 모델링 순서로 진행된다.

    [참고] 럼바우 객체지향 분석 기법 요약: https://devinus.tistory.com/9

     

    위의 3가지 모델링이 순서대로 이루어진다고 암기하며 됩니다. 객 - 동 - 기 로 앞 글자만 따서 외우면 쉽게 외울 수 있습니다.

     

    다음과 같이 문제를 풀어보겠습니다.

    14. 럼바우 (Rumbaugh) 객체지향 분석 절차를 가장 바르게 나열한 것은?
    (1) 객체 모형 -> 동적 모형 -> 기능 모형
    (2) 객체 모형 -> 기능 모형 -> 동적 모형
    (3) 기능 모형 -> 동적 모형 -> 객체 모형
    (4) 기능 모형 -> 객체 모형 -> 동적 모형

    (2020.06.06 정보처리기사 필기 기출문제 - 출처: 전자문제집 CBT)

    답은 당연히 객동기인 1번이 됩니다.

     


    6. 캡슐화 ★★

    교재 단원: 애플리케이션 설계

    정보처리기사 필기 (2020.06.06 ~ 2020.09.22) 의 3번의 시험 중 2회 출제된 문제입니다.

     

    객체지향 기법은 다음과 같습니다.

    객체지향 기법

    1) 캡슐화(Encapsulation)
    - 데이터와 함수를 하나로 묶는 것을 의미
    - 재사용성 증가, 오류 파급 효과 감소
    - 인터페이스가 단순해짐, 객체 간 결합도가 낮아짐

    2) 정보 은닉(Information hiding)
    - 다른 객체에게 자신의 정보를 숨기고 자신의 연산만을 통해 접근
    - 다른 객체에게 주는 영향을 감소시킴

    3) 추상화(Abstraction)
    - 불필요한 부분을 생략하고 중요한 것에만 중점을 두어 모델화

    4) 상속성(Inheritance)
    - 상위 클래스의 모든 속성과 연산을 하위 클래스가 물려받음

    5) 다형성(Polymorphism)
    - 같은 함수, 기능에 대해 다른 정의를 통해 각 클래스가 다른 행동을 할 수 있게 해줌
    - Overloading : 같은 이름을 가진 함수지만 인자가 달라 각기 다른 인자에 따라 함수를 선택해 수행
    - Overriding : 상위 클래스로부터 상속받은 함수들을 다르게 구현하여 사용

    [참고] 객체지향 기법: https://dongdd.tistory.com/119

     

    위에 개념들 중 시험에 자주 나오는 것은 캡슐화와 정보 은닉입니다.

    캡슐화는 데이터와 함수를 하나로 묶는 것을 의미합니다. 프로그래밍 언어와 친숙하지 않으실 수도 있지만 JAVA 언어로 예시를 들어보겠습니다.

     

    [코드 출처] https://www.guru99.com/java-oops-encapsulation.html

    class Account{ 
      private int account_number;
      private int account_balance; 
    
      // getter method
      public int getBalance() {
          return this.account_balance;
      }
    }

    Account 라는 클래스 안에 계좌 번호 (account_number) 와 계좌 잔고 (account_balance) 데이터가 있습니다. 여기서 계좌 잔고를 얻어오기 위한 함수 (getBalance) 가 중괄호 {}로 함께 묶여 있습니다. 이렇게 데이터와 함수를 하나로 묶으면 캡슐화가 됩니다. 매번 계좌를 만들고, 계좌를 처리할 수 있는 함수를 따로 만드는 대신에 이렇게 Account 라는 클래스 하나씩 통째로 생성하면 되기 때문에 단순하고 재사용하기도 좋습니다.

     

    정보 은닉은 말 그대로 정보를 숨기는 것입니다. 캡슐화와 밀접한 관련이 있기도 합니다. 캡슐화 시켜서 안에 데이터를 외부에서 볼 수 없게 만들면 정보 은닉을 시킬 수 있습니다. (위의 코드 예시에서 public은 외부에서 접근 가능, private은 외부에서 접근 불가하게 만드는 접근 제한자입니다. 지금 private 되어서 감춰진 계좌 번호 및 통장 잔고도 public으로 선언하면 데이터도 외부에서 접근 가능합니다. 이런 방식으로 정보 은닉을 시킬 수 있습니다.)

     

    문제를 잠깐 풀어보겠습니다.

    4. 객체지향 기법의 캡슐화 (Encapsulation) 에 대한 설명으로 틀린 것은?
    (1) 인터페이스가 단순화 된다.
    (2) 소프트웨어 재사용성이 높아진다.
    (3) 변경 발생시 오류의 파급효과가 적다.
    (4) 상위 클래스의 모든 속성과 연산을 하위 클래스가 물려받는 것을 의미한다.

    (2020.09.26 정보처리기사 필기 기출문제 - 출처: 전자문제집 CBT)

    답은 4번입니다. 나머지는 캡슐화에 대한 설명인데, 4번은 상속을 의미합니다. 

     

    캡슐화와 관련하여 중요한 개념이 바로 클래스입니다. 객체지향의 구성 요소는 다음과 같습니다.

    객체지향 구성 요소

    1) 객체(Object)
    - 데이터와 데이터를 처리하는 함수를 캡슐화한 소프트웨어 모듈
    - 데이터 : 객체 정보, 속성, 상태
    - 함수 : 객체가 수행하는 기능

    2) 클래스(Class)
    - 공통된 속성, 연산을 갖는 객체들의 집합
    - Instance : 클래스에 속한 각각의 객체

    3) 메시지(Message)
    - 객체들 간 상호작용을 하기 위한 수단

    [참고] 객체지향 구성 요소: https://dongdd.tistory.com/119

     

    아까 보셨듯이 계좌 번호와 잔고, 잔고를 알 수 있는 함수를 한데 묶은 것이 클래스입니다. 그런데, 이것은 추상적인 개념일 뿐이고 이 클래스를 통해 실제로 저의 계좌, 여러분의 계좌를 발급받게 되면 그 실체가 있는 것은 객체 혹은 인스턴스라고 합니다. 

     

    [참고] 객체와 인스턴스 정확히 구별하기: https://gmlwjd9405.github.io/2018/09/17/class-object-instance.html

     

    그러면 문제를 보겠습니다.

    13. 객체 지향 소프트웨어 공학에서 하나 이상의 유사한 객체들을 묶어서 하나의 공통된 특성을 표현한 것은?
    (1) 트랜지션
    (2) 클래스
    (3) 시퀀스
    (4) 서브루틴

    (2020.08.22 정보처리기사 필기 기출문제 - 출처: 전자문제집 CBT)

    객체지향에서 객체를 묶어서 공통된 특성을 표현 혹은 데이터를 추상화하는 단위는 바로 2번 클래스입니다.

     


    7. 객체 지향 설계 원칙 ★★

    교재 단원: 애플리케이션 설계

    정보처리기사 필기 (2020.06.06 ~ 2020.09.22) 의 3번의 시험 중 2회 출제된 문제입니다.

     

    객체지향 설계 원칙은 5가지가 있습니다. 한글 이름과 영어 이름 둘 다 알아야하며, 달달 외울 필요는 없고 뜻과 매칭시킬 수 있으면 됩니다.

     

    각 5글자를 따서 객체지향 설계 원칙을 SOLID 원칙이라고도 합니다.

     

    객체지향 설계 원칙

    원칙 설명
    단일 책임의 원칙 (SRP)
    (Single Responsibility Principle)
    하나의 클래스는 하나의 목적을 위해 생성
    개방 폐쇄 원칙 (OCP)
    (Open Close Principle)
    소프트웨어의 구성요소는 확장에는 열려있고, 변경에는 닫혀있어야 한다는 원칙
    리스코프 치환의 원칙 (LSP)
    (Liskov Substitution)
    서브 타입(상속받은 하위 클래스)은 어디서나 자신의 기반 타입(상위 클래스)으로 교체할 수 있어야 한다는 원칙
    인터페이스 분리의 원칙 (ISP)
    (Interface Segregation Principle)
    클라이언트는 자신이 사용하지 않는 메서드와 의존관계를 맺으면 안된다.
    클라이언트가 사용하지 않는 인터페이스 때문에 영향을 받아서는 안된다.
    의존성 역전의 원칙 (DIP)
    (Dependency Inversion Principle)
    실제 사용 관계는 바뀌지 않으며, 추상을 매개로 메시지를 주고받음으로써 관계를 최대한 느슨하게 만드는 원칙

    [참고] 객체지향 설계원칙: https://simuing.tistory.com/entry/2021-%EC%A0%95%EB%B3%B4%EC%B2%98%EB%A6%AC%EA%B8%B0%EC%82%AC-%ED%95%84%EA%B8%B0%EC%9A%94%EC%95%BD-%EC%95%A0%ED%94%8C%EB%A6%AC%EC%BC%80%EC%9D%B4%EC%85%98-%EC%84%A4%EA%B3%84

    [참고] 프로그래머를 위해 실제 예시와 함께 객체지향 설계 원칙을 설명한 글: https://velog.io/@ggomjae/%EA%B0%9D%EC%B2%B4-%EC%A7%80%ED%96%A5-%EC%84%A4%EA%B3%84-5%EC%9B%90%EC%B9%99-SOLID

    [참고] 객체지향 설계 원칙 요약: https://y-oni.tistory.com/m/entry/2021-%EC%A0%95%EB%B3%B4%EC%B2%98%EB%A6%AC%EA%B8%B0%EC%82%AC-%ED%82%A4%EC%9B%8C%EB%93%9C-%EC%A0%95%EB%A6%AC-%EA%B0%9D%EC%B2%B4%EC%A7%80%ED%96%A5-%EB%B6%84%EC%84%9D%EC%9D%98-%EB%B0%A9%EB%B2%95%EB%A1%A0

     

    객체지향 설계 원칙을 위에서부터 살펴보겠습니다. 단일 책임 원칙은 말 그대로 클래스가 하나의 책임만 가져야하는 것이죠. 아래의 설명들을 다 알아야할 필요는 없지만 이해가 되어야 외우기 쉬운 분들은 긴 설명들도 참고하시면 될 것 같습니다.

     

    [추가 설명]

    클린 아키텍처 (저자: 로버트 C. 마틴) 책에 나온 예시를 보면 한 Employee 클래스 안에 임금을 계산하는 calculatePay() (회계팀에서 임금 계산용으로 사용할 함수) 와 일한 시간을 확인하는 reportHours() (인사팀에서 일한 시간 확인을 위하여 사용할 함수) 가 모두 포함되어있는 경우 단일 책임 원칙에 위배됩니다. 혹시나 해당 클래스 안에서 공통된 부분 (초과 근무시간 계산 방법 등)이 바뀌게 되면 회계팀과 인사팀에서 필요로하는 함수가 모두 영향을 받을 수 있습니다. 그러면? 인사팀을 위한 클래스, 회계팀을 위한 클래스를 분리한다면 각자 클래스 내부를 수정하더라도 서로에게 영향을 주지 않게 될 것입니다.

    [그림 출처] https://medium.com/swlh/solid-design-principles-the-simplest-explanation-8df7164308f5

     

    개방 폐쇄 원칙은 "변경에는 닫혀있고 (Close), 확장에는 열려있다 (Open)" 는 원칙입니다. 기존의 코드는 변경하지 않고 (Close) 도 새로운 기능을 추가 (Open) 할 수 있게 하는 것입니다. 피치 못하는 경우, 기존의 코드도 수정해야할 수 있겠지만 그러면 기존의 코드가 수행하던 동작은 다 영향을 받게 되니 최대한 건드리지 않는 편이 좋을 것입니다. 

     

    리스코프 치환 (혹은 교체)의 원칙은 치환 (Substitution) 이라는 단어에 집중하시면 될 것 같습니다. 'B가 A의 자식 타입이면 부모 타입인 A 객체는 자식 타입인 B로 치환해도, 작동에 문제가 없어야 한다'. 는 원칙입니다. 요약하면 부모 클래스와 자식 클래스 간에 치환이 되어야한다는 뜻이죠. 부모 클래스를 상속받아 자식 클래스를 만들 수가 있는데, 그러면 자식 클래스는 최대한 부모 클래스에서 제공하는 기능들은 동작할 수 있어야할 것입니다. 부모 클래스에서 만든 객체를 자식 클래스 객체처럼 다뤄도 문제 없이 동작할 수 있다면 리스코프 치환 원칙이 만족된 것입니다.

     

    [참고] 리스코프 치환의 원칙 자세한 설명: https://pizzasheepsdev.tistory.com/9

     

    인터페이스 분리의 원칙은 클라이언트가 사용하지 않는 메서드에 의존하지 않아야 하는 원칙입니다. 더 간단하게 표현하면 자신과 관련없는 메서드 (함수) 는 구현하지 말라는 뜻입니다. 구체적인 코드 예시로 보면 다음과 같습니다.

     

    이동체라는 이름으로 drive() 와 fly() 기능을 다 선언해두었습니다. 그러나 실제 클라이언트는 자동차, 비행기 등 drive() 만 할 수 있거나 fly() 만 할 수 있는 물체일 것입니다. 그러면 분리해야한다는 것입니다.

    Interface 이동체 {
      drive();
      fly();
      sail();
      stop();
    }

    분리하면 다음과 같습니다.

    Interface 자동차 {
      drive(); 
      stop(); 
    }
    Interface 비행기 { 
      fly();
      stop(); 
    }
    Interface 배 {
      sail();
      stop(); 
    }

    [코드 출처] https://itwiki.kr/w/%EC%9D%B8%ED%84%B0%ED%8E%98%EC%9D%B4%EC%8A%A4_%EB%B6%84%EB%A6%AC%EC%9D%98_%EC%9B%90%EC%B9%99

     

    분리하지 않으면? 부모 클래스를 상속받아 자식 클래스를 만드는 경우 자동차 클래스를 만들더라도 fly() 함수를 반드시 선언해야할 것입니다. 아무 동작도 하지 않게 만들겠지만 굳이 필요하지 않은 메서드를 남겨두고, 사용자가 접근할 수 있게 두는 것은 이상할 것입니다. (어? 자동차에 비행 버튼이 있네? 같은 느낌이죠...)

     

    [참고] SRP와 ISP 가 무엇이 다른지: https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=ruvendix&logNo=221976211995 

     

    마지막 개념은 의존성 역전 원칙입니다. 의존성 역전 원칙은 "고수준 모듈은 저수준 모듈의 구현에 의존해서는 안 된다. 저수준 모듈이 고수준 모듈에서 정의한 추상 타입에 의존해야 한다."를 원칙입니다. 이는 다음과 같이 쉽게 설명하기도 합니다. "자신보다 변하기 쉬운 것에 의존하지 마라"

     

    자동차에 겨울에 필요한 스노우 타이어를 장착하여 의존성을 만들었습니다. 그런데 스노우 타이어를 다른 타이어로 교체하게 되면 자동차가 의존성을 가지고 있었기 때문에 교체에 영향을 받게 됩니다.  

    이를 해결하기 위해서 (자동차가 스노우 타이어 교체에 영향을 받지 않기 위해서) 타이어라는 추상적인 인터페이스를 중간에 하나 만들면 됩니다. 

    그러면 스노우타이어를 일반 타이어로 교체해도 자동차는 영향을 받지 않게 됩니다.

     

    [그림 및 설명 출처] https://steady-coding.tistory.com/388

     

    문제를 풀어보겠습니다.

    5. 다음 내용이 설명하는 객체지향 설계 원칙은?
    - 클라이언트는 자신이 사용하지 않는 메서드와 의존 관계를 맺으면 안 된다.
    - 클라이언트가 사용하지 않는 인터페이스 때문에 영향을 받아서는 안 된다.

    (1) 인터페이스 분리 원칙
    (2) 단일 책임 원칙
    (3) 개방 폐쇄의 원칙
    (4) 리스코프 교체의 원칙

    (2020.09.26 정보처리기사 필기 기출문제 - 출처: 전자문제집 CBT)

    사용하지 않는 인터페이스에 영향을 받지 않는 것이므로 1번 인터페이스 분리 원칙이 됩니다.

     


    8. 코드 ★★★

    교재 단원: 애플리케이션 설계

    정보처리기사 필기 (2020.06.06 ~ 2020.09.22) 의 3번의 시험 중 100% 출제된 문제입니다.

     

    코드란 컴퓨터를 이용하여 자료를 처리하는 과정에서 분류, 조합, 집계를 용이하게 하고 특정 자료의 추출을 쉽게 하기 위해 사용하는 기호를 의미합니다.

    예를 들어, 서울특별시는 101, 부산광역시는 102, 대구광역시는 103, 인천광역시는 104 처럼 기호를 부여하는 것입니다. 혹은 주민등록번호, 학번도 모두 코드의 예시입니다.

     

    코드의 기능은 3가지가 있습니다. 위의 예시를 생각해보면 식별할 수 있고, 분류할 수 있을 것입니다. 숫자 크기에 의미가 있는 경우 순서대로 나열하는 배열 기능도 있을 수 있습니다.

    코드의 기능
    (1) 식별 기능
    (2) 분류 기능
    (3) 배열 기능

     

    이보다 더 중요한 것은 코드의 종류입니다. 설명이 주어졌을 때 어떤 종류의 코드인지 알 수 있어야합니다.

    코드의 종류
    (1) 순차 코드: 일정 기준에 따라 최초의 자료부터 일련번호를 부여하는 방법
    (2) 블록 코드: 대상 항목에서 공통적인 것들을 블록으로 구분하고 블록 내에 일련번호를 부여하는 방법
    (3) 10진 코드: 대상 항목을 0~9까지 10진 분할하고 다시 각각에 대하여 10진 분할을 필요한 만큼 반복하는 방법
    (4) 그룹 분류 코드: 일정 기준에 따라 대분류, 중분류, 소분류 등으로 구분하고 그룹 안에서 일련 번호를 부여하는 방법
    (5) 연상 코드: 항목의 명칭이나 약호와 관계있는 숫자, 문자, 기호를 이용하여 코드를 부여하는 방법
    (6) 표의 숫자 코드: 항목의 성질(길이, 넓이, 부피 등) 의 물리적인 수치를 그대로 코드에 적용시키는 방법
    (7) 합성 코드: 하나의 코드로 수행하기 어려운 경우 2개 이상의 코드를 조합하여 적용시키는 방법

    [참고] 코드의 종류 요약: https://1d1cblog.tistory.com/146

     

    순차 코드는 특정 기준을 가지고 순서대로 번호를 부여하는 것입니다. 사람 이름을 가나다라 순서에 따라 1, 2, 3, 4... 순으로 번호를 매긴다면 순차 코드가 됩니다.

     

    블록 코드는 블록으로 구분하고 그 안에서 순서대로 코드를 부여합니다. 예를 들어, 1-5는 총무부에 해당하면 그 안에 있는 총무과, 인사과, 서무과, 경리과는 1, 2, 3, 4 코드를 부여받게 됩니다. 6-10 은 판매부에 해당하면 그 안에 있는 판매1과, 판매2과, 판매3과는 6, 7, 8 코드를 부여받게 됩니다. 학번도 입학년도 블록 안에 순서대로 번호를 부여받기 때문에 블록 코드에 해당합니다.

     

    10진 코드는 한 자리마다 10진수로 표현할 것을 의미합니다. 도서관에서 책 분류 코드로 많이 볼 수 있습니다. 총류는 000, 철학은 100, 역사는 200, 사회과학은 300, 정치는 310 이런 식입니다. (3자리로 다 표현이 안 된다면 숫자는 더 길어지게 됩니다.)

     

    그룹 분류 코드는 기준에 따라 대분류, 중분류, 소분류로 구분하는 것입니다. 총무부 (1) - 인사과 (1) - 행정계 (1) 혹은 총무부 (1) - 경리과 (2) - 행정계 (1) 이런 식으로 표현하게 됩니다.

     

    연상 코드는 코드 값을 보면 어떤 대상을 의미하는지 연상할 수 있도록 의미를 그대로 부여하는 것입니다. 예를 들어 한국은 KOR, 미국은 USA, 중국은 CHN 으로 표현하는 방식이 있을 수 있습니다. 숫자를 섞는다면 18인치 컬러 TV는 TV-C-19, 17인치 흑백 TV는 TV-W-17 이런 식으로 표현할 수 있을 것입니다.

     

    표의 숫자 코드는 길이, 부피, 넓이 등 성질을 의미하는 물리적 수치를 그대로 코드에 적용시키는 방법입니다. 예를 들어 두께 127 mm, 폭 890 mm, 길이 1245 mm 의 강판을 127-890-1245로 표기했다면 이건 표의 숫자 코드가 됩니다.

     

    합성 코드는 두 개 이상의 코드를 조합하여 만드는 코드입니다. 예를 들어 항공회사 (연상 코드) + 일련번호 (순차 코드) 를 섞어서 대한항공 737기는 KAL-737 로, 일본항공 131기는 JAL-131로 표현할 수 있습니다.

     

    [예시 출처] https://slidesplayer.org/slide/16356629/https://m.blog.naver.com/luciakimtv/222052940159

     

    한 번에 잘 외워지셨을지 모르겠습니다. 문제를 한 번 풀어보겠습니다.

    2. 코드 설계에서 일정한 일련번호를 부여하는 방식의 코드는?
    (1) 연상 코드
    (2) 블록 코드
    (3) 순차 코드
    (4) 표의 숫자 코드

    (2020.06.06 정보처리기사 필기 기출문제 - 출처: 전자문제집 CBT)

    일정한 일련번호를 부여하는 것은 순서대로 숫자를 부여하는 것이므로 3번 순차 코드가 정답입니다.


    9. 자료사전 ★★★

    교재 단원: 요구사항 확인

    정보처리기사 필기 (2020.06.06 ~ 2020.09.22) 의 3번의 시험 중 100% 출제된 문제입니다.

     

    자료사전 (Data Dictionary) 은 자료 흐름도(10. DFD는 아래에서 다시 설명합니다.)에 기술된 자료들에 대해 정의하는 것입니다. 시험에는 특정 의미를 가진 기호가 어떤 것인지 찾는 문제가 나옵니다. 따라서 기호와 의미를 매칭할 수 있어야합니다.

    자료 사전의 기호
    • =: 정의(is composed of)
    • +: 연결(and)
    • {}: 반복(iteration of)
    • []: 선택(choose only one of)
    • (): 생략(optional)
    • **: 주석(comment)

    [참고] 자료 사전의 기호 요약: https://jtrimind.github.io/%EC%A0%95%EB%B3%B4%EC%B2%98%EB%A6%AC%EA%B8%B0%EC%82%AC/2020/12/09/data-dictionary.html

     

    잘 외워지지 않는다면 다음 예시를 참고해도 좋을 것 같습니다.

    [그림 출처] https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=leehojun13&logNo=30153022406 

     

    =는 정의하는 것이고, +는 연결을 의미합니다. 예약 구분이 [ "예약신청" | "입금완료" | "미예약" ] 상태 중 하나를 선택할 수 있도록 표현한 것이 보입니다. () 는 생략 가능한 것을 의미합니다. 7.2 코드 = * 2.4.1에 정의됨 * 으로 *과 *을 이용하여 comment (주석) 용도로 사용한 것을 볼 수 있습니다. 마지막으로 {} 는 반복입니다. 12. 예약결과 통보서를 보면 {} 안에 예약일자, 호실, 예약자 성명 등이 들어있는데, 3박 4일 예약을 했다면 예약 결과 통보서에 3일치가 나올 것이므로 이만큼 반복하여 표현하게 될 것입니다.

     

    문제를 풀면 다음과 같습니다.

    16. 자료 사전에서 자료의 반복을 의미하는 것은?
    (1) =
    (2) ( )
    (3) { }
    (4) [ ]

    (2020.08.22 정보처리기사 필기 기출문제 - 출처: 전자문제집 CBT)

    혹시 잘 안 외워지고 헷갈리신다면 위에 예시와 함께 보시면, 쉽게 외워지실 것 같습니다. 반복을 의미하는 것은 3번 중괄호 입니다.

     


    10. DFD ★★★

    교재 단원: 요구사항 확인

    정보처리기사 필기 (2020.06.06 ~ 2020.09.22) 의 3번의 시험 중 100% 출제된 문제입니다.

     

    자료 사전 (DD) 와 같이 다니는 개념인 자료 흐름도 (Data Flow Diagram) 입니다.

    자료 흐름도 (DFD)는 시스템 구성 요소인 프로세스와 프로세스 간 데이터 흐름을 표현하는 주요 도구입니다. 버블 차트라고 부르기도 합니다. 구조적 분석 기법에 사용됩니다. (이런 설명도 맞는지 틀린지 고르도록 시험에 나오기도 합니다)

     

    자료 흐름도의 구성 요소가 다음과 같은데, 문제를 풀기 전에 다음의 구성 요소들을 반드시 확인해주세요.

    • process : 원
    • data flow: 화살표
    • data store: 직선(단선/이중선)
    • terminator: 사각형

    [참고] DFD 그림 출처: https://jtrimind.github.io/%EC%A0%95%EB%B3%B4%EC%B2%98%EB%A6%AC%EA%B8%B0%EC%82%AC/2020/08/07/dfd.html

    [참고] DFD 설명: https://devinus.tistory.com/8

     

    Data Store는 위 아래 선으로 표현됩니다. Data Flow는 화살표로 표현됩니다. Process는 원입니다. 마지막 끝부분에 해당하는 Terminator는 사각형입니다.

     

    문제를 풀어보겠습니다.

    18. 자료흐름도 (Data Flow Diagram) 의 구성요소로 옳은 것은?
    (1) process, data flow, data store, comment
    (2) process, data flow, data store, terminator
    (3) data flow, data store, terminator, data dictionary
    (4) process, data store, terminator, mini-spec

    (2020.08.22 정보처리기사 필기 기출문제 - 출처: 전자문제집 CBT)

    구성요소는 data store, data flow, process, terminator 이죠. 답은 2번입니다.

     


    보너스. 디자인 패턴 ★★

    교재 단원: 애플리케이션 설계

    정보처리기사 필기 (2020.06.06 ~ 2020.09.22) 의 3번의 시험 중 2번 출제된 문제입니다.

     

    10개 개념을 다 학습하여 추가적인 학습이 필요하신 분들을 위하여 준비하였습니다.

     

    디자인 패턴은 크게 3가지, 생성 패턴, 구조 패턴, 행위 패턴으로 분류할 수 있는데요. 각각에 속하는 세부적인 디자인 패턴을 보면 이렇게나 많습니다.

    디자인 패턴
    • 생성 패턴
      • 추상 팩토리 패턴
      • 빌더 패턴
      • Factory Method 패턴
      • 프로토타입 싱글톤
    • 구조 패턴
      • 어댑터
      • 브리지
      • 컴포지트
      • 데코레이터
      • 퍼씨드
      • 플라이웨이트
      • 프록시
    • 행위 패턴
      • 책임 연쇄
      • 커맨드
      • 인터프리터
      • 반복자
      • 중재자
      • 메멘토
      • 옵서버
      • State (상태) 패턴
      • 전략
      • 템플릿 메소드
      • 방문자

    [참고] 디자인 패턴: https://shlee1990.tistory.com/category/%EC%9E%90%EA%B8%B0%EA%B3%84%EB%B0%9C/%EC%9E%90%EA%B2%A9%EC%A6%9D

     

    이걸 다 외우면 모든 문제를 맞출 수 있어 좋겠지만, 정보처리기사 필기 범위를 공부할 시간은 부족하고 양은 많기 때문에 다 외우기 보다 꼭 필요한 것을 외운다면 각 이름들이 어디에 속하는지 분류할 수 있어야합니다.

     

    생성 패턴에 속하는 추상 팩토리, 빌더, 팩토리 메소드, 프로토타입 싱글톤 들은 새로운 것을 생성하는 듯한 느낌의 이름들입니다.

     

    구조 패턴은 중간 다리 역할을 하는 브리지, 구성 요소를 뜻하는 컴포넌트 등 구조와 관련된 디자인 패턴입니다.

     

    행위 패턴의 경우 책임 연쇄, 커맨드, 인터프리터, 반복자, 중재자, 옵저버, 방문자 등 행위자의 느낌을 주는 이름이 많습니다. 그런데 문제에서 함정으로 내기 좋은 "상태 패턴" 이 행위 패턴이라는 것을 잘 기억해주시기 바랍니다. 이 "상태"는 게임 캐릭터가 달리거나 가만히 있는 상태처럼 어떤 행위를 의미하게 됩니다.

     

     

    혹시나 구체적으로 알고 싶고, 실제로 코드 예시가 필요한 경우 아래를 참고 부탁드립니다.

     

    [참고] 스테이트 패턴: https://victorydntmd.tistory.com/294

     

    마지막 문제를 풀어보겠습니다.

    8. 디자인 패턴 중에서 행위적 패턴에 속하지 않는 것은?
    (1) 커맨드 (Command) 패턴
    (2) 옵저버 (Observer) 패턴
    (3) 프로토타입 (Prototype) 패턴
    (4) 상태 (State) 패턴

    (2020.08.22 정보처리기사 필기 기출문제 - 출처: 전자문제집 CBT)

    디자인 패턴 중에서 행위적 패턴에 속하지 않는 것... 커맨드 (명령), 옵저버 (관찰) 등은 행위와 관련이 있고, 프로토타입은 생성 패턴입니다. 상태 패턴이 헷갈릴 수 있는 함정이었는데, 위에서 봤듯이 상태는 행위적 패턴에 속합니다. 답은 3번입니다.

     


    참고

    정보처리기사 필기 전자문제집 CBT: https://www.comcbt.com/xe/iz

     

     

     

     

     

     

     

    댓글

Designed by Tistory.