데이터베이스 종류 ⭐⭐⭐

데이터베이스

1. 데이터베이스 개념

- 다수의 인원, 시스템 또는 프로그램이 사용할 목적으로 통합하여 관리되는 데이터의 집합

- 데이터에 대한 효과적인 관리를 위해 자료의 중복성 제거, 무결성 확보, 일관성 유지, 유용성 보장이 중요

- 데이터베이스 정의

정의 설명
통합된 데이터 (Integrated Data) 자료의 중복을 배재한 데이터의 모임
저장된 데이터 (Stored Data) 저장 매체에 저장된 데이터
운영 데이터 (Operational Data) 조직의 업무를 수행하는 데 필요한 데이터
공용 데이터 (Shared Data) 여러 어플리케이션, 시스템들이 공동으로 사용하는 데이터

 

2. 데이터베이스 특성

특성 설명
실시간 접근성 (Real-Time Accessibility) 쿼리에 대하여 실시간 응답이 가능해야 함
계속적인 변화 (Continuous Evolution) 새로운 데이터의 삽입, 삭제, 갱신으로 항상 최신의 데이터를 유지함
동시 공용 (Concurrent Sharing) 다수의 사용자가 동시에 같은 내용의 데이터를 이용할 수 있어야 함
내용 참조 (Content Reference) 데이터베이스에 있는 데이터를 참조할 때 데이터 레코드의 주소나 위치에 의해서가 아니라, 사용자가 요구하는 데이터 내용으로 데이터를 찾는다.

 

3. 데이터베이스 종류

① 파일 시스템 개념

- 파일에 이름을 부여하고 저장이나 검색을 위하여 논리적으로 그것들을 어디에 위치시켜야 하는지 등을 정의한 뒤 관리하는 데이터베이스 전 단계의 데이터 관리방식

- 종류

종류 개념
ISAM · Index Sequential Access Method
· 자료 내용은 주 저장부, 자료의 색인은 자료가 기록된 위치와 함께 색인부에 기록되는 시스템
VSAM · Virtual Storage Access Method
· 대형 운영체제에서 사용되는 파일 관리시스템

 

② 관계형 데이터베이스 관리시스템 (RDBMS : Relational Database Management System)

- 관계형 DBMS는 관계형 모델을 기반으로 하는 가장 보편화된 데이터베이스 관리시스템

- 데이터를 저장하는 테이블의 일부를 다른 테이블과 상하 관계로 표시하며 상관관계를 정리

- 변화하는 업무나 데이터 구조에 대한 유연성이 좋아 유지 관리가 용이

- 종류 : Oracle, SQL Server, MySQL, Maria DB 등..

 

③ 계층형 데이터베이스 관리시스템 (HDBMS : Hierarchical Database Management System)

- 데이터를 상하 종속적인 관계로 계층화하여 관리하는 데이터베이스

- 데이터에 대한 접근 속도가 빠르지만, 종속적인 구조로 인하여 변화하는 데이터 구조에 유연하게 대응하기가 쉽지 않다.

- 종류 : IMS, System2000 등..

 

④ 네트워크 데이터베이스 관리시스템 (NDBMS : Network Database Management System)

- 데이터의 구조를 네이트워상의 망상 형태로 표현한 데이터 모델

- 트리 구조나 계층형 데이터베이스보다는 유연하지만 설계가 복잡한 단점이 있다.

- 종류 : IDS, IDMS 등..

 

3. 데이터베이스 관리 툴

- DB 관리자(DBA)들이 데이터 베이스를 편리하고 쉽게 다룰 수 있도록 도와주는 도구

- 오픈 소스 기반으로 무료로 사용할 수 있는 툴과 상용화로 비용을 지불해야 사용할 수 있는 툴이 존재

- 기능

기능 설명
데이터베이스 생성, 삭제 CREATE와 DROP 명령을 통해 데이터베이스 생성 및 삭제 기능
SQL 명령어 작성 및 실행 SELECT, INSERT, UPDATE, DELETE 명령을 통해 데이터를 조회, 입력, 수정, 삭제가 가능
상태 모니터링 받은 데이터양, 보낸 데이터양, 동시 연결 수, 실패한 시도 등의 상태 표시
사용자 계정 관리 최상위 레벨의 SYS 계정, SYS로부터 DBA 권한을 받은 SYSTEM 계정, 일반 사용자 계정 등의 관리가 가능
데이터베이스 내보내기 / 가져오기 데이터베이스 마법사를 통해 파일형태로 데이터 내보내기 / 가져오기 가능
환경설정 버퍼의 크기, 동시 접속 클라이언트 숫자, 스레드 숫자 등의 환경변수 설정

 

 

DBMS

1. DBMS 개념

- 데이터 관리의 복잡성을 해결하는 동시에 데이터 추가, 변경, 검색, 삭제 및 백업, 복구, 보안 등의 기능을 지원하는 소프트웨어

- 저장되는 정보는 텍스트, 이미지, 음악 파일, 지도 데이터 등 매우 다양하며, SNS의 발달과 빅데이터의 폭넓은 활용으로 인해 데이터의 종류와 양은 급격히 증가 중이다.

 

2. DBMS 유형

유형 설명
키 - 값 DBMS · 키 기반 Get / Put / Delete 제공, 메모리 기반에서 성능 우선 시스템 및 빅데이터 처리 가능 DBMS
· Unique 한 키에 하나의 값을 가지고 있는 형태
· 예) Redis, DynamoDB
컬럼 기반 데이터 저장 DBMS · Key 안에 (Column, Value) 조합으로 된 여러 개의 필드를 갖는 DBMS
· 데이블 기반, 조인 미지원, 컬럼 기반으로 구글의 Bigtable 기반으로 구현
· 예) HBase, Cassandra
문서 저장 DBMS · 값의 데이터 타입이 문서라는 타입을 사용하는 DBMS
· 문서 타입은 XML, JSON과 같은 구조화된 데이터 타입으로, 복잡한 계층 구조 표현 가능
· 예) MongoDB, Couchbase
그래프 DBMS · 시맨틱 웹과 온톨로지 분야에서 활용되는 그래프로 데이터를 표현하는 DBMS
· 노드와 엣지로 특징되는 요소 특화, 노드 간 관계를 구조화하여 저장
· 예) Neo4j, AllegroGraph

 

3. DBMS 특징

특징 설명
데이터 무결성 부적절한 자료가 입력되어 동일한 내용에 대하여 서로 다른 데이터가 저장되는 것을 허용하지 않는 설징
데이터 일관성 삽입, 삭제, 갱신, 생성 후에도 저장된 데이터가 변함없이 일정
데이터 회복성 장애가 발생하였을 시 특정 상태로 복구되어야 하는 설징
데이터 보안성 불법적인 노출, 변경, 손실로부터 보호되어야 하는 설징
데이터 효율성 응답 시간, 저장 공간 활용 등이 최적화되어 사용자, 소프트웨어, 시스템 등의 요구 조건을 만족시켜야하는 성질

 

4. 상용 DBMS 및 오픈 소스 기반 DBMS

① 상용 DBMS

- 상용 데이터베이스 관리시스템은 특정 회사에서 유료로 판매하는 시스템이다.

- 유지보수와 지원이 원활하다.

 

② 오픈 소스 기반 DBMS

- 오픈 소스 기반 데이터베이스 시스템은 오픈 소스 라이선스 정책을 준용하는 범위 내에서 사용이 자유롭다.

- 오픈 소스 기반 데이터베이스 관리 시스템 사용 시 고려 사항

· 기업들의 원가 절감 노력과의 상관관계 파악한다.
· 인공 지능, 클라우드, 빅데이터 등 새로운 기술의 증가에 따른 오픈 소스 데이터베이스 관리시스템의 대응 동향을 분석한다.
· 오픈 소스 진영에서 보안, 안정성에 대한 우려를 해결하고자 노력하는지를 조사한다.
· 정책적으로 오픈 소스 데이터베이스 관리시스템 활성화를 추진하는 사례를 정리한다.

 

 

데이터베이스 기술 트렌드

1. 빅데이터

① 빅데이터 개념 : 시스템, 서비스, 조직(회사) 등에서 주어진 비용, 시간 내에 처리가능한 데이터 범위를 넘어서는 수십 페타바이트 크기의 비정형 데이터이다.

 

② 빅데이터 특성

특성 설명
데이터의 양
(Volume)		 · 페타바이드 수준의 대규모 데이터
· 빅데이터 분석 규모에 관련된 특성
· 디지털 정보량이 기하급수적으로 폭증하는 것을 의미
데이터의 다양성
(Variety)		 · 정형, 비정형, 반정형의 다양한 데이터
· 빅데이터 자원 유형에 관련된 특성
· 로그, 소셜, 위치 등 데이터 유형이 다양해지는 것을 의미
데이터의 속도
(Velocity)		 · 빠르게 증가하고 수집되며, 처리되는 데이터
· 빅데이터 수집, 분석, 활용 속도와 관련된 특성
· 가치 있는 정보 활용을 위해 실시간 분석이 중요해지는 것을 의미

 

③ 빅데이터 수집, 저장, 처리 기술

구분 설명
비정형/반정형 데이터 수집 내, 외부 정제되지 않은 데이터를 확보, 이를 통해 필요 정보를 추출하여 활용하기 위해서 효과적으로 수집 및 전송하는 기술
예) 척와(Chukwa), 플럼(Flume), 스크라이브(Scribe)
정형 데이터 수집 내, 외부 정제된 대용량 데이터의 수집 및 전송 기술
예) ETL, FTP, 스쿱(Sqoop), 하이호(Hiho)
분산데이터 저장/ 처리 대용량 파일의 효과적인 분산 저장 및 분산 처리 기술
예) HDFS, 맵 리듀스
분산데이터 베이스 HDFS의 컬럼 기반 데이터베이스로 실시간 랜덤 조회 및 업데이트가 가능한 기술
예) HBase

* HDFS : 대용량 데이터의 집합을 처리하는 응용 프로그램에 적합하도록 설계된 하둡 분산 파일 시스템

* 맵 리듀스 : 구글에서 대용량 데이터 처리를 분산 병렬 컴퓨팅에서 처리하기 위한 목적으로 제작하여 2004년에 발표한 소프트 프레임워크

 

④ 빅데이터 분석, 실시간 처리 및 시각화를 위한 주요 기술

구분 설명
빅데이터 분석 · 빅데이터를 분석하기 위한 데이터의 가공과 분류, 클러스터링, 패턴 분석을 처리하는 기술
· 데이터 가공을 위한 대표적인 솔루션에는 피그, 하이브가 있고, 데이터 마이닝을 위한 대표적인 솔루션에는 머하웃이 있음
빅데이터 실시간 처리 · 하둡 기반의 실시간 SQL 질의 처리와 요청된 작업을 최적화하기 위한 워크플로우 관리 기술
· 실시간 SQL 질의를 위한 대표적인 솔루션은 임팔라이고, 워크플로우 관리를 ㅜ이한 대표적인 솔루션은 우지가 있음
분산 코디네이션 · 분산 환경에서 서버들 간에 상호조정이 필요한 다양한 서비스를 분산 및 동시처리 제공 기술
· 분산 코디네이션을 위한 대표적인 솔루션은 주키퍼가 있음
분석 및 시각화 · 빅데이터 분석 기술을 통해 분석된 데이터의 의미와 가치를 시각적으로 표현하기 위한 기술
· 분석 및 시각화를 위한 대표적인 솔루션은 알이 있음

 

2. NoSQL(Not Only SQL)

① NoSQL의 개념 : 전통적인 RDBMS와 다른 DBMS를 지칭하기 위한 용어로 데이터 저장에 고정된 테이블 스키마가 필요하지 않고 조인 연산을 사용할 수 없으며, 수평적으로 확장이 가능한 DBMS이다.

 

② No SQL의 특성

특성 설명
Basically Available · 언제든지 데이터는 접근할 수 있어야 하는 속성
· 분산 시스템이기 때문에 항상 가용성 중시
Soft-State · 노드의 상태는 내부에 포함된 정보에 의해 결정되는 것이 아니라 외부에서 전송된 정보를 통해 결정되는 속성
· 특정 시점에서는 데이터의 일관성이 보장되지 않음
Eventually Consistency · 일정 시간이 지나면 데이터의 일관성이 유지되는 속성
· 일관성을 중시하고 지향

 

③  DBMS 유형

유형 설명
Key-Value Store · 키 기반 Get / Put / Delete 제공하는 빅데이터 처리 가능 DB
· Unique 한 Key에 하나의 Value을 가지고 있는 형태
· 예) Redis, DynamoDB
Column Family Data Store · Key 안에 (Column, Value) 조합으로 된 여러 개의 필드를 갖는 DB
· 데이블 기반, 조인 미지원, 컬럼 기반으로 구글의 Bigtable 기반으로 구현
· 예) HBase, Cassandra
Document Store · Value의 데이터 타입이 Document라는 타입을 사용하는 DB
· 문서 타입은 XML, JSON, YAML과 같은 구조화된 데이터 타입으로, 복잡한 계층 구조 표현 할 수 있음
· 예) MongoDB, Couchbase
Graph Store · 시맨틱 웹과 온톨로지 분야에서 활용되는 그래프로 데이터를 표현하는 DB
· 예) Neo4j, AllegroGraph

* 온톨로지 : 실세계에 존재하는 모든 개념과 개념들의 속성, 그리고 개념 간의 관계 정보를 컴퓨터가 이해할 수 있도록 서술해 놓은 지식 베이스

 

3. 데이터 마이닝

① 데이터 마이닝 개념

· 대규모로 저장된 데이터 안에서 체계적이고 자동적으로 통계적 규칙이나 패턴을 찾아내는 기술이다.

· 데이터 마이닝은 대규모 데이터에서 의미 있는 패턴을 파악하거나 예측하여 의사결정에 활용하는 기법이다.

· 데이터 마이닝은 데이터의 숨겨진 정보를 찾아내어 이를 기반으로 서비스와 제품에 도입하는 과정이다.

· 통계분석은 가설이나 가정에 따른 분석, 검증을 하지만 데이터 마이닝은 수리 알고리즘을 활용하여 대규모 데이터에서 의미 있는 정보를 찾아낸다.

 

② 데이터 마이닝 절차

단계 절차 설명
1단계 목적 설정 · 데이터 마이닝을 통해 얻고자 하는 명확한 목적 설정
· 목적에 따라 사용할 모델과 필요 데이터 정의
2단계 데이터 준비 · 거래정보, 웹로그 데이터, 고객 정보, 데이터 사용량, 소셜 데이터 등 다양한 데이터 활용
· 사전에 운영 데이터 접근에 따른 부하 고려
· 필요시 작업 서버에 저장하여 운영에 지장이 없도록 데이터 준비
· 데이터 정제를 통해 데이터의 품질을 보장하고, 필요시 데이터 추가 등을 통해 충분한 양의 데이터 확보
3단계 가공 · 모델링 목적에 따라 목적 변수 정의
· 필요한 데이터를 데이터 마이닝 소프트웨어에 적용할 수 있는 형식으로 가공 처리
4단계 마이닝 기법 적용 · 1단계의 명확한 목적에 맞도록 데이터 마이닝 기법을 적용하여 정보 추출
5단계 정보 검증 · 데이터 마이닝으로 추출된 정보 검증
· 테스트 데이터와 과거 데이터를 활용하여 최적의 모델 선정
· 데이터 마이닝 결과의 업무 적용 보고서 작성 및 활용

 

③ 데이터 마이닝 주요 기법 :  텍스트 마이닝, 웹 마이닝과 함께 다양한 분양에서 활용되고 있다.

* 텍스트 마이닝 : 대량의 텍스트 데이터로부터 패턴 또는 관계를 추출하여 의미 있는 정보를 찾아내는 기법

* 웹 마이닝 : 웹으로부터 얻어지는 방대한 양의 정보로부터 유용한 정보를 찾아내기 위하여 분석하는 기법

주요 기법 설명
분류 규칙 · 과거 데이터로부터 특성을 찾아내어 분류모형을 만들어 이를 토대로 새로운 레코드의 결과 값을 예측하는 기법
· 마케팅, 고객 신용평가 모형에 활용
예) 우수 고객의 분류 모형 구축으로 마케팅 활용
연관 규칙 · 데이터 안에 존재하는 항목들 간의 종속관계를 찾아내는 기법
· 제품이나 서비스의 교차판매, 매장 진열, 사기 적발 등 다양한 분야에서 활용
예) 넥타이 구매고객의 50% 이상이 셔츠를 구매한다는 정보 분석을 통해 매장의 상품 진열
연속 규칙 · 연관 규칙에 시간 관련 정보가 포함된 형태의 기법
· 개인별 트랜잭션 이력 데이터를 시계열적으로 분석하여 트랜잭션의 향후 발생 가능성 예측
예) A품목을 구매한 회원이 B품목을 구매할 확률은 75%
데이터 군집화 · 대상 레코드들을 유사한 특성을 지닌 몇 개의 소그룹으로 분할하는 작업으로 작업의 특성이 분류규칙과 유사
· 정보가 없는 상태에서 데이터를 분류하는 기법
· 분석대상에 결괏값이 없으며, 판촉활동이나 이벤트 대상을 선정하는 데 활용
예) 고객의 지역/연령/성별에 따른 차별화 홍보전략

 

TEST  →  정답은 드래그!

정답 종류
DBMS 데이터베이스라는 데이터의 집합을 만들고, 저장 및 관리 할 수 있는 기능들을 제공하는 응용 프로그램이다. 

 

 

 

 

※ 해당 글은 수제비 2022 도서 참고하였습니다.

 

수제비- IT 커뮤니티 (정보처리기사... : 네이버 카페

수제비-수험생 입장에서 제대로 쓴 비법서(정보처리기사, 정보처리기능사, 빅데이터 분석기사 등 시리즈)

cafe.naver.com

 

'정보처리기사' 카테고리의 다른 글

Ⅲ 데이터 입출력 구현 - 물리 데이터 저장소 설계  (0) 2023.02.20
Ⅲ 데이터 입출력 구현 - 논리 데이터 저장소 확인  (2) 2023.02.02
Ⅱ 화면설계 - UI 설계  (1) 2023.01.31
Ⅱ 화면설계 - UI 요구사항 확인  (0) 2023.01.30
[2023] 정보처리기사 시험 일정  (0) 2023.01.05

물리 데이터 모델 설계 ⭐⭐⭐

물리 데이터 모델링 개념

· 논리모델을 적용하고자 하는 기술에 맞도록 상세화해가는 과정

· 예시 : DDL을 이용해 데이터 모델 정의

CREATE TABLE TEST(
	t_id		INT PRIMARY KEY,
    td_id		INT REFERENCES TEST_DETAIL(td_id),
    t_name		VARCHAR(20),
    reg_date	DATETIME
);

CREATE TABLE TEST_DETAIL(
	td_id		INT PRIMARY KEY,
    td_contents	VARCHAR(1000),
    stert_date	DATETIME,
    end_date	DATETIME,
    reg_date	DATETIME,
    udt_date	DATETIME
);

 

 

물리 데이터 모델링 변환 절차

순서 절차 변환방법
1 개체를 테이블로 변환 · 일반적으로 테이블명과 개체명을 동일하게 하는 것을 권고
· 개체는 한글명을 사용
· 테이블은 코드 가독성을 위해 영문명을 사용
2 속성을 컬럼으로 변환 · 개발자와 사용자 간 표준화된 약어를 사용하도록 권고
· SQL 예약어 사용은 피해야함
· SQL 문장 가독성을 높이기 위해 컬럼 명칭은 되도록 짧은 것을 권고
· 컬럼명으로 복합단어를 사용 할 경우 미리 정의된 표준에 의해 명명
3 UID를 기본키로 변환 · 개체의 UID에 해당하는 모든 속성에 대해 기본키로 선언
· Not Null, Unique등의 제약 조건을 추가로 정의
· 관계에 의한 외래키가 기본키에 포함될 수 있음
4 관계를 외래키로 변환 · 외래키명은 기본키 이름 그대로 사용하나 다른 의미를 가질 경우 변경 가능
· 순환 관계에서 자신의 기본키는 외래키로 정의
5 컬럼 유형과 길이 정의 · 적절한 유형을 정의하고, 데이터의 최대길이를 파악하여 길이를 설정
데이터 유형 설명
CHAR2 최대 2000바이트의 고정길이 문자열 저장 가능
VARCHAR2 최대 4000바이트의 가변길이 문자열 저장 가능
NUMBER 38 자릿수의 숫자 저장 가능
DATE 날짜 값을 저장
BLOB, CLOB 바이너리(Binary), 텍스트 데이터 최대 4gb까지 저장
6 반 정규화 수행 · 시스템 성능 향상과 개발 및 운영의 단순화를 위해 데이터 모델을 통합
* 상세 설명 : https://chlee21.tistory.com/214

 

 

물리 데이터 저장소 구성 ⭐

: 물리 데이이터 저장소 구성을 위해 DBMS를 선정한 이후의 활동으로 구성된다.

 

테이블 제약조건(Constraint) 설계

1. 참조무결성 제약조건

- 릴레이션과 릴레이션 사이에 대해 참조의 일관성을 보장하기 위한 조건

- 두 개의 릴레이션이 기본키, 외래키를 통해 참조 관계를 형성할 경우, 참조하는 외래키의 값은 항상 참조되는 릴레이션의 기본키로 존재한다.

내용 설명
제한(Restricted) · 참조무결성 원칙을 위배하는 연산을 거절하는 옵션
· 예 : 참조되는 릴레이션의 튜플을 삭제하면 삭제 연산을 수행하지 않고 거절
연쇄(Casecade) · 참조되는 릴레이션에서 튜플을 삭제하고, 참조되는 릴레이션에서 이 튜플을 참조하는 튜플들도 함께 삭제하는 옵션
널 값(Nullify) · 참조되는 릴레이션에서 튜플을 삭제하고, 참조되는 릴레이션에서 NULL 값을 넣는 옵션
· 만일 릴레이션을 정의할 때 참조하는 릴레이션에서 NULL 값이 들어갈 애트리뷰트에 'NOT NULL'이라고 명시되어 있다면 삭제 연산을 거절한다.

- 참조 무결성 제약 조건 SQL 문법(삭제시)

ALTER TABLE 테이블 ADD
FOREIGN KEY (외래키)
REFERENCES 참조테이블(기본키)
ON DELETE [ RESTRICT | CASCADE | SET NULL ];

 

 

인덱스(Index) 설계

1. 인덱스 개념

- 검색 연산의 최적화를 위해 데이터베이스 내 열에 대한 정보를 구성한 데이터구조이다.

- 인덱스를 통해 전체 데이터의 검색 없이 필요한 정보에 대해 신속한 조회가 가능하다

 

2. 인덱스 적용 기준

- 인덱스 분포도가 10~15% 이내인 경우 아래 수식을 참고한다.

· 분포도 = (1 / (컬럼 값의 종류)) × 100
· 분포도 = (컬럼 값의 평균 Row 수) / (테이블의 총 Row 수)  × 100

- 분포도가 번위 이상이더라도 부분처리를 목적으로 하는 경우 적용한다.

- 조회 및 출력 조건으로 사용되는 컬럼인 경우 적용한다.

- 인덱스 자동생성 기본키와 Unique키의 제약 조건을 사용할 경우 적용한다.

* 분포도 : 특정 컬럼의 데이터가 테이블에 평균적으로 분포되어 있는 정도

 

3. 인덱스 컬럼 선정

- 분포도가 좋은 컬럼은 단독적으로 생성한다.

- 자주 조합되어 사용되는 컬럼은 결합 인덱스로 생성한다.

- 결합 인덱스는 구성되는 컬럼 순서 선정(사용빈도, 유일성, 정렬 등)에 유의한다.

- 가능한 한 수정이 빈번하지 않은 컬럼을 선정한다.

 

4. 설계 시 고려 사항

- 지나치게 많은 인덱스는 오버헤드로 작용한다.

- 인덱스는 추가적인 저장 공간이 필요함을 고려해야 한다.

- 인덱스와 테이블의 저장 공간을 적절히 분리될 수 있도록 설계해야 한다.

 

 

 

뷰(View) 설계

1. 뷰 속성

속성 설명
REPLACE 뷰가 이미 존재하는 경우 재생성
FORCE 본 테이블의 존재 여부에 관계없이 뷰 생성
NOFORCE 기본 테이블이 존재할 때 뷰 생성
WITH CHECK OPTION 서브 쿼리 내의 조건을 만족하는 행만 변경
WITH READ ONLY 데이터 조작어 작업 불가

 

2. 뷰 설계 시 고려 사항

- 뷰 사용에 따라 수행속도에 문제가 발생할 수 있다.

- 뷰의 조건은 최적의 액세스 경로를 사용할 수 있도록 한다.

 

 

클러스터(Cluster) 설계 :  대상이 되는 범위의 요소를 몇 개 모은 단위체

1. 적용 기준

- 인덱스의 단점을 해결한 기법, 분포도가 넓을수록 유리

- 액세스 효율 향상을 위한 물리적 저장 방법

- 분포도가 넓은 테이블의 클러스터링은 저장 공간의 절약이 가능

- 대량의 범위를 자주 액세스 하는 경우 적용

- 인덱스를 사용한 처리 부담이 되는 넓은 분포도에 활용

- 여러 개의 테이블이 빈번하게 조인을 일으킬 때 활용

 

2. 클러스터 설계 시 고려 사항

- 검색 효율은 높여주나 입력, 수정, 삭제 시는 부하가 증가함을 고려

- UNION, DISTINCT, ORDER BY, GROUP BY가 빈번한 컬럼, 수정이 자주 발생하지 않는 컬럼이면 검토 대상

- 처리 범위가 넓어 문제가 발생하는 경우 : 단일 테이블 클러스터링, 조인이 많아 문제가 발생되는 경우 : 다중 테이블 클러스터링을 고려

 

 

파티션(Partition) 설계

1. 파티션의 종류

종류 설명
레인지 파티셔닝
( = 범위 파티셔닝)		 · 연속된 숫자나 날짜를 기준으로 하는 파티셔닝 기법
· 손쉬운 관리 기법을 제공하여 관리 시간의 단축이 가능
· 예) 우편번호, 일별, 월별, 분기별 등의 데이터에 적합
해시 파티셔닝 · 파티션 키의 해시 함수 값에 의한 파티셔닝 기법
· 균등한 데이터 불할이 가능하고 질의 성능이 향상 가능
· 예) 파티션을 위한 범위가 없는 데이터에 적합
리스트 파티셔닝
( = 목록 파티셔닝)		 · 특정 파티션에 저장 될 데이터에 대한 명시적 제어가 가능한 파티셔닝 기법
· 분포도가 비슷하고 데이터가 많은 SQL에거 컬럼의 조건이 많이 들어오는 경우 유용함
· 예) 한국, 일본, 중국 → 아시아 / 노르웨이, 스웨덴, 핀란드 → 북유럽 
컴포지트 파티셔닝
( = 조합 파티셔닝)		 · 레인지, 해시, 리스트 파티셔닝 중 2개 이상의 파티셔닝을 결합한 파티셔닝
· 큰 파티션에 대한 I/O 요청을 여러 파티션으로 분산할 수 있다.
· 예) 레인지 파티셔닝할 수 있는 컬럼이나, 파티션이 너무 커서 효과적으로 관리할 수 없을 때 유용
라운드로빈 파티셔닝 · 라운도로빈 분할로 회전하면서 새로운 행이 파티션에 할당하는 방식
· 파티션에 행의 고른 분포를 원할 때 사용

 

2. 파티션의 장점

속성 설명
성능 향상 · 데이터 액세스 범위를 줄여 성능 향상
가용성 향상 · 전체 데이터의 훼손 가능성이 감소 및 데이터 가용성 향상
백업 가능 · 분할 영역을 독립적으로 백업하고 복구가능
경합 감소 · 디스크 스트라이핑으로 입출력 성능을 향상
· 디스크 컨트롤러에 대한 경합의 감소
* 디스트 스트라이핑 : 성능 향상을 위해 데이터를 1개 이상의 디스크 드라이브에 저장하여 드라이브를 병렬로 사용할 수 있는 기술

 

 

디스트 구성 설계

· 정확한 용량을 산정하여 디스크 사용의 효율을 높인다.

· 업무량이 집중되어 있는 디스크를 분리 설계한다.

· 입출력 경합을 최소화하여 데이터의 접근 성능을 향상시킨다.

· 디스크 구성에 따라 테이블스페이스 개수와 사이즈 등을 결정한다.

· 파티션 수행 테이블은 별도로 분류한다.

 

 

 

 

※ 해당 글은 수제비 2022 도서 참고하였습니다.

 

수제비- IT 커뮤니티 (정보처리기사... : 네이버 카페

수제비-수험생 입장에서 제대로 쓴 비법서(정보처리기사, 정보처리기능사, 빅데이터 분석기사 등 시리즈)

cafe.naver.com

 

 

'정보처리기사' 카테고리의 다른 글

Ⅲ 데이터 입출력 구현 - 데이터베이스 기초 활용하기  (0) 2023.02.28
Ⅲ 데이터 입출력 구현 - 논리 데이터 저장소 확인  (2) 2023.02.02
Ⅱ 화면설계 - UI 설계  (1) 2023.01.31
Ⅱ 화면설계 - UI 요구사항 확인  (0) 2023.01.30
[2023] 정보처리기사 시험 일정  (0) 2023.01.05

데이터 모델 ⭐⭐⭐

데이터 모델(Data Model) 개념

· 현실 세계의 정보를 인간과 컴퓨터가 이해할 수 있도록 추상화하여 표현한 모델

· 데이터 모델 표시요소 (연구해서 제시해!)

표시요소 설명
연산
(Operation)		 · 데이터베이스에서 실제 데이터를 처리하는 작업에 대한 명세
· 릴레이션을 조작하기 위한 연산을 나타냄 (SELECT, PROJECT, JOIN, DIVISION)
구조
(Structure)		 · 데이터베이스에 논리적으로 표현될 대상으로서의 개체 타입과 개체 타입 간의 관계
· 데이터 구조 및 정적 성질을 표현하는 요소
제약조건
(Constraint)		 · 데이터베이스에 저장될 수 있는 실제 데이터의 논리적인 제약 조건
· 데이터 무결성 유지를 위한 DB의 보편적 방법
· 릴레이션의 특정 컬럼에 설정하는 제약을 의미(개체 무결성, 참조 무결성 등)

 

 

데이터 모델 절차 ( 요놈말은 개념도 없고 논리도 없고!! 물먹이네!)

단계 모델 설명
요구조건 분석 - · 도출된 요구사항 간 상충 해결, 범위 파악하여 외부 환경과의 상호작용을 분석을 통해 데이터에 대한 요구 분석
개념적 설계 개념적 데이터 모델 · 사용자의 요구에 대한 트랜잭션을 모델링 하는 단계
· 현실 세계에 대한 인식을 추상적, 개념적으로 표현하여 개념적 구조를 도출하는 데이터 모델
· 트랜잭션 모델링, View 통합방법 및 Attribute 합성 고려
· DB의 종류와 관계가 없음
· 주요 산출물 : 개체관계 다이어그램(ERD)
논리적 설계 논리적 데이터 모델 · 트랜잭션의 인터페이스를 설계하는 단계
· DBMS에 맞는 논리적 스키마를 설계하는 단계
· 업무의 모습을 모델링 표기법으로 형상화하여 사람이 이해하기 쉽게 표현한 데이터 모델
· 논리적 설계 단계에서 정규화를 수행
· 논리적 데이터베이스 구조로 매핑(Mapping)
· 스키마의 평가 및 정제
· 논리적 데이터 모델을 통해 '관계 데이터 모델', '계층 데이터 모델', '네트워크 데이터 모델', '객체 지향 데이터 모델', '객체-관계 데이터 모델' 중 하나의 모델에 맞게 설계
· 관계형 데이터베이스에서는 테이블을 설계하는 단계
물리적 설계 물리적 데이터 모델 · 논리 데이터 모델을 특정 DBMS의 특성 및 성능을 고려하여 물리적인 스키마를 만드는 단계
· 무논리 데이터 모델을 사용하고자 하는 각 DBMS의 특성을 고려하여 데이터베이스 저장구조(물리 데이터 모델)로 변환하는 과정
· 테이블, 인덱스, 뷰, 파티션 등 객체를 생성
· 응답시간, 저장 공간의 효율화, 트랜잭션 처리를 고려하여 설계
· 성능 측면에서 반 정규화를 수행
· 레코드 집중의 분석 및 설계
· 저장 레코드 양식 설계
· 접근 경로(Access Path) 설계
· 주요 산출물 : 테이블 정의서

* 정규화

관계형 데이터 모델에서 데이터의 중복성을 제거하여, 이상 현상을 방지하고, 데이터의 일관성과 정확성을 유지하기 위해 무손실 분해를 하는 과정

* 반정규화 

정규화된 엔티티, 속성, 관계에 대해 성능 향상과 개발 운영의 단순화를 위해 중복, 통합, 분리 등 수행하는 데이터 모델링의 기법

 

 

논리 데이터 모델 검증⭐⭐⭐

논리 데이터 모델링 개념

- 업무의 모습을 모델링 표기법으로 형상화하여 사람이 이해하기 쉽게 표현하는 프로세스

- 개념 모델로부터 업무 영역의 업무 데이터 및 규칙을 구체적으로 표현한 모델

* 개념 모델

주제 영역과 핵심 데이터 집합 간의 관계를 정의하는 모델, 전체 모델에서 중요한 골격이 되는 개체와 관계위주의 모델

 

 

논리적 데이터 모델링 종류

종류 설명
관계 데이터 모델 · 논리적 구조가 2차원 테이블 형태로 구성된 모델
· 기본 키(PK)와 이를 참조하는 외래 키(FK)로 관계 표현
· 1:1, 1:N, N:M 관계를 자유롭게 표현
계층 데이터 모델 · 논리적 구조가 트리 형태로 구성된 모델
· 상하관계가 존재한다(부모-자식)
· 1:N 관계만 허용
네트워크 데이터 모델 · 논리적 구조가 그래프 형태로 구성된 모델
· CODASYL DBTG모델이라고 불림
· 상위와 하위 레코드 사이에 다대다(N:M) 관계를 만족하는 구조

 

 

관계 데이터 모델

1. 관계 데이터 모델

- 관계 데이터 모델 개념

　　└  데이터를 행과 열로 구성된 2차원 테이블 형태로 구성한 모델

　　└  수학자 E.F.Codd 박사가 제안한 모델

- 관계데이터 모델의 구성요소

구성요소 설명
릴레이션(Relation) 행(Row)과 열(Column)로 구성된 테이블
튜플(Tuple) 릴레이션의 행(Row)에 해당되는 요소
속성(Attribute) 릴레이션의 열(Column)에 해당되는 요소
카디널리티(Cardinality) 튜플(Row)의 수
차수(Degree) 애트리뷰트(Column)의 수
스키마(Schema) 데이터베이스의 구조, 제약 조건 등의 정보를 담고 있는 기본적인 구조
인스턴스(Instance) 정의된 스키마에 따라 생성된 테이블에 실제 저장된 데이터의 집합

 

2. 관계 데이터 모델의 표현

- 데이터 간의 관계를 기본 키와 이를 참조하는 외래 키로 표현

- 테이블 간 관계를 1:1, 1:N, N:M 관계로 목적에 맞게 표현

 

3. 관계 대수

- 관계 대수 개념 : 관계형 데이터베이스에서 원하는 정보와 그 정보를 어떻게 유도하는가를 기술하는 절차적 정형 언어

- 관계 대수 연산자의 종류

　　└  일반 집합 연산자 : 수학적 집합 개념을 릴레이션에 적용한 연산자 (힙합과 발라드가 교차하는 마이카~) 

연산자 기호 표현 설명
합집합(Union) ∪ R∪S 합병 가능한 두 릴레이션 R과 S의 합집합
교집합(Intersection) ∩ R∩S 릴레이션 R과 S에 속하는 모든 튜플로 결과 릴레이션 구성
차집합(Difference) － R－S R에 존재하고 S에 미 존재하는 튜플로 결과 릴레이션 구선
카티션 프로덕트 × R×S R과 S에 속한 모든 튜플을 연결해 만들어진 새로운 튜플로 릴레이션 구성

 

　　└  순수 관계 연산자 : 관계 데이터베이스에 적용할 수 있도록 특별히 개발한 관계 연산자(셀프조인하면 디진다!)

연산자 기호 표현 설명
셀렉트(Select) σ σ조건(R) · 릴레이션 R에서 조건을 만족하는 튜플을 반환
프로젝트(Project) π(파이) π속성리스트(R) · 릴레이션 R에서 주어진 속성들의 값으로만 구성된 튜플 반환
조인(Join) ⋈ R⋈S · 공통 속성을 이용해 R과 S의 튜플들을 연결해 만든어진 튜플 반환
디지번(Division) ÷ R÷S · 릴레이션 S의 모든 튜플과 관련 있는 R의 튜플 반환
· 릴레이션 A, B가 있을 때 릴레이션 B 조건에 맞는 것들만 릴레이션 A에서 튜플을 꺼내 프로젝션하는 관계

 

4. 관계 해석

- 관계 해석 개념 : 튜플 관계 해석과 도메인 관계 해석을 하는 비절차적 언어

- 관계 해석 특징 : 프레디킷 해석에 기반한 언어이며 비절차적 언어(원하는 정보가 무엇이라는 것만 선언)이다.

 

 

논리 데이터 모델링 속성 (개속관)

구조 설명
개체
(Entity)		 · 관리할 대상이 되는 실체 (사물 또는 사건)
· 피터 챈 모델 개체 표시 : 사각형(ㅁ)
· 까마귀발 모델 개체 표시 : 표 형식
속성
(Attributes)		 · 관리할 정보의 구체적 항목 (요소 또는 성질)
· 피터 챈 모델 속성 표시 : 타원형(O)
· 까마귀발 모델 속성 표시 : 표 내부
· 속성명은 단수형으로 명명, 개체명을 사용하지 않는다.
· 속성이 필수 사항(Not Null)인지, 아닌지(Null) 고려하여 작성한다.
관계
(Relationship)		 · 개체 간의 대응 관계 (두 객채의 관계를 정의)
· 피터 챈 모델 관계 표시 : 마름포(◇)
까마기발 모델 관계 표시 의미
1:1 관계를 표시한다.
1:m 관계를 표시한다.
n:m 관계를 표시한다.

 

 

개체-관계(E-R) 모델

1. 개체-관계(E-R) 모델 개념

- 현실 세계에 존재하는 데이터와 그들 간의 관계를 사람이 이해할 수 있는 형태로 명확하게 표현하기 위해서 가장 널리 사용되고 있는 모델

- 논리 데이터 모델링에서는 모든 이해당사자와 의사소통의 보조 자료로 활용한다.

- 요구사항으로부터 얻어낸 정보들을 개체, 속성, 관계로 기술한 모델이다.

 

2. 개체-관계(E-R) 다이어그램 기호

구성 기호
개체 □ 사각형
관계 ◇ 마름모
속성 ○ 타원
다중 값 속성 ◎ 이중타원
관계-속성 연결 ― 선

 

 

정규화

1. 정규화(Normalization)의 개념

- 관계형 데이터 모델에서 데이터의 중복성을 제거하여 이상현상을 방지하고, 데이터의 일관성과 정확성을 유지하기 위해 무손실 분해하는 과정

 

2. 이상현상 (삽삭갱)

- 데이터의 중복성으로 인해 릴레이션을 조작할 때 발생하는 비합리적 현상

이상 현상 설명
삽입 이상 정보 저장 시 해당 정보의 불필요한 세부정보를 입력해야 하는 경우
삭제 이상 정보 삭제 시 원치 않는 다른 정보가 같이 삭제되는 경우
갱신 이상 중복 데이터 중에서 특정 부분만 수정되어 중복된 값이 모순을 일으키는 경우

 

3. 정규화의 단계 (도부이결다조)

단계 조건
1정규형(1NF) · 도메인이 원자값으로 구성
· 원자값으로 구성, 반복 속성/중복 제거가 필요하다.
2정규형(2NF) · 부분 함수 종속 제거(완전 함수적 종속 관계)
· 주식별자가 아닌 속성을 분리한다.
3정규형(3NF) · 이행함수 종속 제거
· 속성에 종속적인 속성을 분리한다.
보이스-코드 정규형(BCNF) · 결정자 후보 키가 아닌 함수 종속 제거
· 모든 결정자가 후보 키가 되도록 하여 결정자 함수 종속성을 제거
· 3차 정규형을 만족하면서 모든 결정자가 후보키 집합에 속한 정규형
· 3차 정규형으로 해결할 수 없는 이상 현상을 해결할 수 있다.
4정규형(4NF) · 다치(다중 값) 종속 제거
· 특정 속성값에 따라 선택적인 속성을 분리한다.
5정규형(5NF) · 조인 종속 제거

 

 

반 정규화 (비정규화, 역정규화)

1. 반 정규화 개념

- 정규화된 엔티티, 속성, 관계에 대해 성능 향상과 개발 운영의 단순화를 위해 중복, 통합, 분리 등을 수행하는 데이터 모델링의 기법이다.

 

2. 반 정규화 특징

장점 단점
· 반 정규화된 데이터 구조는 성능 향상과 관리의 효율성이 증가 · 데이터의 일관성 및 정합성 저하
· 유지를 위한 비용이 별도로 발생하여 성능에 나쁜 영향을 미칠 수 있음
우선순위 비교 조정 과정 중요 : 데이터의 일관성과 무결성 OR 데이터베이서의 성능과 단순화

 

3. 비 정규화 절차

절차 설명
대량 조사 범위 처리 빈도수, 대량 범위 처리, 통계성 프로세스, 테이블 조인 수를 고려한다.
다른방법 유도 뷰 테이블, 클러스터링, 인덱스의 조정, 어플리케이션의 변경 등을 유도한다.
반 정규화를 적용한다.

 

4. 반 정규화 기법 (테병분중 컬중 관중)

구분 수행 방법 설명
테이블 테이블 병합 · 1:1 관계, 1:M 관계를 통합하여 조인 횟수를 줄여 성능을 향상
· 슈퍼타입/서브타입 테이블 통합 통해 성능 향상
테이블 분할 · 테이블을 수직 또는 수평으로 분할하는 것으로 파티셔닝이라고 함
종류 설명
수평 분할 · 테이블 분할에 레코드를 기준으로 활용
수직 분할 · 하나의 테이블이 가지는 컬럼의 개수가 증가하는 경우 사용
· 갱신 위주의 속성 분할, 자주 조회되는 속성 분할, 크기가 큰 속성 분할, 보안을 적용해야하는 속성 분할
중복 테이블 추가 · 대량의 데이터들에 대한 집계합수를 사용하여 실제 통계정보를 계산하는 경우에 효과적인 수행을 위해 별도의 통계 테이블을 두거나 중복 테이블을 추가
종류 설명
집계 테이블 집계 데이터를 위한 테이블을 생성하고 각 원본 테이블에 트리거를 설정하여 사용하는 것으로, 트리거의 오버헤드에 유의 필요
진행 테이블 이력 관리 등의 목적으로 추가하는 테이블로, 적절한 데이터양의 유지와 활용도를 높이기 위해 기본키를 적절히 설정
특정 부분만을 포함하는 테이블 데이터가 많은 테이블의 특정 부분만을 사용하는 경우 해당 부분만으로 새로운 테이블을 생성
컬럼 컬럼 중복화 · 조인 성능 향상을 위한 중복 허용
관계 중복관계 추가 · 데이터를 처리하기 위한 여러 경로를 거쳐 조인이 가능하지만, 이때 발생할 수 있는 성능 저하를 예방하기 위해 추가적 관계를 맺는 방법

 

 

 

 

 

※ 해당 글은 수제비 2022 도서 참고하였습니다.

 

수제비- IT 커뮤니티 (정보처리기사... : 네이버 카페

수제비-수험생 입장에서 제대로 쓴 비법서(정보처리기사, 정보처리기능사, 빅데이터 분석기사 등 시리즈)

cafe.naver.com

 

'정보처리기사' 카테고리의 다른 글

Ⅲ 데이터 입출력 구현 - 데이터베이스 기초 활용하기  (0) 2023.02.28
Ⅲ 데이터 입출력 구현 - 물리 데이터 저장소 설계  (0) 2023.02.20
Ⅱ 화면설계 - UI 설계  (1) 2023.01.31
Ⅱ 화면설계 - UI 요구사항 확인  (0) 2023.01.30
[2023] 정보처리기사 시험 일정  (0) 2023.01.05

UI 설계를 위한 UML ⭐⭐⭐

UML

1. UML의 개념 

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

 

2. UML의 특징

특징 설명
가시화 언어 · 개념 모델 작성 시 오류가 적고 의사소통이 용이
구축 언어 · 다양한 프로그래밍 언어로 실행 시스템의 예층 가능
· UML을 소스 코드로 변환하여 구축 가능, 역 변환하여 역공학 가능
명세화 언어 · 정확한 모델 제시, 완전한 모델 작성 가능
문서화 언어 · 시스템에 대한 평가 및 의사소통의 문서

 

3. UML의 구성요소 ( 사과한다(사관다~~ ))

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

 

4. UML 다이어그램

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

 

5. UML 확장 모델의 스테레오 타입

- UML 기본적 요소 이외의 새로운 요소를 만들어내기 위한 확장 메커니즘

- 형태는 기존의 UML 요소를 그대로 사용하지만 내부 의미는 다른 목적으로 사용하도록 확장

- '<<>>' 길러멧 기호를 사용하여 표현

- UML 스테레오 타입의 유형

유형 설명
<<include>> 하나의 유스케이스가 어떤 시점에 반드시 다른 유스케이스를 실행하는 포함 관계
<<extend>> 하나의 유스케이스가 어떤 시점에 다른 유스케이스를 실행할 수도 있고 그렇지 않을 수도 있는 확장 관계
<<interface>> 모든 메서드가 추상 메스드이며 바로 인스턴스를 만들 수 없는 클래스로 추상 메서드와 상수만으로 구성된 클래스
<<entity>> 일반적으로 정보 또는 오래 지속되는 연관된 행위를 형상화하는 클래스로 유스케이스 처리 흐름이 수행되는 과정에서 기억 장치에 저장되어야 할 정보를 표현하는 클래스
<<boundary>> 시스템과 외부 액터와의 상호 작용을 담당하는 클래스
<<control>> 시스템이 제공하는 기능의 로직 및 제어를 담당하는 클래스

 

 

UML의 유형

1. 클래스 다이어그램

- 클래스 다이어그램의 개념 : 객체 지향 모델링 시 클래스의 속성 및 연산과 클래스 간 정적인 관계를 표현

- 클래스 다이어그램의 구성요소 

구성요소 설명
클래스(Class) · 공통의 속성, 연산(메서드), 관계, 의미를 공유하는 객체들의 집합
속성(Attribute) · 클래스의 구조적 특성에 이름을 붙인 것으로 특성에 해당하는 인스턴스가 보유할 수 있는 값의 범위를 기술
연산(Operation),
메서드		 · 이름, 타입, 매개변화들과 연관된 행위를 호출하는데 요구되는 제약사항들을 명시하는 클래스의 행위적 특징
· 객체에 요청하여 행동에 영향을 줄 수 있는 서비스
접근 제어자
(Access Modifier)		 · 클래스에 접근할 수 있는 정도를 표현
- 클래스 내부 접근만 허용 (private)
+ 클래스 외부 접근을 허용 (public)
# 동일 패키지/파생 클래스에서 접근 가능 (protected)
~ 동일 패키지 클래스에서 접근 가능 (default)

 

- 클래스 간의 관계(Relationships)

구분 설명
연관관계
(Association)		 · 클래스가 서로 개념적으로 연결된 선
· 2개 이상의 사물이 서로 관련되어 있는 상태
· 사물 사이를 실선으로 연결하여 표현하며, 방향성은 화살표로 표현 
· 서로에게 영향을 주는 양방향의 관계일 경우 화살표를 생략하고 실선으로만 연결
· 예) 축구팀과 공격수(1...3), 수비수(1...5), 골키퍼(1...1)
의존관계
(Dependency)		 · 하나의 클래스가 또 다른 클래스를 사용하는 관계
· 다른 클래스의 멤버 함수 사용
· 의존 관계는 사물 사이에 서로 연관은 있으나 필요에 따라 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계를 표현
· 하나의 클래스에 있는 멤버 함수의 인자가 변함에 따라 다른 클래스에 영향을 미칠 때의 관계
· 영향을 주는 사물이 영향을 받는 사물 쪽으로 점선 화살표를 연결하여 표현
· 예) 교수와 수업
일반화관계
(Generalization)		 · 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지를 표현
· 일반적인 개념을 부모(상위)라고 하고, 구처적인 개념을 자식(하위)이라 함
· 구체적(하위)인 사물에서 일반적(상위)인 사물 쪽으로 속이 빈 화살표를 연결하여 표현
· 일반화 관계는 다른 의미로 상속관계라고 함
· 예) 차와 자가용, 택시, 버스
실체화관계
(Realization)		 · 추상 클래스나 인터페이스를 상속받아 자식 클래스가 추상 메서드를 구현할 때 사용
· 사물이 할 수 있거나, 해야 하는 기능(행위,인터페이스)으로 서로를 그룹화할 수 있는 관계를 표현
· 예) abstact class extends, interface implements
포함관계
(Composition)
= 복합관계		 · 영구적이고, 집합 관계보다 더 강한 관계로 구성
· 포함되는 쪽(부분)에서 포함하는 쪽(전체)으로 채워진 마름모를 연결하여 표현 (◆)
· 포함관계는 집합관계의 특수한 형태로, 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계를 표현
· 예) 엔진과 피스톤, 플러그
집합관계
(Aggregation)		 · 하나의 객체에 여러개의 독립적인 객체들이 구성되는 관계
· 집합관계는 하나의 사물이 다른 사물에 포함되어 있는 관계 표현
· 포함되는 쪽(부분)에서 포함하는 쪽(전체)으로 빈 마름모를 연결하여 표현 (◇)
· 예) 차와 엔진, 바퀴, 운전대

 

* 연관관계의 다중성

다중성 표현 의미
1 · 한 객체와 연관
· 표시하지 않아도 기본값으로 설정
0..1 · 0개 또는 1개의 객체와 연결
0..* · 0개 또는 많은 수의 객체가 연관
* · 0..*와 동일
1..* · 1개 이상의 객체와 연관
1..12 · 1개에서 12개까지 객체가 연관
1..2,4,6 · 1개에서 2개까지 또는 4개 또는 6개의 객체가 연관

 

* 실체화 관계(Realization)에서 추상 클래스와 인터페이스 관계

구분 설명
추상 클래스 · 객체 인스턴스를 생성하지 않고, 단지 유사 클래스들의 공통된 특징을 정의하고, 하나 이상의 추상 메서드와 일반 필드 및 일반 메서드를 포함하는 클래스
· 동일한 부모를 가지는 클래스를 묶는 개념으로 상속을 받아서 기능을 확장시키는 것이 목적
· 이탤릭체로 클래스명을 표시하며, 스테레오타입을 이용하여 <<abstract>>로 표기
인터페이스 · 기능(Function)을 모아놓은 클래스로 추상메서드와 상수만을 포함한다.
· 구현하는 모든 클래스에 대해 특정한 메서드가 반드시 존재하도록 강제하는 역할
· 이탤릭체로 인터페이스명을 표시하며, 스테레오타입을 이용하여 <<interface>>로 표기

 

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

- 유스케이스 다이어그램의 개념 : 시스템이 제공하고 있는 기능 및 그와 관련된 외부 요소를 사용자의 관점에서 표현하는 다이어그램

- 유스케이스 다이어그램의 구성요소 

구성요소 설명
유스케이스 · 시스템이 제공해야 하는 서비스, 기능
· 액터가 시스템을 동해 수행하는 일련의 행위
액터 · 사용자가 시스템에 대해 수행하는 역함
· 시스템과 상호 작용하는 사람 또는 사물
· 이벤트 흐름을 시작하게 하는 객체
시스템 · 전체 시스템의 영역을 표현
시나리오 · 발생되는 이벤트의 흐름
이벤트의 흐름 · 사람, 시스템, 하드웨어, 시간의 흐름에 의해 시작

 

- 유스케이스 다이어그램의 관계

관계 설명 사례
포함관계
(Include)		 · 유스케이스를 수행할 때 다른 유스케이스가 반드시 수행되는 관계
· 여러 유스케이스에서 공통적으로 발견되는 기능 표현
· 2개 이상의 유스케이스 이벤트 흐름에서 중복적인 부분이 발생하는 경우 유스케이스 간 포함 관계를 성정하여 해결
· <<include>>를 사용하여 표현		 대여 유스케이스
이벤트 흐름		 반납 유스케이스
이벤트 흐름
고객확인, 도서번호 입력 필요 고객확인, 도서번호 입력 필요
확장관계
(Extend)		 · 포함관계처럼 여러 유스케이스에 걸쳐 중복적으로 사용되지 않고, 특정 조건에서 한 유스케이스로만 확장되는 관계
· 특정 조건이 만족되는 상황에서만 확장 유스케이스의 이벤트 흐름이 수행
· 한 유스케이스에서 추가되거나 확장된 기능을 표현
· <<extend>>를 사용하여 표현
 금액계산 유스케이스
이벤트 흐름		 금액표시 유스케이스
이벤트 흐름
· 사용자가 자판기에 동전 투입, 음효수 선택
· 현재 금액에 투입된 동전만큼 액수 추가
· 금액표시 유스케이스 확장		 · 금액계산 유스케이스로부터 금액 수령
· 받은금액 표시
일반화관계
(Generalization)		 · 추상적인 액터와 좀 더 구체적인 액터 사이에 맺어어주는 관계
· 일반화 관계를 액터에 적용하면 유스케이스 다이어그램에서 사용되는 여러 액터들의 의미를 좀 더 명확하게 하고 다이어그램도 보다 간결하게 작성
· 하위 액터나 유스케이스에서 상위 액터, 유스케이스 쪽으로 속이 빈 삼각형 화살표를 실선으로 연결

 

3. 시퀀스 다이어그램

- 시퀀스 다이어그램의 개념

　　└  객체 간 상호 작용을 메세지 흐름으로 표현한 다이어그램

　　└  객체 간의 동적 상호 작용을 시간적 개념을 중심으로 모델링하는 과정

　　└  객체의 오퍼레이션과 속송을 상세히 정의

　　└  시퀀스 다이어그램은 유스케이스를 실현(Realization) 한다.

- 시퀀스 다이어그램의 구성요소

구성요소 설명
객체
(Object)		 · 객체는 위쪽에 표시되며 아래로 생명선을 가짐
· 객체는 사각형 안에 밑줄 친 이름으로 명시
생명선
(Lifeline)		 · 객체로부터 뻗어 나가는 점선
· 실제 시간이 흐름에 따라 객체의 생명주기 동안 방생하는 이벤트를 명시
실행
(Activation)		 · 직사각형은 오퍼레이션(함수)이 실행되는 시간을 의미
· 직사각형이 길어질수록 오퍼레이션 수행시간이 긺
메세지
(Message)		 · 객체 간의 상호 작용은 메세지 교환으로 이루어짐
· 한 객체에서 다른 객체로의 메세지를 전달하여 전달받은 객체의 오퍼레이션을 수행

 

4. 패키지 다이어그램

- 패키지 다이어그램의 개념 : 시스템의 서로 다른 패키지들 사이의 의존 관계를 표현하기 위한 다이어그램

- 패키지 다이어그램의 구성요소

구성요소 설명
패키지 · 요소들을 그룹으로 조직하기 위한 요소
의존관계 · 하나의 패키지가 다른 패키지를 사용하는 관계
· 의존성의 성질을 나타내기 위해 스테레오 타입을 붙일 수 있음
· 스테레오 타입에는 <<import>>, <<access>>가 있음

 

5. 활동 다이어그램

- 활동 다이어그램의 개념 

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

　　└  오퍼레이션이나 처리과정이 수행되는 동안 일어나는 일들을 단계적으로 표현한다.

　　└  하나의 유스케이스 안이나, 유스케이스 사이에서 발생하는 복잡한 처리의 흐름을 명확하게 표현할 수 있다.

　　└  하나의 활동이 처리되면 그다음 활동으로 자동적으로 옮겨지며, 활동 상태의 시작과 종료는 항상 존재한다.

- 활동 다이어그램의 구성요소

구성요소 설명
시작점
(Initial Node)		 · 활동의 시작(액션이나 액티비티 시작)을 의미
· 하나의 다이어그램 안에는 하나의 시작점만 존재
· 검은색 동그라미로 표현 (●)
전의
(Transition)		 · 실행의 흐름을 나타냄
· 화살표로 표현 (→)
액션(Action) /
액티비티(Activity)		 · 어떠한 일들의 처리와 실행을 의미
· 액션은 더 이상 분해할 수 없는 단일 작업이고, 액티비티는 몇 개의 액션으로 분리될 수 있는 작업
· 모서리가 둥근 사격형으로 표현하고, 둥근 사각형 안에 액션이나 액티비티 명칭 기술
종료점
(Final Node)		 · 처리의 종료를 의미
· 하나의 다이어그램 안에는 여러 개의 종료 노드가 있을 수 있음
· 검은색 동그라미를 포함한 원으로 표현
조건(판단) 노드
(Decision Node)		 · 조건에 따른 제어 흐름의 분리를 표현
· 마름포로 표현하고 들어오는 제어 흐름은 한 개이고, 나가는 제어 흐름은 여러 개로 표현
병합 노드
(Merge Node)		 · 여러 경로의 흐름이 하나로 합쳐진 것을 표현
· 마름모로 표현하고 들어오는 제어 흐름은 여러 개고, 나가는 제어 흐름은 한 개로 표현
포크 노드
(Fork Node)		 · 평행적으로 수행되는 흐름을 나누는 노드
· 굵은 가로선으로 표현하고 들어오는 액티비티 흐름은 한 개이고, 나가는 액티비티 흐름은 여러 개
조인 노드
(Join Node)		 · Fork Node로 나눠진 흐름을 다시 하나로 합치는 노드
· 굵은 가로선으로 표현하고 들어오는 액티비티 흐름은 여러 개이고, 나가는 액티비티 흐름은 한 개
구획면
(Swim Lane)		 · 액티비티 수행을 담당하는 주체를 구분하는 면
· 가로 또는 세로 실선을 그어 구분

 

6. 상태 다이어그램

- 상태 다이어그램의 개념

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

　　└  어떤 이벤트에 의해 객체 자신이 속한 클래스의 상태 변화나 객체 간 상호 작용하는 과정에서의 상태 변화를 표현

　　└  객체는 파악된 상태들 이외의 상태는 가질 수 없고, 특정 순간에는 오직 한 상태로만 존재할 수 있다.

　　└  객체의 상태란 객체가 갖는 속성값의 변화이다.

- 상태 다이어그램의 구성요소

구성요소 설명
상태 · 객체가 존재할 수 있는 조건 중의 하나
· 둥근 사각형 안에 객체의 상태 기술
시작 상태 · 객체의 시작 상태
· 속이 채워진 원으로 표현
종료 상태 · 객체의 종료 상태
· 원 안에 속이 채워진 원으로 표현
전이 · 객체의 상태가 다른 상태로 변경되는 상태
· 상태 사이의 흐름, 변화
· 이벤트 없이도 상태 전이가 이루어 질 수 있음
· 화살표로 표현
이벤트 · 객체의 전이를 유발하는 자극
· 상태의 변화를 주는 현상
· 상태의 전이를 유발하는 이벤트는 전이 위에 이벤트 이름 표시
· 이벤트 : 시간의 흐름, 조건, 외부 신호 등
전이 조건 · 특정 조건 만족 시 전이 발생하도록 하기 위해 사용되는 속성값의 Boolean 식

 

7. 커뮤니케이션 다이어그램

- 커뮤니케이션 다이어그램의 개념

　　└  동작에 참여하는 객체들이 주고받는 메세지 표현 + 객체 간의 연관 표현 다이어그램

　　└  시스템이나 객체들이 메세지를 주고받으며 시간의 흐름에 따라 상호 작용하는 과정을 표현한 다이어그램

- 커뮤니케이션 다이어그램의 구성요소

구성요소 설명
액터 · 시스템으로부터 서비스를 요청하는 외부 요소(사람, 외부 시스템)
객체 · 메세지를 주고받는 주체
· 콜론(:)을 기준으로 앞쪽은 객체명, 뒤쪽은 클래스명 기술 (객체명:클래스명)
링크 · 객체들 간의 관계를 표현
· 클래스가 아닌 실제 객체와의 관계를 직접적으로 보여주는 객체들 사이의 링크
· 액터와 객체, 객체 간 실선으로 표현
· 링크에 메세지를 표현
메세지 · 객체가 상호 작용을 위해 주고받는 메세지
· 메세지는 상대 객체별로 여러 개의 정의가 이루어지므로, 하나의 동일한 링크에서 여러 개의 메세지를 전달
· 화상표의 방향은 메세지를 받는 쪽으로 향하게 표현

 

8. 컴포넌트 다이어그램

- 컴포넌트 다이어그램의 개념

　　└  시스템을 구성하는 물리적인 컴포넌트와 그들 사이의 의존 관계를 나타내는 다이어그램

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

　　└  실질적 프로그래밍 작업에 사용된다.

- 컴포넌트 다이어그램의 구성요소

구성요소 설명
컴포넌트 · 컴포넌트는 탭이 달린 직사각형으로 표현
· 모든 컴포넌트는 반드시 이름을 가지고 있어야 함
· 컴포넌트가 패키지에 포함되어 있다면 컴포넌트의 이름 앞에 패키지 이름을 붙일 수 있으며, 클래스처럼 컴포넌트에 꼬리표 값을 달아주거나 컴포넌트 내부의 오퍼레이션을 보여줄 수도 있음 (패키지명::컴포넌트명)
인터페이스 · 인터페이스를 실체화한다는 의미는 실제로 동작하는 컴포넌트에 인터페이스를 적용한다는 뜻
· 컴포넌트와 인터페이스의 의존 관계는 화살표 모양의 점선으로 연결
· 스테레오타입은 <<interface>>
의존 관계 · 컴포넌트 사이의 의존하는 관계 표현
· 컴포넌트 사이의 의존 관계는 한 컴포넌트에 변경이 발생한 경우, 변경 범위 추적에 유용

 

* UI 흐름 절차

- UI 설계안의 적정성 확인 → 화면에 표현되어야 할 기능 및 비기능적 요구사항 검토 → 화면의 입력 요소를 통한 UI 요구사항 확인 → 유스케이스 설계 → 기능 및 양식 확인

 

* UI 시나리오 문서 작성 요건

작성 요건 설명
완전성
(Complete)		 · UI 시나리오는 누락이 없어야 하고, 최대한 빠짐없이 상세하게 기술
· 시스템 기능보다는 사용자의 태스트에 초점을 맞춰 기술
일관성
(Consistent)		 · 서비스에 대한 목표, 시스템 및 사용자의 요구사항이 일관성이 있어야 하고, 모든 문서의 UI 스타일(Flow 또는 Layout)을 일관적으로 구성
이해성
(Understandable)		 · 처음 접하는 사람도 이해하기 쉽도록 구성, 설명
· 추상적 표현이나 이해하기 어려운 용서 사용 X
가독성
(Readable)		 · 문서를 쉽게 읽을 수 있어야 하고(문서 템플릿과 타이포그래피), 표준화된 템플릿을 작성하여 적용
· 버전 넘버링은 v1.0, v2.0 등과 같이 일관성 있게 하고, 시각적인 효과를 위해 하이타이팅은 일관성 있게 활용
추적 용이성
(Traceable)		 · 쉽게 추적 가능해야 하고, 변경 사항들이 언제, 어디서, 어떤 부분들이, 왜 발생하였는지 추적이 쉬워야 함
수정 용이성
(Modifiable)		 · 쉽게 변경 가능해야 하고, 수정 사항을 시나리오에 반영하는데 있어 쉽게 적용할 수 있어야 함
· 동일한 수정 사항을 위해 여러 문서를 편집하지 않도록 함

 

TEST  →  정답은 드래그!

정답 문제
UML 객체 지향 소프트웨어 개발 과정에서 산출물을 명세화, 시각화, 문서화할 때 사용되는 모델링 기술과 방법론을 통합해서 만든 표준화된 범용 모델링 언어이다.
사물 UML 구성요소 중 추상적인 개념으로, 주제를 나타내는 요소이고 단어 관점에서 '명사' 또는 '동사'를 의미한다.
유스케이스 다이어그램 시스템이 제공하고 있는 기능 및 그와 관련된 외부 요소를 사용자의 관점에서 표현하는 다이어그램이다.
관계 UML 구성요소 중 사물의 의미를 확장하고 명확히 하는 요소로 사물과 사물을 연결하여 관계를 표현하는 요소이고 단어 관점에서 '형용사' 또는 '부사'를 의미한다.
배치 UML 다이어그램 중 컴포넌트 사이의 종속성을 표현하고, 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현하는 다이어그램이다.
시퀀스 UML 다이어그램 중 객체 간 동적 상호 작용을 시간적 개념을 중심으로 메시지 흐름으로 표현한 다이어그램이다.
커뮤니케이션 UML 다이어그램 중 동작에 참여하는 객체들이 주고 받는 메세지를 표현하고, 메세지뿐만 아니라 객체 간의 연관까지 표현하는 다이어그램이다.
상태 UML 다이어그램 중 하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호 작용에 따라 상태가 어떻게 변화하는지 표현하는 다이어그램이다.
활동 UML 다이어그램 중 시스템이 어떤 기능을 수행하는지를 객체의 처리 로직이나 조건에 따른 처리의 흐름으로 순서대로 표현하는 다이어그램이다.
타이밍 UML 다이어그램 중 객체 상태 변화와 시간제약을 명시적으로 표현하는 다이어그램이다.
UML 스테레오 타입 UML의 기본적 요소 이외의 새로운 요소를 만들어내기 위한 확장 매커니즘으로 '<<>>'기호를 사용하여 표현한다.
+ 기호는 클래스 다이어그램의 접근 제어자 중 클래스 외부접근을 허용하는(public)하는 기호이다.
- 기호는 클래스 다이어그램의 접근 제어자 중 클래스 내부접근만 허용하는(private)하는 기호이다.
일반화 관계 클래스 간의 관계에서 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지 표현하고, 구체적인 사물에서 일반적인 사물쪽으로 속이 빈 화살표를 연결하여 표현한다.
의존 관계 클래스 간의 관계에서 하나의 클래스가 또 다른 클래스를 사용하는 관계로 사물 사이에 서로 관련은 있으나 필요에 따라 서로에게 영향을 주는 짧은 시간 동안만 유지하는 관계를 표현하고, 영향을 주는 사물이 영향을 받는 사물 쪽으로 점선 화살표를 연결하여 표현한다.
액션 활동 다이어그램 구성요소 중 어떠한 일들의 처리와 실행을 의미하고, 더 이상 분해할 수 없는 단일 작업이다.
포크 노드 활동 다이어그램 구성요소 중 평행적으로 수행되는 흐름을 나누는 노드로 굵은 가로선으로 표현하고 들어오는 액티비티 흐름은 한개이고, 나가는 액티비티 흐름은 여러개이다.
전이 조건 상태 다이어그램 구성요소 중 특정 조건 만족 시 전이 발생하도록 하기 위해 사용되는 속성 값의 불리언식이다.
UI 흐름 설계 업무의 흐름이나 업무 수행과 관련된 일련의 클릭에 의한 화면의 위치와 흐름을 흐름도 형식으로 표현하는 활동이다.
UI 설계 구성 UI 설계서 표지, UI 설계서 개정이력, UI 요구사항 정의, 시스템 구조, 사이트맵, 프로세스 정의, 화면 설계 등으로 이루어진다.
UI 상세 설계 프로세스 UI 요구사항 최종 확인, UI 구조 설계, 사용자 기반 메뉴 구조 설계, 화면 설계, 위 시스템 단위의 내·외부상세화면과 폼 설계 절차로 되어있다.
완전성 UI 시나리오 문서의 작성 요건 중 UI 시나리오는 누락이 없어야 하고, 최대한 빠짐없이 가능한 한 상세하게 기술해야 한다는 원칙이다.
이해성 UI 시나리오 문서의 작성 요건 중 처음 접하는 사람도 이해하기 쉽도록 구성하고 설명해야 하고, 이해하지 못하는 추상적인 표현이나 이해하기 어려운 용어는 사용하지 않아야 한다는 원칙이다.
가독성 UI 시나리오 문서의 작성 요건 중 문서를 쉽게 읽을 수 있어야 하고 표준화된 템플릿을 작성하여 적용해야 한다는 원칙이다.
수정 용이성 UI 시나리오 문서의 작성 요건 중 쉽게 변경이 가능해야 하고, 수정 또는 개선 사항을 시나리오에 반영하는데 있어 쉽게 적용할 수 있어야 한다는 원칙이다.
행위적(동적) 다이어그램 유형에는 유스케이스 / 시퀀스 / 커뮤니케이션 / 상태 / 활동 / 타이밍 다이어그램이 있다.
구조적(정적) 다이어그램 유형에는 클래스 / 객체 / 컴포넌트 / 배치 / 복합체 구조 / 패키지 다이어그램이 있다
실체화 관계 추상 클래스나 인터페이스를 상속받아 자식클래스가 추상 메서드를 구현할 때 사용하고, 사물이 할 수 있거나, 해야 하는 기능으로 서로를 그룹화할 수 있는 관계를 표현한다. 사물에서 기능 쪽으로 속이 빈 점선 화살표를 연결하여 표현한다.
포함 관계 유스케이스 다이어 그램의 관계 중 유스케이스를 수행할 때 다른 유스케이스가 반드시 수행되는 관계로 여러 유스케이스에서 공통적으로 발견되는 기능을 표현하고, <<include>>로 표현한다.
링크 커뮤니케이션 다이어그램 구성요소 중 객체들 간의 관계를 표현하고 클래스가 아닌 실제 객체와의 관계를 직접적으로 보여주는 구성요소로 액터와 객체, 객체 간 실선으로 표현한다.
조인 노드 Fork Node로 나눠진 흐름을 다시 하나로 합치는 노드로 굵은 가로선으로 표현하고 들어오는 액티비티 흐름은 여러 개이고, 나가는 액티비티 흐름은 한 개이다.

 

 

 

※ 해당 글은 수제비 2022 도서 참고하였습니다.

 

수제비- IT 커뮤니티 (정보처리기사... : 네이버 카페

수제비-수험생 입장에서 제대로 쓴 비법서(정보처리기사, 정보처리기능사, 빅데이터 분석기사 등 시리즈)

cafe.naver.com

 

'정보처리기사' 카테고리의 다른 글

Ⅲ 데이터 입출력 구현 - 물리 데이터 저장소 설계  (0) 2023.02.20
Ⅲ 데이터 입출력 구현 - 논리 데이터 저장소 확인  (2) 2023.02.02
Ⅱ 화면설계 - UI 요구사항 확인  (0) 2023.01.30
[2023] 정보처리기사 시험 일정  (0) 2023.01.05
Ⅰ 요구사항 확인 - 분석 모델 확인하기  (0) 2022.12.02

UI 요구사항 확인 ⭐⭐⭐

UI ( User Interface) 개념

: 사용자와 시스템 사이에서 의사소통할 수 있도록 고안된 물리적, 가상의 매개체, 정보기기나 소프트웨어의 화면 등에서 사람이 접하게 되는 화면

*UX(사용자 경험)는 UI(사용자 인터페이스)를 포함한다.

 

 

UI 유형

유형 특징 설명
CLI(Command Line Interface) 정적 텍스트 기반  명령어를 텍스트로 입력하여 조작
GUI(Graphical User Interface) 그래픽 반응 기반 그래픽 환경을 기반으로 한 마우스나 전자펜을 이용
NUI(Natural User Interface) 직관적 사용자 반응 기반 신체 부위를 이용(터치, 음성 포함)
OUI(Organic User Interface) 유기적 상호 작용 기반 현실에 존재하는 모든 사물이 입출력장치로 변화할 수 있음

 

 

UI 분야

분야 설명
물리적 제어 분야 정보 제공과 기능 전달을 위한 하드웨어 기반
디자인적 분야 콘텐츠의 정확하고 상세한 표현과 전체적 구성
기능적 분야 사용자의 편의성에 맞춰 쉽고 간편하게 사용 가능

 

 

UI 설계 원칙

설계 원칙 설명 부특성
직관성 누구나 쉽게 이해, 쉽게 사용 쉬운 검색, 쉬운 사용성, 일관성
유효성 정확, 완벽하게 사용자의 목표가 달성될 수 있도록 제작 쉬운 오류 처리 및 복구
학습성 초보와 숙련자 모두 쉽게 배우고 사용할 수 있게 제작 쉽게 학습, 쉬운 접근, 쉽게 기억
유연성 사용자의 요구사항 최대한 수용, 실수 방지할 수 있도록 제작 오류 예방, 실수포용, 오류 감지

 

 

UI 설계 지침

설계 지침 설명
사용자 중심 사용자가 이해하기 쉽고 편하게 사용할 수 있는 환경을 제공하며, 실사용자에 대한 이해가 바탕이 되어야 함
일관성 버튼이나 조작 방법을 사용자가 기억하기 쉽고 빠르게 습득할 수 있도록 설계해야 함
단순성 조작 방법은 가장 간단하게 작동되도록 하여 인지적 부담 최소화
결과 예측 가능 작동시킬 기능만 보고도 결과 예측이 가능해야 함
가시성 주요 기능을 메인 화면에 노출하여 쉬운 조작이 가능해야함
표준화 디자인을 표준화하여 기능구조의 선행 학습 이후 쉽게 사용 가능해야 함
접근성 사용자의 직무, 연령, 성별 등이 고려된 다양한 계층을 수용해야 함
명확성 사용자가 개념적으로 쉽게 인지해야 함
오류 발생 해결 사용자가 오류에 대한 상황을 정확하게 인지할 수 있어야 함

 

 

UI 요구사항 확인

1. UI 요구사항 개요

- UI 요구사항은 사용자가 정보시스템을 구축하여 얻고자 하는 최종 목적의 기준

- 시스템 개발과정 전체에 대한 기준이 되며, 시스템 개발 종료 및 검수의 기준이 된다.

 

2. UI 요구사항 구분

- 기능적 : 시스템이 제공하는 기능, 서비스 및 시스템의 입출력, 데이터, 연산에 관한 요구사항

- 비기능적 : 품질( 사용성, 효율성, 신뢰성, 유지보수성, 재사용성), 시스템 환경(플랫폼, 사용기술), 프로젝트 계획(비용, 일정)에 관한 요구사항

 

3. UI 요구사항 확인

- SW 개발을 위한 UI 표준 및 지침에 따라, 기능 및 비기능 요구사항의 도출을 통해 개발하고자 하는 응용 소프트웨어에 적용될 UI 요구사항을 확인　

 

4. UI 품질 요구사항(ISO/IEC 9126 기반)

품질 기준 설명 요구사항
기능성 실제 수행 결과와 품질 요구사항과의 차이를 분석, 실제 사용 시 정확하지 않은 결과가 발생할 확률과 관련하여 시스템의 동작을 관찰하기 위한 품질 기준 적절성, 정밀성, 상호 운용성, 보안성, 호환성
신뢰성 시스템이 일정한 시간 or 작동되는 시간 동안 의도하는 기능을 수행함을 보증하는 품질 기준 성숙성, 고장 허용성, 회복성
사용성 사용자와 컴퓨터 사이에 발생하는 어떠한 행위를 정확하고 쉽게 인지할 수 있는 품질 기준 이해성, 학습성, 운용성
효율성 할당된 시간에 한정된 자원으로 얼마나 빨리 처리할 수 있는가에 대한 품질 기준 시간 효율성, 자원 효율성
유지보수성 요구사항을 개선하고 확장하는 데 있어 얼마나 용이한가에 대한 품질 기준 분석성, 변경성, 안정성, 시험성
이식성 다른 플랫폼에서도 많은 추가 작업 없이 쉽게 적용 가능한가에 대한 품질 기준 적용성, 설치성, 대체성

 

 

UI 표준 ⭐

UI 표준 개념 

: 디자인 철확과 원칙 기반하에 전체 시스템에 공통으로 적용되는 화면 간 이동, 화면구성에 관한 규약

 

 

UI 표준 구성

: 전체적인 UX 원칙, 정책 및 철학, UI 스타일 가이드, UI 패턴 모델 정의, UI 표준 수립을 위한 조직 구성

 

 

UI 표준 수립 시 고려사항

· 사용자가 불편해하지 않아야 한다.

· 많은 업무 케이스를 포함해야 한다.

· 다양한 사용상황에 대처할 수 있어야 한다.

· 표준 적용이 쉽도록 충분한 가이드와 활용 수단 제공이 필요하다.

· 변화하는 상황에 맞게 빠르게 변경할 수 있는 관리조직 수반이 필요하다.

 

 

UI 스타일 가이드 구성

정의 내용
UI 구동 환경 · 컴퓨터 OS, 웹 브라우저, 모니터 해상도, 프레임세트 확인
레이아웃 · 기본 배치는 크게 Top, Left, Contents 영역으로 부분 설계. Footer는 상황에 맞게 추가 및 제외
메뉴 내비게이션 · 애플리케이션 메뉴 구조에 따라 적당한 타입 선택 적용
공통표준화면 · 검색영역이나 Tab Menu 등 공통된 표준 화면을 정의
기능 · 시스템 요구사항에 대한 개념 모델을 논리적 모델(프로세스 모델, UI 설계, 논리 데이터 모델, 아키텍처 정의, 인터페이스 설계 측면)로 상세화하여 기능 정의
구성요소 · UI 구성요소 중 그리드는 테이블 형태로 UI를 구성

 

 

UI 패턴 모델 정의

: CRUD 방식을 기반으로 데이터의 입출력을 처리하는 화면 흐름을 포함하여 오퍼레이션 방식에 대한 표준 절차를 표시하고, UI 패턴 모델을 개발

 

 

 

UI 지침 ⭐

UI 지침(Guildeline) 개념

: UI 표준에 따라 사용자 인터페이스 설계, 개발 시 지켜야 할 세부 사항을 규정하는 가이드라인

소프트웨어 개발 단계별 UI 지침
목표정의 프로젝트 계획 요구사항 정의 설계 및 구현  테스트 배포 및 관리
· 환경분석
· UI 개발 목표 및 범위 정의
 · 사용자 분석 및 니즈 조사 · 사용자 요구사항 도출
· UI 컨셉션 정의
 · UI 상세 설계
· UI 화면 디자인
· UI 검증
 · 사용성 테스트 실행, 결과분석
 · 메뉴얼 배포, 관리

 

 

UI 표준 적용을 위한 환경 분석

구분 설명
사용자 트렌드 분석 · 현재 UI의 단점 파악 및 트렌드 숙지
· 사용자가 필요로 하는 핵심 요구사항 파악
· 사용자가 쉽게 이해 가능한 기능을 위주로 기술 영역 정의
기능 및 설계 분석 기능 조작성 분석 · 사용자 편의성 확대를 위한 조장 기능 확인
· 스크롤바 지원 가능 여부 확인
· 마우스 조작 및 업무 처리시 동선 확인
오류 방지 분석 · 사용자 조작 시 오류에 대해 예상 가능한지 확인
· 사용자 의도와 관계없는 페이지 이동 여부 확인
· 기능 버튼명이 사용자 조작과 일치 여부 확인
최소한의 조작으로 업무 처리 가능 여부 확인 · 기능 특성에 맞는 UI 확인
· 조작 단계를 최소화하고 동선은 단순한지 확인
UI의 정보 전달력 확인 · 정보 제공 방식이 일관적이며 사용자가 쉽게 이해 가능한지 확인
· 사용자에게 정보 제공이 간결하고 명확한지 확인

 

 

UI 개발 목표 및 범위

: 성공적인 수행을 위해 내부 관계자에게 UI 개발 필요성 및 목표를 공유하고 개발 범위를 수립하기 위한 활동

1. UI 개발을 위한 주요 기법

기법 설명
3C 분석 고객, 자사와 경쟁사를 비교 분석 하여 자사를 차별화 하여 경쟁에서 이길 것인가 분석
SWOT 분석 기업의 내부환경과 외부환경을 분석하여 강점, 약점, 기회, 위협요인을 규정하고 이를 토대로 경영 전략을 수립
시나리오 플래닝 불확실성이 높은 상황 변화를 사전에 예측하고 다양한 시나리오를 성계하는 방법으로 불확실성을 제거
사용성 테스트 사용자가 직접 제품을 사용하면서 미리 작성된 시나리오에 맞추어 과제를 수행한 후, 질문에 답하도록 하는 테스트
워크숍 소집단 정도의 인원으로 특정 문제나 과제에 대한 새로운 지식, 기술, 아이디어, 방법들을 서로 교환하고 검토하는 연구회 및 세미나

 

 

사용자 분석 및 니즈(Needs) 조사

· 최신 트렌드, 경쟁사 동향을 통해 정의된 핵심 기능 관련, 예상 타깃 고객층의 프로파일을 기술하고 정의

· 리서치 대상 선정 및 내용 설계, 리서치 진행, 리서치 결과 정리

 

 

사용자 요구사항 도출 순서

수행 활동 설명 세부 수행 활동
페르소나 정의 잠재적 사용자의 다양한 목적과 관찰된 행동 패턴을 응집시켜 놓은 가상의 사용자 · 페르소나 분류 및 정의
· 페르소나 작성
· 페르소나 활욜
콘셉트 모델 정의 여러가지 추상적인 콘셉트들 사이의 관계를 보여주는 다이어그램 · 콘셉트 모델 정의
· 브레인스토밍 활용
사용자 요구사항 정의 리서치 및 페르소나 결과물을 토대로 요구사항을 도출하고, 우선순위를 정함 · 요구사항 매트릭스 작성
· 정황 시나리오 제작 및 요구사항 도출
UI 컨셉션 정리된 요구사항을 구체화 하는 단계 · 정보 구조 설계
· 대표 화면 와이어프레임 스케치
· 페이퍼 프로토타입을 통한 스토리보드 설계

 

 

스토리보드 ⭐⭐

· UI 설계를 위해서 정책이나 프로세스 및 콘텐츠의 구성, 와이어프레임(UI, UX), 기능에 대한 정의, 데이터베이스의 연동 등 구축하는 서비스를 위한 대부분 정보가 수록된 문서

· 디자이너와 개발자가 최종적으로 참고하는 산출 문서

· UI 화면 설계를 위해서는 와이어프레임, 스토리보드, 프로토타입이 활용된다.

구분 설명 도구
와이어프레임 이해 관계자들과의 화면구성을 협의하거나 서비스의 간략한 흐름을 공유하기 위해 화면단위의 레이아웃을 걸계하는 작업 파워포인트, 키노트, 스케치, 일러스트
스토리보드 정책, 프로세스, 콘텐츠 구성, 와이어프레임, 기능 정의, 데이터베이스의 연동 등 서비스 구축을 위한 모든 정보가 담겨있는 설계 산출물 파워포인트, 키노트, 스케치
프로토타입 정적인 화면으로 설계된 와이어프레임 또는 스토리보드에 동적 효과를 적용하여 실제 구현된 것처럼 시뮬레이션할 수 있는 모형 HTML/CSS

 

· 스토리보드 작성 절차

　└ 전체 개요 작성 → 서비스 흐름 작성 → 스타일 확정 → 메뉴별 화면 설계도 작성 및 상세 설명 → 추가 관련 정보 작성

 

 

UI 프로토타입 제작 및 검토 ⭐

· 컴퓨터 시스템이나 소프트웨어의 설계 또는 성능, 구형 가능성, 운용 가능성을 평가하거나 요구사항을 좀 더 잘 이해하고 결정하기 위하여 전체적인 기능을 간략한 형태로 구현한 시제품

· 사전에 프로토 타입을 먼저 제작하고 이를 기반으로 UI의 적정성을 평가, 수정 보완함으로써 추후 발생 가능한 오류들을 사전에 방지하는 효과가 있다

· 장점 및 단점

장점 단점
· 사용자 설득과 이해가 쉬움
· 개발 시간 감소
· 오류 사전 발견을 통한 예방 가능
 · 수정 과정 증가 시, 작업 시간 증가 위험 존재
· 요구사항에 대한 적절한 타협 필요
· 자원 효율성 관점에서는 필요 이상의 많은 자원 소모

 

TEST  →  정답은 드래그!

정답 문제
UI 넓은 의미에서 사용자와 시스템 사이에서 의사소통할 수 있도록 고안된 물리적, 가상의 매개체이다.
GUI UI 유형 중 명령어를 그래픽 환경을 기반으로 한 마우스나 전자펜을 이용하는 사용자 인터페이스이고, 그래픽 반응 기반 인터페이스이다.
NUI UI 유형 중 사용자가 가진 경험을 기반으로 키보드나 마우스 없이 신체 부위를 이용하는 사용자 인터페이스이고, 터치, 음성을 포함하는 직관적 사용자 반응 기반 인터페이스이다.
CLI UI 유형 중 명령어를 텍스트로 입력하여 조작하는 사용자 인터페이스이고, 정적인 텍스트 기반 인터페이스이다.
OUI UI 유형 중 입력장치가 곧 출력장치가 되고, 현실에 존재하는 모든 사물이 입출력장치로 변화할 수 있는 사용자 인터페이스이고, 유기적 상호 작용 기반 인터페이스이다.
직관성 UI 설계 원칙 중 누구나 쉽게 이해하고, 쉽게 사용할 수 있어야 함을 나타내는 원칙이고, 부특성에는 쉬운 검색, 쉬운 사용성, 일관성이 있다.
유효성 UI 설계 원칙 중 정확하고 완벽하게 사용자의 목표가 달성될 수 있도록 UI를 제작할 수 있는 원칙이고, 부특성에는 쉬운 오류 처리 및 복구가 있다.
학습성 UI 설계 원칙 중 초보와 숙련자 모두가 쉽게 배우고 사용할 수 있도록 UI를 제작할 수 있는 원칙이고, 부특성에는 쉽게 학습, 쉬운 접근, 쉽게 기억이 있다.
유연성 UI 설계 원칙 중 사용자의 인터랙션을 최대한 포용하고, 실수를 방지할 수 있도록 UI를 제작할 수 있는 원칙이고, 부특성에는 오류 예방, 실수 포용, 오류 감지가 있다.
사용자 중심 UI 설계 지침 중 사용자가 이해하기 쉽고 편하게 사용할 수 있는 환경을 제공하며 실사용자에 대한 이해가 바탕이 되어야 한다는 설계 지침이다.
일관성 버튼이나 조작 방법을 사용자가 기억하기 빠르고 쉽게 습득할 수 있도록 설계해야 한다는 설계 지침이다.
단순성 조작 방법은 가장 간단하게 작동되도록 하여 인지적 부담 최소화해야 한다는 설계 지침이다.
결과 예측 작동시킬 기능만 보고도 결과 예측이 가능해야 한다는 설계 지침이다.
가시성 주요 기능을 메인 화면에 노출하여 쉬운 조작이 가능해야 한다는 설계 지침이다.
접근성 사용자의 직무, 연령, 성별 등이 고려된 다양한 계층을 수용해야 한다는 설계 지침이다.
기능성 UI 품질 요구사항 중 실제 수행 결과와 품질 요구사항과의 차이를 분석하고, 실제 사용 시 정확하지 않은 결과가 발생할 확률과 관련하여 시스템의 동작을 관찰하기 위한 품질 기준이다.
신뢰성 UI 품질 요구사항 중 시스템이 일정한 시간 또는 작동되는 시간동안 의도하는 기능을 수행함을 보증하는 품질 기준이다.
사용성 UI 품질 요구사항 중 사용자와 컴퓨터 사이에 발생하는 어떠한 행위를 정확하고 쉽게 인지할 수 있는 품질 기준이다.
효율성 UI 품질 요구사항 중 할당된 시간에 한정된 자원으로 얼마나 빨리 처리할 수 있는가에 대한 품질 기준이다.
UI 표준 디자인 철학과 원칙 기반하에 전체 시스템에 공통으로 적용되는 화면 간 이동, 화면구성 등에 관한 규약이다.
UX 제품과 시스템, 서비스 등을 사용자가 직·간접적으로 경험하면서 느끼고 생각하는 총체적 경험이다.
UI 스타일 가이드 UI의 통일과 일관적인 화면을 위해서 시스템이 지켜야 할 UI 요소 정의와 화면설계원칙을 제시하여 디자이너 또는 개발자들이 웹사이트의 관련 분야 업무를 수행 할 때 지켜야 하는 규칙 문서이다.
레이아웃 UI 스타일 가이드에서 화면 구조 정의, 상단 메뉴 구성 정의, 좌측 메뉴 구성 정의, 내용 구성 정의, 하단 메뉴 구성 정의, 사용 환경에 맞춰 페이지 폭 정의로 구성되어 있다.
UI 지침 UI 표준에 따라 사용자 인터페이스 설계, 개발 시 지켜야할 세부 사항을 규정한다.
3C 분석 고객, 경쟁하고 있는 자사와 경쟁사를 비교, 분석하여 자사를 어떻게 차별화해서 경쟁에서 이길 것인가를 분석하는 기법이다.
SWOT 분석 기업의 내부환경과 외부 환경을 분석하여 강점, 약점, 기회, 위협 요인을 규정하고 이를 토대로 경영 전략을 수립하는 방법이다.
시나리오 플래닝 불확실성이 높은 상황 변화를 사전에 예측하고 다양한 시나리오를 설계하는 방법으로 불확실성을 제거해나가려는 경영 전략의 한 방법이다.
리서치 지식에 대한 탐구를 기반으로 한 인간 활동이며, 이미 존재하던 지식의 발견, 해석, 정정, 재확인 등에 초점을 맞추는 체계적인 조사를 말한다.
페르소나 사용자 요구사항 도출을 위하여 잠재적 사용자의 다양한 목적과 관찰된 행동 패턴을 응집시켜 놓은 가상의 사용자이다.
UI 컨셉션 정리된 요구사항을 구체화하는 단계로 화면 디자인 단계 전에 대표 화면 설계를 진행하는 단계이다.
사용성 테스트 사용자가 직접 제품을 사용하면서 미리 작성된 시나리오에 맞추어 과제를 수행한 후 질문에 답하도록 하는 테스트이며, 현 제품에 대한 사용자의 요구사항과 행동을 관찰할 수 있는 유용한 진단방법이다.
스토리보드 UI 화면 설계를 위해서 정책이나 프로세스 및 콘텐츠의 구성, 와이어 프레임(UI,UX), 기능에 대한 정의, 데이터베이스의 연동 등 구축하는 서비스를 위한 대부분 정보가 수록된 문서이다.
와이어 프레임 이해관계자들과의 화면구성을 협의하거나 서비스의 간략한 흐름을 공유하기 위해 화면 단위의 레이아웃을 설계하는 작업이다.
프로토타입 컴퓨터 시스템이나 소프트웨어의 설계 또는 성능, 구현 가능성, 운용 가능성을 평가하거나 요구사항을 좀 더 잘 이해하고 결정하기 위하여 전체적인 기능을 간략한 형태로 구현한 시제품이다.
이해성 사용성의 부특성 중 소프트웨어의 논리적인 개념과 적용 가능성을 분간하는 데 필요한 사용자의 노력 정도에 따른 소프트웨어 특성이다.
학습성 사용성의 부특성 중 소프트웨어 애플리케이션을 익히는 데 필요한 사용자의 노력 정도에 따른 특성이다. 
운용성 사용성의 부특성 중 소프트웨어의 활용과 운용 통제에 필요한 사용자의 노력정도에 따른 특성이다.
적절성 기능성의 부특성 중 소프트웨어 제품이 주어진 작업과 사용자의 목표에 필요 적절한 기능들을 제공해 줄 수 있는 소프트웨어의 능력이다.
정밀성 기능성의 부특성 중 소프트웨어 제품이 요구되는 정확도로 올바른 결과를 산출할 수 있는 능력이다.
UI 설계 도구 사용자와 시스템 사이에 의사소통할 수 있도록 일시적 또는 영구적인 접근을 목적으로 만들어진 물리적, 가상적 매개체인 UI의 설계를 지원하는 도구이다.
화면 설계 도구 UI 설계 도구 중 파워 목업, 발사믹 목업, 카카오 오븐이 있다.
프로토타입 도구 UI 설계 도구 중 UX핀, 액슈어, 네이버 프로토나우가 있다.
UI 디자인 UI 설계 도구 중 스케치, 어도비 익스피리언스 디자인CC가 있다.

 

 

 

 

※ 해당 글은 수제비 2022 도서 참고하였습니다.

 

수제비- IT 커뮤니티 (정보처리기사... : 네이버 카페

수제비-수험생 입장에서 제대로 쓴 비법서(정보처리기사, 정보처리기능사, 빅데이터 분석기사 등 시리즈)

cafe.naver.com

 

 

'정보처리기사' 카테고리의 다른 글

Ⅲ 데이터 입출력 구현 - 논리 데이터 저장소 확인  (2) 2023.02.02
Ⅱ 화면설계 - UI 설계  (1) 2023.01.31
[2023] 정보처리기사 시험 일정  (0) 2023.01.05
Ⅰ 요구사항 확인 - 분석 모델 확인하기  (0) 2022.12.02
Ⅰ 요구사항 확인 - 요구사항 확인  (0) 2022.12.01

2023 정보처리기사 시험일정

정보처리기사 필기

차수 원서접수 기간 시험 기간 합격자 발표 응시자격 서류 제출
1차 2023.01.10.(화) ~ 2023.01.19.(목) 2023.02.13.(월) ~ 2023.03.15.(수)
 2023.03.21.(화)
 2023.02.13.(월) ~ 2023.03.31.(금)
빈자리접수 : 2023.02.07~2023.02.08
2차 2023.04.17.(월) ~ 2023.04.20.(목) 2023.05.13.(토) ~ 2023.06.04.(일) 2023.06.14.(수) 2023.05.15.(월) ~ 2023.06.23.(금)
3차 2023.06.19.(월) ~ 2023.06.22.(목) 2023.07.08.(토) ~ 2023.07.23.(일) 2023.08.02.(수) 2023.07.10.(월) ~ 2023.08.11.(금)

 

정보처리기사 실기

차수 원서접수 기간 시험 기간 합격자 발표
1차 2023.03.28.(화) ~ 2023.03.31.(금) 2023.04.22.(토) ~ 2023.05.07.(일) 2023.06.09.(금) ~ 2023.08.08.(화)
2차 2023.06.27.(화) ~ 2023.06.30.(금) 2023.07.22.(토) ~ 2023.08.06.(일) 2023.09.01.(금) ~ 2023.10.31.(화)
3차 2023.09.04.(월) ~ 2023.09.07.(목) 2023.10.07.(토) ~ 2023.10.20.(금) 2023.11.15.(수) ~ 2024.01.14.(일)

 

 

 

모두들 합격을 기원합니다!!!

'정보처리기사' 카테고리의 다른 글

Ⅱ 화면설계 - UI 설계  (1) 2023.01.31
Ⅱ 화면설계 - UI 요구사항 확인  (0) 2023.01.30
Ⅰ 요구사항 확인 - 분석 모델 확인하기  (0) 2022.12.02
Ⅰ 요구사항 확인 - 요구사항 확인  (0) 2022.12.01
Ⅰ 요구사항 확인 - 현행 시스템 분석  (0) 2022.11.17

분석 모델 검증 ⭐

 : 요구사항 도출 기법을 활용하여 업무 분석가가 제시한 분석 모델에 대해서 확인하는 활동

분석 모델 검증 방법

검증 방법 설명
유스케이스 모델 검증 · 시스템 기능에 대한 유스케이스 모형 상세화 수준 및 적정성 검증을 위해 액터, 유스케이스, 유스케이스 명세서 점검
개념 수준의 분석 클래스 검증 · 주요 클래스 도출 여부, 도출된 클래스 이름과 속성의 적절성, 올바른 클래스들 간의 관계 여부 점검
분석 클래스 검증 · 유스케이스 실현에 필요한 분석 클래스 도출 확인
· 클래스 간의 관계, 클래스 정보의 상세화 정도 확인

 

 

분석 모델 검증 프로세스

검증 프로세스 설명
검토의견 컬럼 추가 · 분석 모델까지 요구사항 추적표를 작성하고 검토의견 컬럼 추가
검토의견 작성 · 유스케이스 모델 / 개념 수준 분석 클래스 모델 / 분석클래스 모델에 대한 검토의견 작성
검토의견 정제 · 요구사항 추적표에서 요구사항에 대한 검토의견 정제
· 누락된 유스케이스 모델 / 개념 수준 분석 클래스 / 분석클래스가 존재하는 경우, 검토의견 추가

 

 

분석 모델의 시스템화 타당성 분석 ⭐

: 업무 분석가가 제시한 분석 모델이 개발할 응용 소프트웨어에 미칠 영향을 검토하여 기술적 타당성을 조사하는 활동

분석 모델의 기술적 타당성 검토

: 유스케이스 모델의 개별 유스케이스에 대한 분석 모델을 작성한 후, 해당 분석모델로 시스템을 개발할 경우에 대한 영향을 필요한 자원, 상호 운용성, 시장 성숙도, 기술적 위험 분석 측면으로 타당성 조사

 

1. 성능 및 용량 산정의 적정성

- 요구사항을 만족시키기 위한 분석 모델에 따라 시스템을 구현할 때 요구되는 시스템의 자원 식별

- 분석 클래스에서 불필요 속성을 많이 포함하게 되면 객체 생성 시 시스템 메모리 자원이 많이 요구되며, 전체 시스템 성능 저하 발생

 

2. 시스템 간 상호 운용성

- 시스템 간 상호 정보 및 서비스가 교환 가능한지 검토

- 분석 모델에서 정의한 구체적인 정보의 존재 여부, 생성 가능성, 교환 방식 지원 등에 대하여 확인

 

3. IT 시장 성숙도 및 트렌드 부합성

- 분석 모델이 과거의 문제를 해결하고 최근 많이 사용되는 트렌드에 부합되는지 확인

- 분석 자동화 도구 활용 방안 고려

 

4. 기술적 위험 분석

- 분석모델이 시스템의 기술 구조, 프레임워크, 사용되는 하드웨어 및 소프트웨어와 부합되는지 확인

- 분석 모델이 검증되지 않은 기술의 사용을 가정하고 있어 추가적인 비용 발생 가능성이 있는지 확인

- 분석 모델을 구현하기 위하여 특정 업체 기술, 특허, 라이선스에 의존해야 하는지 확인

 

 

분석 모델의 시스템화 타당성 분석 프로세스

분석 프로세스 설명
타당성 검토의견 컬럼 추가 · 분석 모델까지 요구사항 추적표를 작성하고 타당성 검토의견 컬럼 추가
타당성 검토의견 작성 · 작성된 요구사항 추적표에 타당성 검토의견 작성
타당성 분석 결과 검증 · 타당성 분석 결과를 관련 이해관계자에게 배포하여 사전 검토 요청
· 관련 이해관계자가 모여 분석 모델 타당성 분석 결과 검증
타당성 분석 결과 확인 및 배포 / 공유 · 이해관계자 검증을 거친 타당성 분석 결과를 의사 결정자 확인 후 배포 공유

 

 

 

※ 해당 글은 수제비 2022 도서 참고하였습니다.

 

수제비- IT 커뮤니티 (정보처리기사... : 네이버 카페

수제비-수험생 입장에서 제대로 쓴 비법서(정보처리기사, 정보처리기능사, 빅데이터 분석기사 등 시리즈)

cafe.naver.com

 

'정보처리기사' 카테고리의 다른 글

Ⅱ 화면설계 - UI 요구사항 확인  (0) 2023.01.30
[2023] 정보처리기사 시험 일정  (0) 2023.01.05
Ⅰ 요구사항 확인 - 요구사항 확인  (0) 2022.12.01
Ⅰ 요구사항 확인 - 현행 시스템 분석  (0) 2022.11.17
Ⅰ 요구사항 확인 - 소프트웨어 개발 방법론  (1) 2022.11.17

요구사항 ⭐⭐⭐

요구사항 개념

1. 요구공학의 개념 :  사용자의 요구가 반영된 시스템 개발을 위해 요구사항에 대한 도출, 분석, 명세 확인 및 검증하는 구조화된 활동

 

2. 요구공학의 목적 

- 이해관계자 사이에 효과적 의사소통 수단 제공, 시스템 개발의 요구사항에 대한 공통된 이해 설정

- 요구사항 누락 방지 및 이해 오류로 인한 불필요 비용 절감, 요구사항 변경 추적 용이

- 초기 요구사항 관리로 개발 비용과 시간 절약, 효과적인 의사소통 수단 제공

 

3. 요구사항의 분류

구분 기능적 요구사항 비기능적 요구사항
개념 · 시스템이 제공하는 기능, 서비스 · 시스템 구축에 대한 제약사항
도출
방법		 · 특정 입력에 대한 반응
· 특정 상황에 대한 동작
 · 품질 속성에 관련하여 시스템이 갖춰야 할 사항
· 시스템이 준수해야할 제한 조건
특성 · 기능성, 완전성, 일관성  · 신뢰성, 사용성, 효율성, 유지보수성, 이식성, 보완성 및 품질관련 요구사항, 제약사항 
사례 · 상품의 결제수단은 신용카드, 무통장입금, 포인트 결제가 가능해야함  · 특정 함수의 호출시간은 3초를 넘지 않아야 함 

 

 

요구공학 프로세스 : 요구사항 개발 단계와 요구사항 관리 단계로 구성

1. 요구사항 개발 단계 (CMM Level 3 프로세스 영역)

도출 분석 명세 확인
 · 요구사항 소스
 · 도출 기법


  · 요구사항 분류
 · 개념 모델링
 · 기술 구조 설계 및 요구사항 할당
 · 요구사항 협상
  · 시스템 정의서
 · 시스템 요구사항 명세서
 · 소프트웨어 요구사항 명세서

  · 검토 
 · 프로토타이핑
 · 모델 검증
 · 인수 테스트

 

2. 요구사항 개발 단계 상세

- 요구사항 도출 단계 : 소프트웨어가 해결해야 할 문제를 이해하고, 고객으로부터 제시되는 추상적 요구에 대해 관련 정보를 식별하고 수집 방법 결정, 수집된 요구사항을 구체적으로 표현하는 단계

주요기법 설명
인터뷰 이해관계자와 직접 대화해 공식적/비공식적 정보 수집
브레인스토밍 대화하기 편한 분위기를 조성해 아이디어를 비판없이 수용하는 회의
델파이기법 전문가의 경험지식을 통한 문제해결, 미래예측
롤플레잉 현실 장면을 설정하고 각자 맡은 역할을 연기해 요구사항 분석 및 수집
워크숍 단기간 집중을 통해 전문적 정보 획득, 공유. 프로젝트 핵심인물참여 필요. 사전 준비 요구
설문조사 설문지, 여론 조사로 간접적 정보 수집. 다수의 의견수렴 용이.

- 요구사항 분석 단계 : 추출된 요구사항에 대해 충돌, 중복, 누락 등의 분석을 통해 완전성과 일관성을 확보하는 단계

　　└  절차

순서 절차 설명
1 요구사항 분류 · 요구사항이 기능/비기능 확인
· 요구사항이 SW에 미치는 영향 범위 파악
· 요구사항이 SW 생명주기 동안 변경이 발생하는지 확인
· 하나 이상의 상위 요구사항에서 유도된 것인지 or 이해관계자나 다른 원청으로부터 직접 발생한 것인지 분류
2 개념 모델링 생성 및 분석 · 모델링 : 요구사항을 쉽게 이해할 수 있도록 단순화, 개념적으로 표현한 것 → 모델링을 만드는 활동
· 개념모델 : 문제 도메인의 엔티티들과 개별 관계 및 종속성을 반영
· 다양한 개념모델 작성 가능  →  유스케이스 다이어그램, 데이터 흐름 모델, 상태 모델, 목표기반 모델, 사용자 인터랙션, 객체 모델, 데이터 모델
· 모델링 표기는 주로 UML 사용
3 요구사항 할당 · 요구사항에 만족하기 위한 아키텍처 구성요소를 식별하는 활동
· 다른 구성요소와 어떻게 상호 작용하는지 분석을 통해 추가적인 요구사항 발견 가능
4 요구사항 협상 · 두 명의 이해관계자의 의견이 상충되는 경우 적절한 지점에서 합의하기 위한 활동
5 정형 분석 · 형식적으로 정의된 의미를 지닌 언어로 요구사항을 표현하는 활동
· 구문과 의미를 갖는 정형화된 언어를 사용하여 수학적 기호로 표현
· 요구사항 분석의 마지막 단계

 

　　└  기법

　　　- 자료흐름지향 분석 : 데이터 흐름도, 자료 사전으로부터 SW 구조 유도 방법

　　　- 객체지향 분석 : 시스템 기능과 데이터 분석, UML로 표준화

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

 

- 요구사항 명세 단계 :  체계적으로 검토, 평가, 승인될 수 있는 문서(요구사항 명세서)를 작성하는 단계

　　└ 기법

비정형 명세기법 요구표현을 자연어로 서술.
명확성 및 검증에 문제. 사용자와 개발자의 이해가 용이.
정형 명세기법 요구표현을 수학적 원리와 표기법으로 서술. 정형 명세인 Z-스키마, Petri Nets, 상태차트 활용.
표현 간결, 명확성 및 검증 용이. 기법 이해 어려움.

　　　

　　└ 요구사항 명세 원리 및 검증 항목 : 명확성, 완전성, 검증 가능성, 일관성, 수정 용이성, 추적 가능성, 개발 후 이용성

 

- 요구사항 확인 및 검증 단계 : 요구사항 명세서에 사용자의 요구가 올바르게 기술되었는지에 대한 검토, 베이스라인을 설정하는 활동

　　└ 순서 : 요구사항 목록 확인 → 요구사항 정의서 작성 여부 확인 → 비기능적 요구사항 확인 → 타 시스템 연계, 인페 요구사항 확인

　　└  주요 기법

주요 기법 설명
요구사항 검토  · 요구사항 명세서의 오류 확인 및 표준 준수 여부 등의 결함 여부를 검토
 · 담당자들이 수작업으로 분석
정형 기술 검토  동료검토  · 2~3명 리뷰 진행. 
 · 작성자가 요구사항 명세서를 설명하고, 이해관계자들이 들으면서 결함을 발견하는 형태로 진행. 
워크스루  · 검토 자료를 회의 전에 미리 배포하여 짧은 시간동안 회의를 진행하는 형태로 리뷰를 통해 오류 검출. 
 · 사전검토
인스펙션  · 소프트웨어 요구, 설계 원시 코드 등의 작성자 외의 다른 전문가 or 팀이 검사하여 오류를 찾아내는 공식적 검토 방법
프로토타이핑   · 실제 개발될 소프트웨어의 견본품을 만들어 최종 결과물 예측
모델 검증  · 분석단계에서 개발된 모델의 품질 검증 필요
 · 정적 분석 수행에 유용
테스트 케이스 및 테스트를 통한 확인  · 테스트 케이스를 생성하고 이후 요구사항이 현실적으로 테스트 가능한지를 검토
 · 인수테스트에는 알파 테스트와 베타 테스트가 있음
CASE 도구 활용  · 일관성 분석을 통해 요구사항 변경사항의 추적 및 분석, 관리, 표준 준수 여부 확인. 
 · 자동화된 요구 사항 관리 도구 이용
베이스 라인 검증  · 요구사항 변경을 체계적으로 추적하고 통제하는 시점인 베이스라인을 통한 요구사항에 대한 지속적 검층 수행
요구사항 추적표  · 요구사항 정의서를 기준으로 개발단계별 최종 산출문의 반영과 변경을 확인가능한 문서

 

　　└  상세 정형 기술 검토 기법 : 관리리뷰, 기술리뷰, 인스펙션(== 동료검토), 워크스루, 감사

 

3. 요구사항 관리 단계 (CMM Level 2 프로세스 영역)

- 프로젝트 진행 과정에서 발생하는 요구사항의 변경에 대해 일치성과 무결성을 제공하기 위해 변경제어와 추적 등 일련의 관리를 수행하는 활동

 

 

TEST  →  정답은 드래그!

정답 문제
요구공학 사용자의 요구가 반영된 시스템을 개발하기 위하여 사용자 요구사항에 대한 도출, 분석, 명세, 확인 및 검증하는 구조화된 활동이다.
비기능적 요구사항 시스템이 수행하는 기능 이외의 사항, 시스템 구축에 대한 제약사항에 관한 요구사항으로, 품질 속성에 관련하여 시스템이 갖춰야 할 사항에 관하여 기술한다.
기능적 요구사항 시스템이 제공하는 기능, 서비스에 대한 요구사항으로, 특정 입력에 대해 시스템이 어떻게 반응해야 하는지에 대해 기술한다.
브레인스토밍 말을 꺼내기 쉬운 분위기로 만들어 회의 참석자들이 내놓는 아이디어들을 비판없이 수용할 수 있도록 하는 회의이다.
롤 플레잉 현실에 일어나는 장면을 설정하고 여러 사람이 각자가 맡은 역을 연기함으로써 요구사항을 분석하고 수집하는 방법이다.
워크숍 단기간의 집중적인 노력을 통해 다양하고 전문적인 정보를 획득하고 공유하는 방법으로 프로젝트에 참여하는 모든 핵심 인물의 참여가 필요하고, 참석자들은 해당 전문 영역별로 팀 협력이 필요하며 사전 준비가 요구된다.
UML 객체 지향 소프트웨어 개발 과정에서 산출물을 명세화, 시각화, 문서화 할 시 사용되는 모델링 기술과 방법론을 통합해 만든 표준화된 범용 모델링 언어이다.
비정형 명세 기법 명세 기법 중에서 사용자의 요구를 표현할 때 자연어를 기반으로 서술하는 기법으로 사용자와 개발자의 이해가 용이하지만, 명확성 및 검증에 문제가 있다.
정형 명세 기법 사용자의 요구를 표현할 때 수학적인 원리와 표기법으로 서술하는 기법으로, Z-스키마, Petri Nets, 상태 차트를 활용하여 표현한다.
인스펙션 정형 기술 검토 기법 중 소프트웨어 요구, 설계, 원시 코드 등의 저작자 외의 다른 전문가 또는 팀이 검사하여 문제를 식별하고 문제에 대한 올바른 해결을 찾아내는 형식적인 검토 기법이다.
워크스루 정형 기술 검토 기법 중 컴토 자료를 회의 전에 배포해서 사전 검도한 후 짧은 시간 동안 회의를 진행하는 형태로 리뷰를 통해 문제 식별, 대안 조사, 개선 활동, 학습 기회를 제공하는 가장 비형식적인 검토 기법이다.
감사 소프트웨어 제품 및 프로세스가 규제, 표준, 가이드라인, 계획, 절차를 준수하고 있는지를 독립적으로 평가하는 기법으로 소프트웨어 제품의 제공자, 소비자, 제3기관이 수행한다.

 

 

 

 

 

※ 해당 글은 수제비 2022 도서 참고하였습니다.

 

수제비- IT 커뮤니티 (정보처리기사... : 네이버 카페

수제비-수험생 입장에서 제대로 쓴 비법서(정보처리기사, 정보처리기능사, 빅데이터 분석기사 등 시리즈)

cafe.naver.com

 

'정보처리기사' 카테고리의 다른 글

Ⅱ 화면설계 - UI 요구사항 확인  (0) 2023.01.30
[2023] 정보처리기사 시험 일정  (0) 2023.01.05
Ⅰ 요구사항 확인 - 분석 모델 확인하기  (0) 2022.12.02
Ⅰ 요구사항 확인 - 현행 시스템 분석  (0) 2022.11.17
Ⅰ 요구사항 확인 - 소프트웨어 개발 방법론  (1) 2022.11.17

현행 시스템 파악 ⭐⭐

현행 시스템 파악

1. 개념 : 현행 시스템의 어떤 기술 요소 사용을 하는지 파악하는 활동

 

2. 절차 : 구성/기능/인터페이스 파악 → 아키텍처 및 소프트웨어 구성 파악 → 하드웨어 및 네트워크 구성 파악

- 구성/기능/인터페이스 파악

　　└  구성 현황 파악 : 조직의 주요 업무를 처리하는 기간 업무, 이를 지원하는 지원업무로 구분

　　└  기능 현황 파악 : 단위 업무 시스템이 현재 제공 중인 기능 파악 / 주요 기능과 하부 기능을 구분하여 계층형으로 표시

　　└  인터페이스 파악 : 단위 업무 시스템이 다른 시스템과 주고받는 데이터의 종류, 형식, 프로토콜 등을 파악 / 통신규약, 데이터 형식 (XML, 고정포맷)

- 아키텍처 및 소프트웨어 구성 파악

　　└  아키텍처 파악 : 업무 수행을 위해 계층별 사용 기술 요소를 최상위 수준에서 파악

　　└  소프트웨어 파악 : 단위 업무 시스템의 업무 처리를 위해 설치된 소프트웨어 파악 / WAS - Apache Tomcat, DB - MySQL

- 하드웨어 및 네트워크 구성 파악

　　└  하드웨어 파악 : 단위 업무 시스템들이 운용되고 있는 서버 위치, 운용 서버의 주요 사양 등 파악

　　└  네트워크 구성 파악 : 업무 처리 시스템을 위해 어떤 네트워크 장비를 사용하는지 파악

 

 

현행 시스템 분석서 작성 및 검토

1. 현행 시스템 관련 자료 수집 및 분석

팀구성  취득자료 분석대상
정보시스템 구성/기능 및 인터페이스 자료 수집팀 정보시스템 구성도, 기능 구성도  정보시스템명, 구분, 주요기능, 기능구성
인터페이스 현황  송수신 시스템, 연동 데이터 형식, 주요 연동 데이터 등
현행 시스템 아키텍처 및 소프트웨어 자료 수집팀 현행 시스템 아키텍처 구성도  운영체제 종류, 적용 프레임워크, 계층별 적용기술 등
소프트웨어 구성도  단위 시스템별 필요 소프트웨어의 제품명 및 용도 등
하드웨어 및 네트워크 자료 수집팀 하드웨어 구성도  단위 시스템별 서버 제품명 및 용도, 이중화 적용 여부 등
네트워크 구성도  네트워크 장비의 용도 및 제품명, 장비 수량 및 주요사항, 위치 및 프로토콜

 

2. 분석 산출물 종류

- 정보시스템 구성 현황, 정보시스템 기능 구성도, 인터페이스 현황, 현행 시스템 아키텍처 구성도, 소프트웨어 구성도, 하드웨어 구성도, 네트워크 구성도

 

 

소프트웨어 아키텍처

1. 개념

- 여러 가지 소프트웨어 구성요소와 그 구성요소가 가진 특성 중 외부에 드러나는 특성
- 소프트웨어를 구성하는 요소들 간의 관계를 표현하는 시스템의 구조 or 구조체

 

2. 소프트웨어 아키텍처 프레임워크

- 소프트웨어 집약적인 시스템에서 아키텍처가 표현해야 하는 내용 및 이들 간 관계를 제공하는 아키텍처 기술 표준

- 구성요소 : 아키텍처 명세서, 이해관계자, 관심사, 관점, 뷰, 근거, 목표, 환경,  시스템

- 구성요소 해석

　　└  1..* : 1개이거나 더 많음(*)

　　└  0..1 : 0개이거나 1개

 

3. 소프트웨어 아키텍처 4+1뷰 (유논프구배)

- 고객의 요구사항을 정리해 놓은 시나리오를 4개의 관점에서 바라보는 소프트웨어적인 접근 방법

- 체크방법 : 유스케이스

뷰 설명
유스케이스 뷰 ·  유스케이스 or 아키텍처를 도출하고 설계하며 다른 뷰를 검증하는데 사용되는 뷰
논리 뷰 ·  시스템의 기능적인 요구사항이 어떻게 제공되는지 설명해주는 뷰
프로세스 뷰 ·   시스템의 비기능적인 속성으로 자원의 효율적인 사용, 병행 실행, 비동기, 이벤트 처리 등을 표현한 뷰
구현 뷰 ·  개발 환경 안에서 정적인 소프트웨어 모듈의 구성을 보여주는 뷰
·  컴포넌트 구조와 의존성을 보여주고 부가적인 정보 정의
배포 뷰 ·  컴포넌트가 물리적인 아키텍처에 어떻게 배치되는가를 매핑해서 보여주는 뷰

 

4. 소프트웨어 아키텍처 패턴 : 소프트웨어를 설계할 때 참조할 수 있는 전형적인 해결 방식, 재사용 가능한 솔루션

유형 설명
계층화 패턴 (Layered) ·  시스템을 계층으로 구분하여 구성하는 패턴
클라이언트-서버 패턴 · 하나의 서버와 다수의 클라이언트로 구성된 패턴
· 서버는 계속 클라이언드로부터 요청을 대기
파이프-필터 패턴 · 데이터 스트림을 생성하고 처리하는 시스템에서 사용 가능한 패턴
· 재사용성 & 추가가 쉬워 확장에 용이
브로커 패턴 · 분리된 컴포넌트들로 이루어진 분산 시스템에서 사용
· 각 컴포넌트를 원격 서비스 실행을 통해 상호작용이 가능
모델-뷰-컨트롤러 패턴
(MVC)		 · 대형 애플리케이션을 3개의 서브 시스템으로 구조화한 패턴
· 컴포넌트로 분리되어 있어 서로 영향을 받지 않고 개발 작업 수행 가능
모델 핵심 기능과 데이터 보관
뷰 사용자에게 정보 표시
컨트롤러  사용자로부터 요청을 입력받아 처리

 

5. 소프트웨어 아키텍처 비용 평가 모델 : 아키텍처 접근법이 품질 속성에 미치는 영향 판단, 적합성을 평가하는 모델

- 종류 : SACAA(사카)

종류 설명
SAAM · 변경 용이성과 기능성에 집중, 경험이 없는 조직에서도 활용 가능 모델
ATAM · 아키텍처 품질 속성을 만족시키는지 판단 및 품질 속성들의 이해 상충관계까지 평가 모델
· SAAM 계승하여 발전
CBAM · ATAM 바탕의 시스템으로 경제적 의사결정에 대한 요구 충족 모델
ADR · 소프트웨어 아키텍처 구성요소 간 응집도 평가 모델
ARID · 전체 아키텍처가 아닌 특정 부분에 대한 품질요소에 집중 모델
· ATAM + ADR

 

 

디자인 패턴 : 소프트웨어 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계 방법을 정리한 패턴

1. 유형

구분 유형 설명
목적 생성  객체 인스턴스 생성에 관여, 클래스 정의와 객제 생성방식을 구조화, 캡슐화를 수행하는 패턴
구조  클래스나 객체의 조합을 다루는 패턴
행위  클래스나 객체들이 상호작용하는 방법과 역할 분담을 다루는 패턴
범위 클래스  상속 관계를 다루는 패턴, 컴파일 타임이 정적으로 결정
객체  객체 간 관련성을 다루는 패턴, 런타임에 동적으로 결정

 

2. 종류

 

- 생성 패턴 (생 빌프로팩앱싱)

패턴 설명
Builder · 생성과 표기를 분리해서 복잡한 객체를 생성
· 복합 객체 생성 시 객체 생성 방법과 객체 구현 방법을 분리함으로써 동일한 생성 절차에서 서로 다른 표현 결과를 만들 수 있음.
Prototype · 처음부터 일반적인 원형을 만들어 놓고 그것을 복사한 후 필요한 부분만 수정해서 사용하는 패턴
Factory Method · 상위 클래스에서 객체를 생성하는 인터페이스를 정의하고, 하위 클래스에서 인스턴스를 생성하도록 하는 방식(하위클래스에서 오버라이딩)
Abstract Factory · 구체적인 클래스에 의존하지 않고 서로 연관되거나 의존적인 객체들의 조합을 만드는 인터페이스 제공
· 동일한 주제의 다른 팩토리 묶음
Singleton · 전역 변수를 사용하지 않고 객체를 하나만 생성하도록 하며, 생성된 객체는 어디서든지 참조할 수 있도록 함.

 

- 구조 패턴 (구 브데퍼플프록컴어)

패턴 설명
Bridge · 인터페이스(API)가 서로 다른 클래스 연결하는 패턴. 기능의 계층과 구현의 계층 연결
Decorator · 기존에 구현되어 있는 클래스에 필요한 기능을 추가해 나가는 설계 패턴
· 새로운 기능 추가될 때마다 새로운 객체 내부에서도 그대로 유지, 보장해줌
Facade · 서브 시스템 복잡할 경우 간단한 인터페이스 통해 서브시스템 주요 기능 사용 가능
Fly weight · 인스턴스 가능한 한 공유시켜 불필요한 생성을 하지 않도록 함
· 목적 : 클래스의 경량화
· 여러 개의 '가상 인스턴스'를 제공하여 메모리 절감
Proxy · 특정 객체 접근 제어하려는 목적으로 인터페이스 역할 하는 객체 사용하여 제어
Composite · 객체들의 관계를 트리 구조로 구성하여 부분-전체 계층을 표현하는 패턴
· 복잡한 객체 구조 표현하여 객체 집합 속에 또 다른 객체 집합 가짐
 Adapter · 기 생성된 클래스를 재사용할 수 있도록 중간에 맞춰주는 역할을 하는 인터페이스를 만드는 패턴
· 상속을 이용한 클래스 패턴과 위임을 이용한 인스턴스 패턴이 있음.
· 인터페이스가 호환 되지 않는 클래스들을 함께 이용할 수 있도록, 타 클래스의 인터페이스를 기존 인터페이스에 덧씌움

 

- 행위 패턴 (행 미인이템옵스테비커스트메체)

패턴 설명
Mediator(중재자) 수많은 객체들 간의 복잡한 상호작용을 캡슐화하여 객체로 정의
Interpreter(인터프리터) 언어에 문법표현을 정의
Iterator(반복자) 자료 구조와 같이 접근이 잦은 객체에 대해 동일한 인터페이스를 사용
Template Method 상위 클래스는 골격 정의, 하위클래스에서 세부처리를 구체화하는 구조
Observer 한 객체의 상태가 변화하면 객체에 상속되어 있는 다른 객체들에게 변화된 상태를 전달 (느슨한 결합)
State 객체의 상태에 따라 동일한 동작을 다르게 처리해야 할 때 사용
Visitor(방문자) 각 클래스의 데이터 구조에서 처리기능을 분리하여 별도의 클래스로 구성
Command 요청을 객체의 형태로 캡슐화하여 재이용하거나 취소할 수 있도록 요청에 필요한 정보를 저장하거나 로그에 남김
Strategy(전략) 동일계열 알고리즘 상호교환, 각각 동립사용. 영향없이 변동가능
Memento 특정 시점에서의 객체 내부 상태를 객체화함으로써 이후 요청에 따라 객체를 해당시점으로 돌릴 수 있음
Chain of Responsibility(연쇄책임) 요청을 처리할 수 있는 객체가 둘 이상 존재하여 한 객체가 처리하지 못하면 다음객체로 넘어가는 형태. 책임이 다음 차례로 넘어감

 

 

개발 기술 환경 정의 ⭐⭐⭐

개발 기술 환경 현행 시스템 분석

1. 운영체제 현행 시스템 분석

- 운영체제(Operating System) : 컴퓨터 사용자와 컴퓨터 하드웨어 간의 인터페이스를 담당하는 프로그램

- 운영체제 현행 시스템 분석 시 고려사항

　　└  품질 측면 : 신뢰도 - 장기간 시스템 운영시 장애 발생 가능성 / 성능 - 대규모 및 대량 파일 작업(배치) 처리

　　└  지원 측면 : 기술지원 - 오픈 소스 여부 / 주변 기기 - 설치 가능한 하드웨어 / 구축비용 - 지원 가능한 하드웨어 비용

- 운영체제 종류 및 특징

　　└  PC : 윈도우, 유닉스, 리눅스

　　└  모바일 : 안드로이드, IOS

　　└  리눅스 기반 시스템이 하드웨어 및 소프트웨어 소유 비용이 가장 적게 소요

 

2. 네트워크 현행 시스템 분석

- 현행 시스템이 구성된 네트워크 구조를 네트워크 구성도를 통해 분석

- 백본망, 라우터, 스위치, 게이트웨이, 방화벽 등을 대상으로 분석

- 네트워크의 개념 : 컴퓨터 장치들의 노드 간 연결(데이터 링크)을 사용하여 서로에게 데이터를 교환할 수 있도록 하는 기술

- OSI 7계층 : 네트워크 통신에서 충돌 문제를 완화하기 위해 국제 표준화 기구(ISO)에서 제시한 모델

계층 설명 프로토콜 전송단위
응용계층
(Application Layer)		 · 사용자와 네트워크 간 응용서비스 연결, 데이터 생성 HTTP, SMTP, FTP, DNS 데이터
표현 계층
(Presentation Layer)		 · 데이터 형식 설정과 부호교환, 암/복호화 JPEG, MPEG
세션 계층
(Session Layer)		 · 연결 접속 및 동기 제어
· 통신 시스템 사용자 간의 연결을 유지 및 설정		 SSH, TLS
전송 계층
(Transport Layer)		 · 신뢰성 있는 통신보장. 데이터 분할과 재조립.
· 흐름제어, 혼잡제어 등 담당		 * TCP : 신뢰성, 연결지향적 
* UDP : 비신뢰성, 비연결성, 실시간		 세그먼트
네트워크 계층
(Network Layer)		 · 단말 간 데이터 전송을 위한 최적화된 경로 제공(라우팅) IP, ICMP 패킷
데이터 링크 계층
(Data Link Layer)		 · 인접 시스템 간 데이터 전송, 전송 오류 제어
· MAC 주소를 가지고 통신, 물리계층에서 받은 정보를 전달. Point to Point
· 프레이밍, 흐름제어, 오류제어, 접근제어		 이더넷 프레임
물리 계층
(Physical Layer)		 · 0과 1의 비트 정보를 회선에 보내기 위한 전기적 신호 변환(on/off)
· 데이터를 전달만 함.		 RS_232C 비트

 

3. DBMS 현행 시스템 분석

- DBMS의 개념 : 데이터베이스라는 데이터의 집합을 만들고, 저장 및 관리할 수 있는 기능들을 제공하는 응용 프로그램

- DBMS의 기능

기능 설명
중복 제어 동일한 데이터가 여러 위치 중복 저장 방지
접근 통제 권한에 따라 데이터 접근 제어
인터페이스 제공 사용자에게 SQL 및 CLI, GUI 등 다양한 인터페이스 제공
관계 표현 서로 다른 데이터 간의 다양한 관계를 표현할 수 있는 기능 제공
샤딩/파티셔닝 구조 최적화를 위해 작은 단뒤로 나눔
무결성 제약 조건 무결성에 관한 제약 조건을 정의/검사
백업 및 회복 장애 발생시 데이터 보존

- DBMS 현행 시스템 분석

관점 고려 사항 설명
성능 측면 가용성 · 장기간 운영시 장애 발생 가능성
· 백업 및 복구 편의성
· DBMS 이중화 및 복제 지원 여부
성능 · 대규모 데이터 처리 성능
· 대략 거래 처리 성능
· 다향한 튜닝 옵션 지원 여부
· 비용 기반 최적화 지원 및 설정의 최소화 지원 여부
상호 호환성 · 설치 가능한 운영체제 종류
· 다양한 운영체제에서 지원되는 JDBC, ODBC
지원 측면 기술 지원 · 공급 업체들의 안정적인 기술 지원 여부
· 다수의 사용자 간의 정보 공유 여부
· 오픈 소스 여부
구축 비용 · 라이선스 정책 및 비용
 · 유지 및 관리 비용

 

4. 미들웨어 현행 시스템 분석

- 미들웨어 개념 : 분산 컴퓨팅 환경에서 응용 프로그램과 프로그램이 운영되는 환경 간에 원만한 통신을 이루어질 수 있도록 제어해주는 소프트웨어 ex) WAS

- 웹 애플리케이션 서버(WAS) 개념 : 서버 계층에서 애플리케이션이 동작할 수 있는 환경 제공, 안정적 트렌잭션 처리와 관리, 다른 이기종 시스템과의 애플리케이션 연동을 지원하는 서버

- 미들웨어의 현행 시스템 분석

　　└  가용성 : 장기간 운영시 장애 발생 가능성, 안정적 트랜젝션 처리 능력, WAS 이중화 여부, WAS의 개선하는 패치 설치를 위한 재기동 기능 지원 여부

　　└  성능 : 대규모 데이터 처리 성능, 설정 옵션 지원 여부, 가비지 컬렉션의 옵션 기능 여부

　　└  기술 지원 : 오픈 소스 여부

　　└  구축 비용 : 총 소유 비용

 

5. 오픈 소스 사용시 고려 사항 : 자유배포, 소스코드 공개, 파생작업 허용, 코드 일관성 확보, 차별금지, 라이선스 배포, 포괄적 허용

 

 

개발 기술 환경 요구사항 파악

1. 기술 환경 정의를 위한 자료수집

구분 조사항목 설명
온라인 트랜잭션
처리(OLTP)시스템		 시스템 구축 형태 고가용성 시스템, 단독 시스템, 벙렬 구성 여부
사용자 수 전체 사용자 수, 동시 사용자 비율, 연간 사용자 증가율
트랜잭션 수 연간/1일 평균/피크타임 트랜잭션 수, 예상 연간 트랜잭션 증가율
WEB/WAS 시스템 용도 및 시스템 형태 웹 페이지만 제공, 트랜잭션 빈번 여부
시스템 구성 형태 1계층, 2계층, 3계층
접속자 수 평균/최고/연간 접속자 수, 증가율

2. 자료 조사 분석 및 개발 기술 환경 결정

- 조사한 자료를 이용하여 OS, DBMS, WAS 결정

- 분식 시 각 항복별 고려 사항을 반영하여 개발 기술 환경 결정

 

 

TEST  →  정답은 드래그!

정답 문제
소프트웨어 아키텍처 여러가지 소프트웨어 구성요소와 그 구성요소가 가진 특성 중에서 외부에 드러나는 특성, 그리고 구성요소 간의 관계를 표한하는 시스템의 구조나 구조체이다.
파이프-필터 패턴 소프트웨어 아키텍처 패턴 유형 중 하나로 데이터스트림을 생성하고 처리하는 시스템에서 사용 가능한 패턴이다.
모듈 소프트웨어 설계에서 기능 단위로 분해하고 추상화되어 재사용 및 공유 가능한 수준으로 만들어진 단위이다.
소프트웨어 패키징 개발이 완료된 제품 소프트웨어를 고객에게 전달하기 위한 형태로 포장하는 과정이다.
모듈화 모듈을 이용하여 소프트웨어의 성능을 향상시키거나 시스템의 디버깅, 시험, 동합, 수정을 용이하도록 하는 소프트웨어 설계 기법이다.
빌드 소스 코드 파일을 컴퓨터에서 실행할 수 있는 제품 소프트웨어의 단위로 변환하는 과정이다.
제품 소프트웨어 패키징 도구 배포를 위한 패키징 시에 디지털 콘텐츠의 지적재산권을 보호하고 관리하는 기능을 제공하며, 안전한 유통과 배포를 보장하는 도구이다.
패키저 저작권 관리에서 콘텐츠를 메타 데이터와 함께 배포 가능한 단위로 묶는 기능을 수행한다.
ATAM 소프트웨어 아키텍처 비용 평가 모델 중 하나로 아키텍처 품질 속성을 만족시키는지 판단 및 품질 속성들의 이해 상충관계까지 평가하는 모델이다.
CBAM 소프트웨어 아키텍처 비용 평가 모델 중 하나로 ATAM 바탕의 시스템 아키텍처 분석 중심으로 경제적 의사결정에 대한 요구를 충족하는 비용 평가 모델이다.
디자인 패턴 소프트웨어 공항의 소프트웨어 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계 방법을 정리한 패턴이다.
빌터 패턴 생성 패턴 중 하나로 복잡한 인스턴스를 조립하여 만드는 구조로, 복합 객체를 생성할 때 객체를 생성하는 방법과 객체를 구현하는 방법을 분리함으로써 동일한 생성 절차에서 서로 다른 표현 결과를 만들 수 있는 디자인 패턴이다.
프로토타입 패턴 생성 패턴 중 하나로 처음부터 일반적인 원형을 만들어 놓고, 그것을 복사한 후 필요한 부분만 수정하여 사용하는 패턴으로, 생성할 객체의 원형을 제공하는 인스턴스에서 생성할 객체들의 타입이 결정되도록 설정하며 객체를 생성할 때 갖추어야 할 기본 형태가 있을 때 사용되는 디자인 패턴이다.
팩토리 메서드 패턴 생성 패턴 중 하나로 상위 클래스에서 객체를 생성하는 인터페이스를 정의하고, 하위 클래스에서 인스턴스를 생성하도록 하는 방식으로, 상위 클래스에서는 인스턴스를 만드는 방법만 결정하고, 하위 클래스에서 그 데이터의 생성을 책임지고 조작하는 함수들을 오버라이딩 하여 인터페이스와 실제 객체를 생성하는 클래스를 분리할 수 있는 특성을 갖는 디자인 패턴이다.
싱글톤 패턴 생성 패턴 중 하나로 전역 변수를 사용하지 않고 객체를 하나만 생성하도록 하며, 생성된 객체를 어디에서든지 참조할 수 있도록 하는 디자인 패턴이다.
브리지 패턴 구조 패턴 중 하나로 기능의 클래스 계층과 구현의 클래스 계층을 연결하고, 구현부에서 추상 계층을 분리하여 추상화된 부분과 실제 구현 부분을 독립적으로 확장할 수 있는 디자인 패턴이다.
퍼사이드 패턴 구조 패턴 중 하나로 복잡한 시스템에 대하여 단순한 인터페이스를 제공함으로써 사용자와 시스템 간 또는 여타 시스템과의 결합도를 낮추어 시스템 구조에 대한 파악을 쉽게 하는 패턴으로 오류에 대해서 단위별로 확인할 수 있게 하며, 사용자의 측면에서 단순한 인터페이스 제공을 통해 접근성을 높일 수 있는 디자인 패턴이다.
어댑터 패턴 구조 패턴 중 하나로 기존 생성된 클래스를 재사용할 수 있도록 중간에서 맞춰주는 역할을 하는 인터페이스를 만드는 패턴으로, 상속을 이용하는 클래스 패턴과 위임을 이용하는 인스턴스 패턴의 두 가지 형태로 사용되는 디자인 패턴이다.
템플릿 메서드 패턴 행위 패턴 중 하나로 어떤 작업을 처리하는 일부분을 서브 클래스로 캡슐화해 전체 일을 수행하는 구조는 바꾸지 않으면서 특정 단계에서 수행하는 내역을 바꾸는 패턴으로 일반적으로 상위 클래스에는 추상 메서드를 통해 기능의 골격을 제공하고, 하위 클래스의 메서드에는 세부 처리를 구체화하는 방식으로 사용하며 코드 양을 줄이고 유지보수를 용이하게 만드는 특징을 갖는 디자인 패턴이다.
커맨드 패턴 행위 패턴 중 하나로 실행될 기능을 캡슐화함으로써 주어진 여러 기능을 실행할 수 있는 재사용성이 높은 클래스를 설계하는 패턴으로 하나의 추상 클래스에 메서드를 만들어 각 명령이 들어오면 그에 맞는 서브 클래스가 선택되어 실행되는 특징을 갖는 디자인 패턴이다.
옵저버 패턴 행위 패턴 중 하나로 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들에 연락이 가고 자동으로 내용이 갱신되는 방법으로 일 대 다의 의존성을 가지며 상호 작용하는 객체 사이에서는 가능하면 느슨하게 결합하는 디자인 패턴이다.
전략 패턴 행위 패턴 중 하나로 알고리즘 군을 정의하고 같은 알고리즘을 각각 하나의 클래스로 캡슐화한 다음, 필요할 때 서로 교환해서 사용할 수 있게 하는 패턴으로, 행위를 클래스로 캡슐화해 동적으로 행위를 자유롭게 바꿀 수 있게 해주는 디자인 패턴이다.
운영체제(OS) 컴퓨터 시스템이 제공하는 모든 하드웨어, 소프트웨어를 사용할 수 있도록 해주고, 컴퓨터 사용자와 컴퓨터 하드웨어 간의 인터페이스를 담당하는 프로그램으로, 사용자가 컴퓨터를 좀 더 쉽게 사용하기 위해 지원하는 소프트웨어이다.
네트워크 컴퓨터 장치들의 노드 간 연결(데이터 링크)을 사용하여 서로에게 데이터를 교환할 수 있도록 하는 기술이다.
응용 계층 OSI 7계층 중 하나로 사용자와 네트워크 간 응용서비스 연결, 데이터를 생성하는 계층이며, 대표적인 프로토콜로 HTTP, FTP가 있다.
전송 계층 OSI 7계층 중 하나로 신뢰성 있는 통신을 보장하고, 데이터 분할과 재조립, 흐름제어, 오류제어, 혼잡제어 등을 담당하는 계층이며, 대표적인 프로토콜에는 TCP, UDP가 있다.
네트워크 계층 OSI 7계층 중 하나로 단말 간 데이터 전송을 위한 최적화된 경로를 제공하는 계층이며, 대표적인 프로토콜로는 IP, ICMP가 있다.
데이터 링크 계층 OSI 7계층 중 하나로 인접 시스템 간 데이터 전송, 전송오류 제어, 동기화, 흐름제어 등의 전송 기능을 제공하는 계층이며, 대표적인 프로토콜은 이더넷이다.
물리 계층 OSI 7계층 중 하나로 0과 1의 비트 정보를 회성에 보내기 위한 전기적 신호로 변환하는 계층이며, 대표적인 프로토콜은 RS-232C이다.
백본망 다양한 네트워크를 상호 연결하는 컴퓨터 네트워크의 일부로서, 각기 다른 LAN이나 부분망 간에 정보를 교환하기 위한 경로를 제공하는 망이다.
라우터 3계층 데이터 패킷을 발신지에서 목적지까지 전달하기 위해 최적의 경로를 지정하고, 이 경로를 따라 데이터 패킷을 다음 장치로 전달하는 네트워크 장비이다.
스위치 2계층 장비로서, 동일 네트워크 내에서 출발지에 들어온 데이터 프레임을 목적지 MAC 주소 기반으로 빠르게 전달하는 네트워크 장비이다.
게이트웨이 컴퓨터 네트워크에서 서로 다른 통신망, 프로토콜을 사용하는 네트워크 간의 통신을 가능하게 하는 네트워크 장비이다.
방화벽 외부로부터 불법침입과 내부의 불법 정보 유출을 방지하고, 내·외부 네트워크의 상호간 영향을 차단하기 위한 보안 시스템이다.
미들웨어 분산 컴퓨팅 환경에서 응용 프로그램과 프로그램이 운영되는 환경 간에 원만한 통신이 이루어질 수 있도록 제이해주는 소프트웨어로, 운영체제와 소프트웨어 애플리케이션 사이에 있다.
웹애플리케이션 서버(WAS) 서버계층에서 애플리케이션이 동작할 수 있는 환경을 제공하고 안정적인 트랜잭션 처리와 관리, 다른 이기종 시스템과의 애플리케이션 연동을 지원하는 서버이다.
가비지 컬렉션(GC) 메모리 관리 기법의 하나로, 프로그램이 동적으로 할당했던 메모리 영역 중에서 필요 없게 된 영역을 해제하는 기능이다.
추상클래스 객체 인스턴스를 생성하지 않고, 단지 유사 클래스들의 공통된 특징을 정의하고, 하나 이상의 추상 메서드와 일반 필드 및 일반 메서드를 포함하는 클래스이다.
XML 다른 특수한 목적을 갖는 마크업 언어를 만드는 데 사용하도록 권장하는 다목적 언어이다.  
인스턴스 객체 지향 프로그래밍에서 해당 클래스의 구조로 컴퓨터 저장 공간에서 할당된 실체이다.

 

 

 

 

 

 

 

※ 해당 글은 수제비 2022 도서 참고하였습니다.

 

수제비- IT 커뮤니티 (정보처리기사... : 네이버 카페

수제비-수험생 입장에서 제대로 쓴 비법서(정보처리기사, 정보처리기능사, 빅데이터 분석기사 등 시리즈)

cafe.naver.com

 

'정보처리기사' 카테고리의 다른 글

Ⅱ 화면설계 - UI 요구사항 확인  (0) 2023.01.30
[2023] 정보처리기사 시험 일정  (0) 2023.01.05
Ⅰ 요구사항 확인 - 분석 모델 확인하기  (0) 2022.12.02
Ⅰ 요구사항 확인 - 요구사항 확인  (0) 2022.12.01
Ⅰ 요구사항 확인 - 소프트웨어 개발 방법론  (1) 2022.11.17

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

소프트웨어 생명주기 모델

1. 개념

 - 시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차

 - 시스템이 개발될 때부터 운용과 유지보수를 거쳐 생애를 마칠 때까지 어떠한 순서를 밟는지에 대한 작업 프로세스를 모델화한 것

 

2. 프로세스 ( 요구사항 분석 → 설계 → 구현 → 테스트 → 유지보수 )

 - 요구사항 분석 : 개발할 소프트웨어의 기능과 제약 조건, 목표 등을 소프트웨어 사용자와 함께 정의하는 단계

　　└  기능 요구사항, 비기능 요구사항  

 - 설계 : 시스템 명세 단계에서 정의한 기능을 실제 수행할 수 있도록 수행 방법을 논리적으로 결정하는 단계

　　└  시스템 구조 설계, 프로그램 설계, 사용자 인터페이스 설계

 - 구현 : 프로그래밍 언어 선택, 기법, 스타일, 순서 등을 결정하여 실제 프로그램을 작성하는 단계

　　└  인터페이스 개발, 자료 구조 개발, 오류 처리

 - 테스트 : 예상과 실제결과의 차이를 검사, 평가 단계

　　└  단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트

 - 유지보수 : 시스템 인수되고 설치된 후 일어나는 모든 활동

　　└  예방, 완전, 교정, 적응 유지보수

 

3. 모델 종류

종류 설명
폭포수 모델
(Waterfall Model)

 · 개발시 각 단계를 확실히 마무리 지은 후 다음 단계로 넘어감
· 선형 순차적 모형, 고전적 생명주기 모형
· 요구사항 변경 어려움
절차 타당성 검토 → 계획 → 요구사항 분석 → 설계 → 구현 → 테스트 → 유지보수
프로토타이핑 모델
(Prototyping Model)		 · 고객이 요구한 주요기능을 프로토타입으로 구현하여, 고객의 피드백을 반영
· 요구사항 분석 용이, 타당성 검증가능
· 프로토타입 폐기에 따른 비용 증가
나선형 모델
(Spiral Model)

 · 시스템 개발 시 위험을 최소화하기 위해 점진적으로 완벽한 시스템으로 개발
· 위험분석, 반복개발
· 위험성 감소와 변경에 유연한 대처
· 단계 반복에 따른 관리 어려움  
절차 계획 및 정의 → 위험 분석 → 개발 → 고객평가 
반복적 모델
(Iteration Model)		 · 구축대상을 나누어 병렬적으로 개발 후 통합하거나, 반복적으로 개발하여 점증 완성시키는 SDLC 모델
· 병행 개발로 인한 일정 단축 가능
· 병행 개발에 따른 관리 비용 증가

 

 

소프트웨어 개발 방법론

1. 개념

- 소프트웨어 개발 전 과정에 지속적으로 적용할 수 있는 방법, 절차, 기법

- 소프트웨어 개발의 시작부터 시스템을 사용하지 않는 과정까지의 전 과정을 형상화한 방법론

 

2. 종류

종류 설명
구조적 방법론 ·  전체 시스템을 기능에 나누어 개발, 이를 통합하는 분할과 정복 접근 방식의 방법론
·  프로세스 중심의 하향식 방법론
·  나씨 슈나이더만 차트 사용 : 논리의 기술에 중점을 둔 도형식 표현방법
정보공학 방법론 · 정보시스템 개발에 필요한 관리 절차와 작업 기법을 쳬계화
객체 지향 방법론 · '객체'라는 기본 단위로 시스템을 분석 및 설계
컴포넌트 기반 방법론(CBD) · 컴포넌트를 조립해서 하나의 새로운 응용프로그램 작성
· 개발시간 단축 - 생산성 향상, 확장성, 재사용성
애자일 방법론 · 절차보다는 사람 중심, 변화에 유연 신속 적응하면서 효율적인 시스템 개발
제품 개발 방법론 · 특정 제품에 적용하고 싶은 공통된 기능을 정의 개발, 임베디드 S/W작성에 유용

 

3. 애자일 : 절차보다는 사람중심, 변화에 유연 신속 적용, 즉시 피드백을 받아 유동적 개발

- 유형

　　① XP : 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질 향상을 위한 방법론

　　　　└ XP 5가지 가치 : 용기, 단순성, 의사소통, 피드백, 존중

　　　　└ XP 12가지 기본원리

기본원리 설명
짝 프로그래밍  개발자 둘이서 짝 코딩
공동 코드 소유  시스템에 있는 코드는 누구든 언제든 수정 가능
지속적인 통합 (CI)  매일 여러번 소프트웨어 통합, 빌드
계획 세우기  고객 요구 비즈니스 가치 정의, 개발자가 필요한 것이 무엇인지, 어떤 부분에서 지연 여부를 알려줌
작은 릴리즈  작은 시스템을 먼저 만들고, 짧은 단위 업데이트
메타포어  공통적인 이름 체계와 시스템 서술서를 통해 의사소통을 원활
간단한 디자인  요구사항에 적합한 가장 단순한 시스템을 설계
테스트 기반 개발 (TDD)  작성하는 프로그램에 대한 테스트 먼저 수행, 테스트를 통과하도록 실제 코드 작성
리팩토링  프로그램 기능을 바꾸지 않으면서, 코드의 중복제거, 단순화
40시간 작업  개발자 실수 방지를 위해 일주일 40시간 이상 일하지 말아야 함
고객 상주  개발자 질문에 즉각 대응을 위해 고객 풀타임 상주
코드표준  효과적인 공동 작업을 위해 코딩 표준 정의


　　② 린(Lean) : 토요타의 린 시스템 품질 기법을 소프트웨어 개발 프로세스에 적용해서 낭비 요소를 제거하여 품질 향상을 위한 방법론

　　　　└ 린 7가지 가치 : 낭비제거, 품질 내재화, 지식창출, 늦은 확정, 빠른 인도, 사람존중, 전체 최적화

　　③ 스크럼(SCRUM) : 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 중심 방법론

　　　　└ 백로그, 스프린트, 스크럼 미팅, 스크럼 마스터, 스프린트 회고, 번 다운 차트

 

 

 

객체 지향 분석 방법론 ( OOA : Object Oriented Analysis )

1. 개념 : 사용자의 요구사항을 분석하여 요구된 문제와 관련된 모든 클래스, 속성과 연산, 관계를 정의

 

2. 종류

- OOSE(Object Oriented Software Engineering) : 유스케이스를 모든 모델의 근간으로 활용되는 방법론, 야콥스

- OMT(Object Modeling Technology) : 그래픽 표기법을 이용하여 소프트웨어 구성요소를 모델링, 럼바우

　　└ 분석 절차  : 객체 - 동적 - 기능
　　└ 객체 모델링 (Object, Information)  : 객체 다이어그램, 객체들 간의 관계 정의하여 ER 이어그램을 만드는 과정까지의 모델링
　　└ 동적 모델링 (Dynamic) : 상태 다이어그램, 시간의 흐름에 따라 객체들의 동적인 행위를 표현
　　└ 기능 모델링 (Functional) : 자료흐름도(DFD), 프로세스들의 자료 흐름을 중심으로 처리과정 표현 

- OOD(Object Oriented Design) : 설계 문서화를 강조하여 다이어그램 중심으로 개발, 부치

 

 

 

 

비용산정, 일정관리 모형 ⭐⭐⭐

비용산정 모형 : 소프트웨어 비용 산정 방식

1. 분류

- 하향식 산정방법 : 경험이 많은 전문가에게 비용산정

　　└ 전문가 판단
　　└ 델파이 기법  : 전문가의 경험적 지식을 통한 문제 해결 및 미래예측을 위한 기법

- 상향식 산정방법 : 세부적인 요구사항과 기능에 따라 비용산정

　　└ 코드라인수(LoC) 모형, Man Month 모형, COCOMO 모형, 푸트남 모형, 기능점수(FP) 모형

 

2. 종류

종류 설명
코드라인수(LoC) 모형 ·  원시 코드 라인수의 낙관치, 중간치, 비관치 측정하여 예측치를 구해 비용산정
Man Month 모형 ·  한 사람이 1개월동안 할 수 있는 일의 양을 기준으로 비용산정
·  (Man Month) = (LoC) / (프로그래머 월간 생산성) 
·  (프로젝트 기간) = (Man Month) / (프로젝트 인력)
COCOMO 모형 ·  보헴이 제안한 모형으로 프로그램 규모에 따라 비용산정
·  조직형(Organic) : 5만 라인 이하
·  반분리형(Semi) : 30만 라인 이하
·  임베디드형(Embedded) : 30만 라인 이상
푸트남 모형 ·  개발주기의 단계별로 요구할 인력의 분포를 가정하는 방식
기능점수(FP) 모형 ·  소프트웨어 기능을 증대시키는 요인별로 가중치를 부여햐여 비용산정

 

 

일정 관리 모델 :  프로젝트가 일정 기한 내에 완료될 수 있도록 관리하는 모델

1. 종류 (주,펄,중)

- 주 공정법(CPM)  : 여러 작업의 수행 순서가 얽혀 있는 프로젝트의 일정을 계산하는 기법
　　└ 주 공정(임계경로) : 프로젝트의 시작에서 종료까지 가장 긴 시간이 걸리는 경로
- PERT  : 일의 순서를 계획적으로 정리하기 위한 수렴 기법. 비관치, 중간치, 낙관치 이용
- 중요 연쇄 프로젝트 관리(CCPM) : 주 공정 연쇄법으로 자원 제약사항을 고려하여 일정 작성

 

TEST  →  정답은 드래그!

정답 문제
소프트웨어 생명주기
(SDLC)		 시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차이다.
폭포수 모델 소프트웨어 개발시 각 단계를 확실히 마무리 지은 후에 다음단계로 넘어가는 가장 오래된 생명주기 모델이다.
나선형 모델 시스템 개발 시 위험을 최소화하기 위해 점진적으로 완벽한 시스템으로 개발해 나가는 모델이다.
소프트웨어 개발 방법론 소프트웨어 개발 전 과정에 지속적으로 적용할 수 있는 방법, 절차, 기법이다.
구조적 방법론 전체 시스템을 기능에 따라 나누어 개발하고, 이를 통합하는 분할과 정복 접근 방식을 사용하는 방법론이다.
나씨-슈나이더만 차트 구조적 프로그래밍 표현을 위해 논리의 기술에 중점을 둔 도형식 표현 방법으로 연속, 선택, 반복 등의 제어 논리 구조로 표현한다.
애자일 방법론 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적으로 시스템을 개발할 수 있는 신속 적응적 경량 개발 방법론이다.
XP 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론으로 5가지 가치와 12개의 실천항목이 존재한다.
지속적인 통합(CI) 매일 여러 번씩 소프트웨어를 통합하고 빌드해야 한다는 원리이다.
메타포어 XP의 12가지 기본원리 중 하나로 공통적인 이름체계와 시스템 서술서를 통해 고객과 개발자간의 의사소통을 원활하게 한다는 원리이다.
테스트 기반 개발(TDD) 작성해야 하는 프로그램에 대한 테스트를 먼저 수행하고 이 테스트를 통과할 수 있도록 실제 프로그램의 코드를 작성한다는 원리이다
스크럼 애자일 방법론 중 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론이다.
스프린트 스크럼 방법론에서 2~4주의 짧은 개발 기간으로 반복적 수행하는 개발 품질을 향상시키는 프로젝트 수행법이다.
번 다운 차트 스크럼 방법론에서 남아있는 백로그 대비 시간을 그래픽적으로 표현한 차트이다.
리팩토링 프로그램의 기능을 바꾸지 않으면서 중복제거, 단순화 등을 위해 시스템 재구성 한다는 원리이다.
LoC 모형 소프트웨어 각 기능의 원시 코드 라인 수의 낙관치, 중간치, 비관치를 측정하여 예측지를 구하고 이를 이용하여 비용을 산정하는 방식이다.
Man Month 한 사람이 1개월 동안 할 수 있는 일의 양을 기준으로 프로젝트 비용을 산정하는 방식이다.
COCOMO 모형 보헴이 제안한 모형으로 프로그램 규모에 따라 비용을 산정하는 방식으로, 규모에 따라 조직형, 반 분리형, 임베디드형으로 나뉜다.
푸트남 모형 소프트웨어 개발 주기의 단계별로 요구할 인력의 분포를 가정하는 방식으로, 시간에 따른 함수로 표현되는 Rayleigh-Norden 곡선의 노력분포도를 기초로 한다.
델파이 기법 비용산정 모형 중 하향식 산정방법이며, 전문가의 경험적 지식을 통한 문제 해결 및 미래예측을 위한 기법이다.
기능 점수 모형(FP 모형) 요구 기능을 증가시키는 인자별로 가중치를 부여하고, 요인별 가중치를 합산하여 총 기능의 점수를 계산하여 비용을 산정하는 방식이다.
주 공정법 일정관리 모델 중에서 여러 작업의 수행 순서가 얽혀 있는 프로젝트의 일정을 계산하는 기법이며, 모든 자원 제약사항을 배제한 상태로 프로젝트의 시작과 끝을 나타내는 노드와 노드 간을 연결을 통해 공정을 계산하기 위한 액티비티로 표기한다.
PERT 일정관리 모델 중에서 일의 순서를 계획적으로 정리하기 위한 수렴기법으로 비관치, 중간치, 낙관치의 3점 추정방식을 통해 일정을 관리하는 기법이다.
데이터 흐름도(DFD) 데이터가 각 프로세스를 따라 흐르면서 변환되는 모습을 나타낸 그림으로, 시스템 분석과 설계에서 매우 유용하게 사용되는 다이어그램이다.
자료 사전(DD) 자료 요소, 자료 요소들의 집합, 자료의 흐름, 자료저장소의 의미와 그들 간의 관계, 관계 값, 범위, 단위들을 구체적으로 명시하는 사전이다.
릴리즈노트 조직의 최종사용자인 고객과 잘 정리된 릴리즈 정보를 공유하는 문서이다.
헤더 릴리즈 노트 작성 항목 중 문서 이름, 제품 이름, 버전 번호, 릴리즈 날짜, 참고 날짜, 노트 버전 등의 정보이다.
재현 항목 릴리즈 노트 작성 항목 중 버그 발견에 따른 재현 단계 기술이다.
사용자 영향도 릴리즈 노트 작성 항목 중 버전 변경에 따른 최종 사용자 기준의 기능 및 응용 프로그램상의 영향도 기술이다.
노트 릴리즈 노트 작성 항목 중 소프트웨어 및 하드웨어 설치 항목, 제품, 문서를 포함한 업그레이드 항목 메모이다.
면책조항 릴리즈 노트 작성 항목 중 회사 및 표준 제품과 관련된 메시지, 프리웨어 및 불법 복제 방지, 중복 등 참조에 대한 고지 사항이다.

 

 

 

 

 

 

 

※ 해당 글은 수제비 2022 도서 참고하였습니다.

 

수제비- IT 커뮤니티 (정보처리기사... : 네이버 카페

수제비-수험생 입장에서 제대로 쓴 비법서(정보처리기사, 정보처리기능사, 빅데이터 분석기사 등 시리즈)

cafe.naver.com

 

'정보처리기사' 카테고리의 다른 글

Ⅱ 화면설계 - UI 요구사항 확인  (0) 2023.01.30
[2023] 정보처리기사 시험 일정  (0) 2023.01.05
Ⅰ 요구사항 확인 - 분석 모델 확인하기  (0) 2022.12.02
Ⅰ 요구사항 확인 - 요구사항 확인  (0) 2022.12.01
Ⅰ 요구사항 확인 - 현행 시스템 분석  (0) 2022.11.17

+ Recent posts

티스토리툴바