정보처리기사 필기 1과목 - 소프트웨어 설계

1. 요구사항 확인

2. 분석모델 확인

 

1. 요구사항 확인

요구분석

-요구분석은 도출된 요구사항 간 상충을 해결하고 소프트웨어의 범위를 파악하여 외부 환경과의 상호작용을 분석하는 과정이다

 

요구사항 분석기술

청취기술, 인터뷰와 질문기술, 분석기술, 중재 기술, 관찰 기술, 작성 기술, 조직 기술, 모델 작성 기술

 

요구사항 검토 방법

- 동료검토 (Peer Review) :  요구사항 명세서 작성자가 명세서 내용을 직접 설명하고 동료들이 이를 들으면서 결함을 발견

- 워크스루 (Walk Through) : 검토 회의 전에 요구사항 명세서를 미리 배포하여 사전 검토한 후에 짧은 회의로 결함을 발견

- 인스펙션 (Inspection) :  요구사항 명세서 작성자를 제외한 다른 검토 전문가들이 요구사항 명세서를 확인하여 결함을 발견 

 

요구사항 분석에 사용되는 기능 모델링 기법

 

1. 데이터 흐름도 (DFD ;  Data Flow Diagram)

- 데이터가 각 프로세스를 따라 흐르면서 변환되는 모습을 나타낸 그림

- 가장 보편적으로 사용됨

- 자료 흐름 그래프 또는 버블 차트라고함

- 구조적 분석 기법에 이용

- 데이터 흐름에 중심을 둠

- 제어의 흐름은 중요하지 않음

- 시간의 흐름을 명확하게 표현할 수 없다

데이터 흐름도 구성요소	설명
처리기 (Process)	입력된 데이터를 원하는 형태로 변환하여 출력하기 위한과정, 원으로 표시 O
데이터 흐름(Data Flow)	DFD 의 구성요소(프로세스, 데이터 저장소, 외부 엔터디)들 간의 주고받는 데이터 흐름 -> 화살표로 표시
데이터 저장소 (Data Store)	데이터가 저장된 장소이고 평행선(=)으로 표시하며, 평행선 안에는 데이터 저장소의 이름을 넣음
단말 (Terminator)	프로세스 처리 과정에서 데이터가 발생하는 시작과 종료를 나타내고, 사각형으로 표시하며, 사각형 안에는 외부 엔터티의 이름을 넣음

 

2. 자료사전 (DD; Data Dictionary)

- 자료 요소, 자료 요소들의 집합, 자료의 흐름, 자료 저장소의 의미와 그들 간의 관계, 관계값, 범위, 단위들을 구체적으로 명시하는 사전

기호	설명
=	-자료의 정의로서  '~로 구성되어 있다' 라는 것을 나타내는 기호 (is composed of) - 값, 단위 , 정의
+	- 자료의 연결 (and , along with) 을 나타냄
()	- 자료의 생략
{}	- 자료의 반복
[]	- 자료의 선택을 나타내는 기호
**	주석

 

UML (Unified Modeling Language)

- UML 은 객체 지향 소프트웨어 개발 과정에서 산출물을 명세화, 시각화, 문서화 할때 사용되는 모델링 기술과 방법론을 통합해서 만든 표준화된 범용 모델링 언어

 

UML 특징

- 가시화언어, 구축언어, 명세화 언어, 문서화 언어

 

UML  구성요소

구성요소	설명
사물(Things)	-추상적인 개념으로, 주제를 나타내는요소 -단어 관점에서 명사 또는 동사를 의미
관계(Relationships)	-사물의 의미를 확장하고 명확히 하는 요소 -사물과 사물을 연결하여 관계를 표현하는 요소
다이어그램 (Diagrams)	-사물과 관계를 모아 그림으로 표현한 형태 -형식과목적에 따라 9가지 정의

 

UML 다이어그램

구분	다이어그램	설명
구조적 다이어그램(Structural Diagram) / 정적 다이어그램(Static Diagram)	클래스(Class)✨	- 시스템 내 클래스의 정적 구조를 표현 - 속성과 동작으로 구성 - 클래스와 클래스, 클래스의 속성 사이의 관계 표현
	객체(Object)	- 클래스에 속한 사물들(객체) ,  즉 인스턴스를 특정 시점의 객체와 객체 사이의 관계로 표현 - 객체 인스턴스를 나타내는 대산 실제 클래스를 사용 - 연관된 모든 인스턴스를 표현
	컴포넌트(Component)	- 코드 컴포넌트 기반의 물리적 구조 표현 - 실질적 프로그래밍 작업에 사용 - 구현단계에서 사용 적절
	배치 (Deployment)	- 컴포넌트 사이의 종속성으로 표현 - 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현 - 구현단계에서 사용 적절
	복합체 구조 (Composite Structure)	- 클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현
	패키지 (Package)	- 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계를 표현
행위적 다이어그램 (Behavioral Diagram) / 동적 다이어그램(Dynamic Diagram)	유스케이스(Usecase)✨	- 사용자 관점에서 시스템의 활동을 표현 - 유스케이스는 시스템의 기능적 요구 정의에 활용
	시퀀스 (Sequence)✨	- 객체 간 상호 작용을 메세지 흐름으로 표현 - 객체 사이 메시지를 보내는 시간을 표현
	커뮤니케이션 (Communication)	- 시퀀스 다이어그램과 같이 동작에 참여하는 객체들이 주고 받는 메시지를 표현하는데, 메시지 뿐만 아니라 객체간의 연관까지 표현
	상태 (State)	- 하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객제와의 상호 작용에 따라 상태가 어떻게 변화하는지 표현 - 모든 가능한 상태와 전이 표현
	활동 (Activity)	- 시스템이 어떤 기능을 수행하는 지를 객체의 처리 로직이나 조건에 따른 처리의 흐름으로 순서대로 표현 - 활동의 순서대로 흐름을 표현
	타이밍 (Timing)	- 객체 상태 변화와 시간 제약을 명시적으로 표현

UML 상세

1. 클래스 다이어그램

구성요소	설명
클래스 이름 (Class name)	클래스의 이름
속성 (Attribute)	클래스의 특징에 이름부여
연산 (Operation)	클래스에 속하는 객체에 적용될 메서드를 정의
접근 제어자 (Acees Modilifier)	클래스에 접근 할 수 있는 정도를 표현

2. 유스케이스 다이어그램

구성요소	설명
유스케이스 (Usecase)	시스템이 제공해야하는 서비스 액터가 시스템을 통해 수행해야하는 일련의 행위
액터 (Actor)	사용자가 시스템에 대해 수행하는 역할 시스템과 상호 작용하는 사람 또는 사물
시스템(System)	전체 시스템의 영역을 표현

3. 시퀀스 다이어그램

구성요소	설명
객체 (Object)	객체는 위쪽에 표시되어 아래로 생명선을 가짐
생명선( LifeLine)	객체로부터 뻗어가는 점선
실행(Activation)	직사각형은 오퍼레이션이 실행되는 시간을 의미
메세지 (Acees Modilifier)	객체간의 상호작용은 메시지 교환으로 이루어짐

 

애자일(Agile)

- 소프트 웨어 개발방법론의 하나로서 개발과 함께 즉시 피드백을 받아서 유동적으로 개발하는 방법

- 고객의 요구사항 변화에 빠르게 대응할 수 있는 모형

- 프로젝트의 요구사항은 기능 중심으로 정의

- 절차와 도구보다 개인과 소통을 중요하게 생각한다

- 요구 변화에 유연하고 신속하게 대응 할 수 있다

- 소프트웨어가 잘 실행되는데 가치를 둔다

- 고객과의 피드백을 중요하게 생각한다

 

애자일(Agile) 선언문

- 공정과 도구보다 개인과 상호작용

- 계획을 따르기보다 변화에 대응하기

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

- 계약 협상 보다 고객과의 협력

 

스크럼(SCRUM)

- 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론

- 스크럼 마스터(Scrum master) :  프로젝트 리더(PL) , 스크럼 수행 시 문제를 인지 및 해결하는 사람

- 백로그(Backlog) :  제품과 프로젝트에 대한 요구사항 정리(스토리)(요구사항을 우선순위로 정리)

- 스프린트 (Sprint) :  할일, 진행, 완료 상태 반복 개발 품질 향상

- 스프린트 회고(Sprint Retrospective) :  스프린트 주기를되돌아보며 규친 준수 여부 확인, 개선점 기록

- 검토회의 : PO 제품책임자 주도 

- 스크럼미팅(데일리미팅) : 매일 15분 정도 미팅을 통해 TO-DO List  계획을 수립 

 

XP(eXtreme Programming)

- 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법

- 애자일 방법론 중 하나

- 실용성 강조

- 짧고 반복적인 개발 주기 +  고객의 적극적 참여

- 소규모 개발 프로젝트에 효과적

핵심가치 : 피드백, 존중 ,용기, 단순, 의사소통

 12가지 기본원리 :  Pair Programing, Collective OwnerShip , Continous Intergration , Planning Process , Small Release, Metapjor, Simple Design, TDD , Refactoring, One site Customer, Coding Standard ,  40-Hour Work

---

2. 분석 모델 확인 

모델링

- 모델링은 실세계의 물리현상을 특정한 목적에 대응하여 이용하기 쉬운 형식으로 표현하는 기법

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

- 개발팀이 응용문제를 이해하는데 도움을 줄 수 있다

- 프로세스 위주의 모델링

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

 

분석 자동화 도구 특징

- 표준화 적용과 문서화를 통한 보고를 통해 품질 개선이 가능

- 변경사항과 변경으로 인한 영향에 대한 추적이 쉽다

- 명세에 대한 유지보수 비용의 축소가 가능

- 자동화된 기법을 통해 소프트웨어 품질이 향상된다

- 소프트웨어 모듈의 재사용성이 향상되고, 유지보수가 용이하다

 

분석 자동화 도구 (CASE)

-  요구사항 검증 방법으로 Computer 의 도움을 받는 방법

- CASE(Computer Aided software Engineering)

- 차트와 다이어그램을 그릴 수있는 프로그램

- 자신이 생각하는 모형을 그려서 공유할 수 있음 , 쉽게 협업 가능(작업 과정 및 데이터 공유를 통해 작업자 간의 커뮤니케이션 증대)

- 그래픽을 지원

- 소프트웨어 생명주기의 전 단계를 연결

- 다양한 소프트 웨어 개발 모형을 지원

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

상위 CASE :  계획수립, 요구분석, 기본 설계 단계를 다이어그램으로 표현

하위 CASE : 구문 중심 편집 및 정적, 동적 테스트 지원 ,  시스템 명세서 생성 및 소스 코드 생성 지원

CASE 의 원천 기술 : 구조적 기법, 프로토타이핑 기법, 정보 저장소 기법, 분산 처리 기술

 

요구사항 관리 도구 : JIRA , Helix RM , Orcanos, ReQtest , Redmin ,  Testlink

 

---

3. 화면 설계

UI

- UI 는 넓은 의미에서 사용자와 시스템 사이에서 의사소통할 수 있도록 고안된 물리적 가상의 매개체이다

 

UI 유형

CLI(Command Line Interface) : 정적인 텍스트 기반 인터페이스

GUI(Graphical User Interface) : 그래픽 반응 기반 인터페이스

NUI(Natural User Interface) : 직관적 사용자 반응 기반 인터페이스(터치, 음성)

OUI(Organic User Interface) : 유기적 상호 작용 기반 인터페이스

 

UI 특징

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

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

상호 작용 :  사용자 중심의 상호 작용이 되도록 함

작업시간 감소 : 사용자의 편의성을 높여 작업시간을 감소시킴

 

UI 설계 원칙 

설계 원칙	설명
직관성(Intuitiveness)	누구나 쉽게 이해하고, 쉽게 사용할 수 있어야함
유효성(Effectiveness)	정확하고 완벽하게 사용자의 목표가 달성될 수 있도록제작
학습성(Learnability)	초보자와 숙련자 모두가 쉽게 배우고 사용할 수 있게 제작
유연성(Flexibility)	사용자의 인터랙션을 최대한 포용하고, 실수를 방지할 수 있도록 제작

---

4. 애플리케이션 설계

모듈

- 모듈은 크게 독립된 하나의 소프트웨어 또는 하드웨어 단위를 지칭하는 용어

 

모듈의 특징

- 독립성 , 다양한 조합, 재사용, 영향 최소화

 

공통모듈의 개념

- 전체 프로그램 기능중 특정 기능을 처리 할 수 있는 실행코드를의미

- 자체적으로 컴파일 가능, 다른 프로그램에서 재사용이 가능

- 여러 기능 및 프로그램에서 공통으로 사용할 수 있는 모듈을 의미

 

공통모듈의 원칙

- 정확성, 명확성, 완전성, 일관성, 추적성

 

바람직한 모듈 설계 방안

- 모듈의 독립성과 재사용성을 높이기 위하여 결합도는 낮추고 응집도는 높인다

- 모듈의 복잡도와 중복성을 줄이고 일관성을 유지한다

- 모듈의 기능은 예측이 가능해야 하며, 지나치게 제한적이여서는 안된다

- 적당한 모듈의 크기를 유지한다

- 모듈간의 효과적인 제어를 위해 설계에서 계층적 자료 조직이 제시되어야 한다

- 유지보수가 용이해야하고, 이식성을 고려해야한다

 

코드

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

 

코드의 기능

- 식별 기능, 표준화 기능, 분류 기능, 배열 기능, 간소화 기능, 암호화 기능, 오류 검출 기능, 연상 기능

 

코드의 종류

종류	설명
연상코드 (Mnemonic)	코드만 보고 대상을 연상할 수 있도록 명칭 일부를 약호 형태로 넣어 구성된 코드 - 한국 : KR ,  영국: US
블록코드 (Block)	공통성 있는것끼리 블록으로 구분하고, 각 블록 내에서 일련번호를 부여하는 코드(구분코드) - 전화번호(지역번호 - 국번 - 일련번호 조합)
순차 코드 (Sequence)	일정한 기준에 따라 순서대로 일련 번호를 부여한 코드 -  중고등 학생들의 반에서 번호 (가나다 순으로 나열)
표의 숫자 코드(Significant Digit)	대상 자료의 물리적인 수치인 길이, 넓이, 용량등을 코드로 표시 - 20-10-300 (길이,넓이,용량)
십진코드(Decimal)	10진수 형태로 표현한 코드
그룹 분류식 코드(Group Classification)	대상을 기준에 따라 대분류, 중분류, 소분류로 구분하여 번호를 부여

 

코드 오류 종류

종류	설명
사본오류(Transcription Error)	한글자를 잘못 표기한 경우
전위오류(Transposition Error)	연속된 두 글자가 서로 바뀌어 표기된 경우
생략오류(Omission Error)	한 글자를 빼먹고 기술한 경우
첨가오류(Addition Error)	한 글자 추가되어 기술한 경우
이중 전위오류(Double Transposition Error)	전위 오류가 중복 발생한 경우

HIPO

-체계적인 문서 관리가 가능

- 하향식 소프트웨어 개발을 위한 문서화 도구

- 기호, 도표 등을 사용해서 보기가 쉽고 이해도 쉽다

- 기능과 자료의 의존 관계를 동시에 표현가능

- 변경, 유지보수가 용이

 

Fan in : 내가 들어가는 것

Fan Out : 내가  나가는 것

 

소프트웨어 아키텍처 설계 시스템 품질 속성

-가용성, 변경용이성, 성능, 보안성, 사용 편의성, 시험용이성

 

객체 지향

- 객체 지향은 실세계의 개체를 속성과 메서드가 결합한 형태의 객체로 표현하는 기법

 

객체 지향 구성 요소

구성요소	설명
클래스 (Class)	- 특정 객체 내에 있는 변수와 메서드를 정의하는 일종의 틀 - 객체 지향 프로그래밍에서 데이터를 추상화 하는 단위 - 하나 이상의 유사한 객체들을 묶어서 하나의 공통된 특성을 표현 - 속성은 변수의 형태로 , 행위는 메서드 형태로 선언
객체 (Object)	- 물리적, 추상적으로 자신과 다른 것을 식별 가능한 대상 - 클래스에서 정의한 것을 토대로 메모리에 할당됨 - 객체마다 각각의 상태와 식별성을 가짐
메서드(Method)	-클래스로 부터 생성된 객체를 사용하는 방법 - 객체가 메시지를 받아 실행해야 할 객체의 구체적인 연산 - 전통적 시스템의 함수 또는 프로시저에 해당하는 연산 기능
메시지 (Message)	- 객체 간 상호작용을 하기 위한 수단 - 객체에서 어떤 행위를 하도록 지시하는 방법
인스턴스 (Instance)	- 객체 지향 기법에서 클래스를 통해 만든 실제의 실형 객체 - 실제로 메모리상에 할당
속성 (Property)	- 한 클래스 내에 속한 객체들이 가지고 있는 데이터 값들을 단위별로 정리 - 성질 , 분류, 식별, 수량 , 현재 상태 등에 대한 표현값

 

객체 지향 기법

기법	설명
캡슐화 (Encapsulation)	- 서로 연관된 데이터와 함수를 하나로 묶는 것을 의미 - 결합도가 낮아지고 재사용이 용이 - 인터페이스가 단순해짐 - 정보은닉과 관계가 깊음 - 변경 발생시 오류의 파급효과가 적음
상속성(Inheritance)	- 상위 클래스의 속성과 메서드를 하위 클래스가 물려받음
다형성(Polymorphism)	- 하나의 메시지에 대해 각 객체가 가지고 있는 고유한 방법으로 응답할 수 있는 능력 - 상속받은 여러개의 하위 객체들이 다른 형태의 특성을 갖는 객체로 이용될수 있는 성질 - Overloading : 같은 이름을 가진 함수지만 인자가 달라 각기 다른 인자에 따라 함수를 선택해 수행(파라미터 다르게) - Overriding : 상위 클래스로부터 상속받은 함수들을 다르게 구현하여 사용(자식 클래스가 재정의해서 사용)
정보 은닉(Information Hiding)	- 다른 객체에게 자신의 정보를 숨기고 자신의 연산만을 통해 접근 - 다른 객체에게 주는 영향을 감소시킴
추상화(Abstraction)	- 공통 성질을 추출하여 추상 클래스를 설정하는 기법 - 과정 추상화, 자료 추상화, 제어 추상화 - 불필요한 부분을 생략하고 중요한 것에만 중점을 두어 모델화
관계성 (RelationShip)	- 두개 이상의 엔터티 형에서 데이터를 참조하는 관계를 나타내는 기법

 

객체 지향 설계 원칙 (SOLID)

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

디자인 패턴

• 생성 패턴
  • Abstract Factory: 구체적인 클래스에 의존하지 않고 서로 연관되거나 의존적인 객체들의 조합을 만드는 인터페이스를 제공
  • Buider : 복잡한 인스턴스를 조립하여 만드는 구조, 객체 생성방법과 객체 구현 방법을 분리
  • Factory Method 패턴 : 상위 클래스에서 생성하는 인터페이스를 정의, 하위클래스에서 인스턴스 만듬 (서브 클래스가 결정하도록함)
  • Prototype : 처음부터 일반적인 원형을 만들어놓고, 그것을 복사한 후 필요한 부분만 수정하여 사용
  • Singleton : 전역변수를 사용하지 않고 객체를 하나만 생성하여, 생성된 객체를 어디에서든지 참조할 수 있도록 함
• 구조 패턴
  • Adapter: 기존에 생성된 클래스를 재사용할 수 있도록 중간에서 맞춰주는 역할
  • Bridge : 기능의 클래스 계층과 구현의 클래스 계층을 연결, 추상 계층을 분리하여 추상화된 부분과 실제 구현부분을 독립적으로 확장 할 수 있는 디자인 패턴(결합도를 낮춤)
  • Composite : 객체들의 관계를 트리 구조로 구성
  • Decorator : 기존에 구현되어 있는 클래스에 필요한 기능을 추가해 나감
  • Facade :  복잡한 시스템에 대하여 단순한 인터페이스 제공
  • Flyweight : 다수의 객체로 생성될 경우 모두가 갖는 본질적인 요소를 클래스화함
  • Proxy: 실제 객체에 대한 대리 객체
• 행위 패턴
  • Chain of Responsibility : 한 요청을 두개 이상의 객체에서 처리
  • Iterator : 내부 구조를 노출하지 않고, 복잡 객체의 원소를 순차적으로 접근 가능
  • Interpreter : 언어의 다양한 해석, 여러 형태의 언어 구문을 해석 가능
  • 반복자
  • Mediator : 중재자
  • Memento : Undo 기능을 개발할때 사용
  • Obsever  : 일대 다 의존
  • Strategy : 행위 객체를 클래스로 캡슐화(다양한 알고리즘을 캡슐화)
  • Command : 요구사항을 객체로 캡슐화
  • State (상태) 패턴 : 객체의 상태에 따라 행위 내용을 변경
  • 전략
  • Template Method: 상위 작업의 구조를 바꾸지 않으면서 서브 클래스로 작업의 일부분을 수행
  • Visitor : 특정 구조를 이룬는 복합 객체의 원소 특성에 따라 동작을 수행할 수 있도록 지원

럼바우의 객체 지향 분석 절차

객체 모델링(객체관의 관계정의) -> 동적 모델링(동작 순서 등의 동적인 행위 표현) -> 기능 모델링(DFD를 활용)

 

객체지향의 관계성

일반화 :  is-a 관계

집단화 : is - part-of 관계, part - whole 관계