정처기 필기 요약 - 애플리케이션 설계

소프트웨어 설계의 종류

- 상위 설계(High-Level-Design)

아키텍처 & 인터페이스 위주

아키텍처 설계, 예비 설계라고 한다

시스템 수준에서의 소프트웨어 구성 컴포넌트들 간의 관계를 구성된 시스템의 전체적인 구조

시스템 구조도

외부 파일 및 DB설계도

화면 및 출력물 레이아웃

 

- 하위 설계(Low-Level-Design)

모듈 설계, 상세 설계라고 한다.

시스템의 각 구성 요소들의 내구 구조, 동적 행위 등을 결정한다.

각 구성 요소의 제어와 데이터들 간의 연결에 대한 구체적인 정의를 하는 것이다.

절차기반(Procedure-Oriented), 자료위주(Data-Oriented), 객체지향(Object-Oriented)설계 방법이 있다

 

 

소프트웨어 아키텍처

소프트웨어의 골격이 되는 기본 구조

소프트웨어를 구성하는 요소 간의 관계를 표현하는 시스템의 구조 또는 구조체

좋은 품질을 주지하면서 사용자의 비기능적 요구사항으로 나타난 제약을 반영하고, 기능적 요구사항을 구현하는 방법을 찾는 해결 과정

애플리케이션의 분할 방법과 분할된 모듈에 할당된 기능, 모듈 간의 인터페이스 등을 결정

원칙, 지침, 소통 도구

 

<모듈화>

소프트웨어의 성능을 향상하거나 시스템의 수정 및 재사용, 유지 관리 등이 용이하도록 시스템의 기능들을 모듈 단위로 나누는 것

너무 작게 나누면 통합 비용이 올라가고 너무 작게 나누면 통합비용을 적게 들지만, 모듈 1개를 개발하는 비용은 많이 들게 된다

 

<추상화 Abstraction>

문제의 전체를 설계 후 세분화하여 구체화하는 과정

완전한 시스템을 구축하기 전에 그 시스템과 유사함 모델을 만들어 여러 가지 요인들을 테스트할 수 있음

최소 비용으로 실제 상황에 대처할 수 있고 시스템의 구조 및 구성을 대략 파악할 수 있음

추상화 유형

- 과정 추상화 : 전반적인 흐름만 파악, 자세하게 정의하지 않음

- 데이터 추상화 : 데이터의 세부사항을 정의하지 않고 구조를 대표할 수 있는 표현으로 대체

- 제어 추상화 : 이벤트의 발생 세부사항은 정의하지 않고 구조를 대표할 수 있는 표현으로 대체

 

<단계적 분해>

- 하향식 설계

-  문제를 상위 중요 개념으로부터 하위의 개념으로 구체화하는 분할 기법

- 추상화의 반복으로 세분화

 

<정보은닉 Information Hiding>

한 모듈 내부에 포함된 정보들을 감추어 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법

다른 모듈과 커뮤니케이션을 할 때는 필요한 정보만 인터페이스를 통해 주고받은

모듈을 독립적으로 수행하기 때문에 다른 모듈에 영향을 주지 않아 수정, 시험, 유지보수가 용이

 

소프트웨어 아키텍처의 품질 속성

소프트웨어 아키텍처가 이해 관계자들이 요구하는 수준의 품질을 유지하고 보장할 수 있게 설계되었는지를 확인하기 위해 품질 요소들을 구체화해 놓은 것

 

소프트웨어 아키텍처의 설계 과정

1. 설계 목표 설정

: 시스템의 개발 방향을 명확히 하기 위해 요구사항을 분석하여 전체 시스템의 설계 목표 설정

 

2. 시스템 타입 결정

: 시스템과 서브 시스템 타입 결정

설계 목표를 고려하여 아키첵처 패턴 선택

 

3. 아키텍처 패턴 적용

: 아키텍처 패턴을 참조하여 시스템의 표준 아키텍처 설계

 

4. 서브시스템 구체화

: 서브시스템의 기능 및 상호작용을 위한 동작과 인터페이스 정의

 

5. 결론

: 아키텍처가 설계 목표에 부합하는지, 요구사항이 잘 반영되었는지 등을 검토

 

아키텍처 패턴

아키텍처를 설계할 때 참조할 수 있는 전형적인 해결 방식 또는 예제

시스템의 구조를 구성하기 위한 기본적인 틀을 제공

서브 시스템과 그 역할이 정의되어 있어 서브 시스템 사이 관계와 규칙, 지침 등이 포함되어 있음

 

아키텍처 패턴의 장점

- 개발 시간을 단축함

- 고품질의 소프트웨어 생산 가능

- 검증된 구조로 작업을 하여 안정적인 개발 가능

- 시스템 구조를 이해하기 쉬워 개발에 참여하지 않아도 유지보수가 쉬움

 

<레이어 패턴>

가장 고전적

시스템을 계층으로 구분하여 구성

각각의 서브 시스템이 계층 구조를 이룸

상위 계층은 하위 계층에 대한 서비스 제공자가 되고 하위 계층은 상위 계층의 클라이언트가 됨

마주 보든 두 계층 사이에만 상호작용이 이루어짐

특정 계층만을 교체하여 시스템을 개선하는 것이 가능

 

레이어 N --> 레이어 N-1 --> ... --> 레이어 1

 

<클라이언트 - 서버 패턴>

하나의 서버와 다수의 클라이언트로 구성

사용자는 클라이언트를 통해 서버에 요청하고 응답을 받아 사용자에게 제공

서버는 클라이언트의 요청에 대비해 항상 대기 상태 유지

요청을 위하여 동기화되는 경우를 제외하고는 서로 독립적임

 

서버 -- TCP/IC --> 클라이언트

 

<파이프 - 필터 패턴>

데이터 스트림 (데이터가 송수신되거나 처리되는 흐름) 절차의 각 단계를 필터 컴포넌트로 캡슐화하여 파이프를 통해 데이터를 전송

필터 컴포넌트는 재사용성이 좋고 추가가 쉬워 확장이 용이

필터 컴포넌트를 재배치하여 다양한 파이프라인 구축 가능

데이터 변환, 버퍼링, 동기화 등에 사용

 

Source -- 파이프1 --> 필터1 -- 파이프2 --> 필터2 -- 파이프3 --> Sink

 

<모델 - 뷰 컨트롤러 패턴 MVC >

서브 시스템을 3개의 부분으로 구조화

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

- 뷰 : 사용자에게 정보 표시

- 컨트롤러 : 사용자로부터 받는 입력 처리

각 부분은 별도로 분리되어 있어 서로 영향을 받지 않고 독립적인 개발 작업 수행

여러 개의 뷰를 만들 수 있어 한 개의 모델에 여러 개의 뷰가 있어야 하는 대화형 애플리케이션에 적합

기타 패턴

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

브로커 패턴 : 사용자가 원하는 서비스와 특성을 브로커 컴포넌트에 요청하면 브로커 컴포넌트가 요청에 맞는 컴포넌트를 연결

피어 - 투 - 피어 패턴 : 피어를 하나의 컴포넌트로 간주하여 각 피어는 클라이언트 또는 서버가 될 수도 있음

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

블랙보드 패턴 : 모든 컴포넌트가 공유 데이터 저장소와 블랙보드 컴포넌트에 접근이 가능하여 검색을 통해 블랙 보드에서 원하는 데이터를 찾을 수 있음. 음성인식, 차량 식별, 신호 해석 등에 주로 이용

인터프리터 패턴 : 프로그램 코드의 각 라인을 수행하는 방법을 지정하고 기호마다 클래스를 갖도록 구성

 

 

객체지향

현실 세계의 개체를 기계의 부품처럼 하나의 객체로 만들어 소프트웨어를 개발할 때 객체를 조립하여 작성할 수 있는 기법

구조적 기법의 문제점을 해결하기 위해 사용

소프트웨어의 재사용 및 확장이 용이하여 고품질의 소프트웨어를 빠르게 개발할 수 있어 유지보수가 쉬움

복잡한 구조를 단계적이고 계층적으로 표현

멀티미디어 데이터 및 병렬 처리 지원

구성 요소 : 객체, 클래스, 메시지

객체 지향 기법 : 캡슐화, 정보은닉, 상속, 추상화, 다형성, 연관성

 

<객체>

데이터와 데이터를 처리하는 함수를 묶어 캡슐화한 하나의 소프트웨어 모듈

데이터 : 객체가 가지고 있는 정보

함수 : 객체가 수행하는 기능으로 데이터를 처리하는 알고리즘

객체의 특성

- 객체는 독립적으로 식별 가능한 이름을 가지고 있음

- 객체의 상태는 시간에 따라 변함

- 객체 간의 상호 연관성에 의해 관계 형성

- 객체가 반응할 수 있는 메시지의 집합을 행위라고 하며 객체는 행위의 특징을 나타낼 수 있음

- 객체는 일정한 기억 장소를 가지고 있음

 

<클래스>

공통된 속성과 연상을 갖는 객체의 집합으로 객체의 일반적인 타입을 의미

각각의 객체들이 갖는 솔성과 연산을 정의하고 있는 틀

인스턴스 : 클래스에 속한 각각의 객체

인스턴스 화 : 클래스로부터 새로운 객체를 생성하는 것

슈퍼 클래스 : 특정 클래스의 상위 클래스

서브 클래스 : 특정 클래스의 하위 클래스

 

<메시지>

객체 간의 상호작용이 일어나기 위해서 메시지가 필요하며 메시지를 통하여 객체의 동작이 수행됨

 

객체 지향 기법

- 캡슐화 Encapsulation

데이터와 함수를 하나로 묶은 것

인터페이스를 제외한 세부 내용이 은폐되어 외부에서 접근이 제한적이기 때문에 외부에서 변경하기 어려움

 

- 정보 은닉 Information Hiding

객체가 다른 객체로부터 자신의 자료를 숨기고 자신의 연산만을 통하여 접근을 허용하는 것

정보 은닉의 가장 근본적인 목적은 고려되지 않은 영향 (Side Effect)를 최소화 하는 것

 

- 상속 Inheritance 

이미 정의된 상위 클래스의 모든 속성과 연산을 하위 클래스가 물려받는 것

하위 클래스는 부모 클래스의 도든 속성과 연산을 다시 정의하지 않고 사용할 수 있음

하위 클래스는 상속받은 속성 외에 새로운 속성과 연산을 첨가하여 사용할 수 있음

객체와 클래스의 재사용을 높이는 중요한 개념

다중 상속 : 한 객의 클래스가 두 개 이상의 상위 클래스로부터 상속받는 것

 

- 추상화 Abstraction

중요하고 관계있는 부분만을 분리하여 단순화하는 것

 

- 다형성 Polymorphism

메시지에 의해 객체가 연산을 수행하게 될 때 하나의 메시지에 대해 각각의 클래스가 가지고 있는 고유한 방법으로 응답할 수 있는 능력

객체지향의 오버 로딩의 개념

C++ 오버 로딩과 오버 라이딩

 

- 연관성 Relation

클래스간의 연관관계를 정의

객체간의 관계를 세부적으로 정의히여 구현 용의

일반화 Generalization : is - a

상세화 Specialization : has - a

집단화 Aggregation : is part of

 

 

객체지향 소프트웨어 설계의 5원칙 ( SOLID )

S : Single responsibility principle (단일 책임 원칙)

하나의 클래스는 하나의 책임을 갖는다

클래스나 모듈은 한가지 기능만을 가지고 있으며 이를 변경하려는 이유도 딱 한가지여야 한다.

한 개의 클래스에 둘 이상의 기능이 들어가 있으면 복잡해진다.   

 

O : Open Closed principle ( 개방 패쇄 원칙 )

소프트웨어의 각 요소는 확장에 열려있고 변경에는 닫혀있어야 한다.

변경이 필요한 경우 기존 코드를 수정하지 말고 상속과 확장을 활용하여 변경한다.

 

L : Liskov substitution principle ( 리스코프 교환 방식)

서브타입은 기반타입으로 교환할 수 있도록 설계되어야 한다.

상속은 다형성을 통하여 확장성을 극대화 하려는 목적으로 사용해야 한다.

 

I : Interface segregation principle ( 인터페이스 분리 원칙 )

필요한 메서드만 인터페이스로 제공하고 사용하지 않는 메서드와는 연결관계를 제공하지 말아야 한다.

범용의 통합 인터페이스보다는 특정 클라이언트를 위하여 구체적인 인터페이스를 여러 개 만드는 것이 더 낫다.

 

D : Dependency inversion principle ( 의존관계 역전 원칙 )

구체적인 클래스에 의존하지 말고, 추상화된 것에 의존하여 설계한다.

상위 모듈이 하위모듈에 의존적이면 하위모듈의 변경에 상위모듈이 영향을 받게 되므로, 상위모듈이 하위모듈에 의존하지 않도록 하고 모두 별도의 추상화에 의존하도록 한다.

 

모듈

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

서브루틴, 서브 시스템, 소프트웨어 내의 프로그램, 작업 단위 등과 같은 의미로 사용

단독으로 컴파일 가능하며 재사용 할 수 있음

각 모듈의 기능이 서로 독립적이고 모듈이 하나의 기능만을 수행하고 다른 모듈과의 과도한 상호작용을 배제함

독립성이 높을수록 모듈을 수정해도 다른 모듈에 영향이 없어 오류가 발생해도 쉽게 해결 가능

모듈의 독립성을 높이기 위해서는 결합도는 약하게, 응집도는 강하게 해야 함

 

<결합도> 내공외제스자

모듈 간에 상호 의존도 또는 모듈 사이의 연관 관계

결합도와 품질은 반비례 관계

결합도가 강하면 시스템 구현 및 유지보수 작업이 어려움

 

<응집도> 기순통절시논우

정보 은닉 개념을 확장한 것으로 모듈 내부 요소들의 서로 관련된 정도

모듈이 독립적인 기능으로 정의된 정도

응집도 품질은 비례 관계

 

<팬인, 팬아웃>

팬인 : 호출하는 모듈의 수 (Indegree)

팬아웃 : 호출되는 모듈의 수 (outdegree)

 

 

공통 모듈

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

자주 사용되는 계산식이나 매번 필요한 사용자 인증 같은 기능들이 공통 모듈로 구성될 수 있음

공통 모듈의 명세 기법 : 정확성(기능의 필요를 정확하게 기술), 명확성(중의적으로 해석되지 않도록), 완전성(구현에 필요한 모든 것을 기술), 일관성(상호 충돌이 없도록), 추적성(기능에 대한 출처, 관련 시스템과의 관계를 파악할 수 있도록)

 

<재사용>

비용과 시간을 절약하기 위해 이미 개발된 기능들을 파악하고 재구성하여 새로운 시스템 개발에 사용하기 적합하도록 최적화시키는 작업

재사용 되는 대상은 외부 모듈과의 결합도는 낮고 응집도는 높아야 함

 

<효율적인 모듈 설계 방안>

결합도는 줄이고 응집도는 높여 모듈의 독립성과 재사용성을 높임

하나의 입구와 하나의 출구를 가져야 함

 

 

코드

컴퓨터를 이용하여 자료를 처리하는 과정에서 분류, 조합 및 집계를 용이하게 하고 특정 자료의 추출을 쉽게 하기 위해 사용하는 기호

코드의 기능 : 식별 기능(데이터에 성격에 따라 구분 가능), 분류 기능(특별한 기준으로 분류 가능), 배열 기능(의미를 부여하거나 나열할 수 있음)

 

코드의 종류

- 순차 코드 : 일정 기준에 따라 최초의 자료부터 (발생 순서에 따라) 차례대로 일련 번호를 부여하는 방법

- 블록 코드 : 대상 항복에서 공통적인 것들을 블록으로 구분하고 블록에 일련번호를 부여하는 방법

- 10진 코드 : 대상 항복을 0~9까지 10진 분할하고 다시 각각에 대하여 10진 분할을 필요한 만큼 반복하는 방법 (도서 분류 코드 1000)

- 그룹 분류 코드 : 일정 기준에 따라 대분류, 중분류, 소분류 등으로 구문하고 그룹 안에서 일련번호를 부여하는 방법 (1-01-001)

- 연상 코드 : 항목의 명칭이나 약호와 관계있는 숫자, 문자, 기호를 이용하여 코드를 부여하는 방법 (TV-23)

- 표의 숫자 코드 = 유효 숫자 코드 : 항목의 성질(길이, 넓이, 부피, 지름 등)의 물리적인 수치를 그대로 코드에 적용하는 방법

- 합성 코드 : 하나의 코드로 수행하기 어려운 경우 2개 이상의 코드를 조합하여 적용하는 방법 (KE-811)

 

코드 부여 체계

코드 (이름)만으로도 개체의 용도와 적용 범위를 알 수있도록 코드를 부여하는 방식

시스템의 고유한 코드와 개체를 나타내는 코드 등이 정의되어야 함

 

 

디자인 패턴

각 모듈의 세분화된 역할이나 모듈 간의 인터페이스와 같은 코드를 작성하는 수준의 세부적인 구현 방안을 설계할 때 참조할 수 있는 전형적인 해결방식 또는 예제

개발 과정에 문제가 발생 시 새로 해결책을 구상하기보다 문제에 해당하는 디자인 패턴을 참고하여 적용하는 것이 더욱 효율적임

재사용할 수 있는 기본형 코드들이 포함되어 있음

 

생성 패턴

객체의 생성과 참조 과정을 샘플화 하여 객체가 생성되거나 변경되어도 프로그램의 구조에 영향을 크게 받지 않도록 하여 프로그램의 유연성을 더해줌

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

- 빌더 : 작게 분리된 인스턴스를 건축하듯이 조합하여 객체 생성

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

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

- 싱글톤 : 하나의 객채를 생성하면 생성된 객체를 어디서든 참조할 수 있지만 여러 프로세스가 동시에 참조할 수는 없음

 

구조 패턴

클래스나 객체들을 조합하여 더 큰 구조로 만들 수 있게 해주는 패턴

- 어댑터 : 호환성이 없는 클래스들의 인터페이스를 다른 클래스가 이용할 수 있도록 변환해주는 패턴

- 브리지 : 구현부에서 추상층을 분리하여 서로가 독립적으로 확장할 수 있도록 구성한 패턴 (기능과 구현 분리)

- 컴포지트 : 복합 객체와 단일 객체를 구분 없이 다루고자 할 때 사용하는 패턴

- 데코레이터 : 객체 간의 결합을 통해 능동적으로 기능을 확장할 수 있는 패턴, 부가적인 기능을 추가하기 위해 다른 개체를 덧붙임

- 퍼씨드 : 복잡한 서브 클래스들을 피해 더 상위에 인터페이스를 구상함으로써 서브 클래스의 기능을 간편하게 사용할 수 있도록 하는 패턴

- 플라이웨스트 : 인스턴스가 필요할 때마다 생성하는 것이 아닌 공유해서 사용함으로써 메모리를 절약하는 패턴

- 프록시 : 접근이 어려운 객체와 여기에 연결하려는 객체 사이에서 인터페이스 역할을 수행하는 패턴

 

행위 패턴

클래스나 객체들이 상호 작용하는 방법이나 책임 분배 방법을 정의한 패턴

- 책임 연쇄 : 요청을 처리할 수 있는 객체가 둘 이상 존재하여서 한 객체가 처리하지 못하면 다음 객체로 넘어가는 형태의 패턴

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

- 인터프리터 : 언어에 문법 표현을 정의하는 패턴 (SQL, 통신 프로토콜 개발에 사용)

- 반복자 : 자료 구조와 같이 접근이 자주 일어나는 객체에 대해 동일한 인터페이스를 사용하여 순차적인 접근 가능

- 중재자 : 수많은 객체 간의 복잡한 상호작용을 캡슐화하여 객체로 정의하여 결합도를 낮추는 패턴

- 메멘토 : 특정 시점에서의 객체 내부 상태를 객체화함으로써 이후 요청에 따라 객체의 상태를 되돌릴 수 있는 기능을 제공하는 패턴

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

- 상태 : 객체의 상태에 따라 동일한 동작을 다르게 처리해야 할 때 사용하는 패턴

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

- 탬플릿 메소드 : 상위 클래스에서 골격을 정의하고 하위 클래스에서 처리를 구체화하는 구조의 패턴

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

 

 

럼바우 분석 기법

소프트웨어 구성 요소를 그래픽 표기법을 이용하여 모델링

객체 모델링 기법 OMT (Object Modeling Technique)이라고도 함

분석 활동은 객체 모델링, 동적 모델링, 기능 모델링을 통해 이루어짐

 

- 객체 모델링 (Object Modeling)

객체 다이어그램 (객체 관계)로 표시

가장 중요하며 선행되어야할 모델링

순서

1. 객체와 클래스를 식별

2. 클래스에 대한 자료를 사전 작성

3. 클래스 간의 관계 정의

4. 객체 속성 및 연결 관계 정의

5. 클래스 계층화 및 모듈로 정의

6. 생성된 모형을 반복적으로 검증

 

- 동적 모델링 (Dynamic Modeling)

상태 다이어그램 (상태도)를 이용해 시간에 흐름에 따른 객체들 간의 제어흐름, 상호작용, 동작 순서 등의 동적인 행의를 표현하는 모델링

순서

1. 사건의 상효 작용 순서에 대한 시나리오 작성

2. 시나리오를 역할과 시간에 따라 표기한 후 사전 추적도 작성

3. 사건 추적도를 사건 발생자의 관계로 설명하는 사건 흐름도 작성

4. 사건과 상태를 연결시킨 상태로 작성

 

- 기능 모델링 (Functional Modeling)

자료 흐름도 (DFD)를 이용하여 다수의 프로세스들 간의 자료 흐름을 중점으로 처리

어떤 데이터를 입력하여 어떤 결과를 구할 것이가를 표현함

순서

1. 외부와 시스템 간의 입출력 자료를 정의

2. 자료 흐름도를 상세화

3. 프로세스 기능에 대한 정의를 기능 명세서로 작성

4. 제약 조건 파악

5. 최적화 기준 명세화

 

 

자료 흐름도 DFD (Data Flow Diagram)

구조적 분석 기법에 이용

자료 흐름과 기능을 자세히 표현하기 위해 단계적으로 세분화

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

 

구성요소

process (원)

data flow (화살표)

data store (단선/이중선)

terminator (사각형)

 

작성 지침

자료는 처리를 거쳐 변환될 때마다 새로운 명칭을 부여해야 한다.

자료흐름도의 최하위 처리(process)는 소단위 명세서를 갖는다.

어떤 처리(process)가 출력자료를 산출하기 위해서는 필요한 자료가 반드시 입력되어야 한다.

상위단계의 처리(Process)와 하위 자료흐름도의 자료 흐름은 서로 일치돼야 한다.

 

 

자료 사전 DD (Data Dictionary)

기호

= 정의(is composed of)

+ 연결(and)

{} 반복(iteration of)

[] 선택(choose only one of)

() 생략(optional)

** 주석(comment)

 

작성 시 고려사항

갱신하기 쉬워야 한다

이름으로 정의를 쉽게 찾을 수 있어야 한다.

정의하는 방식이 명확해야 한다

 

 

 

 

 

2020 ~ 2022 정보처리기사 필기 출제 기준