Dev Diary.

2. 소프트웨어 개발

 2.1 데이터 입출력 구현

  2.1.4 데이터 조작 프로시저 최적화

1. 쿼리성능 측정

데이터 조작 프로시저 최적화는 데이터베이스에서 프로시저에 있는 SQL의 실행 계획을 분석하여 시간이 오래걸리는 부분을 수정하여 최소의 시간으로 원하는 결과를 얻도록 프로시저를 수정하는 활동이다.

이를 수행하기 위해서는 쿼리 성능 측정 방법을 알고 있어야 한다.

관계형 데이터베이스 특히 Oracle의 쿼리 성능을 측정하는 방법에는 크게 두가지 방법이 있다. TKPROF 명령어와 EXPLAIN PLAN이 그것이다.

1.1 관계형 데이터베이스에서 SQL 처리 이해

1. SQL 처리 흐름

관계형 데이터베이스에서 SQL 구문은 통계자료를 기반으로 옵티마이저가 최적의 수행경로를 찾고 이를 기반으로 데이터를 실행한다.

2. 쿼리 성능 최적화를 위한 고려사항

개발자는 SQL 특성을 충분히 이해하고 SQL문을 적절히 구사할 수 있는 기본적인 능력을 갖추어야 한다.

개발자는 SQL 작성 시 옵티마이저의 일련의 행위를 이해하고 있어야 한다.

구문분석 단계에서 옵티마이저의 실행계획에 따라서 실행 속도의 차이는 크게 날 수 있다.

옵티마이저의 실행계획이 비정상적이라면 개발자는 HInt 같은 조건을 부여하여 실행계획을 수정 할 수 있다.

1.2 TKPROF 기반의 쿼리 성능 측정

1. TKPROF 란?

Oracle DBMS에서 실행되는 SQL문장에서 분석정보를 제공하여 개발자가 특정 SQL문장을 어떻게 사용해야 할 것인지에 대한 가이드라인을 제공하는 도구이다.

2. TKPROF 결과로 파악할 수 있는 분석정보 내용

Call : 커서 상태에 따라 Prase, Excute, Fetch 3개의 Call로 나누어 각각의 통계 정보를 보여준다.

• Prase : 커서를 파싱하고 실행계획을 생성하는 통계
• Execute : 커서의 실행 단계에 대한 통계
• Fetch : 레코드를 실제로 Fetch하는 통계

Count : Parse, Execute, Fetch 각 단계가 수행된 횟수

CPU : 현재 커서가 각 단계에서 사용한 CPU 시간

Elapsed : 현재 커서가 각 단계의 시작에서 종료까지 총 경과 시간

Disk : 물리적인 디스크로부터 읽은 블록 수

Rows : 각 단계에서 읽거나 갱신한 처리 건수

3. TKPROF를 활용한 Trace 유형

Instancd level 추적 : 모든 SQL 수행에 대한 Trace 파일을 생성하여 부하가 많다.

Session level 추적 : 특정 프로세스별로 추적 파일을 생성한다.

Instance level로 모든 SQL을 Trace하는 경우는 거의 없고 , Session level을 일반적으로 활용한다.

Trace를 Enable하는 것은 DB부하가 수반되므로 필요한 경우를 제외하고는 Disable하는 것이 좋다.

4. Trace 관련 파라미터 설정

Tkprof를 통하여 트레이스 설정을 on하면 user_dump_desk 파라미터로 지정된 서버 디렉터리 밑에 확장자가 .trc파일로 생성된다.

5. Trace 관련 파라미터 설정 확인 방법

시스템 사용자 권한으로 DB connect : sqlplus "/ as sysdba"

SQL Mode에서 show parameter 또는 show parameter parameter_name

1.3 TKPROF 활용방법

1. 적용 명령어 

TKPROF는 SQL Trace가 생성한 Trace 파일을 분석하여 사용자가 읽을 수 있는 형태로 변환 시켜주는 Oracle 제공 도구이다.

2. 명령어 활용 예시

tkprof oral_219.trc 219.1st explain=sctt/tiger

3.관련정보 파악 절차

Data Divtionary 변경

SQL > Analyze table table 명 extimate(compute) statistics;

환경변수 점검

SQL > show parameter parameter_name (특히 user_dump_dest)

해당 SQL과 관련된 Index 정보파악

SQL > select*from user_ind_column where table_name='emp';

1.4 EXPLAIN PLAN 기반 쿼리 성능 측정

1. EXPLAIN PLAN이란?

EXPLAIN PLAN은 사용자들이 SQL문의 액세스 경로를 확인하여 성능개선을 할 수 있도록 SQL문을 분석하고 해석하여 실행계획을 수립하고, 관련 테이블에 저장하도록 지원해 주는 도구이다.

2. EXPLAIN PLAN준비

해당 사용자로 DB접속하여 PLAN Table생성

1.5 SQL 성능 개선 순서

1. 문제 있는 SQL 식별

문제 있는 SQL을 식별하기 위해서는 애플리케이션의 성능을 관리하거나 모니터링 하기 위한 툴인 APM 등을 활용한다.

Oracle의 경우, TKPROF 또는 SQL_Trace와 같은 유틸리티를 사용한다.

2. 옵티마이저 통계 확인

옵티마이저는 개발자가 작성한 SQL을 가장 빠르고 효율적으로 수행할 최적의 처리경로를 생성해 주는 데이터베이스 핵심 모듈이다.

3. SQL문 재구성

가능한 한 where 절을 많이 써서 범위가 아닌 특정 값 지정으로 범위를 줄여 처리속도가 빠르도록 한다.

Where 절의 Column에 연산자를 사용하여 Column변경이 발생하면 인덱스를 활용하지 못하게 됨을 이해하여 Column 변경 연사자를 쓰지 않는다.

옵티마이저가 비정상적인 실행계획을 수립하여 처리되면, Hint로서 옵티마이저의 액세스 경로 및 조인 순서를 제어한다.

4. 인덱스 재구성

성능에 중요한 액세스 경로를 고려하여 인덱스화 한다.

실행계획을 검토하여 기존 인덱스의 열 순서를 변경하거나 추가 할 수 있도록 한다.

인덱스 추가 시 정상적으로 처리되고 있던 다른 SQL에 심각한 영향을 줄 수 있으므로 주요 SQL 질의 결과를 함께 검토한다.

5. 실행계획 유지관리

데이터베이스 버전 업그레이드, 데이터 전환 등 시스템 환경의 변경 사항 발생 시에도 실행계획이 유지되고 있는지 모니터링, 관리한다.

2. 소스코드 인스펙션

데이터 조작 프로시저 소스코드 인스펙션은 데이터베이스 성능 향상을 위하여 프로시저 코드를 보면서 성능 문제점을 개선해 나가는 활동이다.

2.1 SQL PLUS에서 Stored Procedure 소스 확인 방법

1. USER_SOURCE 데이터 사전을 이용

사용자가 만든 모든 프로시저를 보여줌

2. 프로시저 소스 확인

프로시저 소스는 USER_SOURCE의 text 조회를 통하여 확인한다.

2.2 SQL 코드 인스펙션 대상

1. 사용되지 않은 변수

2. 사용되지 않은 서브쿼리

3. NULL 값과 비교

4. 과거의 데이터타입을 이용

2.3 SQL 코드 인스펙션 절차

1. 계획 : 문제되는 SQL 코드 선별, 문제점 인식 및 인스펙션 참여자 선정

2. 개관 : SQL 코드 문제점 공유, 계획 및 방법 공유

3. 준비 : 각자 SQL 소스 코드 분석, 문제점 확인

4. 검사 : 공식적인 SQL인스펙션 수행, 문제점 토의

5. 재작업 : SQL 소스 코드 수정 및 실행 시간 재 측정

6. 추적 : 개선 효과 분석

2. 소프트웨어 개발

 2.1 데이터 입출력 구현

  2.1.4 데이터 조작 프로시저 작성

1. 프로시저

데이터 조작을 위해서 사용하는 언어를 SQL이라고 하는데 SQL은 일정한 데이터 집합으로부터 보다 쉽게 자료를 검색하고 입력, 수정, 삭제와 같은 조작을 할 수 있도록 고안된 언어를 말한다.

프로시저는 이러한 SQL을 이용하여 만들어진 데이터를 조작하는 프로그램이다. 프로시저는 데이터베이스 내부에 저장되고 일정한 조건이 되면 자동으로 수행된다.

1.1 SQL 분류

1. 데이터 정의어 (DDL)

데이터를 저장하고 있는 테이블 등의 구조를 생성하고 변경하기 위하여 사용되는 명령어 들을 의미한다.

Create, Drop, Rename, Alter, Truncate 등이 있다.

2. 데이터 조작이 (DML)

데이터베이스에 있는 데이터를 변경하거나 검색하기 위하여 사용되는 명령어들을 말하며, 이 명령어는 트랜잭션 제어 어를 활용하여 실행 전 상태로 복귀 가능한 명령어이다.

Insert, Update, Delete 등이 있다.

3. 데이터 제어어 (DCL)

사용자별로 데이터베이스에 접근할 수 있는 권한을 부여하거나 회수하는 명령어들을 말한다.

Role, Grant, Revoke 등이 있다.

1.2 트랜잭션 제어어 (TCL)

1. 트랜잭션 제어어란?

트랜잭션 제어 어는 트랜잭션의 DML 작업 단위를 제어하는 명령어이다.

Commit, Rollback, Savepoint 등이 있다.

2. Commit 

트랜잭션을 완료하여 데이터 변경사항을 최종 반영하는 명령어이다.

Commit이후에는 데이터에 대한 변경 사항이 물리적 디스크에 반영된다.

Commit이 되면 이전 데이터는 복구할 수 없다.

모든 사용자가 변경된 결과를 볼 수 있다.

관련된 행에 대해 잠금이 풀리며 다른 사용자들이 조작할 수 있다.

3. Rollback

데이터 변경사항을 이전 상태로 되돌리는 명령어이다.

Rollback이후 데이터 상태는 명령문을 수행하기 전 상태로 되돌려진다.

관련된 행에 대한 잠금이 풀리게 된다.

4. Savepoint

지정된 특정 시점까지 Rollback 할 수 있는 명령어이다.

Savepoint A; 이렇게 명령할 경우 A지점까지 Rollback이 된다.

1.3 데이터 검색어(Select)

1.4 절차형 데이터 조작 프로시저 PL/SQL

1. PL/SQL 개요

표준 SQL을 기본으로 Oracle에서 개발한 데이터 조작 언어이다. Oracle 기반의 모든 프로시저 작성에 사용되며 표준 SQL의 확장 기능이 우수하다.

2. PL/SQL 사용 시 장점

Compile이 필용 벗어 Script 생성 및 변경 후 바로 실행이 가능하다.

프로그램 개발의 모듈화가 가능하다.

변수, 상수 등 식별자를 선언하여 해당 식별자를 SQL과 절차적인 프로그램에서 사용할 수 있다.

IF문 Loop문 등 절차적 언어 구조로 된 프로그램 작성이 가능하다.

Explicit Cursor를 이용한 Multi-row 처리가 가능하다.

Exception 처리 루틴을 이용하여 Error처리가 가능하다.

네트워크 부하를 줄여 프로그램의 성능 향상을 기대할 수 있다.

PL/SQL은 여러 SQL문장을 Bloc으로 묶고 한번에 Block 전부를 서버로 전송하기 때문에 통신량을 줄일 수 있다.

3. PL/SQL 구조

PL/SQL은 프로그램을 논리적인 블록으로 나누게 하는 구조화된 블록 언어로서 다음과 같은 블록 구조로 구성된다.

선언부 : 실행부에서 참조할 모든 변수, 상수, Cursor, Exception을 선언한다.

실행부 : Begin과 End사이에 기술되는 영역으로, 데이터베이스 데이터를 처리할 SQL 문과 PL/SQL 블록을 기술한다.

예외 처리부 : 실행부에서 에러가 발생했을 경우 수행될 문장을 기술한다.

4. PL/SQL 처리절차

PL/SQL로 작성된 Block을 Oracle서버로 보내면 PL/SQL엔진이 SQL문과 Non SQL문을 구분한다.

Non SQL문은 PL/SQL엔진내의 Procedural Statement Executor가, SQL문은 SQL Statement Executor가 처리하게 된다.

Non SQL문은 Client환경에서, SQL문은 서버에서 실행된다.

따라서, PL/SQL문을 사용하게 되면 서버 작업량을 줄이게 되므로 네트워크 부하를 감소시켜 수행성능을 증가시키는 장점이 있다.

1.5 PL/SQL을 활용한 저장형 객체 활용

PL/SQL로 작성할 수 있는 저장형 객체로는 Stored Function, Stored Procedure, Stored Package, Trigger 등이 있다.

1. Stored Function

보통값을 계산하고 결과값을 반환하기 위해서 많이 사용한다.

대부분 구성이 프로시저와 유사하지만 IN 파라미터만 사용할 수 있다.

반드시 반환될 값의 데이터 타입을 Return문에 선언해야 한다.

PL/SQL블록 내에서 Return 문을 통해서 반드시 값을 반환해야 한다.

ㅛ를받아서정해진

2. Stored Procedure

특정 작업을 수행할 수 있는 이름이 있는 PL/SQL블록이다.

매개 변수를 받을 수 있고, 반복적으로 사용할 수 있는 Object이다.

보통 연속 실행 또는 구현이 복잡한 트랜잭션을 수행하는 PL/SQL 블록을 DB에 저장하기 위해 생성된다.

CREATE OR REPLACE 구문을 사용하여 생성한다.

IS 로 PL/SQL 블록을 시작한다.

LOCAL 변수는 IS와 BEGIN 사이에 선언한다.

3. Store Package

패키지는 Oracle 데이터베이스에 저장되어 있는 서로 관련있는 PL/SQL 프로시저와 함수들의 집합이다.

패키지는 선언부와 본문 두부분으로 나누어 진다.

4. Trigger

INSERT, UPDATE, DELETE 문이 TABLE에 대해 행해질 때 묵시적으로 수행되는 PROCEDURE이다.

Trigger는 TABLE과는 별도로 데이터베이스에 저장된다.

Trigger는 VIEW에 대해서가 아니라 TABLE에 관해서만 정의될수 있다.

DBMS_OUTPUT.PUT_LINE을 출력하기 위해 'set serveroutput on'을 사용한다.

2. 프로그램 디버깅

만들어진 데이터베이스 프로시저에 대한 개발자 스스로 검증을 해보아야하는데 , 이를 프로그램 디버깅 이라고 한다. 프로시저 디버깅은 만들어진 프로시저가 정해진 입력 자료를 받아서 정해진 출력을 출력하는지에 과한 확인 과정이다.

2.1 SQL*Plus 개요

1. SQL과 SQL*Plus 차이점

SQL은 데이터를 조작하는 표준 언어인 반면 SQL*Plus는 이러한 SQL을 DBMS 서버에 전송하여 처리할 수 있도록 하는 Oracle에서 제공하는 도구이다.

3. 단위 테스트 도구

Oracle DBMS는 모든 데이터조작 프로시저에 대한 테스트 환경으로 SQL*Plus 라는 도구를 제공하므로, 개발자는 데이터 조작 프로시저 테스트를 위해 해당 도구 활용을 위한 SQL*Plus에대한사전지식이필요한다.

3.1 PL/SQL 테스트

1. DBMS_OUTPUT 패키지 활용

메시지를 버퍼에 저장하고 버퍼로부터 메시지를 읽어오기 위한 인터페이스를 제공하는 패키지인 DBMS_OUTPUT을 코드에 포함한다.

2. 소프트웨어 개발

 2.1 데이터 입출력 구현

  2.1.3 물리 데이터저장소 설계

1. 물리 데이터 저장소

논리 데이터 모델로부터 물리 데이터 모델로 변환하는 순서는 단위엔티티를 테이블로, 속성을 컬럼으로, UID를 기본키로, 관계를 외래키로 변환한 후, 컬럼 유형과 길이를 정의하고, 데이터 처리 범위와 빈도수를 분석하여 반정규화를 고려한다.

1.1 데이터베이스 스키마의 종류

1. 외부 스키마

프로그래머나 사용자의 입장에서 데이터베이스의 모습으로 조직의 일부분을 정의한 것

데이터베이스의 개발 사용자나 응용프로그래머가 접근하는 데이터베이스

2. 개념 스키마

모든 응용 시스템과 사용자들이 필요로 하는 데이터를 통합한 조직 전체의 데이터베이스 구조를 논리적으로 정의한 것

3. 내부 스키마

전체 데이터베이스의 물리적 저장 형태를 기술한 것

데이터베이스 시스템 구조에서 데이터가 실제로 저장되는 구조를 기술

1.2 논리 데이터 모델에서 물리 데이터 모델 변환 순서

1. 단위 엔티티를 테이블로 변환한다.

논리모델에서 정의된 엔티티는 물리모델에서 테이블로 변환한다.

엔티티는 한글명, 테이블은 소스코드 가독성을 위해 영문명을 사용한다.

메타데이터시스템과 같은 사전에 표준화된 용어가 있을 경우 메타에 등록된 단어를 사용하여 명명한다.

2. 속성을 컬럼으로 변환한다.

컬럼의 명칭은 속성의 명칭과 반드시 일치할 필요는 없으니 개발자와 사용자 간 의사소통을 위해 가능한 표준화된 약어를 사용한다.

SQL 예약어 사용은 피한다.

SQL 문장 가독성을 위해 컬럼 명칭은 가능한 짧은 것이 좋다.

컬럼명으로 복합단어를 사용할 경우 미리 정의된 표준에 의해 명명한다.

3. UID를 기본키로 변환한다.

엔티티의 UID에 해당하는 모든 속성에 대해 기본키로 선언하고 NOT Null, Unique등의 제약조건을 추가한다.

4. 관계를 외래키로 변환한다.

n 관게에서 1영역에 있는 기본키를 n영역의 외래키로 선언한다.

5. 컬럼유형과 길이를 정의한다.

정의된 각 컬럼에 대해 적용 DBMS에서 제공하는 데이터유형 중 적절한 유형을 정의하고 해당 데이터의 최대 길이를 파악하여 길이를 설정한다.

CHAR : 고정길이 문자열 Data 최대 2000Byte 까지 저장 가능

VARCHAR : 가변길이 문자열 Data 최대 4000Byte 까지 저장 가능

NUMBER : 38자리수의 숫자 저장가능

6. 반정규화 한다.

1.3 테이블 제약조건 설꼐

1. 삭제 제약 조건 설계 

참조된 기본키의 값이 삭제될 경우의 처리내용을 정의한다.

Cascade : 참조한 테이블에 있는 외부키와 일치하는 모든 Row가 삭제

Restricted : 참조한 테이블에 있는 외부키에 없는 것만 삭제 가능

Nullify : 참조한 테이블에 정의된 외부키와 일치하는 것을 Null로 수정

2. 수정 제약 조건 설계

참조된 기본키의 값이 수정될 경우의 처리내용을 정의한다.

Cascade : 참조한 테이블에 있는 외부키와 일치하는 모든 Row가 수정

Restricted : 참조한 테이블에 있는 외부키에 없는 것만 수정 가능

Nullify : 참조한 테이블에 정의된 외부키와 일치하는 것을 Null로 수정

1.4 인덱스 설계

1. 인덱스 적용 기준

인덱스 적용 대상 컬럼은 전체 Row 값대비 분포도가 10~15% 이내인 경우가 적합하다.

분포도가 범위 이상이더라도 부분처리를 목적으로 하는 컬럼인 경우

입출력 장표등에서 조회 및 출력 조건으로 사용되는 컬럼일 경우

인덱스가 자동 생성되는 기본키와 Unique키의 제약조건을 사용하는 컬럼

2. 인덱스 컬럼 선정

분포도가 좋은 컬럼은 단독적으로 생성하여 활용도를 향상시킨다.

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

결합 인덱스를 구성하는 컬럼순서 선정(사용빈도, 유일성, Sort 등)에 유의해야 한다.

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

3. 인덱스 설계 시 고려사항

새로운 인덱스가 기존 액세스 경로에 영향을 미칠 수 있음에 유의한다.

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

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

넓은 범위를 인덱스 처리 시 오히려 전체 처리보다 많은 오버헤드를 발생 시킬 수 있다.

인덱스와 테이블 데이터의 저장 공간이 적절히 분리되도록 설계해야 한다.

1.5 뷰 설계

1. 뷰 속성

REPLACE : 뷰가 이미 존재하는 경우 재생성 한다.

FORCE : 기본 테이블의 존재 여부에 관계없이 뷰 생성을 한다.

NOFORCE : 기본 테이블이 존재할 때만 뷰를 생성한다.

WITH CHECK OPTION : Sub-Query 내의 조건을 만족하는 행만 변경

WITH READ ONLY : DML 작업 불가

2. 뷰 설계 시 고려사항

최종적으로는 테이블을 액세스하는 것이므로 사용에 따라 수행속도에 문제가 발생할 수 있다.

1.6 클러스터 설계

1. 적용 기준

분포도가 넓은수록 오히려 유리(인덱스의 단점을 해결) 한 기법이다.

액세스 기법이 아니라 액세스 효율 향상을 위한 물리적 저장 방법

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

다중블록 이상의 테이블에 적용

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

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

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

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

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

Union, Distict, Order by,Group by가 빈번한 컬럼이면 고려해 보아야 함

수정이 자주 발생하지 않는 컬럼을 고려 대상이다.

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

1.7 파티션 설계

1. 파티션 종류

범위분할 : 지정한 열의 값을 기준으로 분할

해시분할 : 해시 함수에 따라 데이터를 분할

조합분할 : 범위분할에 의해 데이터를 분할한 다음 해시 함수를 적용하여 다시 분할

2. 파티션 장점

데이터 액세스 범위를 줄여 성능 향상

전체 데이터의 훼손 가능성이 감소 및 데이터 가용성 향상

각 분할 영역을 독립적으로 백업하고 복구 가능

Disk Striping으로 I/O성능 향상 (Disk 컨트롤러에 대한 경합 감소)

1.8 디스크 구성 설계

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

2. 업무량이 집중되어 있는 디스크를 분리하여 설계함으로써 집중화된 디스크에 대한 입출력 부하를 분산한다.

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

• 테이블을 위한 스페이스와 인덱스를 위한 스페이스를 분리 구성한다.
• 테이블 스페이스와 템포러리 스페이스를 분리 구성한다.
• 테이블을 마스터 테이블과 트랜잭션 테이블로 분류한다

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

5. 파티션할 테이블을 별도로 분류한다.

2. ORM 프레임워크

객체 관계 매핑은 관계형 데이터베이스와 객체 지향 프로그래밍언어 간의 호환되지 않는 데이터를변환하는 프로그래밍 기법이다. 객체 지향 언어에서 사용하는 개체를 관계형 데이터베이스로 변환하여 테이블을 구성하는데 활용된다.

2.1 ORM매핑 기법

1. 객체와 테이블 간의 변환 방법

객체지향에서 객체/클래스는 관계형 데이터베이스에서 테이블로 매핑

어트리뷰트는 컬럼으로, 오퍼레이션은 프로시져 혹은 함수로 매핑

2. 관계와 테이블 간의 변환 방법

2.2 ORM 절차

1. 클래스를 테이블로 변환

클래스의 인스턴스는 테이블의 레코드로 매핑

2. 애트리뷰트를 컬럼으로 변환

클래스 인스턴스의 애트리뷰트는 테이블의 컬럼으로 매핑

3. 클래스간 관계는 관계형 테이블 간의 관계로 변환

클래스 간의 관계인(어소시에이션, 애그리게이션, 제너럴리제이션)을 관계형 데이터베이스의 테이블 간 제약사항으로 변환

3. ORM 기술 간 비교

3. 트랜잭션 인터페이스

물리 데이터저장소에서 트랜잭션 인터페이스는 전체적인 데이터베이스 트랜잭션의 골격 및 인터페이스를 정의하는 활동이다. 트랜잭션은 데이터베이스 입출력과 기능적 형태로 정의된다.

3.1 데이터베이스 트랜잭션 특징

1. 원자성

트랜잭션 연산을 데이터베이스 모두 반영되든지 아니면 전혀 반영되지 않아야 한다.

2. 일관성

트랜잭션이 그 실행을 성공적으로 완료하면 언제나 일관성 있는 데이터베이스 상태로 변환된다.

3. 독립성

둘 이상의 트랜잭션이 동시에 병행 실행되는 경우 어느 하나의 트랜잭션 실행 중에 다른 트랜잭션의 연산이 끼어들 수 없다.

4. 영속성

성공적으로 완료된 트랜잭션의 결과는 시스템이 고장나더라도 영구적으로 반영된다.

3.2 데이터베이스 트랜잭션 연산자

1. COMMIT

하나의 트랜잭션에 대한 작업이 성공적으로 끝나고 수행결과를 관리자에게 알려주는 연산

2. ROLLBACK

하나의 트랜잭션 처리가 비정상적 종료되어 해당 트랜잭션을 재시작 혹은 폐기하는 연산

3. RECOVERY

트랜잭션들을 수행하는 도중 장애로 인해 손상된 데이터베이스를 손상되기 이전의 정상적인 상태로 복구시키는 연산

3.3 트랜잭션 인터페이스 설계

데이터베이스 접근 방법 및 인터페이스를 절차적으로 명세한다.

트랜잭션 인터페이스는 주로 프로그래밍 언어로 구현된다.

 예를 들면 java는 JDBC,JTS 등이 여기 해당하는 솔루션이다.

c언어는 MTS가 여기에 해당한다.

2. 소프트웨어 개발

 2.1 데이터 입출력 구현

  2.1.1 데이터 입출력 구현 능력 단위 정의

  2.1.2 논리 데이터저장소 확인

- 데이터 입출력 구현 능력 단위 정의

데이터 입출력 구현이란 응용소프트웨어가 다루어야 하는데 데이터 및 이들 간의 연관성, 제약조건을 식별하여 논리적으로 조직화하고, 소프트웨어 아키텍처에 기술된 데이터저장소에 조직화된 단위의 데이터가 저장될 최적화된 물리적 공간을 구성하고 데이터 조작언어를 이용하여 구현하는 능력이다.

- 논리 데이터 저장소 확인

1. 자료구조 

1.1 자료 구조 정의

자료 구조는 컴퓨터 상에 자료를 저장하기 위해서 만들어진 논리적인 틀을 말한다. 논리 데이터저장소를 확인하기 위해서는 데이터를 저장하는 자료구조를 이해하고 있어야 한다.

1.2 자료 구조 분류

파일은 같은 타입의 레코드들의 집합을 말한다.

파일의 레코드들을 물리적 저장 장치에 저장시키기 위한 배치 방법으로서 데이터베이스의 물리적 저장 방법이 된다.

기본적으로 저장된 레코드들이 어떻게 접근할 수 있게 하느냐에 따라 크게 순차 방법, 인덱스 방법, 해싱 방법 등으로 나눌 수 있다.

1. 선형 리스트

선형 리스트는 배열과 같이 연속되는 기억장소에 저장되는 리스트이다.

선형 리스트의 대표적인 구조 : 배열

가장 간단한 자료구조이며 접근속도가 빠르다

중간에 자료를 삽입하기 위해서는 연속된 빈 공간이 있어야 한다.

자료의 삽입, 삭제 시 자료의 이동이 필요하기 때문에 번거롭다.

2. 연결 리스트

연결 리스트는 자료들을 선형 리스트처럼 연속으로 배열시키지 않고 임의의 기억 공간에 기억 시키되 각 노드의 포인터를 이용하여 서로 연결한 자료구조이다.

노드의 삽입, 삭제 작업이 용이하다.

기억공간이 연속적으로 놓여있지 않아도 저장이 가능하다.

연결을 위한 포인터가 추가로 필요하기때문에 기억공간을 더 필요로한다.

연결을 위한 포인터를 찾는 시간이 필요하기 때문에 순차리스트에 비해 느리다.

희소 행렬을 링크드 리스트로 표현하면 기억장소가 절약된다.

3. 스택

한 쪽 끝에서만 자료를 넣고 뺄 수 있는 LIFO 형식의 자료구조

응용분야는 서브 프로그램 호출 시 복귀 주소 저장에 활용한다.

인터럽트 수행 시 복귀 주소 저장에 활용한다.

수식 연산에 활용한다.

4. 큐

스택과 달리 리스트의 한쪽 끝에서는 삽입 작업이 이루어지고, 반대쪽 끝에서는 삭제 작업이 이루어져 삽입된 순서대로 삭제되는 구조

선입선출 구조 FIFO

Front Pointer는 삭제작업, Rear Pointer는 삽입 작업을 할 때 사용한다.

5. 데크

큐의 양쪽 끝에서 삽입과 삭제가 모두 가능한 자료 구조

두개의 포인터를 사용하여, 양쪽에서 삭제와 삽입을 발생 시킬 수 있다.

큐와 스택을 합친 형태이다.

1.3 트리

1. 트리 개념

데이터들을 계층화 시킨 자료 구조

인ㄷ덱스를 조직하는 방법으로 가장 많이 사용되는 구조

트리는 노드들과 노드들을 연결하는 링크들로 구성

2. 트리의 기본적인 성질

노드가 N개의 트리는 항상 N-1 개의 링크를 가진다.

루트에서 어떤 노드로 가는 경로는 유일하다. 또한 임의의 두 노드 간의 경로도 유일하다.

(같은 노드를 두번 이상 방문하지 않는다는 조건하에)

1.4 트리의 순회 방법

1. 중위 순회

왼쪽 서브트리를 중위 순회한다.

중간 노드를 방문한다.

오른쪽 서브 트리를 중위 순회한다.

위의 예에서 D,B,E,A,F,C 순서로 조회한다.

2. 전위 순회

중간 노드를 방문한다.

왼쪽 서브트리를 전위 순회한다.

오른쪽 서브 트리를 전위 순회한다.

위의 예에서 A,B,D,E,C,F 순서로 조회한다.

3. 후위 순회

왼쪽 서브트리를 후위 순회한다.

오른쪽 서브 트리를 후위 순회한다.

중간 노드를 방문한다.

위의 예에서 D,E,B,F,C,A 순서로 조회한다.

1.5 트리 순회방법을 활용한 수식표현법

1. 전위 표기법(prefix)

연산자, 변수, 변수(+AB)의 순서로 수식을 표현하는 표기법

연산자가 가장 먼저 나온다.

2. 중위 표기법(infix)

변수, 연산자, 변수(A+B)의 순서로 수식을 표현하는 표기법

연산자가 중간에 나온다.

3. 후위 표기법(posfix)

변수, 변수, 연산자 (AB+)의 순서로 수식을 표현하는 표기법

연산자가 가장 나중에 나온다.

4. 중위식 -> 전위식으로 표현하는 방법

Infix를 prefix나 postfix로 바꿀 때는 먼저 연산순위를 결정한다.

연산순서가 빠른 순으로 연산자를 그 연산을 수행하는 변수 앞으로 옮긴다.

5. infix -> postifx

연산순서가 빠른순으로 연산자를 그 연산을 수행하는 변수 뒤로 옮긴다.

6. prefix -> infix

앞에서부터 연산자, 변수, 변수 순으로 된 것을 찾아 연산자를 변수와 변수 사이로 옮긴다.

7. postfix -> infix

앞에서부터 변수, 변수, 연산자 순으로 된 것을 찾아 연산자를 변수와 변수 사이로 옮긴다.

1.6 이진트리

1. 이진트리의 개념

이진트리에서 각 노드는 최대 2개의 자식노드를 가진다.

각각의 자식 노드는 자신이 부모의 왼쪽 자식인지 오른쪽 자식인지가 지정된다.

2. 이진트리 종류

포화 이진트리는 모든 레벨에서 노드들이 모두 채워져 있는 트리이다.

완전 이진트리는 마지막 레벨을 제외하고 노드가 모두 채워져있는 트리이다.

마지막 레벨도 모두 다 채워져 있거나 오른쪽으로 연속된 몇개의 노드만 비어 있을 수 있다.

편향 이진트리는 트리의 노드가 왼쪽이나 오른쪽으로 한쪽으로만 노드가 있는 트리이다.

3. 이진트리 특징

높이가 h인 포화이진트리는 2의 h승 -1개의 노드를 가진다.

노드가 N개인 포화 혹은 완전 이진트리의 높이는 O(log2N)이다.

노드가 N개인 이진트리의 높이는 최악의 경우 O(N)이 될 수 있다.

1.7 그래프

1. 그래프의 개념

단순히 노드와 그 노드를 연결하는 간선을 하나로 모아 놓은 자료구조이다.

즉 연결되어 있는 객체 간의 관계를 표현할 수 있는 자료구조이다.

2. 그래프 표현 방법

그래프 G = (V,E)이고 다음 V,E는 다음과 같다.

V(G) : 정점

E(G) : 간선, 정점을 연결하는선

3. 그래프종류

무방향 그래프 : 정점을 연결하는 선에 방향이 없다.

정점(V)이 n개인 무방향 그래프에서는 최대 간선(E)가 n(n-1)/2이다.

방향 그래프 : 정점을 연결하는 선에 방향이 있다.

방향그래프에서는 두 정점에 대하여 방향이 다른 두 개의 간선을 연결할 수 있으므로 최대 간선 수는 무방향 그래프의 2배가 되어 n(n-1)이 된다.

4. 그래프 특징

 그래프는 네트워크 모델이다.

루트노드, 부모-자식 관계라는 개념이 없다.

2개 이상의 경로가 가능하다.

자기 자신을 향하는 간선은 없다.

중복된 간선을 허용하지 않는다.

1.8 그래프 관련 용어

1. 완전 그래프

그래프에서 간선의 수가 최대인 그래프를 말한다.

무방향 그래프 경우 n개의 정점이 있는 경우 간선의 수는 n(n-1)/2 이다.

방향 그래프의 경우 n개의 정점이 있는 경우 간선의 수는 n(n-1)이다.

2. 인접 : 무방향 그래프에서 정점 a,b에 대하여 간선(a,b)가 있으면 정점 a는 정점 b에 인접하다고 한다.

3. 부속 : 무방향 그래프에서 정점 a,b에 대하여 간선(a,b)가 있으면, 간선(a,b)는 정점 a,b에 부속한다고 한다.

4. 부분 그래프 

그래프 G에 일부분인 그래프 G'를 말한다.

5. 경로 : 정점 Vp에서 Vp로 가는 경로

6. 경로의 길이 : 경로상에 있는 간선의 수

7. 단순 경로 : 처음과 마지막을 제외하고 정점이 모두 다른 경로, 즉 경로상의 정점이 중복되지 않는 경로를 단순경로라고 한다.

8. 사이클 

처음과 마지막 정점이 다른 단순 경로, 즉 단순경로 중 경로가 다시 원점에 도달하는 경우이며 사이클을 형성한다.

방향성 그래프에서는 방향성 사이클이라 한다.

9. 연결됨 : 점점 V0와 V1이 연결되어 있다는 것은 그래프 G에서 정점V0에서 V1로 가는 경로가 있는 경우이다.

2. 자료 저장 방법

2.1 순차 방법

1. 정의 

레코드들의 물리적 순서가 그 레코드들의 논리적 순서와 같게 저장하는 방법이다.

2. 종류

엔트리 순차 파일 : 레코드가 시스템에 삽입되는 순서대로 만들어지는 파일

키순차 파일 : 레코드들의 키값의 크기 순으로 만들어지는 파일

3. 특징

레코드 접근은 기본적으로 레코드가 저장되어 있는 물리적 순서에 따른다.

따라서 어느 한 레코드를 접근하기 위해서는 물리적으로 이 레코드 앞에 저장되어 있는 모든 레코드들을 접근하지 않으면 안되기 때문에 이 순차파일은 파일을 복사하거나 레코드들을 순차적으로 일괄 처리 하는 응용에서 많이 사용한다.

2.2 인덱스 방법

1. 정의

기본적으로 데이터 레코드를 접근하기 위해서 먼저 인덱스를 찾아서 그 인덱스가 가리키는 주소를 따라가 원하는 레코드를 접근하는 방법이다.

2. 특징

인덱스 파일을 사용하는데 데이터파일은 인덱스 파일과 데이터 파일로 구성

인덱스 파일은 <키, 주소> 쌍으로 구성된다.

3. 종류

인덱스된 순차파일 : 하나의 인덱스를 사용

키값에 따라 정렬된 데이터 레코드를 순차적으로 접근하거나 주어진 키 값을 가지고 직접 접근하는 두가지 방법을 모두 지원하는 구조 이다.

3. 데이터 모델링 개요

3.1 데이터 모델링 정의

현실 세계의 사용자 요구사항을 컴퓨터 세계의 정보구조로 변환하기 위하여 실체와 관계를 중심으로 분석/설계하여 점차 자료구조를 만들어가는 과정이다.

3.2 데이터 모델링 목적 및 특징

1. 데이터 모델링 목적

연관 조직의 정보요구에 대한 정확한 이해를 할 수 있다.

사용자, 설계자, 개발자 간에 효율적인 의사소통 수단을 제공한다.

데이터 체계 구축을 통한 고품질 S/W와 유지보수 비용의 감소효과를 기대할 수 있다.

신규 또는 개선 시스템의 개발 기초를 제공한다.

2. 데이터 모델링 특징

데이터 중심 분석을 통한 업무 흐름 파악이 용이하다.

데이터 무결성을 보장할 수 있다.

데이터의 공유를 통한 중복을 제거하고 일관성 있는 정보를 제공받을 수 있다.

3. 데이터 모델링 절차

4. 논리 데이터저장소

4.1 논리 데이터저장소 개요

1. 논리 데이터저장소 개념

데이터 구조 등의 논리적인 자료구조로 만들어진 데이터 저장소이다.

물리 데이터 저장소와는 별개로 사용자 혹은 개발자가 이해하기 쉬운 놀리적인 구조로 추상화 하여 제공한다.

엔티티 : 관리할 대상이 되는 실체

속성 : 관리할 정보의 구체적 항목

관계 : 엔티티간의 대응 관계

2. 논리 데이터 모델링 개념

데이터 구조에 대한 논리적 정의단계로서 정확한 업무 분석을 통한 자료의 흐름을 분석하여 현재 사용 중인 양식, 문서, 장표를 중심으로 자료항목을 추출하여 추출된 엔티티와 속성들의 관계를 구조적으로 정의하는 단계이다.

논리 데이터 저장소를 설꼐하는 과정이 논리 데이터 모델링이다.

3. 논리 데이터 모델링 특성

논리적 데이터 모델링 시 요구사항을 충분히 수집하지 않으면 다음 단계의 요구사항 변경에 따른 많은 비용이 발생한다.

모든 이해당사자들과 의사소통의 보조자료로서 E-R 모델을 활용한다.

논리적 모델은 하드웨어나 소프트웨어에 독립적이다.

4.2 논리 데이터저장솧 확인 절차

1. 엔티티 확인 

작성된 엔티티 목록, 엔티티 정의서, 논리 ER-Diagram과 To-Be업무 흐름도를 비교하면서 엔티티 누락 여부 및 중복 여부를 확인한다.

2. 속성 확인

엔티티 정의서에서 데이터 속성을 확인한다.

자주 사용되는 코드성 데이터는 공통코드 대상이다.

3. 데이터 흐름 확인

데이터 프로세스와 엔티티 목록으로 CRUD Matrix를 작성한다.

CRUD Matrix에서 사용되지 않는 엔티티가 있는지 확인한다.

CRUD Matrix에서 엔티티를 사용하지 않는 프로세스가 있는지 확인한다.

4. 데이터 접근 권한 및 통제 확인

다수의 사용자가 접근하는 데이터베이스에서 각 사용자 또는 사용자 집단이 자신들이 허가받은 데이터에만 접근하도록 제어해야 한다.

5. 데이터 백업 정책 및 분산 구조 확인

데이터 백업 주기 및 대상, 백업 방식에 대하여 확인한다.

1.소프트웨어 설계

 1.4 인터페이스 설계

  1.4.4 인터페이스 상세 설계

-인터페이스 상세 설계

1. 내외부 송/수신

내외부 송/수신의 연계 방식은 직접 연계 방식과 간접 연계 방식으로 분류할 수 있다. 직접 연계 방식은 중계 서버나 솔루션을 사용하지 않고 송신 시스템과 수신 시스템이 직접 인터페이스 하는 방식이다. 간접 연계 방식은 연계 솔루션에서 제공하는 송/수신 엔진과 어댑터를 활용하는 인터페이스 방식이다.

1.1 직접 연계 방식

일반적으로 중간의 연계 매개체가 생략되어 연계 처리 속도가 빠르고 구현이 단순하며, 개발 비용과 기간이 짧은 장점이 있다.

송신 시스템과 수신 시스템 사이의 결합도가 높아 시스템 변경에 민감함 특성이 있다.

보안을 위한 암/복호화 처리와 업무 기능 구현을 인터페이스별로 작성하여, 전사 차원의 시스템 인터페이스 통합 환경 구축이 어려운 단점이 있다.

1.2 간접 연계 방식

연계 서버를 활용하여 송/수신 처리와 송/수신 현황을 모니터링하고 통제하는 방식으로, 서로 상이한 네트워크와 프로토콜 등 다양한 환경의 시스템들을 연계하고 통합 관리할 수 있다.

장점으로 인터페이스 변경 시에도 유연하게 대처가 가능하고 보안이나 업무처리 로직 반영이 용이하다.

단점으로 인터페이스 아키텍처와 연계 절차가 복잡하고 연계 서버로 인한 성능 저하, 개발 및 테스트 기간이 직접 연계 방식보다 오래 걸린다.

1.3 연계 기술

시스템 연계 기술은 데이터베이스에서 제공하는 DB Link, JDBC, Socket, Web Service 등이 있다.

1.4 인터페이스 처리유형

업무의 성격 및 데이터 전송량에 따라 사용자의 요청이 즉시 처리해야 하는 경우는 실시간 처리 방식, 단위 처리의 비용이 과다하게 발생하는 경우는 지연처리 방식, 대량의 데이터를 한번에 처리해야하는 경우는 배치 처리 방식으로 처리 유형을 정의한다.

2. 데이터 명세화

2.1 데이터 명세화의 개념

인터페이스 요구 사항 분석 과정에서 식별한 연계 정보에 해당하는 테이블 정의서, 파일 레이아웃, 코드 정의서 등을 통해 데이터를 명세화 한다.

1. 개체 정의서

데이터베이스 개념모델링 단계에서 도출한 개체의 타입과 관련 속성, 식별자 등의 정보를 개괄적으로 명세화한 정의서이다.

2. 테이블 정의서

논리 및 물리 모델링 과정에서 작성하는 설계 산출물로 테이블을 구성하는 컬럼들의 특성, 인덱스 업무 규칙을 문서화한 것이다.

컬럼의 특성은 컬럼명, 데이터 타입, 길이, NULL 여부, 키 여부, 디폴드 값 등을 의미한다.

3. 코드 정의서

코드 정의서는 코드에 대한 명명규칙을 정하고, 명명규칙에 따라 어떠한 코드를 사용할 지를 정의한 문서이다. 코드는 전체 데이터베이스에서 유일하게 정의된다.

2.2 송수신 데이터 명세서

송/수신 시스템의 테이블 정의서, 파일 레이아웃,코드 정의서 등에서 연계하고자하는 테이블 또는 파일 단위로 송/수신 데이터 병세를 작성한다.

송/수신 데이터 항목에 대한 데이터 타입 길이, 필수항목 여부, 식별자 여부를 정의하고 코드 데이터 항목의 경우 공통 코드 여부와 코드 값 범위 등을 정의한다.

법률 또는 조직 내부에서 정한 개인정보보호 관련 규정 들을 참고하여 암호화 대상 컬럼을 식별하고 송/수신 데이터에 포함된 경우 암호화 적용 여부를 정의한다.

3. 오류 처리방안 명세화

3.1 인터페이스 오류 유형

시스템 연계 과정에서 발생할 수 있는 장애나 오류의 유형은 연계 시스템의 장애, 송신 시스템의 연계 프로그램 오류 또는수신 시스템의 연계 프로그램 오류, 연계 데이터 자체 오류 등으로 구분할 수 있다.

송신 시스템의 연계 프로그램 오류는 연계 데이터를 생성하거나 추출하는 과정, 코드 및 데이터를 변환하는 과정에서 발생할 수 있다.

수신시스템의 연계 프로그램 오류는 운영 데이터베이스에 데이터를 반영하거나 코드 및 데이터를 변환하는 과정에서 발 생할 수 있다.

3.2 인터페이스 오류 처리 방법

1. 인터페이스 오류 처리 절차

연계 서버와 송/수신 시스템의 로그파일에 오류 코드와 발생한 에러의 상세 내용을 기록하도록 연계프로그램을 작성하여, 인터페이스 오류의 확인과 해결에 활용한다.

오류가 발생하면 연계 서버와 송/수신 시스템에 기록된 로그 파일의 내용을 확인하여 오류 원인을 분석하고 해결 방안을 수립한다.

오류 유형에 따른 해결 방안은 다음과 같다.

연계 데이터 오류의 경우 데이터를 보정하고 재전송한다.

송/수신 시스템의 접속 오류인 경우 담당자 또는 시스템 상태 확인을 통해 접속오류를 해결한 후 재전송한다.

2. 인터페이스 오류 코드 및 내용

인터페이스 장애 및 오류 처리를 위해 발생할 수 있는 오류를 유형별로 구분하여 관리해야한다.

오류코드는 오류를 식별하고 관리할 수 있는 고유 코드이며, 오류 발생지와 오류 유형, 일련번호를 포함하여 오류 코드 명명 규칙을 정의할 수 있다.

3. 오류처리 명세화 절차

대내외 시스템 연계에서 발생할 수 있는 시스템 장애, 전송 오류, 연계 프로그램에서 정의한 예외 상황 등의 오류 상황을 식별하고 분류한다.

오류 상황에 대하여 발생 영역 분류, 오류 코드, 오류 메시지, 오류 설명, 대응 방법 등을 명시한다.

4.인터페이스 설계

인터페이스 설계는 인터페이스 목록의 도출과 인터페이스 정의서 작성이 주된 활동이 된다.

4.1 인터페이스 목록 도출

 인터페이스 목록은 연계 업무와 연계에 참여하는 송/수신 시스템의 정보, 연계방식과 통신 유형 등의 대한 정보를 포함한다. 인터페이스 목록에는 다음과 같은 주요 항목들이 정의되어야 한다.

• 인터페이스 아이디
• 인터페이스 명
• 시스템 및 대내외 구분
• 연계방식
• 통신유형
• 처리유형
• 주기
• 데이터형식

4.2 인터페이스 정의서 작성

인터페이스 명세는 데이터 송신 시스템과 수신 시스템 간의 데이터 저장소와 속성등의 상세 내역을 포함한다.

• 인터페이스 아이디
• 요구성능
• 시스템 정보
• 데이터 정보

5. 미들웨어 솔루션

5.1 미들웨어 솔루션의 개념

기능적으로 클라이언트와 서버 사이의 통신을 담당하는 시스템 소프트웨어

컴퓨터와 컴퓨터의 연결의 담당하는 소프트웨어로 중간을 의미하는 미들과 소프트웨어를 의미하는 웨어의 합성어

5.2 웹 서버와 웹 애플리케이션 서버

1. 웹서버

웹브라우저의 요청을 받아 html파일이나 이미지/그림,자바스크립트의 정적인 콘텐츠를 제공한다.

2. 웹 애플리케이션 서버

서버계층에서 애플리케이션이 동작할 수 있는 환경을 제공하고 안정적인 트랜잭션 처리와 관리, 다른 이기종 시스템과의 애플리케이션 연동을 지원한다. 웹서버와의 가장 큰 차이점은 동적 서버 콘텐츠를 수행할 수 있는 기능이다.

3. 웹서버와 웹 애플리케이션 서버의 일반적인 구성

사용자가 웹 브라우저를 이용해 요청하는 경우 정적인 데이터는 웹서버가 처리하고 동적인 콘텐츠의 경우 WAS로 서비스를 요청함으로써 서버 자원을 효율적으로 처리할 수 있도록 구성한다.

1.소프트웨어 설계

 1.4 인터페이스 설계

  1.4.3 인터페이스 대상 식별

- 인터페이스 대상 식별 

1. 시스템 아키텍처

1.1 시스템 아키텍처 개념

시스템이 어떻게 작동하는지를 설명하는 프레임 워크이다. 시스템 목적을 달성하기 위해 시스템의 각 컴포넌트가 무엇이며 어떻게 상호작용하는지, 정보가 어떻게 교환되는지를 설명한다.

1.2 시스템 아키텍처의 기본 요구사항 

• 시스템 구성 및 동작 원리를 나타내고 있다.
• 시스템 구성 요소(부품)에 대해 설계 및 구현을 지원하는 수준으로 자세히 기술된다.
• 구성요소 간의 관계 및 시스템 외부 환경과의 관계가 묘사된다.
• 요구 사양 및 시스템의 전체 수명주기를 고려한다.
• 하드웨어와 소프트웨어를 포함하는 시스템 전체에 대한 논리적인 기능 체계와 그것을 실현하기 위한 구성 방식. 시스템의 전체적인 최적화를 목표로 하고 있다.

1.3 시스템 아키텍처 설계

• 소프트웨어 개발에서는 다양한 수준의 설계작업이 있다. 소프트웨어 시스템의 아키텍처 설꼐에 제약을 주는 상위설계로서의 시스템 아키텍처의 설계가 있고, 소프트웨어 아키텍처의 제약 안에서 세부적인 설계작업을 수행하게 되는 소프트웨어 상세 설계가 있다.
• 이들 세가지 설계는 일반적인 설계활동의 하나로서 설계가 갖는 일반적인 특성을 공통적으로 갖는다.

그러나 시스템 아키텍처는 하드웨어와 소프트웨어로 구성된 시스템의 아키텍처를 지칭하며 소프트웨어 아키텍처의 결정을 제약하게 되고, 소프트웨어 아키텍처 설계는 소프트웨어 상 세설계의 결정을 제약하는 각기 다른 수준의 설계를 의미한다. 위 그림에서 화살표의 굵기는 영향력의 크기를 나타낸다.

2. 인터페이스 시스템

2.1 인터페이스 시스템의 개념

시스템 인터페이스의 구성은 크게 송신시스템과 수신시스템, 연계방식에 따라 중계시스템을 구성할 수 있다.

1. 송신 시스템

데이터베이스와 애플리케이션으로부터 연계할 데이터를 테이블 또는 파일 형태로 생성하여 송신하는 시스템이다.

2. 수신 시스템

수신한 테이블 또는 파일의 데이터를 수신 시스템의 환경에 맞게 변환하여 데이터베이스에 저장하거나 애플리케이션에서 활용할 수 있도록 처리하는 시스템이다.

3. 중계 시스템

송신시스템과 수신시스템 사이에서 데이터를 송/수신 하고 송/수신 현황을 모니터링 하는 시스템이다.

2.2 인터페이스 데이터 표준

인터페이스 시스템 사이에서 교환되는 데이터는 규격화된 표준 형식을 정의하여 사용한다.

인터페이스 설계 단계에서 송/수신 시스템 사이에 전송되는 표준 항목과 업무 처리 데이터, 공통 코드 정보 등을 누락없이 식별하고 인터페이스 명세서를 작성해야 한다.

인터페이스 데이터 공통부는 인터페이스 표준 항목을 포함하며 인터페이스 데이터 개별부는 송/수신 시스템에서 업무처리에 필요한 데이터를 포함한다. 인터페이스 데이터는 전송 데이터의 끝을 표시하는 문자를 포함하여 종료를 나타낸다.

2.3 인터페이스 시스템의 처리 흐름

송신시스템에서 전송할 데이터를 생성하여 연계서버에 전달하면 연계서버는 목표시스템에 데이터를 연계 전송한다.

연계서버는 시스템간 연계상태와 데이터의 송/수신 오류 여부를 모니터링하여 해당하는 조치를 수행한다.

오답 풀이

모두 정답~~~~!!

1.소프트웨어 설계

 1.4 인터페이스 설계

  1.4.1 인터페이스 설계 능력 단위 정의

  1.4.2 인터페이스 요구사항 확인

- 인터페이스 설계 능력 단위 정의

인터페이스 설계란 응용소프트웨어 개발을 위해 정의된 시스템 인터페이스 요구사항을 확인하고 인터페이스 대상을 식별하여 인터페이스 설계서를 작성하는 능력이다

- 인터페이스 요구사항 확인

1. 내외부 인터페이스 요구사항

1.1 내외부 인터페이스 요구사항의 개념

내외부 인터페이스란 조직 내/외부에 존재하는 시스템이 연동을 통해 상호 작용하기 위한 접속 방법이나 규칙을 의미한다. 네트워크를 통해 조직 내/외부에 존재하는 시스템 간의 요구기능을 수행하기 위해서 내외부 인터페이스 설계와 개발은 필수적이다.

내외부 인터페이스 요구 사항의 구성

• 내외부 인터페이스 이름
• 연계 대상 시스템
• 연계 범위 및 내용
• 연계 방식
• 송신 데이터
• 인터페이스 주기
• 기타 고려 사항

1.2 내외부 인터페이스 요구 사항 분석

내외부 인터페이스 요구 사항 분석은 요구사항 정의 단계에서 정의한 기능 및 비기능 내외부 인터페이스 요구 사항을 식별하고 분류, 조직화하여 명세를 구체화하는 작업이다.

요구사항 명세서와 유스케이스 다이어그램 등과 같은 개념모델을 검토하여 상위 수준의 요구사항은 분해하여 적절한 수준으로 상세화 한다.

요구사항에 대한 중요도를 평가하여 우선순위를 부여한다.

2. 요구공학

2.1 요구공학의 개념

1. 요구공학

요구공학이란 시스템 요구사항 문서를 생성, 검증, 관리 하기위하여 수행되는 구조화된 활동의 집합을 의미한다.

2. 요구공학의 목적

이해관계자 사이에 효과적인 의사소통 수단을 제공하고 요구사항에 대한 공통 이해를 설정한다.

요구사항 손실 방지 및 에러감지로 불필요한 비용을 절감하고 요구사항 변경 추적을 가능하게 한다.

2.2 요구공학 프로세스

요구공학의 프로세스는 요구사항 개발과 요구사항 관리로 구성된다.

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

요구사항 개발은 요구사항 도출, 분석, 명세, 확인의 절차로 이루어진다. (SWEBOK : SoftWare Enginnering Body of Knowledge)

요구사항 개발 절차

요구사항 명세 원리와 내용

요구사항은 기능적 요구사항과 비기능적 요구사항으로 구분된다.

2. 요구사항 검증

요구 사항 검증은 사용자의 요구가 정확하게 요구 사항 명세서에 기술되었는지를 검토하고 베이스라인으로 설정하는 활동이다.

3. 요구 사항 검증 방법

요구 사항 검토는 요구 사항 검토 담당자들이 요구사항 명세서를 수작업으로 분석하는 방법으로 요구사항 명세서에 오류가 없는지, 불명확한지, 표준을 준수했는지 등을 검토한다. 검토방법은 동료 검토와 워크 스루, 인스펙션 등이 활용된다.

프로토타이핑은 개발할 시스템에 대한 주요기능이나 일부분을 약식으로 개발하여 최종 사용자나 고객을 대상으로 시연하면서 시스템이 작동하는 모습을 경험할 수 있게 하고 요구사항을 확인한다.

테스트 설계는 요구사항을 테스트할 수 있도록 테스트 케이스를 생성하여 추후 요구사항이 현실적으로 테스트 가능한지를 검토한다.

• 인터페이스 요구사항에 대한 테스트 케이스는 송신시스템과 수신 시스템에서 확인해야 할 사항을 각각 도출하고, 송/수신 시스템에서 각각 개별 데이터의 유효값을 체크하는 테스트 케이스와 송/수신 데이터 간 연관 관계를 체크하느 테스트 케이스로 구별해서 작성한다.
• 송/수신 데이터가 코드성 데이터일 경우, 코드의 유효값을 체크할 수 있도록 테스트 케이스를 작성한다.
• 수신 시스템에서 전송받은데이터를 운영 DB에 반영하는 과정에서 오류가 발생하지않는지, 송/수신 시스템에서 참조하는 테이블에 데이터가 없거나 데이터 갱신 및 등록 오류가 발생하는지를 점검할 수 있도록 테스트 케이스를 작성한다.

CASE 도구 활용은 구조화된 요구사항명세서에 대해서는 자동화된 일관성 분석을 제공하느 CASE도구를 활용할 수 있다 대규모 개발 프로젝트에서는 다양한 이해관계자들이 요구사항 명세서를 검토해야 하고, 요구사항 명세서에 대해 형상관리를 수행해야 해서 요구사항 관리툴을 이용한다.

4. 요구사항 관리(CMMI Level2 프로세스 영역(PA))

요구사항 협상, 요구사항 기준선, 요구사항 변경관리, 요구사항 확인을 수행한다.

오답풀이

다음 중 CASE 도구의 설명으로 옳지 않은 것은?

1. 소프트웨어 개발과정 일부 또는 전체를 자동화하기 위한 도구이다.

2. 표준화된 환경구축 및 문서과정의 자동화를 할 수 있다.

3. Upper CASE는 계획 수립, 요구분석, 기본설계 단계를 지원하고 이를 Diagram으로 표현한다.

4. Lower CASE는 상세설계 작업을 지원하며 화면 출력 등의 작성을 지원한다.(정답)

Lower CASE 는 시험, 유지보수 작업을 지원하며 소스코드와 시스템 명세서를 획득한다.

CASE 도구의 분류

Upper CASE

계획수립, 요구분석, 기본설계 단계를 지원하고 이를 다이어그램으로 표현한다.

Middle CASE

상세설계 작업을 지원하며 화면 출력 등의 작성을 지원한다.

Lower CASE

시험, 유지보수 작업을 지원하며 소스코드와 시스템 명세서를 획득한다.

I - CASE

위 세가지를 통합한 것으로 Rational ROSE, COOL 등이 국내에서 사용중이다.

1.소프트웨어 설계

 1.3 애플리케이션 설계

  1.3.3 객체지향 설계

- 객체지향 설계

1. 객체지향(OOP)

1.1 객체지향(Object Orient)

1. 객체지향의 개념

실 세계의 개체를 속성과 메소드가 결합된 형태의 객체로 표현하는 개념으로 구현대상을 하나의 객체로 보고 객체와 객체들 간의 관계를 모델링하는 방법을 의미한다.

2. 객체지향의 등장배경

개발측면에서 소프트웨어 위기 해결을 위한 대안과 생산성 저하에 따른 재사용성, 확장성의 필요에 의해 등장하였다.

사용측면에서 컴퓨팅 환경에 대한 보다 많은 기능, 단순성, 사용편의성 요구가 증대되었다.

1.2 객체지향 프로그래밍(Object Oriented Programming)

1. 객체지향 프로그래밍의 개념

컴퓨터 프로그래밍의 패러다임 중 하나로 컴퓨터 프로그램을 명령어의 목록으로 보는 시각에서 벗어나 여러 개의 독립된 단위, 즉 "객체"들의 모임으로 파악하고자 하는 것이다. 각각의 객체는 메시지를 주고받고, 데이터를 처리할 수 있다.

프로그램을 유연하고 변경이 용이하게 만들기 때문에 대규모 소프트웨어 개발에 많이 사용된다. 또한 프로그래밍을 더 배우기 쉽게하고 소프트웨어 개발과 보수를 간편하게하며 보다 직관적인 분석을 가능하게 하는 장점이 있다.

2. 객체지향의 구성요소

3.객체지향 기법

4.다형성과 상속성 비교

5.다형성의 오버로딩과 오버라이딩

1.3 객체지향 설계원칙

1. 단일 책임의 원칙

객체는 하나의 책임만 맡아야 한다.(낮은 결합도, 높은 응집도 추구)

2. 개방 폐쇄 원칙

소프트웨어 Entity는 확장에는 열려있고 수정 시에는 닫혀있어야 한다.

3. 리스코프 치환의 원칙

하위 클래스 및 타입들은 상위 타입들이 사용되는 곳에 대체될 수 있어야 하는 설계 원칙이다.

4.인터페이스 분리의 원칙

하나의 일반적인 인터페이스보다 구체적인 여러 개의 인터페이스가 낫다.

5.의존성 뒤집기의 원칙

추상화된 것에 의존하게 만들고 구체클래스에 의존하도록 만들지 않도록 한다.

2. 디자인 패턴(Design Pattern)

2.1 디자인 패턴의 개념

디자인 패턴은 반복적으로 나타나는 문제들을 해결해 온 전문다들의 경험을 모아서 정리한 일관된 솔루션으로 설계의 재사용을 통해 생산성 향상을 위한 기법이라 할 수 있다.

소프트웨어 프로그래머들이 유용하다고 생각되는 객체들간의 일반적인 상호작용 방법들을 모은 목록이라 할 수 있다.

디자인 패턴은GoF(Gang of Four)의 븐류가 많이 활용되고 있으며 GoF는 에릭 감마, 리처드 헬름, 랄프 존슨, 존 블리스데스로 알려져 있다.

2.2 디자인 패턴의 구성

1. 패턴이름

설계의 의도를 표현하며 한 두단어로 설계문제와 해법을 서술한다.

2. 문제

해결해야할 문제와 그 배경을 설명하며 언제 패턴을 사용하는 지를 서술한다.

3. 해법

설계의 구성 요소와 그 요소들 간의 관계, 책임, 협력관계를 서술한다.

4. 결과

디자인 패턴을 적용해서 얻는 결과와 장점/단점을 서술한다.

2.3 GoF 디자인 패턴의 분류

1. 패턴이 수행하는 목적에 따른 분류

2. 패턴이 다루는 영역에 따른 분류

2.4 MVC(Model View Controller)패턴

1. MVC패턴의 개념

소프트웨어 공학에서 사용되는 소프트웨어 디자인 패턴으로 사용자 인터페이스로부터 비즈니스 로직을 분리하여 애플리케이션의 시각적 요소나 그 이면에서 실행되는 비즈니스 로직을 서로 영향없이 쉽게 고칠 수 있는 애플리케이션을 만들 수 있다.

MVC에서 모델은 애플리케이션의 정보를 나타내며, 뷰는 텍스트, 체크박스 항목 등과 같은 사용자 인터페이스 요소를 나타내고, 컨트롤러는 데이터와 비즈니스 로직 사이의 상호동작을 관리한다.

2. MVC패턴의 구성

컨트롤러는 모델에 명령을 보냄으로써 모델의 상태를 변경할 수 있다. 또, 컨트롤러가 관련된 뷰에 명령을 보냄으로써 모델의 표시 방법을 바꿀 수 있다.

모델은 모델의 상태에 변화가 있을 때 컨트롤러와 뷰에 이를 통보한다. 이와 같은 통보를 통해서 뷰는 최신의 결과를 보여줄 수 있고, 컨트롤러는 모델의 변화에 따른 적용 가능한 명령을 추가,제거,수정할 수 있다. 어떤 MVC 구현에서는 통보 대신 뷰나 컨트롤러가 직접 모델의 상태를 읽어 오기도 한다.

뷰는 사용자가 볼 결과물을 생성하기 위해 모델로부터 정보를 얻어온다.

오답풀이

객체지향 모형에서 기능 모형의 설계 순서로 가장 옳은것은?

a. 기능의 내용을 상세히 기술

b. 자료흐름도 작성

c. 입출력 결정

d. 제약사항을 결정하고 최소화

정답 : c-b-a-d

객체지향 분석 방법론 중 E-R다이어그램을 사용하여 객체의 행위를 모델링하며, 객체식별, 구조식별, 주제정의, 속성과 인스턴스 정의, 연산과 메시지 연결 정의 등의 과정으로 구성되는것은?

1.Coad와 Yourdon방법 (정답)

2.Booch 방법

3.Jacobson 방법

4.Wifs-Brock 방법

Booch 방법 

미시적 개발 프로세스와 거시적 개발 프로세스 모두 사용하는 분석 방법이다. 클래스와 객체를 분석, 식별하고 클래스의 속성과 연산을 정의한다.

Jacobson 방법

Use Case를 강조하여 사용하는 분석 방법이다. 

Wifs-Brock

분석과 설계의 구분이 없으며 고객 명세서를 평가하여 설계 작업까지 연속적으로 수행하는 기법이다.

1.소프트웨어 설계

 1.3 애플리케이션 설계

  1.3.1 애플리케이션 설계 능력 단위 정의

  1.3.2 공통 모듈 설계

- 애플리케이션 설계 능력 단위 정의

애플리케이션 설계란 요구사항 확인을 통한 상세 분석 결과, 소프트웨어 아키텍처 가이드라인 및 소프트웨어 아키텍처 산출물에 의거하여 이에 따른 애플리케이션 구현을 수행하기 위해 공통모듈 설계, 타 시스템 연동에 대하여 상세 설계하는 능력이다.

-공통 모듈 설계

1. 공통 모듈

1.1 공통 모듈의 개념

날짜 처리를 위한 유틸리티 모듈 등과 같이 전체 프로그램의 기능 중 공통적으로 사용할 수 있는 모듈을 의미한다.

• 정확성 : 실제 시스템 구현 시 필요한 기능인지 여부를 알 수 있도록 정확하게 작성한다.
• 명확성 : 해당 기능에 대한 일관된 이해와 하나로 해석될 수 있도록 작성한다.
• 완전성 : 시스템의 구현 시 요구사항과 필요한 모든 것을 기술한다.
• 일관성 : 공통 기능 사이에 충돌이 발생하지 않도록 작성한다.
• 추적성 : 해당 기능에 대한 요구사항의 출처와 관련 시스템 등 유기적 관계에 대한 식별이 가능하도록 작성한다.

1.2 모듈화 개념

소프트웨어의 성능을 향상시키거나 시스템의 수정 및 재사용 유지 관리를 용이하게 하여 프로그램을 효율적으로 관리할 수 있도록 시스템을 분해하고 추상화하는 기법을 의미한다.

모듈의 크기가 과도하게 작은 경우 모듈의 개수가 많아져 모듈 간의 통합 비용이 과다 발생하고, 모듈의 크기가 과도하게 크면 모듈 간의 통합 비용이 상대적으로 감소하는 대신 하나의 모듈을 개발하는데 소용되는 비용이 커진다.

1. 응집도

응집도는 모듈 내부의 구성 요소간 관계의 밀접 정도로 평가되며, 응집도가 높을수록 필요한 요소들로 구성되어 지고 낮을수록 요소들 간의 관련성이 적은 요소들로 구성되어진다.

품질측면에서 가장 높은 품질은 기능적 응집이며, 가장 낮은 품질은 우연적 응집도 이다.

• 기능적 응집도 : 모듈 내부의 모든 기능이 단일한 목적을 위해 수행되는 경우이다.
• 순차적 응집도 : 모듈 내에서 한 활동으로부터 나온 출력값을 다른 활동이 사용할 경우이다.
• 통신적 응집도 : 동일한 입력과 출력을 사용하여 다른 기능을 수행하는 활동들이 모여 있을 경우이다.
• 절차적 응집도 : 모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성 요소들이 그 기능을 순차적으로 수행할 경우이다.
• 시간적 응집도 : 연관된 기능이라기보다는 특정 시간에 처리되어야 하는 활동들을 한 모듈에서 처리할 경우이다.
• 논리적 응집도 : 유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들이 한 모듈에서 처리되는 경우이다.
• 우연적 응집도 : 모듈 내부의 각 구성 요소들이 연관이 없을 경우이다.

2. 결합도

결합도는 모듈과 모듈 사이의 관련성이 어느 정도인가를 나타내며, 관련성이 적을수록 모듈의 독립성이 높아 모듈간 영향이 작아지게 된다.

품질 측면에서 가장 높은 품질은 자료 결합이며, 내용 결합이 가장 낮다.

• 자료 결합도 : 모듈 간의 인터페이스로 전달되는 파라미터를 통해서만 모듈 간의 상호 작용이 일어나는 경우이다.
• 스탬프 결합도 : 모듈 간의 인터페이스로 배열이나 오브젝트, 스트럭처 등이 전달되는 경우이다.
• 제어 결합도 : 단순 처리할 대상인 값만 전달되는 게 아니라 어떻게 처리를 해야한다는 제어 요소가 전달되는 경우이다.
• 외부 결합도 : 모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성 요소들이 그 기능을 순차적으로 수행할 경우이다.
• 공통 결합도 : 파라미터가 아닌 모듈 밖에 선언되어 있는 전역변수를 참조하고 전역 변수를 갱신하는 식으로 상호 작용하는 경우이다.
• 내용 결합도 : 다른 모듈 내부에 있는 변수나 기능을 다른 모듈에서 사용하는 경우이다.

2. 설계 모델링

2.1 소프트웨어 설계와 모델링의 개념

소프트웨어 설계는 요구사항 분석 단계에서 규명된 필수 기능들의 구체적인 구현 방법을 명시하는 단계로 장치, 프로세스, 시스템을 명확하고 상세하게 정의하며 실현가능 하도록 관련 변형된 기술과 원칙을 적용하는 과정을 말한다.

설계 모델링은 소프트웨어에 요구되는 기능과 성능 조건들을 만족하는 소프트웨어의 내부 기능외에 구조 및 동적 행위들을 모델링하여 표현, 분석하는 과정이다.

2.2 구조와 행위 모델링

1. 구조 모델링

소프트웨어를 구성하는 컴포넌트들의 유형, 인터페이스, 내부 설계 구조 및 이들의 상호 연결구조를 모델링한다.

2. 행위 모델링

소프트웨어의 구성요소들이 기능들과 이들이 언제, 어떠한 순서로 기능을 수행하고 상호작용하는지를 모델링한다.

2.3 설계 모델의 구성과 요소

1. 설계 모델의 구성

2. 설계 모듈의 동적요소와 정적요소

3. 소프트웨어 아키텍처

3.1 소프트웨어 아키텍처 개념

소프트웨어 아키텍처는 소프트웨어 시스템의 구조를 비롯한 시스템 개발에 중요한 영향을 미치는 결정들로, 소프트웨어 시스템 개발에서 특정 시스템에 대하여 요구되는 기능과 품질을 확보하고 또한 소프트웨어 시스템의 구축 및 지속적인 개선이 용이하도록 하는 역할을 한다.

1. 소프트웨어 아키텍처의 역할

요구사항 분석 활동에 의해 도출된 요구사항을 모두 충족시킬 수 있는 시스템이 만들어 질 수 있도록 하기 위한 설계 활동으로서 설계 및 구현을 위한 구조적/ 비구조적 틀을 제공한다.

틀이란 아키텍처 설계의 결과물로서 실행을 요구하는 결정 또는 모델을 의미한다. 구조적틀은 시스템 개발을 위해 결정된 컴포넌트의 구조모델을 말하고, 비구조적 틀은 이 구조모델 이외의 다른 아키텍처설계의 결정들을 말한다.

2. 아키텍처 설계의 입력과 출력

시스템 개발은 모든 요구사항을 달성대상으로 하지만 아키텍처 설계는 아키텍처에 관련된 대표적인 요구사항들로만 주된 관심의 대상이 된다. 이와 같은 특별한 요구사항들을 아키텍처 드라이브라고 한다.

설계의 결과는 아키텍처를 문서화한 아키텍처 문서가 주된 출력물이 되고 이에 대한 추가적인 관련사항을 정리한 아키텍처 가이드 라인이 이차적인 출력물이 된다.

테스크는 한 명의 수행자가 수행하는 일을 지칭하며, 소프트웨어 설계 모델링 언어인Uml의 활동 다이어그램은 더 이상 분해하지 않는 일의 단위를 테스크라고 부르고 다른 태스크 혹은 활동으로 구성된 일의 단위를 활동이라고 부르고 있다.

3.2 아키텍처 설계 절차와 적용 원리

1. 아키텍처 드라이버

시스템의 요구사항 중 아키텍처에 영향을 주는 요구사항을 아키텍처 드라이버라하며, 아키텍처 설계에 더 집중할 수 있기 위해 아키텍처 드라이버를 먼저 잘 식별해낸 후 아키텍처 설계에 효과적으로 반영해야 한다.

2. 품질속성, 검증가능성, 품질속성 시나리오

아키텍처 드라이버들을 먼저 검증할 수 있는 형태로 바꾸어 놓은 것으로, 특히 품질속성으로 불리는 요구사항들은 아키텍처에 영향을 미치면서 고객의 도움 없이는 개발자 단독으로 검증 가능한 형태로 바꾸기 어려운 유형의 요구사항들이다.

3. 문제분석

요구사항들이 어떠한 문제의 해결을 요청하는 것인지 분석한다.

4. 컴포넌트와 커넥터

컴포넌트는 처리, 저장, 전달을 수행하는 소프트웨어 시스템의 구성 요소이며 커넥터는 컴포넌트를 연결하는 연결자를 말한다.

5. 아키텍처 스타일

아키텍처 스타일은 아키텍처의 유형을 말한다. 적절한 아키텍처 스타일의 선택은 대상시스템의 개발을 효율적이고 효과적으로 만들 수 있다.

6. 소프트웨어 아키텍처를 보는 관점관계

 아키텍처 스타일에 따라 적합한 관점체계가 서로 다를 수 있다.

J2EE 기반의 응용, BPMS 기반의 SOA 응용, 내장소프트웨어, Web 응용 등의 아키텍처 스타일에 적절한 관점체계가 모두 동일 하지는 않다.

7. 설계의 일반원리

소프트웨어 아키텍처에 적용되는 보편적인 원칙이다.

8. 아키텍처 설계 절차

아키텍처를 결정하는 요구사항들로 부터 먼저 어떤 아키텍처적인 설계의 선택들이 있는가를 판단한다.

9. 아키텍처 패턴

반복적으로 발생하는 문제에 대해 미리 만들어진 솔루션이다.

10. 품질속성 설계전술

단일 품질속성 응답을 제어하는데 영향력 있는 설계의 결정이다.

11. 아키텍처의 분석

주어진 아키텍처가 적절한지 판단하기 위한 분석이다.

12. 아키텍처의 평가

평가는 완결된 설계를 대안과 비교함으로써 그 결과에 따라 설계라는 큰 과정을 다시 수행할 것을 요구할 수도 있는 활동이다.

3.3 소프트웨어 아키텍처 프래임워크(ISO/IEC/IEEE 42010)

JEEE 1471는 소프트웨어 구조에 대한 기술을 규정한 IEEE 표준이다.

IEEE 42010는 시스템 및 SW 엔지니어링 아키텍처 기술 과 관련된 용어와 개념을 정의한 국제 표준이다.

3.4 SW 아키텍처 4+1 View의 개요

시스템의 여러가지 측면을 고려하기 위한 다양한 관점을 바탕으로 정의되며 UML의 4+1 View가 표준이다.

고객 요구사항을 중심으로 4가지 관점으로 소프트웨어 아키텍처를 설계하는 기법이다.

오답풀이

다음 중 설계모델링에 대한 설명으로 옳지 않은 것은?

1. 구조 모델링은 소프트웨어를 구성하는 컴포넌트들의 유형, 인터페이스, 내부 설계 구조 및 이들의 상호 연결 구조를 모델링한다.

2. 행위 모델링은 소프트웨어의 구성요소들의 기능들과 이들이 언제, 어떠한 순서로 기능을 수행하고 상호작용하는지를 모델링한다.

3. 인터페이스, 데이터 구조, 알고리즘 구조 모델 중 시스템 구조에 해당한다.(정답)

4. 설계모델링은 소프트웨어에 요구되는 기능과 성능 조건들을 만족하는 소프트웨어의 내부 기능외에 구조 및 동적 행위들을 모델링하여 표현, 분석, 검증하는 과정이다.

인터페이스, 데이터 구조, 알고리즘 구조는 구조 모델중 컴포넌트 구조에 해당한다. 구조 모델중 시스템 구조는 구성요소, 컴포넌트 연결 구조 등이 해당된다.

다음 중 소프트웨어 설계모델의 분류와 구성요소가 옳지 않은 것은?

1. 구조모델-시스템구조-구성요소, 컴포넌트 연결구성

2. 구조모델-컴포넌트구조-인터페이스, 데이터구조, 알고리즘

3. 행위모델-시스템행위-구성요소들의 배열, 결합관계, 인터페이스(정답)

4. 행위모델-컴포넌트행위-계산, 실행제어, 상호작용

행위모델-시스템행위-시스템기능, 컴포넌트 제어

1.소프트웨어 설계

 1.2 화면 설계

  2.1.3 UI 설계

- UI 설계

1. 흐름 및 상세설계

1.1 UI설계 단계

1. 문제 정의

시스템의 목적을 기술하고 해결해야할 문제를 정의한다.

2. 사용자 모델 정의

사용자의 특성을 명확히 하지 않고는 시스템의 사용성을 확보할 수 없으므로 사용자의 특성을 결정한다.

사용자의 컴퓨터 소프트웨어와 작업에 대한 지식 정도에 따라 초보자, 중급자, 숙련자로 분류 할 수 있다.

3. 작업 분석

작업분석은 항상 해결해야 할 문제를 정제하고 사용자의 특징들을 세분화하고 시스템을 통해 수행되어야 할 작업들을 정의한다.

4. 컴퓨터 오브젝트 및 기능 정의

분석한 작업을 컴퓨터의 어떤 사용자 인터페이스를 통해 표현할 것인지를 정의한다.실제로 사용자는 시스템을 이용해 작업할 경우 컴퓨터 오브젝트를 통해 수행한다.

5. 사용자 인터페이스 정의

컴퓨터나 작업 수행 방법에 대하여 상호작용하는 오브젝트를 선택하고 시스템의 상태를 명확히 한다.

상호작용 오브젝트란 작업을 하기 위한 마우스나 키보드 스크린 등의 물리적인 입력이나 출력 디바이스를 말한다.

6, 디자인 평가

설계한 인터페이스가 분석한 작업에 맞게 설계가 되었는지, 사용자의 능력이나 지식에 대해 적당한지, 사용자가 쓰기 쉽고 편리한지 등을 평가한다.

사용성 평가 실험을 통해 설계한 인터페이스에 대한 사용성 평가를 할 수 있다. 평가방법론은 GOMS 나 휴리스틱 등의 사용성 공학의 방법론이 있다.

1.2 흐름설계

1. 화면에 구현되어야할 기능을 정의한다.

기능적 요구사항에 대한 설명을 정리한다.

• 입출력 데이터
• 정보의 등록, 수정, 삭제 등 기능
• 이벤트에 따른 수행 기능 

비기능적 요구사항에 대한 설명을 정리한다.

• 플랫폼 및 적용 기술 등 시스템환경적 요구 기능
• 처리속도 등 시스템 성능
• 시스템 제약사항 

2. 화면의 입력 요소를 파악한다.

• 화면에서 수행되어야할 기능
• 화면의 입력항목
• 화면간 이동과 흐름

3. UI 요구사항에 대한 유스케이스를 설계한다.

• 엑터별 시나리오 구상
• 엑터의 상호작용에 따른 세분화

4. 기능 및 양식의 규칙을 정의한다.

• Input Box 적용 규칙 정의
• Control Box 적용 규칙 정의
• Rado Box 적용 규칙 정의
• Check Box 적용 규칙 정의

2. 감성공학

2.1 감성공학의 개념

인체의 특징과 삼정을 제품설계에 최대한 반영시키는 기술로, 인간이 가지고 있는 소망으로서의 이미지나 감성을 구체적인 제품설계로 실현해내는 공학적인 접근방법이다.

기본 철학은 인간중심의 설계이며 1988년 시드니 국제 학회에서 감성공학으로 명명되었다. 궁극적으로 감성공학은 인간의 감성을 과학적으로 해석할 후 이에 적합한 제품, 환경 시스템 설계, 개발을 최종 목적으로 하는 과학이다.

2.2 감성공학 관련 기술

감성공학기술에는 크게 생체측정 인간감성 특성파악기술, 감성디자인 기술, 오감센서 및 감성처리기술, 마이크로 기구 설계, 동력전달기술, 마이크로 가공기술 등이 있으며 내용을 다음과 같다.

1. 인간공학 인지공학 등 인간의 특성을 파악하려는 연구에 기본을 둔 생체 측정 기술

2. 인간 특성에 적합하도록 사용자 인터페이스를 실현하기 위한 기술로서 센서 공학 퍼지뉴럴 네트워크 기술 신경망 기술 등 인간의 오감 센서 및 감성처리 기술

3. 산업 디자인 등의 감성 디자인 기술

4. 마이크로 기구 설계 극소기계 응용 등 마이크로 가공 기술

5. 사용성 평가 기술 가성현실 기술 등으로서 인간에 대한 적합성을 판단하고 새로운 감성을 창출하기 위한 기술

2.3 감성공학의 접근 방법(나가마치 미츠오 교수, 히로시마대학)

감성공학은 각각의 세부분야가 가진 목적 및 필요 기술에 따라 1류에서 3류까지 나뉜다.

1. 감성공학 1류

인간의 감성을 형용사로 표현할 수 있다고 보고 인간의 감성 이미지를 측정하는 방법이다. 이를 통해 제품에 대한 이미지를 조사 분석하여 제품의 디자인 요소와 연계시킨다.

2. 감성공학 2류

개인의 연령 성별 등의 개별적 특성과 생활 방식으로부터 개인이 갖고 있는 이미지를 구체화하는 방법이다. 감성의 심리적 특성을 강조한 접근 방법이라 할 수 있다. 또한 감성의 개인성에 중점을 둔 '문화적 감성'의 일부를 반영하기도 한다.

3. 감성공학 3류

기존의 감성적 어휘 대신 공학적인 방법으로 접근하여 인가의 감각을 측정하고, 이를 바탕으로 수학적 모델을 구축하여 활용한다. 대상이 되는 제품의 물리적 특성과 인간의 감각이 객관화된 지표 사이의 연관성을 분석하여 제품 설계에 응용 할 수 있으며, 측정 시 감성의 생리적 특성을 중시한다.

3. UI 설계 도구

3.1 UI 설계도구의 개념

사람과 사물 또는 시스템, 특히 , 기계, 컴퓨터 프로그램 등 사이에서 의사소통을 할 수 있도록 일시적 또는 영구적인 접근을 목적으로 만들어진 물리적, 가상적 매개체인 UI의 설계를 지원하는 도구를 의미한다.

3.2 UI 개발 프로세스와 설계도구 적용

일반적인 UI개발 프로세스는 분석, 설계, 구현의 절차를 거쳐 요구사항에 부합하는 화면의 구현이 이루어진다.

UI 설계 도구는 분석과 설계를 지원하며, 구현을 지원하는 개발 도구의 기능을 포함하기도 한다.

3.3 UI 설계 도구의 유형

UI 설계 도구의 유형은 UI 구현 절차에 따라 기획단계에서 화면 UI 설계 및 인터랙션 적용에 적합한 도우와 설계 작업 이후 이미 설계된 이미지의 인터랙션 적용에 적합한 도구로 나눌 수 있다.

또한 문서 작성 도구 및 드로잉 전문 도구, 화면 설계 전문 도구, UI 설계 및 개발 전문 도구, UI 플랫폼에 포함되어 UI설계를 지원하는 도구로 구분할 수 있다.

1. 문서 작성 도구 및 드로잉 전문 도구

일반 문서 작성 도구나 웹사이트, 윈도우 컴포넌트, 블럭 다이어그램 등 다양한 스텐실을 제공하는 드로잉 도구이다.

2. 화면 설계를 위한 전문 도구

다양한 프로잉을 지원하기 보다는 화면 스케치를 위한 단순하고 전문화된 기능을 제공하는 도구이다.

3. UI설계 및 개발 전문 도구

UI패턴과 UI모델링, UI디자인 및 소스코드 생성 등 생산성 향상과 화면의 품질 확보를 위한 전문 도구이다.

4. 해당 UI 플랫폼에 포함된 도구

해당 UI플랫폼에서 프로토타이핑을 하고 이를 이용하여 설계에 관한 협의를 할 수 있을 뿐 아니라 바로 코딩이 가능한 도구이다.

오답풀이

6.다음 중 감성공학에 대한 설명으로 옳지 않은 것은?

1.인간이 가지고 있는 소망으로서의 이미지나 감성을 구체적인 제품설계로 실현해내는 공학적인 접근방법이다.

2.감성공학 1류는 개인의 연령, 성별 등의 개별적 특성과 생활 방식으로부터 개인이 가지고 있는 이미지를 구체화 하는 방법이다.(정답)

3.감성공학기술에는 크게 생체측정 인간감성 특성파악기술, 감성디자인 기술, 오감센서 및 감성처리기술, 마이크로 기구 설계, 동력전달기술 등이 있다.

4.나가마치 미츠오 교수의 감성공학의 접근 방법은 감성공학 1류, 감성공학 2류, 감성공학 3류 등으로 나눈다.

4가지 전부 맞는것 같았지만 2번은 감성공학 2류에 대한 설명이었다....

감성공학 1류는 인간의 감성을 형용사로 표현할 수 있다고 보고 인간의 감성 이미지를 측정하는 방법이다.!!!!