정보처리기사) 1과목 정리 ( 2 / 4 )

자료 사전 기호

{ }

- 자료의 반복을 나타냄

 

**

- 자료의 설명을 나타냄

- 주석

 

=

- 자료의 정의로서 '~으로 구성되어(is Composed of) 있다' 는 것을 나타냄

 

( )

- 자료 생략 가능함을 나타냄

 

+

- 자료의 연결(and, along, with)을 나타내는 기호

 

[ ]

- 자료의 선택을 나타내는 기호

---

DFD(Data Flow Diagram)

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

- 구조적 분석 기법에 이용됌

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

 

 

데이터 흐름도(DFD)의 구성 요소

처리기(Process)

- 입력된 데이터를 원하는 형태로 변환하여 출력하기 위한 요소

표기법 = 원 ( ○ )

 

데이터 흐름(Data Flow)

- DFD의 구성 요소(프로세스, 데이터 저장소, 외부 엔터티)들 간의 주고받는 데이터 흐름을 나타내는 요소

표기법 = 화살표 ( → )

 

데이터 저장소(Data Store)

- 데이터가 저장된 장소를 나타내는 요소

- 평행선 안에는 데이터 저장소의 이름을 넣음

표기법 = 평행선 ( = )

 

단말(Terminator)

- 프로세스 처리 과정에서 데이터가 발생하는 시작과 종료를 나타내는 요소

- 사각형 안에는 외부 엔터티의 이름을 넣음

표기법 = 사각형 ( □ )

---

UML(Unified Modelng Language)

- 기능적 모델은 사용자 측면에서 본 시스템 기능이며, UML에서는 Use Case Diagram을 사용한다.

- 정적모델은 객체, 속성, 연관 관계, 오퍼레이션의 시스템 구조를 나타내며, UML에서는 Class Diagram을 사용한다.

- 동적 모델은 시스템의 내부 동작을 말하며, UML에서는 Sequence Diagram, State Diagram, Activity Diagram을 사용한다.

- Sequence Diagram은 객체들 사이의 메시지 교환을 나타내며, State Diagram은 하나의 객체가 가진 상태와 그 상태의 변화에 의한 동작 순서를 나타낸다.

 

기본 구성 요소

사물

- Things

- 추상적인 개념으로 주제를 나타내는 요소

- 단어 관점에서 명사 또는 동사를 의미

관계

- Relationships

- 사물의 의미를 확장하고 명확히 하는 요소

- 사물과 사물을 연결하여 관계를 표현하는 요소

- 단어 관점에서 '형용사' 또는 '부사'를 의미

다이어그램

- Diagrams

- 사물과 관계를 모아 그림으로 표현한 형태

- 형식과 목적에 따라 9가지로 정의

 

 

확장 모델

<< >>

- 스테레오 타입

- 길러멧(Guillemet) 기호를 사용하여 표현

---

구조적 다이어그램 (Structural Diagram)

클래스

- Class Diagram

- 시스템 내 클래스의 정적 구조를 표현

- 속성(Attribute)과 동작(Behavior)으로 구성

- 시스템의 구조를 파악하고 구조상의 문제점 도출 가능

- 클래스와 클래스, 클래스의 속성 사이의 관계를 표현

구성요소

클래스 이름

- Class Name

- 클래스의 이름을 명시

 

속성

- Attribute

- 클래스의 특징에 이름을 부여

 

연산

- Operation 

- 클래스에 속하는 객체에 적용될 메서드를 정의

- 클래스의 동작을 의미하며 , UML에서는 동작에 대한 인터페이스를 지칭

 

접근 제어자

- Access Modifier 

- 클래스에 접근할 수 있는 정도를 표현

- priavate, public, protected, default

 

객체

- Object Diagram

- 클래스에 속한 사물(객체)들, 즉 인스턴스(Instance)를 특정 시점의 객체와 객체 사이의 관계로 표현

- 객체인스턴스를 나타내는 대신 실제 클래스를 사용

- 연관된 모든 인스턴스를 표현

 

컴포넌트

- Component Diagram

- 코드 컴포넌트 기반의 물리적 구조 표현

- 실질적 프로그래밍 작업에 사용

 

배치

- Deployment Diagram

- 컴포넌트 사이의 종속성을 표현

- 결과물, 프로세서, 컴포넌트 등 물리적 요소들의 위치를 표현

 

복합체 구조

- Composite Structure Diagram

- 클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현

 

패키지

- Package Diagram

- 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계를 표현

---

행위적 다이어그램(Behavioral Diagram)

유스케이스

- Use Case Diagram

- 사용자 관점에서 시스템의 활동을 표현

- 유스케이스는 시스템의 기능적 요구 정의에 활용

구성 요소

유스케이스

- 시스템이 제종해야 하는 서비스

- 액터가 시스템을 통해 수행하는 일련의 행위

액터

- 사용자가 시스템에 대해 수행하는 역할

- 시스템과 상호 작용하는 사람 또는 사물

시스템

- 전체 시스템의 영역을 표현

 

시퀀스

- Sequence Diagram

- 객체 간 상호 작용을 메시지 흐름으로 표현

- 객체 사이 메시지를 보내는 시간을 표현

- 교류 다이어그램(Interaction Diagram)의 한 종류로 볼 수 있음

- 동적 다이어그램으로 구분

- 시간의 흐름에 따라 객체들이 주고받는 메시지의 전달 과정을 강조한

 

커뮤니케이션

- Communication Diagram

- 시퀀스 다이어그램과 같이 동작에 참여하는 객체들이 주고 받는 메시지를 표현하는데, 메시지뿐만 아니라 객체 간의 연관까지 표현

 

상태

- State Diagram

- 하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호 작용에 따라 상태가 어떻게 변화하는지 표현

- 모든 가능한 상태와 전이를 표현

- 진입 조건, 탈출 조건, 상태 전이 등 기술

 

활동

- Activity Diagram

- 시스템이 어떤 기능을 수행하는지를 객체의 처리 로직이나 조건에 따른 처리의 흐름으로 순서대로 표현

- 활동의 순서대로 흐름을 표현

 

타이밍

- Timing Diagram

- 객체 상태 변화와 시간 제약을 명시적으로 표현

---

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

Data flow Diagram(DFD)

- 데이터가 각 프로세를 따라 흐르면서 변환되는 모습을 표현하는 방식

 

UML Diagram

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

 

E-R Diagram

- 객체 타입과 관계 타입을 기본 개념으로 현실 세계를 개념적으로 표현하는 방식

---

XP의 12가지 기본 원리

- 짝 프로그래밍(Pair Programming)

- 공동 코드 소유(Collective Ownership)

- 지속적인 통합(CI; Continuous Integration)

- 계획 세우기(Planning Process)

- 작은 릴리즈(Small Release)

- 메타포어(Metaphor)

- 간단한 디자인(Simple Design)

- 테스트 기반 개발(TDD; Test Driven Development)

- 리팩토링(Refactoring)

- 40시간 작업(40-Hour Work)

- 고객 상주(On Site Customer)

- 코드 표준(Coding Standard)

---

XP의 5가지 가치

용기

- Courage

- 용기를 가지고 자신감 있게 개발

(코드를 작성하기 전에 테스트, 빠르게 피드백, 테스트에 부합하지 못하는 코드를 리팩토링 할 수 있는 용기)

 

단순성

- Simplicity

- 필요한 것만 하고 그 이상의 것들은 하지 않음

 

의사소통

- Communication

- 개발자, 관리자, 고객 간의 원활한 소통

 

피드백

- Feedback

- 의사소통에 대한 빠른 피드백

 

존중

- Respect

- 팀원 간의 상호 존중

---

애자일 방법론 특징

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

- 작업 계획을 짧게 세워 요구 변화에 유연하고 신속하게 대응할 수 있다.

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

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

- 포괄적인 문서보다 동작하는 소프트웨어에 중점을 둔 방법론이다.

- 개발 기법은 이해하기 좋은 문서보다는 실제 작동하는 소프트웨어에 더 가치를 둔다

- 애자일 선언문은 애자일 방법론을 실천하기 위한 주요 원칙이다.

 

- 기능 중심 개발

- 스크럼

- 익스트림 프로그래밍

 

애자일 선언문

- 개인과 상호 작용

- 변화에 대응

- 동작하는 소프트웨어

- 고객과 협력