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

시스템의 구성요소

Input : 처리 방법, 처리할 데이터, 조건을 시스템에 투입하는 것

Process : 입력된 데이터를 처리 방법과 조건에 따라 처리하는 것

Output : 처리된 결과를 시스템에 산출하는 것

Control : 자료를 입력하여 출력될 때까지의 처리 과정이 올바르게 진행되는지 감독하는 것

Feeback : 출력된 결과가 예정된 목표를 만족시키지 못할 경우 목표 달성을 위해 반복 처리하는 것

-> Maintenance : 유지보수

 

요구사항 정의 및 분석,설계의 결과물을 표현하기 위한 모델링 과정에서 사용되는 다이어그램

- Data Flow Diagram

- UML Diagram

- E-R Diagram

 

UML(Unified Modeling Language)

객체 지향 시스템을 개발할 때 산출물을 명세화, 시각화, 문서화 하는데 사용됨

개발하는 시스템을 이해하기 쉬운 형태로 표현하여 분석가, 의뢰인, 설계자가 효율적인 의사소통을 할 수 있게 한다

따라서, 개발 방법론이나 개발 프로세스가 아닌 표준화된 모델링 언어이다

 

- 연관 관계(Association Relationship)  -> 두 사물간의 구조적 관계로 어느 한 객체가 다른 객체와 연결되어 있음을 말함 (has-a)

- 의존 관계(Dependency Relationship) -> 한 사물의 명세가 바뀌면 다른 사물에 영향을 주는 관계 Cascade

- 실체화 관계(Realization Relationship) -> 한 객체가 다른 객체에 의해 오퍼레이션을 수행하도록 지정하는 의미적 관계

- 일반화 관계(Generalization Relationship) -> 일반화된 사물과 좀 더 특수화된 사물 사이의 관계 (is-a)

 

UML다이어그램의 분류

구조적(정적) : 클래스, 객체, 패키지, 컴포넌트, 복합구조, 배치             클객컴배복패

행위(동적) : 유스케이스, 시퀀스, 커뮤니케이션, 상태, 활동, 타이밍, 상호작용            유시커상활타상

 

순차다이어그램(동적)

UML 다이어그램 중의 하나인 동적이며 순차인 표현을 위한 행위 다이어그램

객체 간의 동적 상호작용을 시간 개념을 중심으로 모델링

다이어그램의 수직 방향이 시간의 흐름을 나타냄

회귀 메시지(Self-Message), 제어블록(Statement Block) 등으로 구성됨

 

클래스다이어그램(정적)의 요소

Operation -> 클래스의 동작을 의미하며 클래스에 속하는 객체에 대해 적용될 메소드를 정의한 것(UML에서는 동작에 대한 인터페이스 지칭)

 

미들웨어(Middleware)

클라이언트와 서버 간의  통신을 담당하는 시스템 소프트웨어로 여러 운영체제에서 응용 프로그램들 사이에 위치

소프트웨어 컴포넌트를 연결하기 위한 준비된 인프라 구조를 제공함

여러 컴포넌트를 1대1, 1대다, 다대다 등의 여러 형태로 연결 가능

 

메시지 지향 미들웨어(Message-Oriented Middleware)

메시지 기반의 비동기형 메시지를 전달하는 방식의 미들웨어로

즉각적인 응답이 필요한 온라인 업무보다는 이기종 분산 데이터 시스템의 데이터를 위해 많이 사용됨

독립적인 애플리케이션을 하나의 통합된 시스템으로 묶기 위한 역할

송신측과 수신측의 연길 시 메시지 큐를 활용하는 방법이 있음

 

익스트림 프로그래밍(XP)

애자일 방법론 중 하나로 소규모 개발조직이 불확실하고 변경이 많은 요구를 접했을 때 적절한 방법

구동 원리는 상식적인 원리와 경험을 최대한 끌어올리는 것 

구체적인 실천 방법을 정의하고 있으며, 개발 문서보다는 소스코드에 중점을 둠

사용자의 요구사항은 언제든지 변할 수 있다

빠른 개발을 한다고해서 테스트를 안하진 않는다 해야함

 

액터(Actor)

시스템과 상호작용하는 모든 것 (사람, 기계, 시스템 등)

 

유스케이스(Use Case Diagram) -> 행위(동적)다이어그램

사용자 측면에서의 요구사항으로, 사용자가 원하는 목표를 달성하기 위해 수행할 내용을 기술함

액터는 대상 시스템과 상호 작용하는 사람이나 다른 시스템에 의한 역할이다

시스템이 액터에게 제공해야 하는 기능으로 시스템의 요구사항이자 기능을 의미함

유스케이스 다이어그램은 사용자의 요구를 추출하고 분석하기 위해 주로 사용됨

- 사용자 액터 : 기능을 요구하는 대상이나 시스템의 수행 결과를 통보받는 사용자 혹은 기능을 사용하게 될 대상으로

                            시스템이 제공해야 하는 기능인 유스케이스의 권한을 가지는 역할

- 시스템 액터 : 사용자 액터가 사용한 유스케이스를 처리해주는 내부 시스템(시스템의 기능 수행을 위해 연동이 되는 또 다른 시스템 액터를 의미)

 

유스케이스(Use Case)의 구성 요소 간의 관계

- 포함 관계 : 하나의 유스케이스가 다른 유스케이스의 실행을 전제로 할 때 형성되는 관계

- 확장 관계 : 확장 기능 유스케이스와 확장 대상 유스케이스 사이에 형성되는 관계

- 일반화 관계 : 유사한 유스케이스 또는 액터를 모아 추상화한 유스케이스, 또는 액터와 연결시켜 그룹을 만들어 이해도를 높이기 위한 관계

 

요구사항 개발 프로세스

도출(Elicitation) -> 분석(Anlaysis) -> 명세(Specification) -> 확인(Validation)

 

요구사항 분석이 어려운 이유

- 개발자와 사용자 간의 지식이나 표현의 차이가 커서 상호 이해가 쉽지 않다

- 사용자의 요구는 예외가 많아 열거와 구조화가 어렵다

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

- 소프트웨어 개발 과정 중에 요구사항이 계속 변할 수 있다

 

요구사항 검증(Requirements Validation)

실제로 고객이 정말 원하는 시스템을 제대로 정의하고 있는지 점검하는 과정

개발완료 이후 문제점이 발견될 경우 막대한 재작업 비용이 들 수 있기 때문에 요구사항 검증은 매우 중요하다

요구사항이 실제 요구를 반영하는지, 문서상의 요구사항은 서로 상충되지 않는지 점검한다

요구사항 검증 과정을 통해 모든 요구사항 문제를 발견할 수는 없다 

 

요구사항 체크리스트

유효성 : 고객의 필요를 충족하는 기능을 제공하는지(요구한 것이 맞는지)

일관성 : 충돌하는 요구사항이 존재하는지

무결성 : 고객이 요구한 모든 기능이 포함되었는지

사실성 : 예산과 기술적으로 실행가능한지

검증 가능성 : 만들고 난 뒤 요구사항들을 검증할 수 있는지(요구사항 일치여부)

 

요구사항 관리 도구의 필요성 -> 요구사항 변경

- 요구사항 변경으로 인한 비용 편익 분석

- 요구사항 변경의 추적

- 요구사항 변경에 따른 영향 평가

(기존 시스템과 신규 시스템의 성능 비교 -> 개발, 설계 등 구현단계 에서)

 

요구분석(Requirement Analysis)

소프트웨어 개발의 실제적인 첫 단계로 사용자의 요구에 대해 이해하는 단계이다

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

도메인 분석(Domain Analysis)은 요구에 대한 정보를 수집하고 배경을 분석하여 이를 토대로 모델링 하게 된다

 

기능적 요구사항 vs 비기능적(Nonfunctional) 요구사항

기능적 요구사항 : 시스템이 실제로 어떻게 동작하는지에 관점을 둔 요구사항

비기능적 요구사항 : 시스템 구축에 대한 성능, 보안, 품질, 안정 등에 대한 보조적인 요구사항

 

Entity-Relationship Diagram

정보공학 방법론에서 데이터베이스 설계의 표현으로 사용하는 모델링 언어

 

Package, State Transition, Deployment Diagram

UML다이어그램

 

UI설계 지침

- 사용자 중심 : 사용자가 쉽게 이해하고 편리하게 사용할 수 있는 환경을 제공, 실사용자에 대한 이해가 바탕이 되야함

- 일관성 : 버튼이나 조작 방법 등을 일관성 있게 제공하여 사용자가 쉽게 기억하고 습득할 수 있게함

- 단순성 : 조작 방법을 단순화시켜 인지적 부담을 감소

- 결과 예측 가능 : 작동시킬 기능만 보고도 결과를 미리 예측할 수 있게 설계해야 함

- 가시성 : 메인 화면에 주요 기능을 노출시켜 최대한 조작이 쉽도록 설계함

- 표준화 : 기능 구조와 디자인을 표준화해 한번 학습한 이후에는 쉽게 사용할 수 있게 설계함

- 접근성 : 사용자의 연령, 성별, 인종 등에 상관없이 다양한 계층이 사용할 수있게 설계함

- 명확성 : 사용자가 개념적으로 쉽게 인지할 수 있도록 설계함

- 오류 발생 해결 : 오류가 발생하면 사용자가 쉽게 인지할 수 있도록 설계함

 

UI설계 도구

- 목업(Mockup) : 디자인, 사용방법설명, 평가 등을 위해 실제 화면과 유사하게 만든 정적인 형태의 모형

- 스토리보드(Storyboard) : 디자이너와 개발자가 최종적으로 참고하는 작업 지침서

- 프로토타입(Prototype) : 와이어프레임이나 스토리보드등에 인터랙션을 적용함으로써 실제 구현된 것처럼 테스트가 가능한 동적인 형태의 모형

- 유스케이스(Usecase) : 사용자 측면에서의 요구사항으로 사용자가 원하는 목표를 달성하기 위해 수행할 내용을 기술한다

 

아키텍처 설계 과정

설계 목표 설정 -> 시스템 타입 결정 -> 아키텍터 패턴 적용(스타일 적용 및 커스터마이즈)

-> 서브 시스템 구체화(서브시스템의 기능, 인터페이스 동작 작성) -> 검토

 

소프트웨어 아키텍처

외부에서 인식할 수 있는 특성이 담긴 소프트웨어의 골격이 되는 기본 구조

이해 관계자들이 품질 요구사항을 반영하여 품질 속성을 결정한다

- 파이프 필터 아키텍처는 데이터가 파이프를 통해 단방향으로 흐르고, 필터 이동시 오버헤드가 발생할 수 있다

- 데이터 중심 아키텍처는 공유 데이터저장소를 통해 접근자 간의 통신이 이루어지므로 각 접근자의 수정과 확장이 용이하다

[시스템 품질 속성 : 가용성, 변경용이성, 성능, 보안성, 사용편의성, 시험용의성]

 

인터페이스(Interface)

서로 다른 두 시스템이나 소프트웨어 등을 서로 이어주는 부분 또는 접속 장치

- 소프트웨어 의해 간접적으로 제어되는 장치와 소프트웨어를 실행하는 하드웨어

- 기존의 소프트웨어와 새로운 소프트웨어를 연결

- 순서적 연산에 의해 소프트웨어를 실행하는 절차

 

사용자 인터페이스 설계시의 가이드 라인

- 사용자 친화적이게 설계되어야 하기 때문에 사용성이 최우선으로 설계되어야 한다

- 효율성을 높여 설계해야 한다

- 발생하는 오류를 쉽게 수정할 수 있도록 해야 한다

- 사용자에게 피드백을 제공해야 한다

 

객체(Object)

상태, 동작, 고유 식별자를 가진 모든 것

객체의 상태는 속성값에 의해 정의 됨

필요한 자료 구조와 이에 수행되는 함수들을 가진 하나의 독립된 존재

instance = 클래스에 속한 각각의 객체

 

클래스

공통 속성을 공유하는 객체들의 집합

 

Message

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

 

클래스의 설계원칙

- 단일 책임원칙 : 하나의 객체는 하나의 동작만의 책임만 진다

- 개방-폐쇄의 원칙 : 클래스는 확장에 있어 열려 있어야하며 변경에 대해 닫혀 있어야 한다

- 리스코프 교체의 원칙 : 특정 메소드가 상위 타입을 인자로 사용할 때, 그 타입의 하위 타입도 문제 없이 작동해야 한다

- 의존관계 역전의 원칙 : 상위 계층이 하위 계층에 의존하는 관계를 역전시킴으로써 상위 계층이 하위 계층의 구현으로부터 독립되게 할 수 있다

 

OOP의 4가지 특징

- 캡슐화 : 데이터와 코드의형태를 외부로부터 알 수 없게 하고, 데이터의 구조와 역할, 기능을 하나의 캡슐형태로 만듦

(서로 관련성이 많은 데이터들과 연산들을 묶음)

- 추상화 : 클래스들의 공통적인 특성(변수, 메소드)들을 묶어 표현하는 것

- 상속화 : 부모 클래스에 정의된 변수 및 메소드를 자식 클래스에서 상속받아 사용하는 것

- 다형화 : 다양한 형태로 표현이 가능한 구조(오버로딩, 오버라이딩)

 

애자일(Agile) 프로세스 모델

개발에 대한 개념적 방법론으로, 개발 프로젝트 기간을 짧은 주기로 나눠 반복적인 개발을 하는 것이 특징

프로세스,도구 < 사람과 상호작용

광범위한 문서 < 실제 작동하는 제품

계약 협상 < 고객 협력

계획 따르기 < 변화에 대한 대응

 

스크럼(Scrum)과 관련된 용어(애자일 기법 중)

- 스크럼 마스터(Scrum Master) : 스크럼 프로세스를 따르고, 팀이 스크럼을 효과적으로 활용할 수 있도록 보장하는 역할

- 제품 백로그(Product Backlog) : 스크럼 팀이 해결해야하는 목록으로 소프트웨어 요구사항, 아키텍처 정의 등등

- 태스크(Task) : 할 일, 진행 중, 완료의 상태로 구성

- 스트린트(Sprint) : 실제 개발을 2-4주간 진행하는 과정으로 스프린트 백로그에 작성된 Task를 대상으로 작업 시간을 측정한 후 담당 개발자에게 할당함

- 속도(Velocity) : 한 번의 스프린트에서 한 팀이 어느정도의 제품 백로그를 감당할 수 있는지에 대한 추정치

 

컴포넌트(Component)

프로그래밍에 있어 재사용이 가능한 각각의 독립된 모듈로 특정 기능 수행을 위해 독립적으로 분리

넓은 의미에서는 재사용되는 모든 범위라고 할 수 있으며, 인터페이스를 통해서만 접근할 수 있는 것

 

피드백(Feedback)

UI와 관련된 기본 개념 중 하나로, 시스템의 상태와 사용자의 지시에 대한 효과를 보여주어

사용자가 명령에 대한 진행 사항과 표시된 내용을 해석할 수 있게 도와주는 것

 

사용자 인터페이스(User Interface)

구현하고자 하는 결과의 오류를 최소화한다

사용자의 편의성을 높임으로써 작업시간을 감소시킨다

막연한 작업 기능에 대해 구체적인 방법을 제시한다

사용자 중심의 상호 작용이 되도록 한다

- CLI(Command Line Interface) : 텍스트 형태의 인터페이스(명령문자열 입력)

- GUI(Graphical User Interface) : 마우스로 선택하여 작업하는 그래픽 환경 인터페이스

- NUI(Natural User Interface) :  사용자의 말이나 행동으로 기기를 조작하는 인터페이스

- VUI(Voice User Interface) : 사람의 음성으로 기기를 조작하는 인터페이스

- OUI(Organic User Interface) : 모든 사물과 사용자 간의 상호작용을 위한 인터페이스

 

소프트웨어 설계 요구 사항 분석

소프트웨거 개발의 출발점이면서 실질적인 첫 번째 단계

소프트웨어가 무엇을 해야하는가를 추적하여 요구사항 명세를 작성하는 작업

사용자의 요구를 추출하여 목표를 정하고 어떤 방식으로 해결할 것인지 결정하는 단계

 

소프트웨어 설계 요구 사항 개발 프로세스

추출 -> 분석 -> 명세 -> 확인

 

소프트웨어 설계에서 사용되는 추상화 기법

- 제어 추상화 : 제어의 정확한 메커니즘을 정의하지 않고 원하는 효과를 정하는데 이용하는 방법

- 기능 추상화 : 입력 자료를 출력자료로 변환하는 과정을 추상화 하는 방법

- 자료 추상화 : 자료와 자료에 적용될 수 있는 기능을 함께 정의함으로써 자료 객체를 구성하는 방법

- 과정 추상화 : 자세한 수행 과정을 정의하지 않고, 전반적인 흐름만 파악할 수 있게 설계하는 방법

- 데이터 추상화 : 데이터의 세부적인 속성이나 용도를 정의하지 않고, 데이터 구조를 대표할 수 있는 표현으로 대체하는 방법

 

소프트웨어 개발에 이용되는 모델(Model)

- 모델은 개발 대상을 추상화하고 기호나 그림 등으로 시각적으로 표현한다

- 모델을 통해 소프트웨어에 대한 이해도를 향상시킬 수 있다

- 모델을 통해 이해 당사자 간의 의사소통이 향상된다

- 모델을 통해 향후 개발될 시스템의 유추가 가능하다

 

소프트웨어 모델링

소프트웨어 모델을 사용할 경우 개발될 소프트웨어에 대한 이해도 및 이해 당사자 간의 의사소통 향상에 도움

객체지향 방법론에서는 UML 표기법을 사용함

구조적 방법론에서는 DFD(Data Flow Diagram), DD(Data Dictionary) 등을 사용하여 요구 사항의 결과를  표현

모델링 작업의 결과물을 다른 모델링 작업에 영향을 줄 수 있음

개발될 시스템에 대해서 여러 분야의 엔지니어들이 공통된 개념을 공유하는 데 도움을 준다

절차적인 프로그램을 위한 자료흐름도는 프로세스 위주의 모델링 방법이다

(모델링 -> 초반에 하는 것, 유지보수 -> 마지막 단계)

 

소프트웨어 아키텍처

- 클라이언트 서버 구조 : 컴포넌트가 다른 컴포턴트에게 서비스를 요청 (데이터가 여러 컴포넌트를 거치며 처리)

- 계층구조 : 모듈들로 응집된 계층 단위를 소프트웨어로 구성, 계층간에 사용 가능의 관계로 표현

- MVC구조 : 모델-뷰-컨트롤러, 기능을 분리한 아키텍처

- 파이프 필터 : 파이프를 통해 받은 데이터를 변경시키고 그 결과를 파이프로 전송

                           서브시스템이 입력 데이터를 받아 처리하고 결과를 다른 시스템에 보내는 작업이 반복되는 아키텍처 스타일

 

MVC(Model-View-Controller) - 소프트웨어 아키텍처 모델

MVC모델은 사용자 인터페이스를 담당하는 계층의 밀집도를 높일 수 있고, 

여러 개의 다른 UI를 만들어 그 사이의 결합도를 낮출 수 있음

Model : 뷰와 제어 사이의 전달자 역할

View : 모델에 있는 데이터를 사용자 인터페이스에 보이는 역할

Controller : 모델에 명령을 보냄으로써 모델의 상태를 변화시킴

(한 개의 모델에 대해 여러 개의 뷰를 만들 수 있음)

 

자료흐름도(DFD) 구성요소

- 처리(Process) : 원

- 자료흐름(Data Flow) : 화살표

- 자료저장소(Data Store) : 평행선

- 단말(Terminal) : 사각형

 

FEP(Front-End Processor)

입력되는 데이터를 컴퓨터의 프로세서가 처리하기 전에 미리 처리하여 프로세서가 처리하는 시간을 줄여주는 프로그램이나 하드웨어

 

EAL(Enterprise Application Integration)

기업 응용 프로그램의 구조적 통합 방안을 가리킴

 

GPL(General Public License)

자유 소프트웨어 재단(OSF)에서 만든 자유 소프트웨어 라이센스

 

Duplexing (이중화)

데이터베이스의 회복 기법 중 가장 간다한 방법

 

마스터슬레이브(Master-Slave)

분산 시스템을 위한 아키텍처로 일반적으로 실시간 시스템에서 사용된다

마스터 : 작업을 분리, 배포 -> 슬레이브 프로세스들을 제어할 수 있으며 연산,통신,조정을 책임진다 (최종 결과값)

슬레이브 : 마스터의 요청 작업을 처리하고 처리된 결과를 돌려준다

 

송신 시스템

연계할 데이터를 DB와 어플리케이션으로부터 연계 테이블 또는 파일 형태로 생성하여 송신

 

수신 시스템

수신한 연계테이블, 파일데이터를 수신시스템에서 관리하는 데이터 형식에 맞게 변환하여

DB에 저장하거나 애플리케이션에서 활용할 수 있도록 제공

 

중계 서버

송/수신 시스템 사이에서 데이터를 송수신하고, 연계 데이터의 송수신 현황을 모니터링함

 

---

[객체지향 주요 개념]

1. 추상화(Abstraction)

객체의 공통적인 속성과 기능을 추출하여 정의하는 것

 

2. 캡슐화(Encapsulation)

데이터와 데이터를 처리하는 함수를 하나로 묶는 것

객체의 세부 내용이 은폐되어 변경이 발생하더라도 오류의 파급효과가 적다

캡슐화된 객체들은 재사용이 용이함

인터페이스가 단순해지고 객체간의 결합도가 낮아짐

 

3. 상속성(Ingeritance)

상위 클래스의 메소드와 속성을 하위 클래스가 상속 받는 것

하위 클래스는 물려받은 클래스에 새롭게 추가 기능 첨가 가능

클래스의 재사용을 높이는 중요한 개념

 

4. 다형성(Polymorphism)

다형성이란 여러 가지 형태를 가지고 있다는 의미로, 여러 형태를 받아들일 수 있는 특징을 말함

현재 코드를 변경하지 않고 새로운 클래스를 쉽게 추가할 수 있음

ex) 메소드 오버라이딩, 오버로딩

 

- 메소드 오버라이딩(Method Overriding)

상속 관계에서만 발생하며, 슈퍼클래스의 메소드를 서브클래스에서 동일한 메소드를 재정의

 

- 메소드 오버로딩(Method Overloading)

한 클래스 내에서 메소드의 이름은 동일하지만 변수의 개수, 리턴 타입 등을 다르게 하여 재정의

 

※ 정보 은닉 (Information Hiding)

다른 객체에게 자신의 정보를 숨기고 자신의 연산만을 통해 접근을 허용하는 것

클래스 외부에서 특정 정보에 접근을 막는다는 의미

사용자가 굳이 알 필요가 없는 정보는 사용자로부터 숨긴다

요구사항 등의 변화에 따라 수정이 가능하다

설계에서 은닉 되야할 기본 정보로는 IP주소, 물리적 코드, 상세 데이터 구조 등이 있다

 

 

[객체지향 분석기법]

럼바우(Rumbaugh Method) -> 객체동적기능

객체 모형(객체 다이어그램), 동적 모형(상태 다이어그램), 기능 모형(자료흐름도DFD)

3개의 모형을 생성하는 방법으로 그래픽 표기법을 이용하여 모델링하는 기법이다

객체 모델링 기법이라고도 하며 분석활동은 객체 모델링 -> 동적 모델링 - > 기능 모델링 순으로 이루어진다

 

부치(Booch Method)

미시적(micro) 개발 프로세스와 거시적(macro) 개발 프로세스를 모두 사용하는 분석 방법으로

클래스와 객체들을 분석 및 식별하고 클래스의 속성과 연산을 정의한다

 

Jacobson

Use Case(사용사례)를 강조하여 사용하는 분석 방법이다

 

Coad와 Yourdon

E-R 다이어그램을사용하여 객체의 행위를 모델링하며 객체 식별, 구조 식별, 주제 정의, 속성과 인스턴스 연결 정의,

연산과 메시지 연결 정의 등의 과정으로 주로 관계를 분석하는 기법이다

 

Wirfs-Brock

분석과 설계간의 구분이 없고, 고객 명세서를 평가해 분석부터 설계 작업까지 연속적으로 수행하는 기법

 

CASE(Computer-Aided Software Engineering)의

시스템 개발 과정의 일부 또는 전체를 자동화 시킨 것

소프트웨어 생명주기 전체 단계를 연결해주고 자동화해주는 통합된 도구를 제공

소프트웨어, 하드웨어, 데이터베이스, 테스트 등을 통합하여 소프트웨어를 개발하는 환경을 제공

 

- 원천 기술

구조적 기법, 프로토타이핑 기술, 자동 프로그래밍 기술, 정보 저장소 기술, 분산 처리 기술

 

- 상위 CASE

요구 분석과 설계 단계를 지원

모델들 사이의 모순검사 기능

모델의 오류 검증 기능

자료흐름도 작성 기능

 

- 하위 CASE

코드를 작성하고(전체 소스코드 생성) 테스트하며 문서화하는 과정 지원

원시코드 생성 기능

 

- 통합 CASE

소프트웨어 개발 주기 전체 과정을 지원

---

애자일(Agile) 방법론

구체적인 개발 프로세스가 아닌 개발 지침, 철학에 가깝다

변화를 수용하고 협업과 제품의 빠른 인도를 강조하는 반복적인 개발 방법

문서화보다 코드, 프로그램, 소프트웨어 자체를 중요시함

요구사항의 변화는 불가피하며 이에 대응하는 것이 현실적이다

기존의 개발 프로세스는 설계 기간이 길며 재작업시 오버헤드가 크다

요구사항이 바뀌기 쉬운 중소형의 비즈니스 시스템이나 전자 상거래 응용에 적합하다

 

공정, 도구 -> 개인과 상호작용을

포괄적인 문서 -> 작동하는 소프트웨어를

계약 협상 -> 고객과의 협력을

계획 따르기 -> 변화에 대응하기를

 

1. 익스트림 프로그래밍(XP, Extreme Programming)

좋은 실천 지침들(good pracitces)을 적극적으로 적용

XP의 실천 지침

- 작고 빈번한 릴리즈 (빠른 피드백과 지속적인 개선)

- 고객도 개발 팀원의 일원

- 프로세스 중심이 아닌 사람 중심의 작업

- 단순한 설계와 테스트 주도 개발(TDD, Test Driven Development)

- 리팩토링을 통한 코드 품질 개선

 

2. 짝 프로그래밍(Pair Programming)

두 사람이 짝이 되어 한사람이 코딩을, 한 사람이 검사를 수행 (30분마다 역할 교체)

- 코드에 대한 책임 공유

- 비형식적 검토 수행

- 코드 개선을 위한 리팩토링 장려

- 각각 개발하는 경우에 비해 생산성이 떨어지지 않는다

 

3. 테스트 주도 개발(TDD, Test Driven Development)

테스트 케이스를 먼저 작성하고 이를 통과하는 코드를 개발

Task별로 테스트 케이스를 만듦(요구사항 -> 스토리카드 -> Tasks)

요구사항은 스토리 카드로 표현되고 스토리카드는 태스크들로 분해됨

요구사항-코드 관계가 명확해짐

통합 테스트를 강조하며 통합 과정에서 기존 소프트웨어에 오류 유입 방지

 

4. 스크럼(Scrum)

특정 언어나 방법론에 의존적이지 않으며, 넓은 응용 범위의 개발 기법이다

- 솔루션에 포함할 기능/개선점에 대한 우선 순위를 부여한다

- 개발 주기는 30일정도로 조절하고 개발 주기마다 실제 동작할 수 있는 결과를 제공한다

- 개발 주기마다 적용할 기능이나 개선에 대한 목록을 제공한다

- 날마다 15분 정도 회의를 가진다(팀 단위 생각)

- 원활한 의사소통을 위해 구분 없는 열린 공간을 유지한다

 

계획->스프리트의 반복

제품에서 요구하는 기능과 우선순위를 제품 백로그로 정한다

PO(제품책임자)가 정한 제품의 우선순위에서 어디까지 작업을 할지 팀원들과 조율한다

조율하여 선정된 제품 백로그가 이번 스프린트의 목표가 된다

스프린트의 목표를 구현하도록 팀에서 스프린트 백로그를 작성한 뒤 작업 할당

스트린트를 진행하는 동안 매일 스크럼 회의를 가진다

매회의 스프린트가 종료될 때 마다 스프린트 리뷰 미팅을 통해 만들어진 제품을 학습하고 이해한다

스프린트 회고를 통해 개발 프로세스에 대한 개선의 시간을 갖는다

 

5. 기능 주도 개발(FDD, Featur-Drieven Development)

6. 적응형 소프트웨어 개발(ASD, Adaptive Software Development)

---

디자인 패턴

소프트웨어 설계에서(객체 지향 프로그래밍 설계를 할 때) 자주 발생하는 문제들을 피하기 위해 사용되는 패턴

 

GoF(Gang of Four) 디자인 패턴

 

생성패턴 - 싱글톤, 추상팩토리, 팩토리메소드, 빌더, 프로토타입           싱추팩빌토

행동(행위)패턴 - 커맨드, 전략, 템플릿메소드, 상태, 반복자, 옵저버, 역학사슬(책임연쇄),

                               인터프리터, 메멘토, 미디에이터(중재자), 비지터

구조패턴 - 데코레이터, 프록시, 컴포지트, 어댑터, 퍼사드, 브릿지, 플라이웨잇

 

 

1. 생성패턴(Creational Pattern)

객체 인스턴스를 생성하는 패턴으로, 클라이언트와 그 클라이언트가 생성해야 하는 객체 인스턴스 사이의 연결을 끊어주는 패턴

[싱글톤, 추상팩토리, 팩토리메소드, 빌더, 프로토타입]

 

- 싱글턴(Singleton)

특정 클래스에 객체 인스턴스가 하나만 만들어지도록 해주는패턴

싱글턴 패턴을 사용하면 전역변수를 사용할 때와 마찬가지로 객체 인스턴스를 어디서든 액세스 할 수 있음

클래스 인스턴스를 하나만 만들고 해당 인스턴스로의 전역 접근을 제공

 

- 추상 팩토리(Abstract Factory)

구상 클래스에 의존하지 않고도 서로 연관되거나 의존적인 객체로 이루어진 제품군을 생산하는 인터페이스를 제공

제품을 생산할 때 일련의 메소드가 정의되어 있고 서로 다른 제품군을 구현하며 클라이언트가 필요하면

해당 팩토리 가운데 적당한 것을 골라 쓰면 되기 때문에 제품 객체의 인스턴스를 직접 만들 필요가 없음

 

- 팩토리 메소드(Factory Method)

객체를 생성할 때 필요한 인터페이스를 만들고 어떤 클래스의 인스턴스를 만들지는 서브클래스에서 결정함

팩토리 메소드 패턴을 사용하면 클래스 인스턴스 만드는 일을 서브클래스에 맡기게 됨

 

- 빌더(Builder)

제품을 여러 단계로 나누어 만들도록 제품 생산 단계를 캡슐화할 때 사용

반복자패턴을 사용하여 반복 작업을 별도의 객체로 캡슐화하여 컬렉션의 내부 구조를 클라이언트로부터 보호함

[장점]

복합 객체 생성 과정을 캡슐화

여러 단계와 다양한 절차를 걸쳐 객체를 만들 수 있음(팩토리패턴은 한단계에서 모든걸 처리)

제품의 내부 구조를 클라이언트로부터 보호할 수 있음클라이언트는 추상 인터페이스만 볼 수 있기에 제품을 구현한 코드를 쉽게 바꿀 수 있음[단점]팩토리를 사용할 때보다 객체를 만들 때 클라이언트에 대한 정보가 더 많아야 함

 

- 프로토타입(Prototype)

어떤 클래스의 인스턴스를 만들 때 자원과 시간이 많이 들거나 복잡할 때 사용

 

 

2. 행동패턴(Behavioral Pattern)

 클래스와 객체들이 상호작용하는 방법과 역할을 분담하는 방법을 다루는 패턴

[커맨드, 전략, 템플릿메소드, 상태, 반복자, 옵저버, 역학사슬(책임연쇄), 인터프리터, 메멘토, 미디에이터(중재자), 비지터(방문자)]

 

- 커맨드(Command)

받은 요청을 모든 정보가 포함된 독립실행형 객체로 변환(실행될 기능을 캡슐화)

 

- 전략(Strategy)

알고리즘군을 정의하고 캡슐화해서 각각의 알고리즘군을 수정해서 쓸 수 있게 해줌

클라이언트로부터 알고리즘을 분리해서 독립적으로 변경할 수 있음

 

- 템플릿 메소드(Template Method)

알고리즘의 골격을 정의, 템플릿 메소드를 사용하면 알고리즘 일부 단계를 서브클래스에서 구현할 수 있음

알고리즘의 구조는 그대로 유지하면서 알고리즘의 특정 단계를 서브클래스에서 재정의할 수 있음

 

- 상태(State)

상태 패턴을 사용하면 객체의 내부 상태가 바뀜에 따라 객체의 행동을 바꿀 수 있음

마치 객체의 클래스가 바뀌는 것과 같은 결과를 얻을 수 있음

 

- 반복자(Iterator)

컬렉션의 구현 방법을 노출하지 않으면서 집합체 내의 모든 항목에 접근하는 방법을 제공

 

- 옵저버(Observer)

한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체에게 연락이 가고 자동으로 내용이 갱신되는 방식으로 일대다 의존성을 정의

 

- 역할사슬(책임연쇄)

한 개의 요청을 2개 이상의 객체에서 처리해야 할 때 사용

주어진 요청을 검토하는 객체 사슬 생성

-> 그 사슬에 속해 있는 각 객체는 자기가 받은 요청을 검사해서 직접 처리하거나 사슬에 들어있는 다른 객체에게 넘김

주로 윈도우시스템에서 마우스 클릭과 키보드 이벤트를 처리할 때 쓰임

[장점]

요청을 보낸 쪽과 받는 쪽을 구분할 수 있음

객체는 사슬의 구조를 몰라도 되고 사슬에 들어있는 다른 객체에 직접적인 레퍼런스를 가질 필요도 없음

사슬에 들어가는 객체를 바꾸거나 순서를 바꿈으로써 역할을 동적으로 추가하거나 제거 가능

[단점]

요청이 반드시 수행된다는 보장이 없음

실행 시 과정을 살펴보거나 디버깅하기가 힘듦

 

- 인터프리터(Interpreter)

문법과 구문을 번역하는 인터프리터 클래스를 기반으로 간단한 언어를 정의언어에 속하는 규칙을 나타내는 클래스를 사용하여 언어를 표현[장점]문법을 클래스로 표현하여 쉽게 언어를 구현할 수 있음문법이 클래스로 표현되므로 언어를 쉽게 변경하거나 확장할 수 있음클래스 구조에 메소드만 추가하면 프로그램을 해석하는 기본 기능외에도 새로운 기능을 추가할 수 있음스크립트언어와 프로그래밍언어에서 모두 쓸 수 있음[단점]효율보다는 단순하고 간단한 문법을 만드는 것에 더 유용함

문법 규칙의 개수가 많아지면 아주 복잡해지는 단점이 있어 파서나 컴파일러 생성기를 쓰는게 나을 때가 있음

 

- 메멘토(Memento)

객체를 이전 상태로 복구해야 할때(사용자가 작업취소 요청) 사용 -> 상태를 따로 저장하는 객체

시스템에서 핵심적인 기능을 담당하는 객체 상태의 저장, 심적인 객체의 캡슐화 유지

[장점]

저장된 상태를 핵심 객체와는 별도의 객체에 보관할 수 있어 안전함

핵심 객체의 데이터를 계속해서 캡슐화된 상태로 유지할 수 있음

복구 기능을 구현하기 쉬움

[단점]

자바 시스템에서는 시스템의 상태를 저장할 때 직렬화 사용해야함

상태를 저장하고 복구하는데 시간이 오래걸림

 

- 미디에이터(중재자 Mediator)

서로 관련된 객체 사이의 복잡한 통신과 제어를 한곳으로 집중하고 싶을 때 사용(규칙)

상태가 바뀔 때마다 중재자에게 알려줌 -> 중재자에서 보낸 요청에 응답

중재자를 사용하면 객체를 서로 완전히 분리하여 사용할 수 있음

[장점]

시스템의 객체를 분리함으로써 재사용성을 획기적으로 향상시킬 수 있음

제어 로직을 한 군데로 모아놨기때문에 관리가 수월

시스템에 들어있는 객체 사이에서 오가는 메시지를 줄이고 단순화할 수 있음

[단점]

디자인을 잘못하면 중재자 객체가 너무 복잡해질 수 있음

 

- 비지터(방문자 Visitor)

다양한 객체에 새로운 기능을 추가해야 하는데 캡슐화가 중요하지 않다면 비지터를 주로 씀

비지터 객체는 트래버서객체와 함께 돌아가는데 트래버서는 컴포지트를 쓸 때 복합객체 내에 속해있는 모든 객체에 접근하는 일을 도와줌

각각의 상태를 모두 가져오면 클라이언트는 비지터에게 각 상태에 맞는 다양한 작업을 처리하도록 요구할 수 있음

[장점]

구조를 변경하지 않으면서도 복합 객체 구조에 새로운 기능을 추가할 수 있음

비지터가 수행하는 기능과 관련된 코드를 한곳에 모아둘 수 있음

[단점]

비지터를 사용하면 복합 클래스의 캡슐화가 깨짐

컬렉션 내의 모든 항목에 접근하는 트래버서가 있으므로 복합 구조를 변경하기가 더 어려워짐

 

 

3. 구조패턴(Structural Pattern)

 클래스와 객체를 더 큰 구조로 만들 수 있게 구상을 사용하는 패턴

[데코레이터, 프록시, 컴포지트, 어댑터, 퍼사드, 브릿지, 플라이웨잇]

 

 - 데코레이터(Decorator)

객체에 추가 요소를 동적으로 더할 수 있음 

서브클래스만들때보다 훨씬 더 유연하게 기능을 확장할 수 있음

 

- 프록시(Proxy)

특정 객체로의 접근을 제어하는 대리인(특정 객체를 대변하는 객체)을 제공

 

- 컴포지트(Composite)

객체를 트리구조로 구성해서 부분-전체 계층구조를 구현함

클라이언트에서 개별 객체와 복합 객체를 똑같은 방법으로 다룰 수 있음

 

- 어댑터(Adapter)

특정 클래스 인터페이스를 클라이언트에서 요구하는 다른 인터페이스로 변환

인터페이스가 호환되지않아 사용할 수 없었던 클래스를 사용할 수 있게 도와줌

 

- 퍼사드(Facade)

서브시스템에 있는 일련의 인터페이스를 통합 인터페이스로 묶어줌

또한 고수준 인터페이스도 정의하므로 서브시스템을 더 편리하게 사용할 수 있음

 

- 브릿지(Bridge)

구현과 더불어 추상화 부분까지 변경해야할 때 사용

추상화된 부분과 구현 부분을 서로 다른 클래스 계층구조로 분리하여 두 가지 모두 수정 가능함

[장점]

구현과 인터페이스를 완전히 결합하지 않았기에 구현과 추상화 부분을 분리할 수 있음

추상화된 부분과 실제 구현 부분을 독립적으로 확장할 수 있음

추상화 부분을 구현한 구상 클래스가 바뀌어도 클라이언트에게 영향을 끼치지 않음

[단점]

디자인이 복잡해짐

 

- 플라이웨잇(Flyweight)

어떤 클래스의 인스턴스 하나로 여러 개의 가상인스턴스를 제공할 때 사용

트리 객체를 수 천개 만드는 대신 시스템을 고쳐 트리 인스턴스는 하나만 만들고 모든 트리의 상태를 객체가 관리하도록함

[장점]

실행 시에 객체 인스턴스의 개수를 줄여 메모리 절약

여러 가상 객체를 한곳에 모아둘 수 있음

[단점]

특정 인스턴스만 다른 인스턴스와 다르게 행동할 수 없음

---

https://prinha.tistory.com/entry/%EC%A0%95%EB%B3%B4%EC%B2%98%EB%A6%AC%EA%B8%B0%EC%82%AC%ED%95%84%EA%B8%B0-2%EA%B3%BC%EB%AA%A9-%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EA%B0%9C%EB%B0%9C-%EA%B8%B0%EC%B6%9C%EB%AC%B8%EC%A0%9C-%ED%95%B4%EC%84%A4-%EC%9A%94%EC%95%BD%EC%A0%95%EB%A6%AC1

[정보처리기사필기] 2과목 소프트웨어 개발 기출문제 해설 요약정리1

---

자료 및 출처

1. 정보처리기사 필기 기출

2. 한빛 네트워크 https://www.hanbit.co.kr/channel/category/category_view.html?cms_code=CMS8616098823 

[Design pattern] 많이 쓰는 14가지 핵심 GoF 디자인 패턴의 종류