[정보처리기사] 1장 소프트웨어 설계 3, 4

3장 애플리케이션 설계

20. 소프트웨어 아키텍처

소프트웨어의 골격이 되는 기본 구조, 소프트웨어를 구성하는 요소들 간의 관계를 표현하는 시스템의 구조 또는 구조체. 모듈화, 추상화, 단계적 분해, 정보은닉 등이 있다.

모듈화 : 시스템의 기능들을 모듈 단위로 나누는 것. 너무 작게 나누면 통합 비용이 많이 들고 너무 크게 나누면 개발 비용이 많이든다.

추상화 : 전체적이고 포괄적인 개념을 설계한 후 세분화하여 구체화하는 것. 불필요한 부분을 생략하고 필요한 부분을 강조하여 모델화 하는 것.

           과정 추상화 : 수행 과정을 정의하지 않고, 흐름만 파악할 수 있게 설계

           데이터 추상화 : 데이터의 세부적 속성이나 용도를 정의하지 않고,

           제어 추상화 : 정확한 절차나 방법을 정의하지 않고,

단계적 분해(Stepwise Refinement) : 상위의 중요 개념부터 하위의 개념으로 구체화시키는 분할 기법. 추상화의 반복으로 세분화

정보 은닉 : 한 모듈 내부에 포함된 절차와 자료들의 정보가 감춰져, 다른 모듈이 접근, 변경하지 못하게 하는.

 

소프트웨어 아키텍처의 품질 속성 : 품질 평가 요소들을 구분해서 구체화 시켜놓은 것

시스템 측면 : 성능, 보안, 가용성, 기능성, 사용성, 변경 용이성, 확장성

비즈니스 측면 : 시장 적시성, 비용과 혜택, 예상 시스템 수명

아키텍처 측면 : 개념적 무결성, 정확성, 완결성, 구축 가능성

 

21. 아키텍처 패턴

아키텍처를 설계할 떄 참조할 수 있는 전형적인 해결 방식. 안정적인 개발이 가능하고 의사소통이 간편해진다. 개발에 참여하지 않는 사람도 손쉽게 유지보수 가능. 개발 전에 시스템의 특성을 예측 가능해진다.

레이어 패턴 : 계층으로 구분하여 구성. 상위 계층이 하위 계층의 제공자가 되고, 하위 계층은 클라이언트가 된다.

   서로 마주보는 계층에만 영향을 끼쳐 변경 작업이 용이하다. ex) OSI 모델

클라이언트-서버 패턴 : 하나의 서버 컴포넌트와 다수의 클라이언트 컴포넌트로 구성되는 패턴. 서버는 항상 대기 상태를 유지해야 한다.

파이프-필터 패턴 : 데이터 스트림 절차의 각 단계를 필터 컴포넌트로 캡슐화하여 파이프를 통해 데이터를 전송

   재사용성이 좋고 확장이 용이. 다양한 파이프라인 구축이 가능하다. ex) UNIX의 쉘(shell)

모델-뷰-컨트롤러 패턴(MVC) : 서브시스템을 3개의 부분으로 구조화하는 패턴

   모델 : 서브시스템의 핵심 기능, 데이터 보관

   뷰 : 사용자에게 정보 표시

   컨트롤러 : 사용자에게 받은 입력을 처리한다.

   여러 개의 뷰를 만들 수 있으므로 대화형 애플리케이션에 적합하다.

마스터-슬레이브 패턴 : 마스터 컴포넌트에서 슬레이브 컴포넌트로 작업을 분할한 후, 슬레이브 컴포넌트에서 처리된 결과물을 다시 돌려받는 방식으로 작업 수행

브로커 패턴 : 원하는 서비스를 브로커 컴포넌트에게 요청하면 알맞은 컴포넌트와 사용자를 연결해준다.

피어-투-피어 패턴 : 각 피어가 클라이언트가 될 수도, 서버가 될 수도 있는 패턴. 멀티스레딩 방식을 사용

이벤트-버스 패턴 : 소스가 특정 채널에 이벤트 메시지를 발행하면, 해당 채널을 구독하는 리스너들이 받아서 이벤트를 처리하는 방식.

블랙보드 패턴 : 모든 컴포넌트들이 공유 데이터 저장소와 블랙보드 컴포넌트에 접근이 가능.

 

22. 객체지향

현실 세계의 개체를 하나의 객체로 만들어 조립해서 작성하는 기법. 구조적 기법의 문제점으로 인한 해결책. 재사용 및 확장이 용이하다.

데이터 : 객체가 갖고 있는 정보이다. 속성, 상태, 변수 등으로 불린다.

함수 : 객체가 수행하는 기능

클래스 : 공통된 속성과 연산을 갖는 객체의 집합.

캡슐화 : 데이터와 함수를 하나로 묶는 것

상속 : 상위 클래스의 모든 속성과 연산을 하위 클래스가 물려받는 것이다.

다형성 : 하나의 메시지에 대해 각각의 객체가 가지고있는 고유한 방법으로 응답하는 능력.

 

23.모듈

모듈화를 통해 분리된 시스템의 각 기능들.

모듈의 독립성은 결합도와 응집도로 측정되며, 결합도를 약하게, 응집도를 강하게 모듈의 크기는 작게 만들어야 한다.

 

결합도(Coupling) : 두 모듈 사이의 연관 관계.

자료 결합도 - 스탬프 결합도 - 제어 결합도 - 외부 결합도 - 공통 결합도 - 내용 결합도 (내공외제스자)

Data Coupling - Stamp Coupling - Control Coupling - External Coupling - Common Coupling - Content Coupling

자료 결합도 : 다른 모듈을 호출하면서 매개변수나 인수로 데이터를 넘겨주고 다시 돌려받는 방식. 가장 바람직

스탬프 결합도 : 배열이나 레코드 등의 자료구조가 전달될 때의 결합도

제어 결합도 : 다른 모듈 내부의 논리적 흐름을 제어하기 위해 제어신호를 이용

외부 결합도 : 어떤 모듈에서 선언한 변수를 외부의 다른 모듈에서 참조.

공통(공유) 결합도 : 공통 데이터 영역을 여러 모듈이 사용.

내용 결합도 : 다른 모듈의 내부 기능 및 자료를 직접 참조, 수정

 

응집도(Cohesion) : 정보 은닉 개념의 확장, 모듈의 내부 요소들이 서로 연관된 정도.

기능적 - 순차적 - 교환적 - 절차적 - 시간적 - 논리적 - 우연적 응집도 (우논시절 통순기)

Functional - Sequential - Communication - Procedural - Temporal - Logical - Coincidental Cohesion

기능적 응집도 : 모듈 내부의 모든 기능이 단일 문제와 연관된 경우. 가장 바람직하다

순차적 응집도 : 모듈 내 하나의 활동으로 나온 출력 데이터를 다음 활동의 입력데이터로 사용

교환적 응집도 : 동일한 입력과 출력을 사용해 서로 다른 기능을 수행하는 요소들이 모인 경우

절차적 응집도 : 모듈이 다수의 관련 기능을 가질 때 모듈안의 구성 요소들이 그 기능을 순차적으로 수행.

시간적 응집도 : 특정 시간에 처리되는 기능이 모인 경우

논리적 응집도 : 유사한 성격을 갖거나 특정 형태로 분류되는 요소들이 모인 경우

우연적 응집도 : 각 구성 요서가 서로 연관 없는 경우

 

팬인/팬아웃

팬인 : 어떤 모듈을 제어하는 모듈의 수. 높은 경우 단일 장애점이 발생할 수 있으니 주의.

팬아웃 : 어떤 모듈에 의해 제어되는 모듈의 수. 불필요하게 다른 모듈을 호출하는지 검토.

팬인은 높게 팬아웃은 낮게 설계해야 한다.

 

24. 공통 모듈

여러 프로그램에서 사용할 수 있는 모듈

재사용 : 비용과 개발 시간 절약을 위해 이미 개발된 긴으들을 파악해서 최적화 시키는 작업.

 

25. 코드

자료를 처리하는 과정에서 분류, 주합 및 집계르 용히하게 하고, 추출을 쉽게 하는 기호

   식별 기능, 분류 기능, 배열 기능이 있다.

 

순차 코드 : 발생 순서, 크기 순서 등 일정 기준에 따라서 일련 번호를 부여. 1,2,3,4, …

블록 코드 : 공통성이 있는 것끼리 블록으로 구분. 1001~1100 : 총무부, 1101~1200 : 입법부 등

10진 코드 : 0~9까지 10진 분할하고 다시 10진 분할을 반복하는 법. 도서 분류식 코드

그룹 분류 코드 : 기준에 따라 대, 중, 소분류 등으로 구분. 1-01-100 : 본사 - 총무부 - 인사계

연상 코드 : 명칭이나 약호와 관계있는 기호. TV-40 : 40인치 TV

표의 숫자 코드 : 길이, 넓이, 부피 등의 물리적 수치를 적용시키는 방법. 120-720 : 120x720 크기의 강판

합성 코드 : 2개 이상의 코드를 조합

 

26. 디자인 패턴

세부적인 구현 방안을 설계할 떄 참조할 수 있는 전형적인 해결방식.

GoF의 디자인 패턴은 생성 패턴 5개, 구조 패턴 7개, 행위 패턴 11개로 구성된다.

 

생성 패턴(Creational Pattern) : 객체의 생성과 관련된 패턴

           추상 팩토리 : 클래스에 의존하지 않고, 인터페이스를 통해 서로 연관, 의존하는 객체들의 그룹으로 생성.

           빌더 : 인스턴스를 건축하듯이 조합하여 객체를 생성한다.

           팩토리 메소드 : 객체 생성을 서브 클래스에서 처리하도록 분리, 캡슐화한 패턴.

           프로토타입 : 원본 객체를 복제하는 방법으로 객체 생성

           싱글톤 : 하나의 객체를 생성하면 어디서든 참조 가능하지만 동시에 참조는 불가능하다.

 

구조 패턴(Structural Pattern) : 객체들을 조합하여 더 큰 구조로 만들게 해주는 패턴

           어댑터 : 호환성이 없는 클래스들의 인터페이스를 다른 클래스가 이용 가능하게 변환해준다.

           브리지 : 구현부에서 추상층을 분리하여 서로 독립적으로 확장이 가능

           컴포지트 : 여러 객체를 가진 복합 객체와 단일 객체를 구분없이 다루는 패턴.(폴더와 파일을 합성)

           데코레이터 : 객체의 결합을 통해 능동적으로 기능을 확장

퍼싸드(Façade) : 복잡한 서브 클래스들을 피해 더 상위에 인터페이스를 구성해, 서브 클래스들의 기능을 사용하는 패턴. 서브 클래스들 사이에 Wrapper 객체가 필요하다.

플라이웨이트(Flyweight) : 인스턴스를 매번 생성하지 않고 가능한 공유해서 사용함으로써 메모리를 절약

하는 패턴

프록시(Froxy) : 접근이 어려운 객체와 연결하려는 객체 사이에서 인터페이스 역할을 수행. 네트워크 연결, 메모리의 대용량 객체로의 접근에 주로 사용한다.

 

행위 패턴(Behavioral Pattern)

책임 연쇄 : 한 객체가 요청을 처리하지 못하면 다른 객체로 넘어가는 패턴

커맨드 : 요청을 객체의 형태로 캡슐화하여 재이용하거나 취소할 수 있도록 요청에 필요한 정보를 저장하거나 로그에 남기는 패턴

인터프리터 : 언어에 문법표현을 정의하는 패턴

반복자(Iterator) : 자료구조와 같이 접근이 잦은 객체에 순차적인 접근이 가능하게 함

중재자 : 수 많은 객체들 간의 복잡한 상호작용을 캡슐화 하여 객체로 정의

메멘토 : 객체 내부 상태를 객체화해서 객체를 해당 시점의 상태로 돌릴 수 있는 긴으

옵저버 : 객체의 상태가 변화하면 다른 객체들에게 상태를 전달하는 패턴

상태 : 객체의 상태에 따라 동작을 다르게 할 때 사용

전략 : 동일한 계열의 알고리즘들을 개별적으로 캡슐화하여 상호 교환할 수 있게 정의

템플릿 메소드 : 상위 클래스에서 골격을 정의하고, 하위 클래스에서 구체화하는 구조

방문자 : 클래스의 데이터 구조에서 처리 기능을 분리하여 별도의 클래스로 구성

 

4장 인터페이스 설계

27. 시스템 인터페이스 요구사항 분석

시스템 인터페이스는 독립적으로 떨어져 있는 시스템들끼리 서로 연동하여 상호작용하기 위한 접속 방법, 규칙

시스템 인터페이스 명세서는 인터페이스 이름, 연계 대상 시스템, 연계 범위 및 내용, 연계 방식, 송신 데이터, 인터페이스 주기 등이 있다.

시스템 인터페이스 요구사항 분석 절차

           요구사항을 선별하여 요구사항 목록 생성

           요구사항과 관련된 자료를 준비

           기능적/비기능적인 요구사항으로 분류

           요구사항을 분석하고 내용 추가, 수정

           요구사항 명세서와 목록 완성

 

28. 인터페이스 요구사항 검증

요구사항 검토 계획 수립 -> 검토 및 오류 수정 -> 베이스라인 설정

 

요구사항 검증 방법

           요구사항 검토

                       동료 검토 : 요구사항 명세서 작성자가 직접 설명하고 동료들이 결함을 발견

                       워크스루 : 회의 전에 명세서를 미리 배포해서 짧은 검토회의를 통해 결함 발견

                       인스펙션 : 작성자가 아닌 다른 전문가들이 명세서를 확인하면서 결함 발견

           프로토타이핑 : 견본품을 만들어 결과물 예측

           테스트 설계 : 테스트 케이스를 생성하여 검토

           CASE(Computer Aided SW Engineering) 도구 활용

 

30. 송수신 데이터 식별

식별 대상 데이터는 송, 수신 시스템 사이에서 교환되는 데이터다. 데이터의 종류는 인터페이스 표준 항목, 송,수신 데이터 항목, 공통 코드가 있다.

인터페이스 표준 항목 : 송수신 시스템의 연계에 표준적으로 필요한 데이터

           시스템 공통부 : 시스템 간 연동시 필요한 공통 정보

           거래 공통부 : 시스템이 연동된 후 송,수신 데이터를 처리할 떄 필요한 정보

송수신 데이터 항목 : 송 수신 시스템이 업무를 수행하는데 사용하는 데이터

공통 코드 : 시스템들에서 공통적으로 사용하는 코드

 

31. 인터페이스 방법 명세화

내,외부 시스템이 연계하여 작동할 때 송수신 방법, 송수신 데이터, 오류식별 및 처리방안에 대한 내용을 문서로 정리하는 것

명세화를 위해 필요한 것은 시스템 연계기술, 인터페이스 통신유형, 처리유형, 발생 주기 등이다.

시스템 연계 기술 : 개발할 시스템과 내,외부 시스템을 연계할 떄 사용되는 기술

DB Link, API/Opne API, 연계 솔루션, Socket, Web Service 등이 있다.

인터페이스 통신 유형

           단방향 : 시스템에서 거래를 요청만 하고 응답이 없는 방식

           동기 : 거래를 요청하고 응답이 올 때까지 대기하는 방식

           비동기 : 거래를 요청하그 다른 작업을 수행하다 응답이 오면 처리하는 방식

인터페이스 처리유형

           실시간 방식 : 사용자의 요청을 바로 처리

           지연 처리 방식 : 데이터를 매건 단위로 처리할 경우 비용이 많이 발생할 떄 사용

           배치 방식 : 대량의 데이터를 처리할 때 사용

 

32. 시스템 인터페이스 설계서 작성

시스템 인터페이스 설계서는 시스템 인터페이스 목록과, 시스템 인터페이스 정의서로 구성된다.

 

33. 미들웨어 솔루션 명세

미들웨어 : 운영체제와 응용 프로그램 사이에서 운영체제가 제공하는 서비스 이외에 추가적인 서비스를 제공하는 소프트 웨어. DB, RPC, MOM, TP-Monitor, ORB, WAS 등으로 구분한다.

DB : 원격의 데이터베이스와 연결하기 위한 미들웨어. ODBC, IDAPI, Glue 등

RPC(Remote Procedure Call) : 원격 프로시저를 로컬 프로시져처럼 호출하는 방식의 미들웨어

MOM(Message Oriented Middleware) : 비동기형 메시지를 전달하는 방식. MQ, Q, JMS 등

TP-Monitor(Transaction Processing Monitor) :트랜잭션을 처리 및 감시하는 미들웨어. tuxedo, tmax 등

ORB(Object Request Broker) 객체 지향 미들웨어. Orbix, CORBA 등

WAS(Web Application Server) : 웹에서 동적인 컨텐츠를 처리하는 미들웨어. WebLogic, WebSphere 등