티스토리 뷰
2022년 정보처리기사 필기
(수제비 2021년 필기책 보고 공부하며 요약한 내용입니다.)
1. 소프트웨어 설계
Cp1. 요구사항 확인2
1. 요구분석이란?
: 요구사항 상충을 해결하고 소프트웨어의 범위 파악해 외부환경과의 상호작용을 분석하는 과정
: 요구사항중 불명확하거나 이해되지 않는 부분 발견하고 이를 걸러내기 위한 과정
: 문서화를 통해 향후 유지보수에 유용하게 활용할 수 있음
: 구체적 명세 위해 소단위 명세서가 활용될 수 있음
*소단위 명세서: 데이터 흐름도에 있는 처리 항목을 소규모 분량으로 요약하여 작성하는 논리적 명세서
1-1. 요구사항 분석 단계
1) 요구사항 분류
: 요구사항이 기능인지 비기능인지 확인
: 요구사항이 소프트웨어에 미치는 영향 범위 파악
: 요구사항이 소프트웨어 생명주기 동안 변경이 발생하는지 확인
2) 개념모델링 생성 및 분석
: 현실세계를 단순화, 개념적으로 표현하여 모델을 만듦
(객체모델, 데이터모델, 유스케이스다이어그램, 데이터흐름모델, 상태모델, 목표기반모델, 사용자인터렉션 등)
3) 요구사항 할당
: 아키텍처 구성요소 식별
: 다른 구성요소와의 상호작용 분석으로 추가적인 요구사항 발견 가능
4) 요구사항 협상
: 우선순위 부여해 문제 요구사항 상충 문제해결
5) 정형 분석
: 형식적으로 정의된 언어로 요구사항을 표현
: 구문(syntax)과 의미(semantics)를 갖는 정형화된 언어 사용하여 수학적 기호로 표현
1-2. 요구사항 분석 기술
분석 기술 | 설명 |
청취 | 이해관계자로부터 의견 듣기 |
인터뷰와 질문 | 이해관계자를 만나 정보수집하고 이야기 나누기 |
분석 | 요구사항 충돌, 중복, 누락 분석 통해 완전성, 일관성 확보 |
중재 | 상반된 요구 중재 |
관찰 | 작업을 관찰하며 사용자가 언급하지 않은 미묘한 의미 탐지 |
작성 | 문서 작성 |
조직 | 수집된 정보를 일관성 있는 정보로 구조화하는 능력 |
모델 작성 | 수집된 정보를 바탕으로 제어흐름, 기능처리, 동작행위, 정보내용 등을 이해하기 쉽도록 모델로 작성 |
1-3. 요구사항 분석에 사용하는 기능 모델링 기법
1) 데이터 흐름도(DFD)
: 데이터가 각 프로세스를 따라 흐르면서 변환되는 모습을 나타냄
: 시스템 분석 및 설계에서 매우 유용하게 사용되는 다이어그램
: 시스템 모델링 도구로서 가장 보편적으로 사용됨
: 자료 흐름 그래프 또는 버블차트라고도 함.
: 구조적 분석 기법에 이용됨
: 제어의 흐름은 중요하지 않으며, 데이터의 흐름에 중심을 두는 분석용 도구임.
: 시간 흐름을 명확하게 표현할 수 없음
- 데이터흐름도 구성요소
구성요소 | 설명 |
처리기(프로세스) | 입력된 데이터를 원하는 형태로 변환하여 출력하기 위한 과정으로, DFD에서는 원(ㅇ)으로 표시 |
데이터흐름 | DFD 구성요소(프로세스, 데이터저장소, 외부엔터티)들 간 주고받는 데이터 흐름을 나타내며, DFD에서 화살표(->)로 표시 |
데이터 저장소 | 평생선(=)으로 표시. 평행선 안에는 데이터 저장소의 이름을 넣음 |
단말(terminator) | 프로세스 처리 과정에서 데이터가 발생하는 시작과 종료를 나타내고, 사각형으로 표시하며, 사각형 안에는 외부 엔터티의 이름을 넣음 |
2) 자료사전
: 자료요소, 자료요소들의 집합, 자료의 흐름, 자료 저장소의 의미, 관계 등을 구체적으로 명시하는 사전
: 파일 혹은 DB에 있는 자료에 대한 자료 또는 각 자료에 주어진 이름. 길이 등 포함하는 참조를 위한 작업임
: 용어의 정의를 조정하고 취합하고 문서로 명확히 하는 목적이 있음.
자료사전 기호 | 의미 |
= | 자료의 정의로서, '~으로 구성되어있다'를 나타냄 정의는 주석을 사용하여 의미를 기술하며, 자료 흐름과 자료저장소에 대한 구성내역을 설명하고, 자료 원소에 대해 값이나 단위를 나타냄 |
+ | 자료의 연결을 나타냄 |
() | 자료의 생략 가능함을 나타냄 |
{} | 자료의 반복을 나타냄 좌측에 최소반복횟수, 우측에 최대 반복횟수 기록 반복횟수 기록하지 않을 때는 디폴트로 최소0, 최대 무한대 |
[] | 자료의 선택을 나타냄 택일 기호 [ | ]는 |로 분리된 항목 중 하나가 선택됨 |
** | 자료의 설명(의미)을 나타냄 (주석) |
- 자료 사전 작성 원칙
(1) 자료 의미 기술
: 자료 의미는 주석을 통해 기술
: 자료 의미 기술 시 그 자료가 대상 시스템에서 사용되는 적합한 뜻을 표현해야 함
: 중복되는 기술을 회피하는 것은 간결하고 이해 쉬운 자료 사전을 작성하는 데 중요함
(2) 자료 구성항목의 기술
: 구성항목들을 그룹으로 묶음
: 각 그룹에 대해 의미 있는 이름을 부여
: 이름이 붙여진 각 그룹을 다시 정의
(3) 동의어 규정 준수
: 사용자마다 동일한 문서나 자료에 대해 서로 다른 이름을 갖고 있을 수 있으며,
사용자들의 용어를 통일 시키는 것 보다는 사용하는 용어를 이용하여 자료를 정의하는 것이 간단함
: 분석가가 자료를 하향식 분할하는 과정에서 부주의하게 동의어를 사용할 수 있음
(4) 자료 정의의 중복 제거
: 동일한 자료에 대해 여러 명의 분석가가 독립적으로 분석을 시행한다면,
서로 다른 이름을 사용할 수 있기 때문에 자료 정의 중복 제거 필요
2. UML (Unified Modeling Language)
: 객체지향 소프트웨어 개발 과정에서 산출물을 명세화, 시각화, 문서화할 때 사용되는 모델링 기술과 방법론을 통합해서 만든 표준화된 범용 모델링 언어.
: 방법론을 통합한 것으로, 표준화된 모델링 기법을 제공
UML의 특징 | 설명 |
가시화 언어 | 개념 모델 작성 시 오류가 적고 의사소통이 용이 |
구축 언어 | 다양한 프로그래밍언어로 실행 시스템의 예측 가능 UML을 소스코드로 변환하여 구축 가능, 역변환하여 역공학 가능 |
명세화 언어 | 정확한 모델 제시, 완전한 모델 작성 가능 |
문서화 언어 | 시스템에 대한 평가 및 의사소통의 문서 |
2-1. UML 구성요소
1) 사물(Things): 추상적 개념으로 주제를 나타내는 요소.
2) 관계(Relationships): 사물의 의미를 확장하고 명확히하는 요소. 사물과 사물을 연결하여 관계를 표현
3) 다이어그램: 사물과 관계를 모아 그림으로 표현하며, 형식과 목적에 따라 9가지로 정의.
2-2. UML 다이어그램
: 구분에 따라 구조적(정적) 다이어그램, 행위적(동적) 다이어그램으로 구분됨.
UML 다이어그램 구분 | 다이어그램 | 설명 |
구조적 다이어그램/정적 다이어그램 | 클래스 | 속성과 동작으로 구성 시스템 구조 파악하고 구조상 문제점 도출가능 |
객체 | 클래스에 속한 객체들, 즉 인스턴스를 특정 시점의 객체와 객체 사이의 관계로 표현 객체 인스턴스를 나타내는 대신 실제 클래스를 사용 연관된 모든 인스턴스를 표현 |
|
컴포넌트 | 코드 컴포넌트 기반의 물리적 구조 표현 실질적 프로그래밍 작업에 사용 |
|
배치(deployment) | 컴포넌트 사이의 종속성을 표현 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현 |
|
복합체 구조(composite structure) | 클래스, 컴포넌트가 복합구조를 갖는 경우 그 내부 구조를 표현 | |
패키지 | 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계를 표현 | |
행위적 다이어그램/동적 다이어그램 | 유스케이스 | 사용자 관점에서 시스템의 활동을 표현 시스템 기능적 요구 정의에 활용 |
시퀀스 | 객체 간 상호작용을 메시지 흐름으로 표현 객체사이 메시지를 보내는 시간을 표현 |
|
커뮤니케이션 | 시퀀스 다이어그램과 같이 동작에 참여하는 객체들이 주고 받는 메시지를 표현하는데, 메시지 뿐만 아니라 객체 간의 연관까지 표현 | |
상태(state) | 객체가 자신이 속한 클래스의 변화 혹은 타 객체와의 상호작용에 따른 상태변화를 표현. 모든 가능한 상태와 전이를 표현 진입조건, 탈출조건, 상태전이 등 기술 |
|
활동(activity) | 시스템이 어떤 기능을 수행하는지 객체의 처리로직, 조건처리흐름으로 순서대로 표현 활동의 순서대로 흐름을 표현 |
|
타이밍 | 객체 상태변화와 시간 제약을 명시적으로 표현 |
2-3. UML 상세
1) 클래스 다이어그램
객체지향 모델링 시 클래스의 속성 및 연산과 클래스 간 정적인 관계를 표현한 다이어그램
클래스이름 person |
속성 age: int |
연산 getAge: int |
구성요소: 클래스이름, 속성, 연산, 접근 제어자
*접근제어자: 클래스에 접근할 수 있는 정도를 표현
- : 클래스 내부접근만 허용(private)
+: 클래스 외부접근을 허용(public)
#: 동일 패키지, 파생 클래스에서 접근 가능(protected)
~: 동일 패키지 클래스에서 접근 가능(default)
2) 유스케이스 다이어그램
:시스템이 제공하는 있는 기능 및 관련 외부요소를 사용자 관점에서 표현
유스케이스 다이어그램 구성요소 | 설명 |
유스케이스 | 시스템이 재공하는 서비스 액터가 시스템을 통해 수행하는 행위 |
액터 | 사용자가 시스템에 대해 수행하는 역할 시스템과 상호작용하는 사람 또는 사물 |
시스템 | 전체 시스템의 영역을 표현 |
3) 시퀀스 다이어그램
: 객체 간 상호작용을 메시지 흐름으로 표현한 다이어그램
시퀀스 다이어그램 구성요소 | 설명 |
객체 | 객체 위쪽에 표시. 아래로 생명선을 가짐 |
생명선 | 객체로부터 뻗어나가는 점선 시간이 흐름에 따라 객체 생명주기 동안 발생하는 이벤트를 명시 |
실행 | 직사각형은 오퍼레이션(함수)이 실행되는 시간 직사각형이 길어질수록 수행시간이 긺 |
메시지 | 객체간 상호작용은 메시지 교환으로 이루어짐 한객체에서 다른 객체로의 메시지 전달하여 전달받은 객체의 오퍼레이션을 수행 |
- UML의 관계
: 사물과 사이 연관성 표현
: 연관관계, 집합관계, 포함관계, 일반화관계, 의존관계, 실체화 관계 등이 있음.
(1) 연관관계(association)
: 2개 이상의 사물이 서로 관련된 상태를 표현
: 사물 사이를 실선으로 연결하여 표현하며, 방향성은 화살표로 표현
: 서로 영향을 주는 양방향관계인 경우 화살표 생략하고 실선으로만 연결
(2) 집합관계(aggregation)
: 한 사물이 다른 사물에 포함된 관계 표현
: 포함한 부모쪽에 속이 빈 마름모를, 포함된 자식쪽으로 화살표를 연결하여 표현
(3) 포함관계(composition)
: 집합관계의 특수형태. 포함하는 사물의 변화가 포함되는 사물에 영향을 미침
: 포함한 부모쪽에 속이 채워진 마름모를, 포함된 자식쪽으로 화살표를 연결
(4) 일반화관계
: 한 사물이 다른 사물에 비해 더 일반적인지 구체적인지를 표현
: 일반적인 개념=부모(상위), 구체적인 개념=자식(하위). 자식에서 부모쪽으로 속이빈 화살표를 연결
(5) 의존관계
: 사물 사이 서로 연관은 있으나 필요에 따라 서로 영향 주는 짧은 시간동안만 연관을 유지하는 관계를 표현
: 사물 변화가 다른 서물에도 영향을 줌
: 영향을 주는 사물이 영향을 받는 사물 쪽으로 점선 화살표를 연결하여 표현
(6) 실체화관계(realization)
: 사물이 할수있거나, 해야하는 기능(행위, 인터페이스)으로 서로를 그룹화할 수 있는 관계를 표현
: 사물에서 기능 쪽으로 속이 빈 점선 화살표를 연결하여 표현
2-4. UML 확장 모델의 스테레오 타입
: UML의 기본 요소 이외 새로운 요소를 만들어 내기 위한 확장 메커니즘
: 형태는 기존 UML 요소를 그대로 사용하나, 내부 의미는 다른 목적으로 사용함.
: 스테레오 타입은 '<<>>' (길러멧) 기호를 사용하여 표현함
(1) <<include>> : 한 유스케이스가 어떤 시점에 반드시 다른 유스케이스를 실행하는 포함 관계
ex) 고객이 제품 주문시 --> 사용자를 확인
(2) <<extend>> : 한 유스케이스가 어떤 시점에 다른 유스케이스를 실행할수도, 안할수도 있는 확장 관계
ex) 고객이 제품 주문시 --> 고객 등록
(3) <<interface>> : 모든 메소드가 추상메소드이며, 바로 인스턴스를 만들지못함. 추상메소드와 상수로 구성된 클래스
(4) <<entity>> : 정보 또는 오래 지속되는 연관된 행위를 형상화하는 클래스로 유스케이스 처리 흐름이 수행되는 과정에서 기억 장치에 저장되어야 할 정보를 표현하는 클래스
(5) <<boundary>> : 시스템과 외부 액터와의 상호작용을 담당하는 클래스
(6) <<control>> : 시스템이 제공하는 기능의 로직 및 제어를 담당하는 클래스
3. 애자일(Agile) 방법론
: 소프트웨어 개발방법론의 하나로, 개발과 함께 즉시 피드백을 받아 유동적으로 개발하는 방법
: Discover -> Design -> Develop -> Test -> .... 연속
3-1. 애자일 방법론 등장 배경
: 기존 개발방법론의 한계 극복 위함
등장배경 | 설명 |
소프트웨어 개발 환경 변화 | 소프트웨어 개발 트렌드가 모바일 환경으로 변화 시장 적시성과 잦은 배포의 중요성 부각 |
기존 개발방법론의 한계 | 전통적 방법론은 문서와 절차 위주로, 변화에 신속한 대응이 어려움 빠르게 적용하고 효율적으로 개발할 수 있는 방법론의 필요성 증가 |
3-2. 애자일 방법론의 특징
: 요구사항은 기능 중심으로 정의함
: 절차와 도구보다 개인소통을 중요하게 생각함
: 작업 계획을 짧게 세워 요구 변화에 유연하고 신속하게 대응
: 소프트웨어가 잘 실행되는데에 가치를 둠
: 고객과의 피드백을 중요시 생각함
3-3. 애자일 방법론 유형
애자일 방법론의 유형 | 내용 |
XP (eXtreme Programming) | 의사소통 개선과 즉각 피드백으로 소프트웨어 품질을 높이기 위한 방법론 1~3주의 반복 개발 주기 5가지 가치와 12개의 실천항목이 존재 *XP 5가지 가치 1. 용기: 용기갖고 자신감있게 개발 2. 단순성: 필요한것만하고 그이상의 것은 하지 않음 3. 의사소통 4. 피드백: 의사소통에 대한 빠른 피드백 5. 존중: 팀원간 존중 *XP 12가지 기본원리 1. pair programming : 개발자 둘이서 짝으로 코딩 2. 공동코드소유(collective ownership) : 시스템에 있는 코드는 누구든지 언제라도 수정 가능 3. 지속적인통합(CI: continuous integration) : 매일 여러번씩 소프트웨어를 통합하고 빌드 4. 계획 세우기(planning process) : 고객이 요구하는 비즈니스 가치를 정의하고, 개발자가 필요한 것은 무엇이며 어떤 부분에서 지연될 수 있는지를 알려주어야 함 5. 작은릴리즈 : 작은 시스템을 먼저 만들고, 짧은 단위로 업데이트 6. 메타포어 : 공통적 이름 체계와 시스템 서술서를 통해 고객과 개발자 간 의사소통을 원할하게 함 7. 간단한 디자인 : 현재 요구사항에 적합한 가장 단순한 시스템을 설계 8. 테스트기반개발(TDD) : 테스트를 먼저 수행하고 통과할 수 있도록 코드작성 9. 리팩토링 : 프로그램 기능 안바꾸고, 중복제거, 단순화 등 시스템 재구성 10. 40시간 작업 : 피곤으로 실수하지 않도록 1주에 40시간 이상 일하지않음 11. 고객상주 : 개발자 질문에 즉각 대답하는 고객을 풀타임으로 상주 12. 코드표준 : 효과적인 공동작업 위해 모든 코드에 대한 코딩 표준을 정의 |
스크럼(SCRUM) | 매일 정해진 시간, 같은 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론 *주요 개념 1. 백로그: 제품과 프로젝트에 대한 요구사항 2. 스프린트: 2~4주의 짧은 개발 기간으로 반복수행으로 개발품질 향상 3. 스크럼 미팅: 매일 15분 정도 미팅으로 투두리스트 계획수립 = 데일리미팅 4. 스크럼마스터: 프로젝트 리더, 스크럼 수행 시 문제 인지 및 해결자 5. 스프린트 회고(retrospective): 스프린트 주기를 되돌아보며 규칙 준수 여부, 개선점 등 확인 및 기록. 6. 번다운 차트: 백로그 대비 시간을 그래픽적으로 표현 보통 수직축에 위치하며 시간은 수평축에 위치 |
린(LEAN) | 도요타의 린 시스템 품질기법을 소프트웨어 개발 프로세스에 적용해서 낭비요소를 제거하여 품질을 향상시킨 방법론 JIT(just in time), 칸반 보드 사용 *7가지 원칙 1. 낭비제거 2. 품질 내재화 3. 지식 창출 4. 늦은 확정 5. 빠른 인도 6. 사람 존중 7. 전체 최적화 |
3-4. 애자일과 전통적 방법론 비교
비교 대상 | 애자일 방법론 | 전통적 방법론 |
계획수립 | 유동적 범위 설정 | 확정적 범위 설정 |
업무수행 | 팀 중심 | 관리자 주도적 명령과 통제 개인 단위로 업무 수행 |
개발/검증 | 반복 주기 단위로 SW 개발, 검증 | 분석/설계/구현/테스트를 순차적 수행 |
팀관리 | 업무 몰입, 팀 평가 | 경쟁, 개별 평가 |
문서화 | 문서화보다 코드 강조 | 상세한 문서화 강조 |
성공요소 | 고객 가치 전달 | 계획/일정 준수 |
유형 | XP, 스크럼, 린 | 폭포수, 프로토타입, 나선형 |
'도구 > Etc' 카테고리의 다른 글
[2022년 정보처리기사 필기] 1. 소프트웨어설계: Cp2. 화면 설계 (0) | 2022.01.14 |
---|---|
[2022년 정보처리기사 필기] 1. 소프트웨어설계: Cp1. 요구사항 확인3 (0) | 2022.01.13 |
[2022년 정보처리기사 필기] 1. 소프트웨어설계: Cp1. 요구사항확인 (0) | 2022.01.10 |
[정규표현식] 정규식으로 데이터가 개인정보인지 알아내는 방법 (0) | 2021.10.26 |
[Wireshark] PC에서 Mobile(모바일) 패킷 캡쳐 방법(Windows10) (0) | 2021.10.15 |