정보처리기사 필기 요점정리 | 1️⃣소프트웨어 설계
1과목 소프트웨어 설계
시스템 구성요소
- 입력 (Input) : 처리 방법, 처리할 데이터, 조건을 시스템에 투입하는 것
- 처리 (Process) : 입력된 데이터를 처리 방법과 조건에 따라 처리하는 것
- 출력 (Output) : 처리된 결과를 시스템에서 산출하는 것
- 제어 (Control) : 자료를 입력하여 출력될 때까지의 처리 과정이 올바르게 진행되는지 감독하는 것
- 피드백 (Feedback) : 출력된 결과가 예정된 목표를 만족시키지 못할 경우 목표 달성을 위해 반복 처리하는 것
UML이란
- 객체 지향 소프트웨어 개발 과정에서 산출물을 명세화, 시각화, 문서화할때 사용되는 모델링 기술과 방법론을 통합해서 만든 표준화된 범용 모델링 언어.
UML 특징
<가 구 명 문>
- 가시화 언어 : 개념 모델 작성 시 오류가 적고 의사소통이 용이
- 구축 언어 :
- 다양한 프로그래밍 언어로 실행 시스템 예측 가능
- UML을 소스코드로 변환하여 구축 가능, 역 변환하여 역공학 가능
- 명세화 언어 : 정확한 모델 제시, 완전한 모델 작성 가능
- 문서화 언어 : 시스템에 대한 평가 및 의사소통의 문서
UML 구성요소
<사 관 다>
- 사물 : 다이어그램 안에서 관계가 형성될 수 있는 대상
- 관계 : 사물과 사물 사이의 연관성을 표현하는 것
- 연관 Association : 두 사물간의 구조적 관게. 어느 한 사물 객체가 다른 사물 객체와 연결되어 있음을 말함
- 집합
- 포함
- 일반화 Generalization : 일반화된 사물과 좀 더 특수화된 사물 사이의 관계
- 의존 Dependency : 한 사물의 명세서가 바뀌면 그것을 사용하는 다른 사물에게 영향을 끼치는 것.
- 실체화 Realization : 한 객체가 다른 객체에 의해 오퍼레이션을 수행하도록 지정
- 다이어그램 : 사물과 관계를 도형으로 표현한 것
UML 다이어그램 유형 : 구조적(=정적) 다이어그램, 행위적(=동적) 다이어그램으로 구분된다.
구조적 다이어그램
<클 객 컴 배 복 패> : 클래스 / 객체 / 컴포넌트 / 배치 / 복합체 구조 / 패키지
- 클래스 다이어그램 : 객체지향 모델링 시 구성요소간 정적인 관계를 표현한 다이어그램.
- 클래스 다이어그램 구성 요소 : 클래스 이름 / 속성 / 연산 / 접근 제어자
행위적 다이어그램
<유 시 커 상 활 타> : 유스케이스 / 시퀀스 / 커뮤니케이션 / 상태 / 활동 / 타이밍
- 유스케이스 다이어그램 : 사용자의 관점에서 표현하는 다이어그램. 기능 모델링 작업에 사용된다.
- 유스케이스 다이어그램 구성 요소 : 유스케이스 / 액터 / 시스템
- 액터 : 시스템과 상호작용 하는 모든 외부요소(사람, 기계, 시스템 등)
- 유스케이스 구성 요소 간의 관계
- 연관 : 유스케이스와 액터간의 상호작용이 있음을 표현한다.
- 포함 : 하나의 유스케이스가 다른 유스케이스의 실행을 전제로 할 때 형성되는 관계
- 확장 : 확장 기능 유스케이스와 확장 대상 유스케이스 사이에 형성 되는 관계이다.
- 일반화 : 유사한 유스케이스/액터를 모아 추상화한 유스케이스/액터와 연결시켜 그룹을 만들어 이해도를 높이기 위한 관계.
- 시퀀스 다이어그램 : 객체 간 상호작용을 메시지 흐름으로 표현한 다이어그램
- 시퀀스 다이어그램 구성 요소 :
- 객체 : 사각형 안에 밑줄 친 이름으로 명시
- 생명선 : 객체로부터 뻗어나가는 점선
- 실행 : 점선 위 직사각형, (직사각형=실행시간)
- 메시지 : 화살표
UI란
- 사용자와 시스템 사이에서 의사소통할 수 있도록 고안된 물리적, 가상의 매개체이다.
- 정보기기나 소프트웨어 화면 등에서 사람이 접하게 되는 화면
UI 유형
<CG NO>
- CLI : 정적인 텍스트 기반 인터페이스
- 명령어를 텍스트로 입력하여 조작하는 사용자 인터페이스
- GLI : 그래픽 반응 기반 인터페이스
- 그래픽 환경을 기반으로 한 마우스나 전자펜을 이용하는 사용자 인터페이스
- NUI : 직관적 사용자 반응 기반 인터페이스
- 사용자가 가진 경험을 기반으로 키보드나 마우스 없이 신체 부위를 이용하는 사용자 인터페이스(터치 음성 등)
- OUI : 유기적 상호작용 기반 인터페이스
- 입력장치가 곧 출력장치가 되고, 현실에 존재하는 모든 사물이 입출력장치로 변화할 수 있는 사용자 인터페이스
UI 설계 원칙
<직 유 학 유>
- 직관성 : 누구나 쉽게 이해하고, 쉽게 사용할 수 있어야 한다.
- 유효성 : 정확하고 완벽하게 사용자의 목표가 달성될 수 있도록 제작
- 학습성 : 초보와 숙련자 모두가 쉽게 배우고 사용할 수 있게 제작
- 유연성 : 사용자의 인터랙션을 최대한 포용하고, 실수를 방지할 수 있도록 제작
UI 시스템의 필요 기능
- 사용자 입력의 검증
- 에러 처리와 에러 메시지 처리
- 도움과 프롬프트 제공
UI 표준 구성
<액 정 스 패 조>
- 전체적인 UX 원칙
- 정책 및 철학
- UI 스타일 가이드
- UI 패턴 모델 정의
- UI 표준 수립을 위한 조직 구성
UI 컨셉션 세부 수행 활동
<정 와 스> : 정보 구조 설계 / 와이어 프레임 스케치 / 스토리보드 설계
UI 상세 설계 - 시나리오 문서의 작성 요건
<완일이가 추수> : 완전성 / 일관성 / 이해성 / 가독성 / 추적 용이성 / 수정 용이성
UI 화면 설계 구분
<와 스 프> :
- 와이어 프레임 : 이해관계자들과의 화면 구성을 협의하거나 서비스의 간략한 흐름을 공유하기 위해 화면 단위의 레이아웃을 설계하는 작업
- 스토리보드 : 정책, 프로세스, 콘텐츠 구성, 와이어프레임, 기능 정의, 데이터베이스 연동 등 서비스 구축을 위한 모든 정보가 담겨 있는 설계 산출물
- 프로토타입 : 정적인 화면으로 설계된 와이어프레임 또는 스토리보드에 동적 효과를 적용함으로써 실제 구현된 것처럼 시뮬레이션 할 수 있는 모형
UI 설계 프로세스
<문사 작컴 인디>
문제 정의 -> 사용자 모델 정의 -> 작업 분석 -> 컴퓨터 오브젝트 및 기능 정의 -> 사용자 인터페이스 정의 -> 디자인 평가
UI 흐름 설계
<기 입 유 양>
화면에 표현되어야 할 기능 작성 -> 화면의 입력 요소 확인 -> UI 요구사항을 기반으로 유스케이스 설계 -> 기능 및 양식 확인
미들웨어란
- 표준화된 인터페이스를 통해 시스템 간의 데이터 교환에 일관성을 보장한다.
- 운영체제와 애플리케이션 사이에서 중간 매개 역할을 하는 다목적 소프트웨어이다.
- 클라이언트와 서버 간의 통신을 담당하는 시스템 소프트웨어이다.
- 이기종 하드웨어, 소프트웨어, 네트워크, 프로토콜, PC 환경, 운영체제 환경 등에서 시스템 간의 표준화된 연결을 도와주는 스프트웨어이다.
- 분산 시스템에서 다양한 부분을 관리하고 통신하며 데이터를 교환하게 해주는 소프트웨어
- 위치 투명성을 제공한다.
- 분산 시스템의 여러 컴포넌트가 요구하는 재사용 가능한 서비스의 구현을 제공한다.
- 사용자<->애플리케이션 사이 외에도 프로그램과 환경 간에서 서비스를 제공한다.
미들웨어 종류
- DB :
- 데이터베이스 벤더에서 제공하는 클라이언트에서 원격의 데이터베이스와 연결하기 위한 미들웨어이다.
- DB를 사용해 시스템을 구축하는 경우 보통 2-Tier 아키텍처라고 한다.
- 마이크로소프트 ODBC, 볼랜5. 기타 패턴
- RPC :
- 원격 프로시저 호출은 응용 프로그램의 프로시저를 사용해 원격 프로시저를 로컬 프로시저처럼 호출하는 방식.
- 이큐브 시스템즈 Entera, OSF의 ONE/RPC
- *MOM :
- 메시지 지향 미들웨어는 메시지 기반의 비동기형 메시지를 전달하는 방식.
- 온라인 업무보다 이기종 분산 데이터 시스템의 데이터 동기를 위해 많이 사용된다.
- 느리고 안정적인 응답을 필요로 하는 경우 많이 사용한다.
- IBM의 MQ, 오라클 Message Q, JPC의 JMS
- TP-Monitor :
- 항공기, 철도 예약 업무 등과 같은 온라인 트랜잭션을 처리/감시 하는 미들웨어.
- 사용자 수가 증가하더라도 빠른 응답속도를 유지해야 할 경우 사용.
- 오라클 tuxedo, 티맥스소프트 tmax
- ORB :
- 객체 지향 미들웨어로 코바 표준 스펙을 구현한 미들웨어이다.
- TP-Monitor의 장점인 트랜잭션 처리와 모니터링을 추가한 제품도 나오고 있다.
- Micro Focus의 Orbix, OMG의 CORBA
- WAS :
- 동적인 콘텐츠를 처리하기 위한 미들웨어.
- 웹 환경을 구현하기 위한 미들웨어.
- HTTP세션 처리를 위한 웹 서버 기능 + 미션=크리티컬한 기업 업무가지 JAVA, EJB 컴포넌트 기반으로 구현 가능.
- 오라클의 WebLogic, IBM의 WebSphere
소프트웨어 개발 방법론 (5과목 '소프트웨어 공학'이랑 중복되는 내용)
- 소프트웨어 개발, 유지보수 등에 필요한 여러 가지 일들의 수행 방법과 이러한 일들을 효율적으로 수행하려는 과정에서 필요한 각종 기법 및 도구를 체계적으로 정리하여 표준화 한 것이다.
소프트웨어 개발 방법론 목적
- 소프트웨어의 생선성, 품질 향상
소프트웨어 개발 방법론의 종류
<구 정 객 컴 애 제>
1. 구조적 방법론
- 정형화된 분석 절차에 따라 사용자 요구사항을 파악하여 문서화하는 처리 중심의 방법론이다.
- 쉬운 이해 및 검증이 가능한 프로그램을 생성하는 것이 목적이다.
- 복잡한 문제를 다루기 위해 분할과 정복 원리를 적용한다.
- DFD(Data Flow Diagram), DD(Data Dictionary) 등을 사용하여 요구사항 결과를 표현한다.
자료흐름도DFD 구성요소
<프 플 스 터>
- 처리 Process : 원
- 자료흐름 Data Flow : 화살표
- 자료저장소 Data Store : 평행선
- 단말 Terminal : 사각형
구조적 방법론의 절차
- 타당성 검토 -> 계획 -> 요구사항 -> 설계 -> 구현 -> 시험 -> 운용/유지보수
2. 정보공학 벙법론
- 정보 시스템의 개발을 위해 계획, 분석, 설계, 구축에 정형화된 기법들을 상호 연관성 있게 통합 및 적용하는 자료중심의 방법론
- 정보 시스템 개발 주기를 이용하여 대규모 정보 시스템을 구축하는데 적합하다.
- 데이터베이스 설계의 표현으로 ERD(Entity-Relationship-Diagram) 모델링 언어 사용.
정보공학 방법론의 절차
- 정보 전략 계획 수립 -> 업무 영역 분석 -> 업무 시스템 설계 -> 업무 시스템 구축
3. 객체지향 방법론 (아래 더)
- 현실 세계의 개체를 기계의 부품처럼 하나의 객체로 만들어, 소프트웨어를 개발할 때 기계의 부품을 조립하듯이 객체들을 조립해서 필요한 소프트웨어를 구현하는 방법론이다.
- 객체지향 방법론의 구조적 기법의 문제점으로 인한 소프트웨어 위기의 해결책으로 채택되었다.
객체지향 방법론 구성 요소 : 객체 / 클래스 / 메시지
객체지향 방법론 기본 원칙 : 캡슐화 / 정보 은닉 / 추상화 / 상속성 / 다형성
객체 지향 방법론 절차 : 요구 분석 -> 설계 -> 구현 -> 테스트 및 검증 -> 인도
4. 컴포넌트 기반 벙법론
- 기존의 시스템이나 소프트웨어를 구성하는 컴포넌트를 조합하여 하나의 새로운 애플리케이션을 만드는 방법론
- 컴포넌트의 재사용이 가능하여 시간과 노력을 절감할 수 있다.
- 유지 보수 비용을 최소화하고 생산성 및 품질을 향상시킬 수 있다.
컴포넌트 기반 방법론의 절차 :
- 개발 준비 -> 분석 -> 설계 -> 구현 -> 테스트 -> 전개 -> 인도
5. 애자일 방법론
6. 제품 계열 방법론
- 특정 제품에 적용하고 싶은 공통된 기능을 정의하여 개발하는 방법
- 임베디드 소프트웨어를 만드는데 적합
*애자일이란
- 소프트웨어 개발방법론의 하나로서 개발과 함께 즉시 피드백을 받아서 유동적으로 개발하는 방법.
애자일 방법론의 특징
- 프로젝트의 요구사항은 기능 중심으로 정의한다.
- 절차와 도구보다 개인과 소통을 중요하게 생각한다.
- 작업 철차를 짧게 세워 요구 변화에 유연하고 신속하게 대응할 수 있다.
- 소프트웨어가 잘 실행되는 데 가치를 둔다.
- 고객과의 피드백을 중요하게 생각한다.
애자일 선언문 : 애자일 방법론을 실천하기 위한 주요 원칙
<개 변 동 고>
- 공정과 도구보다 *개인과의 상호작용
- 계획을 따르기 보다는 *변화에 대응하기
- 포괄적인 문서보다는 *동작하는 소프트웨어
- 계약 협상보다는 *고객과의 협력
애자일 방법론 유형
- XP : 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론.
- XP의 5가지 가치
<용 단 의 피 존> : 용기 / 단순성 / 의사소통 / 피드백 / 존중
- XP의 12가지 기본원리
1. 짝 프로그래밍(Pair Programming)
2. 공통 코드 소유(Collective Ownership)
3. 지속적인 통합(CI; Continuous Integration)
4. 계획 세우기
5. 작은 릴리즈
6. 메타포어
7. 간단한 디자인
8. 테스트 기반 개발
9. 리팩토링
10. 40시간 작업
11. 고객 상주
12. 코드 표준
- 린 Lean : 도요타의 린 시스템 품질기법을 소프트웨어 개발 프로세스에 적용해서 낭비 요소를 제거하여 품질을 향상시킨 방법론
- 린의 7가지 원칙
<낭 품 지 확 인 사 전> : 낭비제거 / 품질 내재화 / 지식 창출 / 늦은 확정 / 빠른 인도 / 사람 존중 / 전체 최적화
- 스크럼 SCRUM : 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론
- 백로그 : 제품과 프로젝트에 대한 요구 사항
- 스프린트 : 2~4주의 짧은 개발기간으로 반복적 수행으로 개발 품질 향상
- +칸반, 크리스탈, FDD(기능중심 개발) 등..
객체지향 이란
- 현실 세계을 그대로 모형화
- 소프트웨어 개발 시 객체들을 조립해 작성 가능
- 소프트웨어 재사용 및 확장을 용이, 유지보수가 쉬움
객체지향 주요 요소
- 객체 : 데이터와 데이터를 처리하는 함수를 캡슐화한 하나의 모듈
- 클래스 : 공통된 속성과 연산을 갖는 객체의 집합
- 메시지 : 객체들 간에 상호작용을 하는 데 사용되는 수단. 객체에 어떤 행위를 하도록 지시하는 명령
객체지향 주요 개념(원칙)
- 캡슐화 :
- 데이터와 데이터를 처리하는 함수를 하나로 묶은 것
- 캡슐화된 객체의 세부 내용이 은폐되어 변경이 발생해도 오류의 파급효과가 적음
- 캡슐화된 객체들은 재사용이 용이함
- 인터페이스가 단순해지고 객체간의 결합도가 낮아짐
- 상속성 :
- 이미 정의된 상위 클래스의 모든 속성과 연산을 하위 클래스가 물려 받는 것
- 하위 클래스는 상위 클래스로부터 받은 속성과 연산 외에도 새로운 것을 첨가할 수 있음
- 클래스의 재사용, 소프트웨어의 재사용을 높이는 중요한 개념
* 다중 상속성 : 한 개의 클래스가 2개 이상의 클래스로부터 속성과 연산을 상속받는 것
- 다형성 :
- 하나의 메시지에 대해 각 객체가 갖고 있는 고유한 방법대로 응답하는 것을 의미.
- 하나의 클래스나 메서드가 다양한 방식으로 동작이 가능한 것을 의미
- 현재 코드를 변경하지 않고 새로운 클래스를 쉽게 추가할 수 있게 한다.
- 오버로딩과 오버라이딩이 존재
- 오버로딩 : 한 클래스 내에서 메서드 이름은 동일하지만 매개변수의 수나 타입을 다르게 하여 재정의 하는 것
- 오버라이딩 : 상속관계에서만 발생. 슈퍼클래스의 메서드를 서브클래스에서도 동일한 메서드를 재정의 하는 것
+ 정보 은닉
- 캡슐화에서 가장 중요한 개념, 다른 객체에 자신의 정보를 숨기는 것
- 연산만을 통해 접근을 허용함
- 각 객체의 수정이 다른 객체에 주는 Side Effect를 최소화하는 기술
+ 추상화
- 불필요한 부분을 생략, 객체 속성 중 가장 중요한 것에 중심을 두어 모델화 하는 것
- 완전한 시스템 구축 전, 그 시스템과 유사한 모델을 만들어 여러 요인들을 테스트할 수 있음
+ 집단화
- 클래스 간의 구조적인 집약 관계
- 클래스 사이의 '부분-전체(part whole) 관계' 또는 '부분(is-a-part-of)'의 관계로 설명되는 연관성을 나타내는 용어
소프트웨어 설계에 사용되는 추상화 기법
- 제어 추상화 : 제어의 정확한 메커니즘을 정의하지 않고 원하는 효과를 정하는데 이용하는 방법
- 기능 추상화 : 입력 자료를 출력자료로 변환하는 과정을 추상화하는 방법
- 자료 추상화 : 자료와 자료에 적용될 수 있는 기능을 함께 정의함으로써 자료 객체를 구성하는 방법
- 과정 추상화 : 자세한 수행 과정을 정의하지 않고, 전반적인 흐름만 파악할 수 있게 설계하는 방법
- 데이터 추상화 : 데이터의 세부적인 속성이나 용도를 정의하지 않고, 데이터 구조를 대표할 수 있는 표현으로 대체하는 방법
객체 지향 설계 원칙
- 객체 지향 프로그래밍 설계를 할 때 프로그래머가 시간이 지나도 유지보수와 확장이 용이한 시스템을 만들고자 할 때 적용하는 원칙이다.
<SOLID>
- 단일 책임 원칙 | SRP : 한 클래스는 하나의 책임만 가져야 한다.
- 개방 폐쇄 원칙 | OCP : 소프트웨어 요소는 확장에는 열려있느나 변경에는 닫혀 있어야 한다.
- 리스코프 치환의 원칙 | LSP :
- 프로그램 객체는 프로그램의 정확성을 깨뜨리지 않으면서 서브타입(하위클래스)은 어디서나 자신의 기반타입(상위클래스) 인스턴스로 바꿀 수 있어야 한다.
- 특정 메소드가 상위 타입을 인자로 사용할 때, 그 타입의 하위 타입도 문제없이 작동해야 한다.
- 인터페이스 분리의 원칙 | ISP :
- 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.
- 클라이언트는 자신이 사용하지 않는 메서드와 의존 관계를 맞으면 안된다.
- 클라이언트가 사용하지 않는 인터페이스 때문에 영향을 받아서는 안된다.
- 의존성 역전의 원칙 | DIP :
- 추상화에 의존해야지, 구체화에 의존하면 안된다.
- 상위 계층이 하위 계층에 의존하는 전통적인 의존관계를 발전(역전)시킴으로써 상위 계층이 하위 계층의 구현으로부터 독립되게 할 수 있음
객체 지향 분석
-사용자의 요구사항을 분석하여 요구된 문제와 관련된 모든 클래스(객체), 이와 관련된 속성과 연산, 그들 간의 관계 등을 정의하여 모델링 하는 작업을 의미한다.
- 분석 모델링 기법이 사용될 수 있다.
- 데이터와 행위를 하나로 묶어 객체를 정의내리고 추상화시키는 작업이라 할 수 있다.
- 코드 재사용에 의한 프로그램 생산성 향상 및 요구에 따른 시스템의 쉬운 변경이 가능하다.
객체 지향 분석 방법론 종류
1. Rumbaugh 럼바우
- 소프트웨어 구성 요소를 그래픽 표기법을 이용하여 모델링하는 객체 지향 분석 기법
- 가장 일반적으로 사용하는 방법
<객 동 기>
- 객체 모델링 : 객체 다이어그램, 정보 모델링이라 표현. 가장 먼저 선행되며 시스템에서 요구하는 객체를 찾고 객체들 간의 관계를 정의한다.
- 동적 모델링 : 상태 다이어그램, 시간의 흐름에 따라 객체들 사이의 제어 흐름, 동작 순서 등의 동적인 행위
- 기능 모델링 : 자료 흐름도(DFD), 프로세스들의 자료 흐름을 중심으로 처리 과정 표현
2. Booch 부치
- 미시적 개발 프로세스와 거시적 개발 프로세스 모두 포함하여 사용
- Use-Case를 강조하여 활용한 방법
- 클래스와 객체들을 분석 및 식별하고 클래스의 속성과 연산을 정의
3. Code Yourdon 코드 요던
- E-R 다이어그램을 사용하여 객체의 행위를 모델링
- 객체 식별, 구조 식별
4. Wirfs Brock 워프스-브록
- 분석과 설계 간 구분이 없으며, 고객 명세서를 평가하여 설계 작업까지 연속적 수행
소프트웨어 아키텍처 설계
- 소프트웨어의 골격이 되는 기본 구조, 소프트웨어를 구성하는 요소들 간의 관계를 표현하는 시스템의 구조를 설계한다.
- 사용자의 비기능적 요구사항을 반영하고, 기능적 요구사항을 구현하는 방법을 찾는 해결 과정.
소프트웨어 아키텍처-시스템 품질속성
- 성능 : 사용자 요청 같은 이벤트가 발생했을 때, 이를 적절하고 빠르게 처리하는 것
- 보안 : 허용되지 않은 접근을 막고, 허용된 접근에는 적절한 서비스를 제공하는 것
- 가용성 : 장애 없이 정상적으로 서비스를 제공하는 것
- 기능성 : 사용자가 요구한 기능을 만족스럽게 구현하는 것
- 사용성 : 사용자가 소프트웨어를 사용하는데 헤매지 않도록 명확하고 편리하게 구현하는 것
- 변경 용이성 : 소프트웨어가 처음 설계 목표와 다른 하드웨어나 플랫폼에서도 동작할 수 있도록 구현하는 것
- 확장성 : 시스템의 용량, 처리능력 등을 확장시켰을 때 이를 효과적으로 활용할 수 있도록 구현하는 것
- 기타 속성 : 테스트 용이성, 배치성, 안전성 등
요구사항 이란
- 어떠한 문제를 해결하기 위해 필요한 조건이나 제약사항을 요구하는 것.
- 소프트웨어가 무엇을 해야하는가를 추적하며 요구사항 명세를 작성하는 작업
- 사용자의 요구를 추출하여 목표를 정하고 어떤 방식으로 해결할 것인지 결정하는 단계
- 소프트웨어 개발의 출발점이면서 실질적인 첫번째 단계이다.
요구사항 유형
- 기능 요구사항 :
- 시스템이 무엇을 하는지, 어떤 기능을 하는지에 대한 사항.
- 시스템의 입력이나 출력으로 무엇이 포함되어야 하는지, 시스템이 어떤 데이터를 저장하거나 연산을 수행해야 되는지에 대한 사항
- 시스템이 반드시 수행해야 하는 기능
- 사용자 시스템을 통해 제공받기를 원하는 기능
- 비기능 요구사항 :
- 시스템 장비 구성 / 성능 / 인터페이스 / 데이터 / 테스트 / 보안 / 품질 요구사항
- 제약 사항, 프로젝트 관리 요구사항, 프로젝트 지원 요구사항
- 사용자 요구사항 :
- 사용자 관점에서 본 시스템이 제공해야 할 요구사항
- 사용자를 위한 것으로 친숙한 표현으로 이해하기 쉽다.
- 시스템 요구사항 :
- 개발자 관점에서 본 시스템 전체가 사용자와 다른 시스템에 제공해야 할 요구사항
- 사용자 요구사항에 비해 전문적이고 기술적인 용어로 표현
- 소프트웨어 요구사항 이라고도 함.
요구사항 개발 프로세스
*(순서) 도출 -> 분석 -> 명세 -> 확인
요구사항 검증
- 요구사항 명세서의 오류 확인 및 표준 준수 여부 등의 결함 여부를 검토 담당자들이 수작업으로 분석.
- 동료검토 : 요구사항 명세서 작성자가 명세서 내용을 직접 설명하고 동료들이 이를 들으면서 결함을 발견.
- 워크스루 : 검토 회의 전에 요구사항 명세서를 미리 배포하여 사전 검토한 후에 짧은 결함을 발견.
- 인스펙션 : 요구사항 명세서 작성자를 제외한 다른 검토 전문가들이 요구사항 명세서를 확인하면서 결함을 발견.
- 프로토타이핑 : 실제 개발될 소프트웨어의 견본품을 만들어 최종 결과물을 예측
- 테스트 설계 : 테스트케이스를 생성하고 이후 요구사항이 현실적으로 테스트 가능한지를 검토
- CASE 도구 활용 : 일관성 분석을 통해 요구사항 변경사항의 추적 및 분석, 관리하고, 표준 준수 여부를 확인
CASE(Computer Aided Software Engineering)
- 소프트웨어 개발 시 사용되는 분석 자동화 도구
- 요구사항을 자동으로 분석, 요구사항 명세서를 기술하도록 개발된 요구사항 분석을 위한 자동화 도구
CASE 분류
- 상위(Upper) CASE : 모델들 사이의 모순 검사, 모델의 오류 검증, 자료 흐름도 작성 등 지원
- 하위(Lower) CASE : 코드의 작성과 테스트, 문서화하는 과정 지원
- 통합(Integrate) CASE : 소프트웨어 생명 주기 전체 과정 지원
CASE 원천 기술
<구 분 정 자 핑>
- 구조적 기법
- 분산처리 기술
- 정보 저장소 기술
- 자동 프로그래밍 기술
- 프로토타이핑 기술
CASE 도구의 기능 및 효과
- 그래픽 지원
- 소프트웨어 생명 주기 전 단계의 연결
- 다양한 소프트웨어 개발 모형 지원
- 소프트웨어 모듈의 재사용성 향상
- 소프트웨어 품질 향상
- 소프트웨어 유지보수 간편하게 수행 가능
HIPO
- 시스템의 분석 및 설계, 또는 문서화에 사용되는 기법.
- 시스템 실행 과정인 입력/처리/출력의 기능을 표현한 것
- 하향식 소프트웨어 개발을 위한 문서화 도구
- 기능과 자료의 의존관계를 동시에 표현 가능
- 기호, 도표 등을 사용하므로 보기 쉽고 이해하기도 쉬움
HIPO Chart
- 시스템의 기능을 여러 모듈로 고유 모듈로 분할하여 이들 간의 인터페이스를 계층 구조로 표현한 것
HIPO Chart의 종류
<가 총 세>
- 가시적 도표(Visual table of Contents, 도식 목차)
- 총체적 도표(Overview Diagram, 총괄 도표, 개요 도표)
- 세부적 도표(Detail Diagram, 상세 도표)
요구사항 명세기법
- 정형 명세기법 :
- 수학적 기호, 정형화된 표기법으로 작성
- 정확하고 간결하게 표현할 수 있지만 표기법이 어려워 사용자가 이해하기 어렵다.
- 일관성이 있다.
- 비정형 명세기법
- 일반 명사, 동사 등의 자연어를 기반으로 작성한다.
- 이해가 쉽다
- 일관성이 떨어진다.
아키텍처 패턴
- 아키텍처를 설계할때 참조할 수 있는 전형적인 해결 방식, 예제
아키텍처 패턴의 장점
- 시행착오 줄임
- 예측 가능
- 안정적 개발
아키텍처 패턴 종류
1. 레이어 패턴 :
- 시스템 계층으로 구분해 구성하는 고전적인 방법
- 각각의 서브시스템들이 계층 구조를 이룸
2. 클라이언트-서버 패턴
- 하나의 서버 컴포넌트와 다수의 클라이언트 컴포넌트로 구성되는 패턴
- 서버는 클라이언트의 요청에 대비해 항상 대기 상태 유지
- 클라이언트와 서버는 요청과 응답의 경우를 제외한 서로 독립적
3. 파이프-필터 패턴
- 데이터가 파이프를 통해 양방향으로 흐르고, 필터 이동시 오버헤드가 발생할 수 있다.
- 데이터 스트림 절차의 각 단계를 필터 컴포넌트로 캡슐화하여 파이프를 통해 데이터를 전송하는 패턴
- 재사용성이 좋고, 추가가 쉬워 확장에 용이하다.
- 필터 컴포넌트 재배치 가능
- 변환, 버퍼링, 동기화 등에 주로 사용된다.
- 서브시스템이 입력 데이터를 받아 처리하고 결과를 다른 시스템에 보내는 작업이 반복되는 아케틱처 스타일.
4. 모델-뷰-컨트롤러 패턴(MVC)
- 서브 시스템을 3개의 부분으로 구조화하는 패턴
- 각 부분은 별도의 컴포넌트로 분리되어 있음, 영향 X
- 사용자 인터페이스를 담당하는 계층의 응집도를 높일 수 있고, 여러 개의 다른 UI를 만들어 그 사이에 결합도를 낮출 수 있다.
- 대화형 애플리케이션에 적합
- 모델 : 서브시스템의 핵심 기능과 데이터를 보관. 한 개의 모델에 대해 여러 개의 뷰를 만들 수 있다.
- 뷰 : 사용자에게 정보 표시. 모델에 있는 데이터를 사용자 인터페이스에 보이는 역할을 담당한다.
- 컨트롤러 : 사용자로부터 받은 입력 처리. 모델에 명령을 보냄으로써 모델의 상태를 변경할 수 있다.
5. 기타 패턴
- 마스터-슬레이브 패턴 :
- 마스터 컴포넌트에서 슬레이브 컴포넌트로 작업 분할 후, 슬레이브에게 처리된 결과물을 다시 돌려받음
- 일반적으로 실시간 시스템에서 사용된다.
- 마스트 프로세스 : 작업을 분리, 배포 / 연산, 통신, 조정을 책임진다.
- 슬레이브 프로세스 : 요청 작업을 처리 / 데이터 수집 기능을 수행한다.
- 마스터는 슬레이브가 반환한 결과값으로부터 최종 결과값을 계산한다.
- 브로커 패턴 : 사용자가 원하는 서비스와 특성을 요청하면 요청에 맞는 컴포넌트와 사용자를 연결해 줌
- 피어-투-피어 패턴 : 피어=하나의 컴포넌트, 각 피어는 클라이언트가 될 수도 서버가 될 수도 있는 패턴, 멀티스레딩 방식
- 이벤트-버스 패턴 : 소스가 특정 채널에 이벤트 메시지를 발행하면, 해당 채널을 구독한 리스너들이 메시지를 받아 이벤트를 처리함
- 블랙보드 패턴 : 컴포넌트들은 검색을 통해 블랙보드에서 원하는 데이터를 찾음
- 인터프리터 패턴 : 프로그램 코드의 각 라인을 수행하는 방법을 지정하고, 기호마다 클래스를 갖도록 구성
아키텍처 설계 과정
- 설계 목표 설정 -> 시스템 타입 결정 -> 아키텍처 패턴 적용 -> 서브시스템 구체화 -> 검토
GoF 디자인패턴 이란
- 각 모듈의 세분화된 역할 / 모듈들 간 인터페이스와 같은 코드를 작성하느 수준의 세부적인 구현 방안을 설게할 때 참조할 수 있는 전형적인 해결 방식 또는 예제
디자인 패턴 특징
- 재사용 가능한 기본형 코드들이 포함되어 있음
- 개발 과정 중 문제가 발생하면 문제에 해당하는 디자인 패턴을 참고하여 적용하는 것이 더 효율적
- 한 패턴에 변형을 가하거나 특정 요구사항을 반영하면 유사한 형태의 다른 패턴으로 변화
- 1995년 GoF가 처음으로 구체화 및 체계화되었다.
- 가장 일반적 사례에 적용될 수 있는 패턴들을 분류하여 정리한다. 가장 많이 사용되는 디자인 패턴
디자인 패턴 유형
<생 구 행>
1. 생성
- 객체가 생성되는 데 관련된 패턴들
- 객체가 생성되는 과정의 유연성을 높이고 손쉬운 코드의 유지
생성 패턴 종류 :
- 추상 팩토리
- 빌더
- 팩토리 메서드
- 프로토타입
- 싱글턴
2. 구조
- 프로그램 구조에 관련된 패턴들
- 프로그램 내의 자료구조 또는 인터페이스 구조 등 프로그램의 구조를 설계하는 데 활용 가능한 패턴들
- 클래스나 객체를 조합해 더 큰 구조를 만드는 패턴
구조 패턴 종류 :
- 어댑터
- 브리지
- 컴퍼지트
- 데커레이터
- 퍼사드
- 플라이웨이트
- 프록시
3. 행위
- 반복적으로 사용되는 객체들의 상호작용을 패턴화한 것들
- 결합도를 최소화하는 것에 중점
- 객체(클래스) 사이에 알고리즘이나 책임 분배에 관련 패턴
행위 구조 패턴 :
- 책임 연쇄
- 커맨드
- 인터프리터
- 이터레이터
- 미디에이터(중재자)
- 메멘토
- 옵서버
- 상태
- 스트래티지(전략)
- 템플릿메서드
- 비지터(방문자)
통합 테스트
- 단위 테스트가 끝난 모듈을 통합하는 과정에서 발생되는 오류/결함을 찾는 테스트
하향식 통합 테스트
- 프로그램의 상위 모듈 -> 하위 모듈로 통합하면서 테스트한다.
- 깊이 우선 통합법, 넓이 우선 통합법 사용
- 테스트 초기 부터 사용자에게 시스템 구조를 보여줄 수 있다.
- 상위 모듈에서는 tc를 사용하기 어렵다.
- 상위 모듈에서 하위 모듈 방향으로 통합하면서 테스트 하는 기법
절차
- 주요 제어 모듈은 작성된 프로그램을 사용하고, 주요 제어 모듈의 종속 모듈들은 스텁(stub)으로 대체한다.
- 깊이 우선 or 넓이 우선 등의 통합 방식에 따라, 하위 모듈인 스텁들이 한 번에 하나씩 실제 모듈로 교체된다.
- 모듈이 통합될 때마다 테스트 실시
- 새로운 오류가 발생하지 않음을 보증하기 위해 회귀 테스트 실시
상향식 통합 테스트
- 프로그램의 하위 모듈 -> 상위 모듈로 통합하면서 테스트한다.
- 하위 모듈에서 상위 모듈 방향으로 통합하면서 테스트 하는 방법
- 가장 하위 단계의 모듈부터 통합 및 테스트가 수행되므로 스텁은 필요하지 않다.
- 하나의 주요 제어 모듈과 관련된 종속 모듈의 그룹인 클러스터(cluster)는 필요하다.
절차
- 하위 모듈을 클러스터로 결합
- 상위 모듈에서 데이터 입출력을 확인하기 위해 모듈인 드라이버 작성
- 통합된 클러스터 단위로 테스트
- 테스트가 완료되면 클러스트는 프로그램 구조의 상위로 이동하여 결합하고, 드라이버는 실제 모듈로 대체한다.
하향식 설계
- 계츨 구조상에서 시스템의 주요 컴포넌트들을 찾고 그것을 낮은 수준의 컴포넌트들로 분해하는 것으로 단계적 정제라 하며 메인 모듈의 설계에서 시작하여 단계적으로 구체화시키는 것
- 통합 검사 시 인터페이스가 이미 정의되어 있어 통합이 간단하다.
- 레벨이 낮은 데이터 구조의 세부 사항은 설계초기 단계에서 필요하다.
- 시스템 명세가 명확한 경우와 모든 것을 새로 개발하는 작업에는 하햐익이 적합하다.
상향식 설계
- 가장 기본적인 컴포넌트를 먼저 설계한 다음 이것을 사용하는 상위 수준의 컴포넌트를 설계하는 것
- 상향식 설계는 최하위 수준에서 각각의 모듈들을 설계하고 이러한 모듈이 완성되면 이들을 결합하여 검사한다.
- 기존 컴포넌트들을 조합하여 시스템을 개발하는 경우에는 상향식이 적합하다.
인터페이스 방법 명세화
- 내 외부 시스템이 연계하여 작동할 때 인터페이스별 송수신 데이터, 오류 식별 및 처리 방안에 대한 내용을 문서화해놓은 것
시스템 연계 기술 : 개발할 시스템과 내외부 시스템을 연계할 때 사용되는 기술
- DB Link : DB에서 제공하는 DB Link 객체 이용
- API/Open API : 송신 시스템의 DB에서 데이터를 읽어 와 제공하는 Application Programming Interface 프로그램
- 연계 솔루션 : EAI 서버와 송수신 시스템에 설치되는 클라이언트 이용
- EAI : 송수신 데이터를 식별하기 위해 송수신 처리 및 진행 현황을 모니터링하고 통제하는 시스템
- Socket : 서버에서 소켓을 생성하여 클라이언트의 통신 요청 시 클라이언트와 연결하여 통신하는 네트워크 기술
통신을 위한 프로그램을 생성하여 포트를 할당하고, 클라이언트 통신 요청 시 클라이언트와 연결하는 내외부 송수신 연계기술
- Web Service : 웹 서비스에서 WSDL, UDDI, SOUP 프로토콜을 이용하여 연계하는 서비스
- 인터페이스 :
- 소프트웨어에 의해 간접적으로 제어되는 장치와 소프트웨어를 실행하는 하드웨어
- 기존의 소프트웨어와 새로운 소프트웨어를 연결하는 소프트웨어
- 순서적 연산에 의해 소프트웨어를 실행하는 절차
- 객체 :
- 상태, 동작, 고유 식별자를 가진 모든 것
- 필요한 자료 구조와 이에 수행되는 함수들을 가진 하나의 독립된 존재이다.
- 객체의 상태는 속성값에 의해 정의된다.
- 클래스 :
- 공통 속성을 공유하는 객체들의 집합
- 하나 이상의 유사한 객체들을 묶는다.
- 데이터를 추상화 하는 단위
- 인스턴스 :
- 같은 클래스에 속한 각각의 객체
- 메시지 :
- 객체들간에 상효작용을 하는데 사용되는 수단
- 메소드 :
- 객체 지향 시스템에서 전통적인 시스템의 함수 또는 프로시저에 해당하는 연산기능객체가 실행해야할 구체적 연산
- 캡슐화 :
- 서로 관련성이 많은 데이터들과 연산들을 묶는다.
- 속성과 관련된 연산을 클래스 안에 묶어서 하나로 취급하는 것을 의미하는 객체지향 개념.
- 컴포넌트 :
- 프로그래밍에 있어 재사용이 가능한 각각의 독립된 모듈
- 특정 기능 수행을 위해 독립적으로 분리
- 모델 :
- 향후 개발될 시스템을 유츄하기 위해 하는 활동으로, 주로 시스템 개발자가 실행한다.
- 개발 대상을 추상화하고 기호나 그림 등으로 시각적으로 표현한다.
- 모델을 통해 소프트웨어에 대한 이해도를 향상시킬 수 있다.
- 모델을 통해 이해 당사자 간의 의사소통이 향상된다.
- 분석 및 설계 단계(초반)에서 제작되지만 소프트웨어 개발의 전 과정에서 지속적으로 사용된다.
- 소프트웨어 상위 설계 : 아키텍처 설계 / 데이터 설계 / 시스템 분할 / 인터페이스 정의 / UI 설계
- 소프트웨어 하위 설계 : 모듈 설계 / 인터페이스 작성
- 협약에 의한 설계 :
- 클래스에 대한 여러 가정을 공유하도록 명세한 것
- 소프트웨어 컴포넌트에 대한 정확한 인터페이스 명세를 위하여 선행조건, 결과조건, 불변조건을 나타내는 설계방법
- 협약에 의한 설계의 세 가지 타입 :
- 선행조건 : 오퍼레이션이 호출되기 전에 참이 되어야 할 조건
- 결과조건 : 오퍼레이션이 수행된 후 만족하여야 하는 조건
- 불변조건 : 클래스 내부가 실행되는 동안 항상 만족하여야 하는 조건