[정처기] 1과목 소프트웨어 설계 21년 기출 정리

하나·2022년 4월 23일
0

CS

목록 보기
5/7
post-thumbnail

21년 1회

  1. linux 명령어

    ls : 디렉토리 목록

    cat : 파일 출력

    pwd : 현재 디렉토리 출력

    uname : 시스템 정보 출력

  2. 시스템 연계 기술

    1. DB 링크 : DB 링크 객체 이용, 수신 생성, 송신 직접 참조 (e.g., ODBC, JDBC)
    2. DB커넥션 : 수신측 WAS → 송신측 DB로 연결하는 DB connection pool 이용
    3. API/openAPI : 송신측 DB에서 data 가져와 제공하는 응용 어플리케이션 인터페이스
    4. JDBC : JDBC 드라이버 이용, DBMS유형, DBMS 서버 IP, port, DB instance 알아야함
    5. 소켓 : 소켓 생성하고 port를 할당하는 네트워크 기술
  3. 객체 프로그래밍의 특징

    1. 추상화
    2. 캡슐화
    3. 상속
    4. 다형성
    5. 동적바운딩
  4. 미들웨어

  5. WAS : 어플리케이션 수행 미들웨어

  6. MOM : 메세지 지향 미들웨어

  7. RPC : 원격 프로시저 호출

  8. ORB : 네트워크 호출 미들웨어

  9. 객제지향 분석 방법론

    1. booch
      • 미시적, 거시적 개발 프로세스를 모두 사용
      • 클래스와 객체들을 분석 및 식별, 클래스의 속성과 연산을 정의
    2. jacobson
      • 유저케이스 사용하여 분석
      • 사용자, 외부 시스템, 다른 요소들이 시스템과 상호 작용 하는 방법 기술
    3. coad-yourdon
      • ERD 사용하여 객체의 행위를 모델링
      • 객체식별, 구조 식별
    4. wirfs-brock
      • 분석과 설계간 구분이 없으며, 고객 명세서 평가하여 설계 작업까지 연속적으로 수행
  10. 현행 시스템 분석

  • 플랫폼 기능 분석
  • 플랫폼 성능 특성 분석
  • 운영체제 분석
  • 네트워크 분석
  • DBMS 분석
  • 비즈니스 융합 분석
  1. 미들웨어

    • 운영체제와 해당 운영체제에서 실행되는 응용 프로그램 사이에서 운영체제가 제공하는 서비스 이외에 추가적인 서비스를 제공하는 소프트웨어.
    • 표준화된 인터페이스를 제공함으로써 시스템 간의 데이터 환에 일관성을 보장,
    • 분산 환경에서 서로 다른 기종 간의 하드웨어나 프로토콜, 통신환경 등 연결하여 응용프로그램과 운영환경간에 원만한 통신이 이루어질 수 있게 서비스를 제공하는 소프트웨어
    • 그레이웨어 : 정상소프트웨어와 바이러스 사이에 해당하는 것들.
    • adware : 광고를 포함하여 이를 보는 대가로 무료로 사용하는 소프트웨어
    • trackware : 시스템 작업을 추적하고 시스템 정보를 수집하거나 사용자 습관을 추적하여 이 정보를 다른 조직에 전달
    • spy ware : 사용자 몰래 pc에 설치되어 정보를 수집하는 악성 코드
    • 오픈 허브 웨어(open hubware) :많은 사용자들이 판매, 구매, 유통 등의 서비스를 지원받을 수 있도록 지원하는 개방형 소프트웨어. 온라인 쇼핑, 택배회사 등에서 사용하는 소프트웨어.
  2. CASE

    CASE(Computer Aided Software Engineering): software 개발을 지원하는 도구로 software개발자들을 지원한다. (software사용자들을 위해 사용하는 도구가 아님)

    • software module의 재사용성 향상
    • 자동화된 기법을 통해 software 품질 향상
    • software 유지보수를 간편하게 수행할 수 있다
  3. use case 구성요소와의 관계

  • 연관 : use case와 actor 의 관계
  • 확장 : 기본 유스케이스 수행 시 특별한 조건을 만족할 때 수행할 유스케이스
  • 포함 : 시스템의 기능이 별도의 기능을 포함
  • 일반화 : 하위 use case/action 이 상위 usecase/actor에게 기능,역할을 상속받음
  • 그룹화 : 여러개의 usecase 단순화 하는 방법

21년 3회

  1. 요구사항 검증과 관련한 설명

    • 검증 : 개발자, 소프트웨어 잘 만들고 있는지
    • 확인 : 고객 입장에서 기능들 확인
    • 도출 → 분석 → 명세 → 확인

    요구사항 분석 기법은 크게 두가지로 나뉨

    1. 구조적 분석 : 도형 중심의 분석용 도구, " 사용자의 요구사항을 파악하기 위하여 자료의 흐름과 가공 절차를 그림 중심으로 표현하는 방법 " , 하향식 분석 모델

      자료흐름도(DFD)→자료사전(DD)→소단위명세서(mini spec.)

      • DFD : 시스템 내의 모든 자료 흐름을 4가지의 기호 (처리, 자료흐름, 자료 저장소, 단말)로 기술하는 방법
      • DD : DFD에 있는 자료 상세히 기록, = 정의, + 연결, () 생략, [|] 선택, {} 반복, ** 설명
      • mini spec : 자료 흐름도의 최하위 단계 처리 공정의 절차를 기술한 것
    2. 객체지향적 분석 : 주어진 문제를 실세계의 객체로 보고 상호작용 나타낸 것, 재사용성 늘리고 이해도 높이는 장점 (UML 사용)

    요구사항 도출 기법

    • 인터뷰
    • 포커스 그룹
    • 집단창의력 기법
    • 이해관계자 설문조사
    • 관찰
    • 문헌 조사
    • 프로토타입
    • 벤치마킹
    • 사용자 스토리텔링

    요구사항 명세

    분석된 요구사항을 바탕으로 모델 작성, 문서화, 기능 요구사항 빠짐없이 기술, 비기능 요구사항을 필요한 것만 기술, 구체적인 명세를 위해 소단위 명세서가 사용될 수 있음


출처 : https://computer-science-student.tistory.com/166

  1. UML Class 간 관계
  • 일반화 관계 Generalization(상속)
    • 객체지향 개념에서 상속관계
  • 실체화 관계 Realization(구현)
    • 인터페이스와 그것을 구현한 것과의 관계
  • 의존 관계 Dependency (참조) - 일시적 참조
    • 어떤 클래스가 다른 클래스를 참조하는 관계
  • 연관 관계 Association
    • 직접 연관 : 한 클래스가 다른 클래스를 참조하는 관계
    • 집합 연관 : 참조하는 객체나 클래스가 사용 후에도 유지되는 관계
    • 복합 연관 : 참조한 객체가 사라지면 참조하는 객체도 사라지는 관계
  1. 익스트림 프로그래밍 (의사선생님 약주실때 피존 용기에 담아주세요)

+크리스탈

  1. 설계 모형에 사용되는 추상화 (제기자)

    • 제어 추상화 : 제어의 정확한 매커니즘을 정의하지 않고 원하는 효과를 정하는데 이용하는 방법
    • 기능 추상화 : 입력 자료를 출력자료로 변환하는 과정을 추상화
    • 자료 추상화 : 자료와 자료에 적용될 수 있는기능을 함께 정의함으로써 자료 객체 구성하는 방법

    설계 모형 구조

    • 데이터 설계
    • 아키텍쳐(구조) 설계
    • 인터페이스 설계
    • 절차(프로시저) 설계
  2. 정보 은닉 : 다른 객체에게 자신의 정보를 숨기고 자신의 연산만을 통해 접근을 허용하는 것

    클래스 외부에서 특정 정보에 접근을 막음

    장점

    1. 기능의 교체나 변경에 대한 유연성 제공 (객체 간의 구체적인 결합도 약화)
    2. 동일한 타입의 다른 구현 객체들을 교체로 동적 기능 변경 가능
    3. 구체적인 구현이 없는 상태로도 정확한 연동 코드의 생성 가능
    4. 모듈화하여 코드의 가독성 증가
    5. 개발기간 단축

    객체 지향 프로그래밍 특징

    • 추상화
    • 캡슐화
    • 상속
    • 다형성
      • 오버로딩 : 똑같은 이름으로 메서드를 만들면서 인자값만 다르게 하는 것
      • 오버라이딩 : 상속관계에서 부모로부터 물려받은 것을 재정의 하는 것
    • 동적 바운딩 : 변수 선언할때 변수 타입들을 동적으로 변화시키는 것
  3. 요구 분석

소프트웨어 개발의 실제적인 첫 단계

요구 추출은 프로젝트 계획 단계에 정의한 문제의 범위 안에 있는 사용자의 요구를 찾는 단계

도메인 분석 : 요구에 대한 정보를 수집하고 배경 분석, 이를 토대로 모델링

  • 기능적 요구사항
    • 시스엠이 수행해야 하는 행위들을 구체화 한 것
    • 시스템에서 제공해야 할 기능을 정의 한 것
    • 입력, 출력 기능, 데이터베이스기능, 통신 기능 등
  • 비기능적 요구사항
    • 시스템이 가져야 하는 기능 이외의 요구사항
    • 시스템의 전체적인 품질이나 고려해야 하는 제약사항 등
    • 사용 용이성, 효율성, 신뢰성, 이식성, 유연성, 확장성 등
    • 성능적인 면 : 응답 속도, 자원 사용량 등
    • 보안 측면 : 침입 대응, 침입 탐지, 사용자 인증, 권한 부여 등
  1. 클래스 다이어그램 - 객체를 그리는 것 UML 다이어그램 종류 구조 7개, 행위 7개
    • 구조적 다이어그램 : 객체의 구조 (정적)
      • 클래스(class) : 시스템을 구성하는 클래스들 사이의 관계 표현
      • 객체(object) : 객체 정보를 보여줌
      • 복합체구조(composite structure) : 복합 구조의 클래스와 컴포넌트 내부 구조 표현
      • 배치(deployment) : SW, HW, 네트워크를 포함한 실행 시스템의 물리 구조 표현
      • 컴포넌트(component) : 컴포넌트 구조 사이의 관계를 표현
      • 패키지(package): 클래스나 유스케이스 등을 포함한 여러 모델 요소들을 그룹화해 패키지를 구성하고 패키지들 사이의 관계 표현
    • 행위 다이어그램 : 객체들이 어떻게 움직일 것인지 (동적)
      • 활동(activity) : 업무 처리 과정, 연산이수행되는 과정 표현
      • 상태 머신(state machine) : 객체의 생명주기 표현
      • 유스케이스(use case) : 사용자 관점에서 시스템 행위 표현
      • 순차(sequence) : 시간 흐름에 따른 객체 사이의 상호작용 표현
      • 상호작용개요(interaction overview diagram) : 여러 상호작용 다이어그램 사이의 제어 흐름 표현
      • 통신(communication) : 객체 사이의 관계를 중심으로 상호작용 표현
      • 타이밍(timing) : 객체 상태 변화와 시간 제약을 명시적으로 표현
  2. 마스터-슬레이브(Master-Slave)
    • 일반적으로 실시간 시스템에 사용
    • 마스터 프로세스는 일반적으로 연산, 통신, 조정 책임짐
    • 마스터 프로세스는 슬레이브 프로세스들을 제어 할 수 있음
    • 마스터 : 작업을 분리, 배포, 슬레이브가 반환한 결과값으로부터 최종 결과값 계산
    • 슬래이브 : 요청 작업 처리, 처리된 결과를 되돌려 줌, 데이터 수집 기능만 함

  1. 요구 사항 정의 및 분석, 설계의 결과물을 표현하기 위한 모델링 과정에서 사용되는 다이어그램
  • DFD
  • UML
  • ERD
  • AVL : 이진트리의 높낮이가 불규칙해지는 것을 보완하여 일정하게 처리하기 위한 이진트리 모형
  1. 객체지향
  • 연산을 전달받아 새로운형태의 클래스로 확장하여 사용하는 것 → 상속
  • 객체는 실세게에 존재하거나 생각할 수 있는 것
  • 클래스는 하나 이상의 유사한 객체들을 묶어 공통된 특성을 표현한 것
  • 다형성은 상속받은 여러개의 하위 객체들이 다른 형태의 특성을 갖는 객체로 이용될 수 있는 성질
  1. UI 설계 원칙

    • 직관성 : 누구나 쉽게 이해하고 사용할 수 있어야 함
    • 유효성 : 사용자의 목적을 정확하게 달성해야 함
    • 학습성 : 누구나 쉽게 배우고 익힐 수 있어야 함
    • 유연성 : 사용자의 요구사항을 최대한 수용하며, 오류를 최소화해야 함
  2. 객체지향 분석 방법론

  • coad와 yourdon : ERD 사용하여 객체의 행위 모델링, 객체 식별, 구조 식졀, 주체 정의, 속성 및 관계 정의, 서비스 정의 등의 과정으로 구성
  • Booch : 미시적 개발 프로세스와 거시적 개발 프로세스를 모두 사용하는 분석 방법
  • Jacobson : 유스케이스를 강조하여 사용하는 분석 방법
  • Wirfs-Brocks : 분석과 설계 간의 구분이 없고, 고객 명세서를 평가해서 설계 작업까지 연속적으로 수행
  1. 순차 다이어그램은 동적 다이어그램. 교류 다이어그램의 한 종류

  2. 객체 지향 분석 기법 - 상향식

    구조적 분석 기법 - 하향식

- 단일 책임 원칙 : 하나의 클래스는 하나의 기능
- 개방-폐쇄 원칙 : 수정에는 닫혀있고 확장에는 열려있는
- 리스코프 치환 원칙 : 하위클래스는 상위클래스를 대체 가능
- 인터페이스 분리 원칙 : 쓰지 않는 인터페이스에 연결 하지 마라
- 의존관계 역전 원칙 : 자주 바뀌는데 의존 하지 마라
  1. 미들웨어 종류
  • RPC
  • MOM
  • WAS
  • ESB
  • TP moniter
  • DB
  • ORB

  1. SW 아키텍처
    • 외부에서 인식할 수 있는 특성이 담긴 소프트웨어의 골격이 되는 기본 구조
    • 데이터 중심 아키텍처는 공유 데이터 저장소를 통해 접근자 간의 통신이 이루어지므로 각 접근자의 수정과 확장이 용이
    • 이해 관계자들의 품질 요구사항을 반영하여 품질 속성을 결정
    • 파이프 필터 아키텍처는 단방향, 필터 이동시 오버헤드 발생될 수 있음

21년 2회

  1. 시스템의 구성 요소 5가지: input, output, process, feedback, control

  2. 유스케이스 : 시스템이 액터에게 젝공해야 하는 기능, 시스템의 요구사항이자 기능을 의미

    • 유스케이스 다이어그램 : 사용자의 요구를 추출하고 분석하기 위해 주요 사용
    • 액터 : 시스템 외부에서 시스템과 상호작용하는 사람 혹은 시스템
      • 사용자 액터 : 기능을 요구하는 대상이나 시스템의 수행결과를 통보받는 사용자 혹은 기능을 사용하게 될 대상, 유스케이스의 권한을 가지는 대상,역할
      • 시스템 액터 : 사용자 액터가 사용한 유스케이스를 처리해주는 외부 시스템
  3. 요구사항 개발 프로세스 : 도출 → 분석 → 명세 → 확인

  4. instance : 객체지향 기법에서 같은 클래스에 속한 각각의 객체

    message : 객체에게 어떤 행위를 하도록 지시하는 명령

    method : 객체에 소속된 함수

    module : 실행코드와 객체들의 묶음 (함수, 클래스, 변수)

    package : 클래스를 묶어두는 물리적인 단위

    class : 객체를 정의해놓은 것, 객체의 설계도, 틀

    object : 실제로 존재하는 것, 클래스에 정의된 내용대로 메모리에 생성된 것

  5. 캡슐화를 통해 정보은닉 : 객체지향 설계에서 객체가 가지고 있는 속성과 오퍼레이션의 일부를 감추어서 객체의 외부에서는 접근이 불가능하게 하는 개념

  6. GoF (gangs of Four) 디자인 패턴

    • factory method pattern : 상위클래스에서 객체를 생성하는 인터페이스를 정의하고, 하위클래스에서 인스턴스를 생성하도록 하는 방식
    • prototype pattern : 프로토타입을 먼저 생성하고 인스턴스를 복제히여 사용하는 구조
    • Adapter pattern : 기존에 구현되어 있는 클래스에 기능 발생 시 기존 클래스를 재사용할 수 있도록 중간에서 맞춰주는 역할
    • mediator pattern : 객체간의 통제와 지시의 역할을 하는 중재자를 두어 객체지향의 목표를 달성하게 해준다.
    • 디자인 패턴 개념 디자인 패턴이란 ? 모듈의 세분화된 역할이나 모듈들 간의 인터페이스 구현 방식을 설계할때 참조할 수 있는 전형적인 해결 방식, 디자인 패턴을 통해 설계 문제, 해결방법, 해결 방법을 언제 적용해야 할지, 그 결과는 무엇인지 등 알 수 있다. 또한 디자인 패턴은 한 패턴에 변형을 가하거나 어떠한 요구사항을 반영하면 다른 패턴으로 변형되는 특징이 있다. 1995년 GoF(Gang of Four)라고 불리는 Erich Gamma, Richard Helm, Ralph Johnson, John Vissides가 처음으로 디자인 패턴을 구체화하였다. GoF의 디자인 패턴은 소프트웨어 공학에서 가장 많이 사용되는 디자인 패턴이다. 목적에 따라 분류할 시 생성 패턴 5개, 구조 패턴 7개, 행위 패턴 11개, 총 23개의 패턴으로 구성된다.
      • GoF 디자인 패턴을 분류하는 두 가지 기준 : 목적, 범위

      • 목적에 따른 분류 : 생성, 구조, 행동 3가지로 분류

      • 범위에 다른 분류 : 패턴을 주로 클래스에 적용하는지, 객체에 적용하는지로 분류

        클래스 패턴은 클래스와 서브클래스 간의 관련성을 다룬다. 주로 상속을 통해 관련되며, 컴파일 타임에 정적으로 결정된다. 객체 패턴은 객체 간의 관련성을 다루고, 런타임에 변경될 수 있는 동적인 성격을 가진다.

      • 생성 패턴 : 객체를 생성하는 것에 대한 패턴 (추빌팩프싱)

        • 추상팩토리, 빌더, 팩토리 매소트, 프로토타입, 싱글톤
      • 구조 패턴 : 구조를 통해 확장성을 꾀하는 패턴 (어브컴데퍼플프)

        • 어댑터, 브릿지, 컴포지트, 데코레이터, 퍼사드, 플라이웨잇, 프록시
      • 행위 패턴 : 행위의 변경, 수정 등을 위한 패턴

        • 역할 사슬, 커맨드, 인터프리터, 이터레이터, 미디에이터, 메멘토, 옵저버, 스테이트, 스트래티지, 템플릿 메소드, 비지터


https://4z7l.github.io/2020/12/25/design_pattern_GoF.html

  1. 요구사항 분석의 어려움

    개발자와 사용자 간의 지식이나 표현의 차이가 커서 상호 이해 어려움

    사용자의 요구사항이 모호하고 불명확

    소프트웨어 개발 과정 중에 요구사항이 계속 변함

  2. 소프트웨어 아키텍처 설계에서 시스템 품질속성 6가지

    • 가용성
    • 변경용이성
    • 성능
    • 보안성
    • 사용편의성
    • 시험용의성
  3. 연계 시스템 구성

    • 송신 시스템 : 연계할 데이터를 DB와 어플리케이션으로부터 연계 테이블 또는 파일 형태로 생성하여 수신
    • 수신 시스템 : 수신한 연계테이블, 파일 데이터를 수신시스템에서 관리하는 데이터 형식에 맞게 변환하여 DB에 저장하거나 애플리케이션에서 활용할 수 있도록 제공
    • 중계 서버 : 송/수신 시스템 사이에서 데이터 송수신, 연계데이터의 송수신 현황을 모니터링, 연계데이터의 보안강화 및 다중플랫폼 지원 등 가능
  4. CASE (computer - Aided Software Engineering) 의 원천 기술 5개

    • 구조적 기법
    • 프로토타이핑 기술
    • 자동프로그래밍 기술
    • 정보 저장소 기술
    • 분산 처리 기술
  5. 7번 동일

  6. 아키텍처 스타일

    • 클라이언트 서버 구조 : 컴포넌트가 다른 컴포넌트에게 서비스를 요청. 데이터가 여러 컴포넌트를 거치며 처리.
    • 계층 구조 : 모듈들로 응집된 계층 단위로 SW를 구성. 계층간에 사용 가능의 관계로 표현
    • MVC 구조 : 모델-뷰-컨트롤러, 기능을 분리한 아키텍처
    • 파이프 필터 : 파이프를 통해 받은 데이터를 변경시키고 그 결과를 파이프로 전송
  7. 럼바우 (Rumbaugh) 의 객체 지향 분석 (객동기) (동상기자)

    • 객체 모델링
    • 동적 모델링 - 상태도
    • 기능 모델링 - 자료 흐름도
  8. UML 다이어그램 (액시디콜콤클)

    • Activity 다이어그램 : 업무의 흐름을 모델링하거나 객체 생명주기 표현
    • Sequence 다이어그램 : 객체 간 메세지 전달을 시간적 흐름에서 분석
    • Deployment 다이어그램 : 기업 환경의 구성, 컴포넌트들 간의 관계 그림
    • Collaboration 다이어그램 : 객체와 객체가 주고받는 메세지 중식의 작성
    • Component 다이어그램 : 소프트웨어 구조가 그리는
    • Class 다이어그램 : 시스템의 구조적인 모습을 그리는
  9. UML 모델

    • Dependency : 한 사물의 명세서가 바뀌면 그것을 사용하는 다른 사물에게 영향을 끼치는 것
    • Realization (실체화) : 한 객체가 다른 객체에 의해 오퍼레이션을 수행하도록 지정
    • Generalization(일반화) : 일반화된 사물과 좀 더 특수화된 사물 사이의 관계를 말함 (is - a 관계)
    • Association(연관) : 두 사물간의 구조적 관계, 어느 한 사물 객체가 다른 사물 객체와 연결되어 있음을 말함 (has - a 관계)
  10. CASE : 시스템 개발 과정의 일부 또는 전체를 자동화시킨 것

    • 소프트웨어 생명주기의 전체 단계를 연결, 자동화해주는 통합된 도구 제공
    • SW, HW, DB, 테스트 등을 통합하여 소프트웨어를 개발하는 환경 제공

    상위 CASE : 요구 분석과 설계 단계를 지원

    • 모델들 사이의 모순검사 기능
    • 모델의 오류 검증 기능
    • 자료흐름도 작성 기능

    하위 CASE : 코드를 작성하고 테스트하며 문서화하는 과정 지원

    • 원시코드 생성 기능

    통합 CASE : 소프트웨어 개발 주기 전체과정 지원

  11. 요구사항 관리 도구의 필요성

    • 요구사항 변경으로 인한 비용 편익 분석
    • 요구사항 변경의 추적
    • 요구사항 변경에 따른 영향 평가
  12. 애자일 개발 방법론

    • 익스트림 프로그래밍 (XP, Extreme Programming)
    • 스크럼크리스털 패밀리
    • 기능 주도 개발 (FDD, Feature-Driven Development)
    • 적응형 소프트웨어 개발 (ASD, Adaptive Software Development)
  13. 6번 동일

  14. 사용자 인터페이스 (UI) 특징

    • 구현하고자 하는 결과의 오류를 최소화
    • 사용자의 편의성을 높임, 작업시간 단축
    • 막연한 작업 기능에 대해 구체적인 방법 제시
    • 사용자 중심의 상호 작용이 되도록 함.

0개의 댓글