[정보처리기사] 소프트웨어 및 디자인 패턴 관련 요약

2022.07.21 - [정보처리기사] - [정보처리기사] 실기 꼼수로 합격하기

 

(1) 소프트웨어 개발 방법론

소프트웨어 생명주기 모델

• 소프트웨어 생명주기(SDLC): 시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차
• 요구사항 분석 → 설계 → 구현 → 테스트 → 유지보수
• 폭포수 모델, 프로토타이핑 모델, 나선형 모델, 애자일 모델 등이 있다.

 

소프트웨어 개발 방법론 개념

• 소프트웨어 개발 전 과정에 관심을 갖고 시작부터 완료까지 전 과정을 형상화한 방법론
• 요구사항 분석 → 구조적 분석 → 구조적 설계 → 구조적 프로그래밍
• 구조적 방법론, 정보공학 방법론, 객체지향 방법론, 컴포넌트 기반(CBD) 방법론, 애자일 방법론 등이 있다. 

 

객체 지향 분석 방법론

• 사용자의 요구사항을 분석하여 요구되는 사항과 관련된 모든 객체, 클래스와 연관된 속성, 연산, 관계 등을 정의하여 모델링하는 작업
• 종류로는 Rumbaugh(럼바우) 방법, Booch(부치) 방법, Coad와 Yourdon 방법, Wirfs-Borck 방법 등이 있다.

 

Rumbaugh(럼바우) 방법론

• 가장 일반적으로 사용되는 방법으로 분석 활동을 객체모델, 동적모델, 기능모델로 나누어 수행하는 방법
• 모든 소프트웨어의 구성 요소를 그래픽 표기법으로 객체를 모델링하여 시스템 개발의 전 단계가 추상화, 캡슐화, 상속성 등의 일관된 객체지향개념이 적용되는 객체지향 개발 방법
• 객체 모델링 : 정보 모델링이라고도 하며 시스템에서 요구되는 객체를 찾아내어 속성과 연산 식별 및 객체들 간의 관계를 규정하여 그래픽 다이어그램으로 표시하는 모델링
• 동적 모델링 : 상태 다이어그램을 사용하여 시스템의 행위를 기술하는 모델링
• 기능 모델링 : 자료 흐름도(DFD)를 이용하여 다수의 프로세스들 간의 자료 흐름을 중심으로 처리 과정을 표현하는 모델링

 

(2) 현행 시스템 파악

1 단계 현행 시스템 분석

• 시스템 구성 파악 : 기간 업무, 지원 업무 구분하여 파악
• 시스템 기능 파악 : 단위 업무 시스템이 현재 제공하고 있는 기능 파악
• 인터페이스 파악 : 다른 시스템과 주고 받는 데이터의 종류, 형식, 프로토콜 등을 파악

 

2단계 목표시스템 아키텍처 선정

• 아키텍처 구성 파악 : 계층별로 어떤 기술들이 사용되는지 최상위 수준에서 파악
• 소프트웨어 구성 파악 : 설치되어 있는 소프트웨어의 제품명, 용도, 라이센스 여부 등 파악

 

3단계 목표시스템 개발표준 정의

• 하드웨어 구성 파악 : 서버 위치, 사양, 이중화 유무 등 파악
• 네트워크 구성 파악 : 네트워크 장비, 웹 방화벽, 내부망, 외부망 등 파악

 

(3) 개발 기술 환경 파악

플랫폼

• 자신의 시스템을 개방하여 개인, 기업 할 것 없이 모두가 참여하여 원하는 일을 자유롭게 할 수 있도록 환경을 구축하여 참여자들 모두에게 새로운 가치와 혜택을 제공해줄 수 있는 시스템
• 소프트웨어 가동을 위해 하드웨어, 소프트웨어, 네트워크 등 다양한 주변기기 등이 결합되어 있으며 제작된 소프트웨어에 대해 언제, 어디서나 실행시키더라도 쉽게 구동시킬 수 있다. 
• 응용 소프트웨어 개발과 활용 등의 생산성 향상에 많은 도움을 준다. 

 

객체지향 소프트웨어 설계 5원칙

단일 책임 원칙(SRP:Single Responsibility Princple)

• 객체는 반드시 '한 개의 책임'을 가져야 한다는 원칙
• 어떤 클래스를 변경해야 하는 이유는 오직 하나뿐이어야 하며(책임=변경 사유) 같은 이유로 변화하는 것끼리 묶고, 다른 이유로 변화하는 것끼리는 분리함

 

개방 폐쇄 원칙(OCP:Open-Closed Princple)

• 기존의 코드를 변경하지 않으면서 기능을 추가할 수 있도록 설계가 되어야 함
• 소프트웨어 개체는 확장에는 열려있고 수정 시에는 닫혀있어야 함

 

리스코프 치환 원칙(LSP:Liskov Substitution Princple)

• 일반화 관계에 대한 것으로 자식 클래스는 최소한 자신의 부모 클래스에서 가능한 행위는 수행할 수 있어야 함.
• 하위 클래스 및 타입들은 상위 타입들이 사용되는 곳에 대체될 수 있어야 하는 설계 원칙
• 자식 클래스가 부모 클래스 기능을 재정의 하지 않으면 대체 가능함

 

인터페이스 분리 원칙(ISP:Interface Segregation Princple)

• 인터페이스를 클라이언트에 특화되도록 분리하라는 설계 원칙
• 하나의 일반적인 인터페이스보다 구체적인 여러 개의 인터페이스가 나음

 

의존 역전 원칙(DIP:Dependency Inversion Princple)

• 의존 관계를 맺을 때 변화하기 쉬운 것 또는 자주 변화하는 것보다는 변화하기 어렵거나 거의 변화가 없는 것에 의존하라는 원칙
• 추상화된(인터페이스 등) 것에 의존하게 만들고 구체 클래스에 의존하지 않도록 함

 

디자인패턴

• 소프트웨어 공학론에서 유용하다고 생각되는 객체들 간의 일반적인 상호작용 방법들을 모은 목록
• 생성패턴, 구조패턴, 행위패턴

 

 

1. 생성패턴

• 객체 생성에 관련된 패턴
• 객체의 생성과 조합을 캡슐화해 특정 객체가 생성되거나 변경되어도 프로그램 구조에 영향을 크게 받지 않도록 유연성을 제공한다.

 

종류	설명
추상 팩토리(Abstract Factory)	구체적인 클래스에 의존하지 않고 서로 연관되거나 의존적인 객체들의 조합을 만드는 인터페이스를 제공하는 패턴
빌더(Builder)	객체를 생성하는 방법과 표현하는 방법을 정의하는 클래스를 별도로 분리해서 다른 표현이라도 이를 생성할 수 있는 동일한 절차를 제공하는 패턴
팩토리 메소드(Factory Methos)	객체를 생성하기 위한 인터페이스를 따로 정의하여 객체를 생성하는 일을 서브 클래스가 담당하도록 하는 패턴
프로토타입(Prototype)	원본이 되는 인스턴스를 사용하여 생성할 객체의 종류를 명시하고, 견본을 복사해서 새로운 객체를 생성하는 패턴
싱글톤(Singleton)	전역 변수를 사용하지 않고 객체를 하나만 생성하도록 하며, 생성된 객체를 어디에서든지 참조할 수 있도록 하는 패턴

 

 

2. 구조패턴

• 클래스나 객체를 조합해 더 큰 구조를 만드는 패턴
• 예를 들어 서로 다른 인터페이스를 지닌 2개의 객체를 묶어 단일 인터페이스를 제공하거나 객체들을 서로 묶어 새로운 기능을 제공하는 패턴이다.

 

종류	설명
어댑터(Adapter)	클래스의 재사용성을 높이기 위해 클래스 간의 기능을 변환 제공하여 호환성을 확보하는 패턴
브릿지(Bridge)	인터페이스가 서로 다른 클래스를 연결하는 패턴
컴퍼지트(Composite)	여러 개의 객체들로 구성된 복합 객체와 단일 객체를 클라이언트에서 구별 없이 다루게 해주는 패턴
데커레이트(Decorator)	객체의 결합을 통해 기능을 동적으로 유연하게 확장할 수 있게 해주는 패턴
퍼사드(Facade)	서브 시스템이 복잡할 경우 간단하게 인터페이스를 통해 서브시스템의 주요 기능을 사용할 수 있는 패턴
플라이웨이트(Flyweight)	인스턴스를 가능한 한 공유시켜 불필요한 생성을 하지 않도록 하는 패턴
프록시(Proxy)	객체 접근을 제어하려는 목적으로 인터페이스 역할을 하는 객체를 사용하여 제어하는 패턴

 

 

3. 행위패턴

• 객체나 클래스 사이의 알고리즘이나 책임 분배에 관련된 패턴
• 한 객체가 혼자 수행할 수 없는 작업을 여러 개의 객체로 어떻게 분배하는지, 또 그렇게 하면서도 객체 사이의 결합도를 최소화하는 것에 중점을 둔다.

 

종류	설명
책임 연쇄(Chain of Responsibility)	요청을 처리할 수 있는 기회를 하나 이상의 객체에 부여함으로써 객체 간의 결합도를 없애려는 패턴
커맨드(Command)	실행될 기능을 캡슐화함으로써 주어진 여러 기능을 실행할 수 있는 재사용성이 높은 클래스를 설계하는 패턴
인터프리터(Interpreter)	간단한 언어의 문법을 정의하는 방법과 그 언어로 문장을 구성하는 방법, 문장을 해석 하는 방법을 제시하는 패턴
이터레이터(Iterator)	집합 객체 요소들의 내부 표현 방식을 공개하지 않고 순차적으로 접근하는 구조를 제공하는 패턴
미디에이터(Mediator)	중재자를 통해 한 집합에 속해있는 객체들의 상호작용을 캡슐화하는 패턴
메멘토(Memento)	어떤 시점에서의 객체 상태를 저장해 두었다가 필요 시 객체를 그 시점의 상태로 되돌리는 패턴
옵저버(Observer)	한 객체의 상태 변화에 따라 다른 객체의 상태도 연동되도록 일대다 객체 의존 관계를 구성하는 패턴
스테이트(State)	객체의 상태에 따라 객체의 행위 내용을 변경해주는 패턴
스트레티지(Strategy)	행위를 클래스로 캡슐화 해 동적으로 행위를 자유롭게 바꿀 수 있게 해주는 패턴
템플릿 메소드(Template Method)	어떤 작업을 처리하는 일부분을 서브 클래스로 캡슐화해 전체 일을 수행하는 구조는 바꾸지 않으면서 특정 단계에서 수행하는 내역을 바꾸는 패턴
비지터(Visitor)	데이터 구조 안을 돌아다니는 주체인 'Visitor'를 나타내는 클래스를 준비해서 그 클래스에게 처리를 맡김으로서 기능 추가 시 유연성을 제공하는 패턴

 

(4) 요구사항 정의

요구사항의 개념 및 특징

• 소프트웨어 프로젝트의 최종 제품이 충족해야 하는 기능 및 제약조건을 의미한다. 
• 고객 또는 클라이언트의 요구에 맞는 제품을 만들기 위해 필수 조건이다.
• 프로젝트 과정 전반에 걸쳐 변경될 수 있으므로 이러한 변경 사항을 추적하고 관리할 수 있는 메커니즘을 마련하는 것이 중요하다.

 

요구사항 유형

• 기능 요구사항 : 설계할 시스템의 기능을 설명
• 비기능 요구사항 : 설계할 시스템의 한계와 제약을 설명
• 사용자 요구사항 : 기능 요구사항과 비기능 요구사항의 조합
• 시스템 요구사항 : 사용자 요구사항의 확장 버전 

 

요구사항 개발 프로세스

 

 

1. 요구사항 도출

 

인터뷰	ㆍ요구사항을 도출한 사용자를 대상으로 인터뷰를 수행함 ㆍ많은 사용자로부터 인터뷰를 하는 것이 좋고 회의록 작성은 필수임 ㆍ필요시 인터뷰 내용을 녹음하여 반복 청취하는 것이 좋음
관찰	ㆍ개인의 업무처리 방법이나 절차에 대해 직접적으로 관찰하는 방법으로 요구사항을 명확히 설명하기     힘들거나 어려움이 있는 경우 사용하는 방법
프로토타입	ㆍ요구사항에 대한 이해를 하기 위하여 기본적인 기능만 빠르게 구현하여 사용자로부터 피드백을 받는     기법임 ㆍ개발자의 아이디어를 사용자로부터 조기에 피드백을 받고자 할 때 사용함 ㆍ프로토타이핑 전용언어로 모의 사용자 인터페이스를 만들어 사용함
벤치마킹	ㆍ경쟁 제품, 성공 사레 및 업무 절차를 참조하여 유사한 수준의 효과를 낼 수 있는 기능 요구 사항 정의
사용자 스토리텔링	ㆍ사용자의 요구사항을 이야기 형식으로 기술하여 자연스럽게 개발자가 요구사항에 대한 이해가 가도록     구성하는 방법임 ㆍ주로 애자일 방법에서 사용하는데 개발자와 사용자가 서로 긴밀히 대화하면서 요구사항을 함께 만들어감
문헌조사	ㆍ유사 프로젝트 및 업무 문서나 양식을 조사하여 현재 시스템 정보에 대한 이해 도출, 그 외 산업 및     기업 표준, 관련 정부 정책, 규제 등 문서 조사 ㆍ개발팀은 도메인 영역 교육이나 설명서 참고
업무절차 및 양식조사	ㆍ업무 관련 문서, 절차, 양식, 운영 메뉴얼 등을 조사함으로써 업무절차와 처리 입출력의 이해 ㆍ기업의 내부 표준을 검토함으로써 요구와 제한 사항을 찾아 시스템 요구 분석서의 제한 사항으로 적용
설문	ㆍ이해당사자들로부터 요구를 찾는 도구 ㆍ이해당사자들을 의사결정 과정에 포함하여 관심, 내부 정보, 개선 의견을 이끌어 냄
브레인스토밍	ㆍ여러 명으로부터 정보를 얻는 효과적인 방법 ㆍ인터뷰와 같이 수행하면 더 많은 정보 추출이 가능하며 훈련된 요원의 주재로 과정을 정돈하는 것이     성공의 키포인트  ㆍJAD(Joint Application Development): 사용자와 개발자가 공동참여하여 프로토타입 기반의 작업을     수행함으로써 비즈니스 요구사항을 명확히 도출하고 그에 따라 시스템을 설계 및 개발

 

 

2. 요구사항 분석

 

요구사항 분류	ㆍ기능 요구사항과 비기능 요구사항으로 분류 ㆍ하나 이상의 상위 요구사항에서 유도된 것인지 다른 이해관계자로부터 직접 발생한 것인지 분류 ㆍ개발할 제품에 관한 것인지 개발 과정에 관한 것인지 분류 ㆍ우선 순위에 따른 분류 ㆍ소프트웨어에 미치는 영향에 따른 분류 ㆍ소프트웨어 생명주기동안 변경될 가능성이 있는지 여부에 따른 분류
개념 모델링	ㆍ요구사항을 보다 쉽게 이애할 수 있도록 단순화하여 개념적으로 표현한 모델 ㆍ개념 모델은 개체(Entity)들과 그들 간의 관계 및 종속성을 반영한다. ㆍ요구사항을 이해하는 도메인전문가 별로 관점이 다양하므로 그에 맞게 개념 모델도 다양하게 표현되어야 한다.  ㆍ개념 모델의 종류는 유스케이스 다이어그램, 상태 모델, 사용자 인터렉션, 객체 모델, 데이터 모델 등이 있다.
요구사항 할당	ㆍ요구사항을 만족시키기 위한 구성요소를 식별하는 것
요구사항 협상	ㆍ요구사항이 서로 충돌될 경우 이를 적절하게 해결하는 과정 ㆍ요구사항이 서로 충돌되는 경우 각각에 우선순위를 부여하여 무엇이 더 중요한지 인식할 수 있다
정형 분석	ㆍ구문(Syntax)과 의미(Semantics)를 갖는 정형화된 언어를 이용해 요구사항을 수학적 기호로 표현한 후 이를 분석하는 과정 ㆍ정형 분석은 요구사항 분석 마지막 단계에서 이루어 짐

 

 

3. 요구사항 명세

 

정형 명세 기법	ㆍ수학적 원리와 모델을 기반한 명세 기법으로 요구사항을 정확하고 간결하게 표현 가능한 기법 ㆍ표기법이 어려워 사용자가 이해하기 어렵다. ㆍVDM, Z, Petri-net, CSP 등이 있다.
비정형 명세 기법	ㆍ요구사항의 상태, 기능, 객체 중심의 명세 기법으로 자연어를 기반으로한 서술 또는 다이어그램으로 작성한다. ㆍ자연어 사용으로 인해 요구사항의 해석결과가 달라질 수 있음 ㆍFSM, Decision Table, ER 모델링 등이 있다.

 

 

4. 요구사항 확인

 

요구사항 검토	ㆍ문서화된 요구사항을 훑어보면서 확인하는 것으로 가장 일반적인 요구사항 검증 방법
프로토타이핑	ㆍ초기 도출된 요구사항을 기반으로 프로토타입을 만든 후 개발이 진행되는 동안 도출되는 요구사항을 반영하면서 지속적으로 프로토타입을 재작성하는 과정
모델검증	ㆍ요구사항 분석 단계에서 개발된 모델이 요구사항을 충족시키는지 검증하는 것
인수테스트	ㆍ사용자가 실제로 사용될 환경에서 요구사항들이 모두 충족되는지 사용자 입장에서 확인하는 것 ㆍ알파테스트, 베타테스트 등이 있다.

 

 

DB 데이터베이스 관련 요약

네트워크/운영체제 관련 요약

애플리케이션 테스트 관련 요약

응집도와 결합도 관련 요약

UI, UML, 다이어그램 관련 요약