정처기 소프트웨어 설계 - 1.3 어플리케이션 설계

<소프트웨어 아키텍처> ★★★★

(1) 소프트웨어 아키텍처의 설계
- 소프트웨어의 골격이 되는 기본 구조, 구성하는 요소들 간의 관계를 표현하는 시스템의 구조, 구조체
- 소프트웨어 개발 시 적용되는 원칙, 지침
- 이해관계자들의 의사소통 도구

(2) 모듈화(Modularity)
- 소프트웨어의 성능을 향상, 시스템의 수정 및 재사용, 유지 관리 등이 용이하도록 시스템의 기능들을 모듈 단위로 나눔
- 자주 사용되는 기능들 --> 공통 모듈로 구성 --> 프로젝트 재사용성 향상
- 모듈 크기 작게 나눔 --> 개수 많아짐 --> 모듈 간의 통합 비용 大
- 모듈 크기 크게 나눔 --> 개수 적어짐 --> 모듈 간의 통합 비용 小, 모듈 하나의 개발 비용 大

(3) 추상화(Abstraction)
- 문제의 전체적이고 포괄적인 개념을 설계한 후 차례로 세분화하여 구체화시켜나가는 것
- 복잡한 문제를 다룰 때 가장 기본적으로 사용하는 방법
- 최소의 비용으로 실제 상황에 대처 가능하게 함
- 시스템의 구조 및 구성을 대략적으로 파악 가능하게 함
- 과정 추상화, 데이터 추상화, 제어 추상화

(4) 단계적 분해(Stepwise Refinement)
- 하향식 설계 전략 ( 문제를 상위 중요개념부터 하위 개념으로 구체화 시킴)
- 추상화의 반복에 의해 세분화됨

(5) 정보 은닉(Information Hiding)
- 한 모듈 내부에 포함된 절차와 자료들의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 하는 것
- 모듈을 독립적으로 수행 가능 수정, 시험, 유지보수에 용이
- 어떤 모듈이 소프트웨어기능을 수행하는데 반드시 필요한 기능이 있어 정보 은닉된 모듈과 소통할 필요 있을 경우
   : 필요한 정보만 인터페이스를 통해 주고 받음

(6) 소프트웨어 아키텍처의 품질 속성
- 소프트웨어 아티텍처가 이해관계자들이 요구하는 수준의 품질을 유지, 보장할 수 있게 설계되었는지 확인하기 위해
- 시스템 측면 : 성능, 보안, 가용성, 기능성, 사용성, 변경 용이성, 확장성 ...
- 비즈니스 측면 : 시장 적시성, 비용과 혜택, 예상 시스템 수명 ...
- 아키텍처 측면 : 개념적 무결성, 정확성, 완결성, 구축 가능성

(7) 소프트웨어 아키텍처의 설계 과정
- 설계 목표 설정 --> 시스템 타입 설정 --> 아키텍처 패턴 적용 --> 서브시스템 구체화 --> 검토

---

<아키텍처 패턴> ★★★★

(1) 아키텍처 패턴(Patterns)의 개요
- 아키텍처를 설계할 때 참조할 수 있는 전형적인 해결 방식, 예제
- 아키텍처 패턴 = 아키텍처 스타일, 표준 아키텍처
- 아키텍처 패턴의 장점
     - 시행착오 小 --> 개발 시간 小, 고품질 소프트웨어 생산 가능
     - 이해관계자들 공통된 아키텍처 공유 --> 의사소통 간쳔
     - 시스템의 특성을 개발 전에 예측하는 것이 가능해짐

(2) 레이터 패턴(Layers pattern)
- 시스템을 계층(Layer)로 구분하여 구성하는 고전적인 방법
- 각각의 서브시스템들이 계층 구조를 이룸
- 상위 계층은 하위 계층에 대한 서비스 제공자가 됨
- 하위 계층은 상위 걔층의 클라이언트가 됨
- 서로 마주보는 두 개의 계층 사이에서만 상호작용이 이루어짐
- 변경작업이 용이
- 특정 계층만을 교체해 시스템을 개선하는 것이 가능
- 대표적으로 OSI 참조 모델이 있음

(3) 클라이언트 - 서버 패턴(Client-Server Patter)
- 하나의 서버 컴포넌트와 다수의 클라이언트 컴포넌트로 구성되는 패턴
- 사용자는 클라이언트와만 의사소통을 함
- 서버는 클라이언트의 요청에 대비해 항상 대기상태 유지해야 함
- 클라이언트, 서버는 동기화되는 과정(요청, 응답)을  제외하고 서로 독립적

(4) 파이프 - 필터 패턴(Pipe - Filter Pattern)
- 데이터 스트림 절차의 각 단계를 필터(Filter) 컴포넌트로 캡슐화하여 파이프(Pipe)를 통해 데이터를 전송하는 패턴
- 재사용성이 좋음, 추가가 쉬워 확장에 용이함
- 재배치 --> 다양한 파이프라인 구축 가능
- 데이터 변환, 버퍼링, 동기화
- 대표적으로 UNIX의 쉘(Shell)이 있음

(5) 모델 - 뷰 - 컨트롤러 패턴
- 서브시스템을 3개의 부분으로 구조화하는 패턴 (각 부분은 별도의 컴포넌트로 분리 --> 서로 영향 x 개별 작업 수행)
- 모델(Model) : 서브시스템의 핵심 기능과 데이터를 보관
- 뷰(View) : 사용자에게 정보를 표시
- 컨트롤러(Controller) : 사용자로부터 받은 입력을 처리
- 여러개의 뷰를 만들 수 있음
- 대화형 애플리케이션에 적합

(6) 기타 패턴
- 마스터 - 슬레이브 패턴
     : 마스터 컴포넌트는 모든 작업의 주체, 슬레이브 컴포넌트는 마스터 컴포넌트 지시에 따라 작업 수행, 결과 반복
- 브로커 패턴
     : 사용자가 원하는 서비스와 특성을 브로커 컴포넌트에 요청,  요청에 맞는 컴포넌트와 사용자를 연결
- 피어 투 피어 패턴
     : 피어는 서비스를 호출하는 클라이어트나 서비스를 제공하는 서버가 될 수도 있는 패턴
- 이벤트 - 버스 패턴
     : 소스가 특정 채널에 이벤트 메시지를 발행하면, 해당 채녈을 구독한 리스너들이 메시지를 받아 이벤트를 처리
- 블랙보드 패턴
     : 모든 컴포넌트들이 공유 데이터 저장소와 블랙보드 컴포넌트에 접근이 가능한 형태 
       해결책이 명확하지 않은 문제를 처리하는데 유용한 패턴
- 인터프리터 패턴
     : 프로그램 코드의 각 라인을 수행하는 방법을 지정하고, 기호마다 클래스를 갖도록 구성됨
      특정 언어로 작성된 프로그램 코드를 해석하는 컴포넌트를 설계할 때 사용되어짐

---

<객체지향(Object - Oriented)> ★★★★

(1) 객체지향의 개요
- 소프트웨어를 개발할 때에도 객체들을 조립해서 작성할 수 있는 기법
- 구조적 기법의 문제점으로 인한 소프트웨어 위기의 해결책으로 채택되어 사용되고 있음
- 소프트웨어 재사용 및 확장이 용이하여 고품질의 소프트웨어를 빠르게 개발할 수 있고 유지보수가 쉬움
- 복잡한 구조를 단계적, 계층적으로 표현하고, 멀티미디어 데이터 및 병렬 처리를 지원함
- 현실세계를 모형화하므로 사용자와 개발자가 쉽게 이해 가능
- 객체(Object), 클래스(Class), 캡슐화(Encapsulation), 상속(Inheritance), 다형성(Polymorphism)

(2) 객체(Object)
- 데이터와 데이터를 처리하는 함수를 묶어 놓은(캡슐화한) 하나의 소프트웨어 모듈
- 데이터 : 객체가 가지고 있는 정보로 속성, 상태, 분류 등을 나타냄
             속성(Attribute), 상태, 변수, 사수, 자료 구조라고도 함
- 함수 : 객체가 수행하는 기능으로 객체가 갖는 데이터(속성, 상태)를 처리하는 알고리즘
           객체의 상태를 참조하거나 변경하는 수단이 되는 것으로 메소드, 서비스, 동작, 연산이라고도 함
-객체의 특성
     : 독립적으로 식별 가능한 이름을 가지고 있음
       객체가 가질 수 있는 조건을 상태(State)라고 하는데, 일반적으로 상태는 시간에 따라 변함
       객체와 객체는 상호연관성에 의한 관계가 형셩됨
       객체가 반응할 수 있는 메시지의 집합을 행위라고 함, 객체는 행위의 특징을 나타낼 수 있음
       객체는 일정한 기억 장소를 가지고 있음
- 객체의 메소드는 다른 객체로부터 메시지를 받았을 때 정해진 기능을 수행함

(3) 클래스(Class)
- 공통된 속성과 연산(행위)을 갖는 객체의 집합, 객체의 일반적인 타입(Type)을 의미함
- 각각의 객체들이 갖는 속성과 연산을 정의하고 있는 틀
- 인스턴스 : 클래스에 속한 각각의 객체
- 인스턴스화 : 클래스로부터 새로운 객체를 생성하는 것
- 동일 클래스에 속한 각각의 객체(인스턴스)들은 공통된 속성과 행위를 가지고 있으면서,
  그 속성에 대한 정보가 서로 달라서 동일 기능을 하는 여러가지 객체를 나타내게 됨
- 슈퍼 클래스(Super Class) : 특정 클래스의 상위(부모) 클래스
- 서브 클래스(Sub Class) : 특정 클래스의 하위(자식) 클래스

(4) 캡슐화(Encapsulation)
- 데이터(속성)와 데이터를 처리하는 함수를 하나로 묶는 것을 의미
- 캡슐화된 객체는 인터페이스를 제외한 세부 내용이 은폐되어 외부에서의 접근이 제한적
   --> 외부 모듈 변경으로 인한 파급효과 적음
- 인터페이스가 단순해지고, 객체 간의 결합도는 낮아짐

(5) 상속(Inheritance)
- 이미 정의된 상위 클래스(부모 클래스)의 모든 속성, 연산을 하위 클래스(자식 클래스)가 물려받는 것
- 하위 클래스는 자신 클래스 내에서 다시 정의하지 않고서도 즉시 자신의 속성으로 사용 가능
- 하위 클래스는 새로운 속성과 연산을 첨가하여 사용할 수 있음
- 객체와 클래스의 재사용(소프트웨어의 재사용)을 높이는 중요한 개념
- 다중 상속(Multiple Inheritance) : 한 개의 클래스가 두 개 이상의 상위 클래스로부터 속성과 연산을 상속받는 것

(6) 다형성(Polymorphism)
- 메시지에 의해 객체(클래스)가 연산을 수행하게 될 때 하나의 메시지에 대해
  각각의 객체(클래스)가 가지고 있는 고유한 방법(특성)으로 응답할 수 있는 능력의 의미
- 객체(클래스)들은 동일한 메소드명을 사용하며 같은 의미의 응답을 함

 

---

<모듈> ★★★★

(1) 모듈(Module)의 개요
- 모듈화를 통해 분리된 시스템의 각 기능들로, 서브루틴, 서브시스템, 소프트웨어 내의 프로그램, 작업 단위.. 의 의미
- 단독으로 컴파일, 재사용 가능
- 모듈의 독립성은 결합도(Coupling), 응집도(Cohesion)에 의해 측정됨
- 모듈의 독립성을 높이려면 결합도는 小, 응집도 大, 모듈의 크기 小

(2) 결합도(Coupling)
- 모듈 간에 상호 의존하는 정도, 두 묘둘 사이의 연관 관계를 의미
- 결합도와 품질은 반비례 관계
- 결합도 강하면 시스템 구현 및 유지보수 작업이 어려움
- 자료, 스탬프, 제어, 외부, 공통, 내용 결합도 순으로 결합도 약함
- 자료 결합도(Data Coupling) : 모듈 간의 인터페이스가 자료 요소로만 구성될 때의 결합도
- 스탬프(검인) 결합도(Stamp Coupling) : 모듈 간의 자료구조가 전달될 때의 결합도
- 제어 결합도(Control Coupling) : 어떤 모듈이 다른 모듈 내부의 논리적인 흐름을 제어하기 위해
                                            제어신호를 이용하여 통신하거나 제어요소를 전달하는 결합도
- 외부 결합도(External Coupling) : 어떤 모듈에서 선언한 데이터(변수)를 외부의 다른 모듈에서 참조할 때의 결합도
- 공통(공유) 결합도(Common Coupling) : 공유되는 공통 데이터 영역을 여러 모듈이 사용할 때의 결합도
- 내용 결합도(Context Coupling) : 한 모듈이 다른 모듈의 내부 기능, 내부 자료를 직접 참조하거나 수정할 때의 결합도

(3) 응집도(Cohesion)
- 정보 은닉 개념을 확장한 것. 모듈의 내부 요소들의 서로 관련되어 있는 정도
- 모듈이 독립적인 기능으로 정의되어 있는 정도
- 응집도와 품질은 비례 관계
- 기능적, 순차적, 교환적, 절차적, 시간적, 논리적, 우연적 응집도 순으로 응집도 강함
- 기능적 응집도(Functional Cohesion) : 모듈 내부의 모든 기능 요소들이 단일 문제와 연관되어 수행될 경우의 응집도
- 순차적 응집도(Sequential Cohesion)
     : 모듈 내 하나의 활동으로부터 나온 출력데이터를 그 다음 활동의 입력데이터로 사용할 경우의 응집도
- 교환(통신)적 응집도(Procedural Cohesion)
     : 동일한 입력과 출력을 사용하여 서로 다른 기능을 수행하는 구성 요소들이 모였을 경우의 응집도
- 절차적 응집도(Procedural Cohesion)
     : 모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성요소들이 그 기능을 순차적으로 수행할 경우의 응집도
- 시간적 응집도(Temporal Cohesion)
     : 특정 시간에 처리되는 몇 개의 기능을 모아 하나의 모듈로 작성할 경우의 응집도
- 논리적 응집도(Logical Cohesion)
     : 유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들로 하나의 모듈이 형성되는 경우의 응집도
- 우연적 응집도(Coincidental Cohesion)
     : 모듈 내부의 각 구성요소들이 서로 관련 없는 요소로만 구성된 경우의 응집도

(4) 팬인(Fan - In) / 팬아웃(Fan - Out)
- 팬인 : 어떤 모듈을 제어(호출)하는 모듈의 수를 나타냄 (들어오는 것)
- 팬아웃 : 어떤 모듈에 이해 제어(호출)되는 모듈이 수를 나타냄 (나가는 것)
- 시스템의 복잡도를 알 수 있음
- 팬인이 높은 경우 : 재사용 측면에서 설계가 잘 되어있다고 볼 수 있으나, 단일 장애점이 발생할 수 있음
                           --> 중점적인 관리 및 테스트가 필요함
- 팬아웃이 높은 경우 : 불필요하게 다른 모듈을 호출하고 있는지 검토, 단순화시킬 수 있는지 여부에 대한 검토 필요
- 시스템 복잡도 최적화 : 팬인 높게, 팬아웃 낮게 설계해야 함

---

<코드> ★★★☆

(1) 코드(Code)의 개요
- 컴퓨터를 이용해 자료를 처리하는 과정에서 분류, 조합, 집계를 용이하게 하고,
  특정 자료 추출을 쉽게하기 위해 사용하는 기호
- 식별 기능 : 데이터 간의 성격에 따라 구분이 가능함
- 분류 배열 : 특정 기주이나 동일한 유형에 해당하는 데이터를 그룹화 할 수 있음
- 배열 기능 : 의미를 부여하여 나열할 수 있음

(2) 코드의 종류

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

- 블록 코드(Block Code)
     : 공통성이 있는 것끼리 블록으로 구분, 각 블록내에서 일련번호를 부여하는 방법
       = 구분 코드

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

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

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

- 표의 숫자 코드(Significant Digit Code)
     : 코드화 대상 항목의 성질의 물리적 수치를 그대로 코드에 적용시키는 방법
       = 유효 숫자 코드

- 합성 코드(Combined Code)
     : 필요한 기능을 하나의 코드로 수행하기 어려운 경우 2개 이상의 코드를 조합하여 만드는 방법

(3) 코드 부여 체계
- 이름만으로 개체의 용도와 적용 범위를 알 수 있도록 코드를 부여하는 방식
- 각 객체에 유일한 코드를 부여하여 개체들으 식별 및 추출을 용이하게 함
- 코드를 부여하기 전에 각 단위 시스템의 고유한 코드와 개체를 나타내는 코드 등이 정의되어야 함
- 코드 부여 체계를 담당하는 자는 코드의 자릿수와 구분자, 구조 등을 상세하게 명시해야 함

---

<디자인 패턴> ★★★☆

(1) 디자인 패턴(Design Pattern)의 개요
- 각 모듈의 세분화된 역할이나 세부저긴 구현 방안을 설계할 때 참조할 수 있는 전형적인 해결 방식 또는 예제를 의미
- 재사용할 수 있는 기본형 코드들이 포함되어 있음
- 개발 과정 중에 문제 발생 시 문제에 해당하는 디자인 패턴을 참고하는 것이 효율적
- 한 패턴에 변형을 가하거나 특정 요구사항을 반영하면 유사한 형태의 다른 패턴으로 변화하는 특징이 있음
- GOF(Gang of Four)이라 불리는 에릭 감마, 리차드 헬름, 랄프 존슨, 존 블라시디가 처음으로 구체화 및 체계화 함
- GOF의 디자인 패턴은 가장 일반적인 사례에 적용될 수 있는 패턴들 분류, 정리 
  --> 지금까지도 소프트웨어 공학, 현업에서 가장 많이 사용되는 디자인 패턴
- 유형에 따라 생성 패턴 5개, 구조 패턴 7개, 행위 패턴 11개 총 23개의 패턴으로 구성됨

(2) 생성 패턴(Creational Pattern)
- 객체가 생성되거나 변경되어도 프로그램의 구조에 영향을 크게 받지 않도록 하여 프로그램의 유연성을 더해줌
- 추상 팩토리(Abstract Factory)
     : 구체적인 클래스에 의존 x, 인터페이스를 통해 서로 연관, 의존하는 객체들의 그룹으로 생성하여 추상적으로 표현
       연관된 서브 클래스를 묶어 한 번에 교체하는 것이 가능
- 빌더(Builder)
     : 작게 분리된 인스턴스를 건축하듯이 조합하여 객체를 생성함
       객체의 생성 과정, 표현 방법을 분리 --> 동일한 객체 생성에서도 서로 다른 결과 가능 o
- 팩토리 메소드(Factory Method)
     : 객체 생성을 서브 클래스에서 처리하도록 분리하여 캡슐화한 패턴
       상위 클래스에서 인터페이스만 정의하고 실제 생성은 서브 클래스가 담당함
- 프로토타입(Prototype)
     : 원본 객체를 복제하는 방법으로 객체 생성하는 패턴
       일반적인 방법으로 객체 생성, 비용 큰 경우 주로 이용
- 싱글톤(Singleton)
     : 하나의 객체를 생성하면 생성된 객체를 어디서든 참조 가능 o, but 여러 프로세스 동시 참조 x
       클래스 내에서 인스턴스가 하나뿐임을 보장, 불필요한 메모리 낭비 최소화 o

(3) 구조 패턴(Structural Pattern)
- 클래스나 객체들을 조합하여 더 큰 구조로 만들 수 있게 해주는 패턴
- 구조가 복잡한 시스템을 개발하기 쉽게 도와줌
- 어댑터(Adapter)
     : 호환성이 없는 클래스들의 인터페이스를 다른 클래스가 이용할 수 있도록 변환해주는 패턴
- 브리지(Bridge)
     : 구현부에서 추상층을 분리하여, 서로가 독립적으로 확장할 수 있도록 구성한 패턴
- 컴포지트(Composite)
     : 여러 객체를 가진 복합 객체와 단일 객체를 구분 없이 다루고자 할 때 사용하는 패턴
- 데코레이터(Decorator)
     : 객체 간의 결합을 통해 능동적으로 기능들을 확장할 수 있는 패턴
- 퍼싸드(Facade)
     : 복잡한 서브 클래스들을 피해 더 상위에 인터페이스를 구상함
       --> 서브 클래스들의 기능을 간편하게 사용할 수 있도록 하는 패턴
- 플라이웨이트(Flyweight)
     : 인스턴스가 필요할 때마다 매번 생성 x, 가능한 공유해서 사용함으로써 메모리를 절약하는 패턴
- 프록시(Proxy)
     : 접근이 어려운 객체와 여기에 연결하려는 객체 사이에서 인터페이스 역할을 수행하는 패턴

(4) 행위 패턴
- 클래스나 객체들이 서로 상호작용하는 방법이나 책임 분배 방법을 정의하는 패턴
- 하나의 객체로 수행할 수 없는 작업을 여러 객체로 분배하면서 결합도를 최소화 할 수 있도록 도와줌
- 책임 연쇄(Chain of Resposibility)
     : 요청을 처리할 수 있는 객체가 둘 이상 존재하여 한 객체가 처리하지 못하면 다음 객체로 넘어가는 형태의 패턴
- 커맨드(Command)
     : 요청을 객체의 형태로 캡슐화하여 재이용, 취소할 수 있도록 요청에 필요한 정보를 저장, 로그에 남기는 패턴
- 인터프리터(Interpreter)
     : 언어에 문법 표현을 정의하는 패턴
- 반복자(Iterator)
     : 자료 구조와 같이 접근이 잦은 객체에 대해 동일한 인터페이스를 사용하도록 하는 패턴
- 중재자(Mediator)
     : 수많은 객체들 간의 복잡한 상호작용(Interface)을 캡슐화하여 객체로 정의하는 패턴
- 메멘토(Memento)
     : 특정 시점에서의 객체 내부 상태를 객체화
       --> 이후 요청에 따라 객체를 해당 시점의 상태로 돌릴 수 있는 기능을 제공하는 패턴
- 옵서버(Observer)
     : 한 객체의 상태가 변화하면 객체에 상속되어있는 다른 객체들에게 변화된 상태를 전달하는 패턴
- 상태(State)
     : 객체의 상태에 따라 동일한 동작을 다르게 처리해야 할 때 사용하는 패턴
- 전략(Strategy)
     : 동일한 계열의 알고리즘들을 개별적으로 캡슐화하여 상호 교환할 수 있게 정의하는 패턴
- 템플릿 메소드(Temtplate Method)
     : 상위 클래스에서 골격을 정의하고, 하위 클래스에서 세부 처리를 구체화하는 구조의 패턴
- 방문자(Visitor)
     : 각 클래스들의 데이터 구조에서 처리 기능을 분리하여 별도의 클래스로 구성하는 패턴

 

www.yes24.com/Product/Goods/82838724?OzSrank=6

2020 시나공 정보처리기사 필기

* 2020 시나공 정보처리기사 필기 요약한 내용입니다.