[소프트웨어 설계] 3장. 애플리케이션 설계

020 소프트웨어 아키텍처

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

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

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

  - 소프트웨어 개발 시 적용되는 원칙과 지침, 이해관계자들의 의사소통 도구로 활용

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

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

  - 소프트웨어 아키텍처 설계의 기본 원리로는 모듈화, 추상화, 단계적 분해, 정보 은닉이 있음

 

◈ 모듈화(Modularity)

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

  - 자주 사용되는 기능들을 공통 모듈로 구성하여 프로젝트의 재사용성을 향상시킬 수 있음

  - 적정 크기로 구현해야함

   * 작은 경우 : 모듈 개수가 많아져 통합 비용이 증가

   * 큰 경우 : 모듈 하나의 개발 비용이 증가

 

◈ 추상화(Abstraction)

  - 문제의 전체적이고 포괄적인 개념 설계 후, 차례로 세분화하여 구체화시켜나가는 것, 개략화

  - 완전한 시스템을 구축하기 전에 유사한 모델을 만들어 테스트, 모델화

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

  - 추상화의 유형

   * 과정 추상화 : 자세한 수행 과정을 정의하지 않고, 전반적인 흐름만 파악할 수 있게 설계

   * 데이터 추상화 : 데이터의 세부적인 속성이나 용도를 정의하지 않고, 데이터 구조를 대표할 수 있는 표현으로 대체

   * 제어 추상화 : 이벤트 발생의 정확한 절차나 방법을 정의하지 않고, 대표할 수 있는 표현으로 대체

 

◈ 단계적 분해(Stepwise Refinement)

  - Niklaus Wirth에 의해 제안된 하향식 설계 전략

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

  - 추상화의 반복에 의해 세분화

  - 소프트웨어의 기능에서부터 시작하여 점차적으로 구체화하고, 알고리즘, 자료 구조 등 상세한 내역은 뒤로 미룸

 

◈ 정보 은닉(Information Hiding)

  - 한 모듈 내부에 포함된 절차와 자료들의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 함

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

  - 모듈을 독립적으로 수행할 수 있어 하나의 모듈이 변경되더라도 다른 모듈에 영향을 주지 않으므로 수정, 시험, 유지보수가 용이

 

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

  - 시스템 측면

   * 성능 : 사용자의 요청과 같은 이벤트가 발생했을 때 적절하고 빠르게 처리

   * 보안 : 허용되지 않은 접근을 막고 허용된 접근에는 적절한 서비스를 제공

   * 가용성 : 장애 없이 정상적으로 서비스를 제공

   * 기능성 : 사용자가 요구한 기능을 만족스럽게 구현

   * 사용성 : 사용자가 소프트웨어를 사용하는데 헤매지 않도록 명확하고 편리하게 구현

   * 변경 용이성 : 다른 하드웨어나 플랫폼에서도 동작할 수 있도록 구현

   * 확장성 : 시스템의 용량, 처리능력 등을 확장시켰을 때 효과적으로 활용할 수 있도록 구현

   * 기타 속성 : 테스트 용이성, 배치성, 안정성 등

  - 비즈니스 측면

   * 시장 적시성 : 정해진 시간에 맞춰 프로그램 출시

   * 비용과 혜택 : 개발 비용을 투자하여 유연성이 높은 아키텍처를 만들 것인지 결정

   * 예상 시스템 수명 : 시스템을 얼마나 오랫동안 사용할 것인지 고려

   * 기타 속성 : 목표 시장, 공개 일정, 기존 시스템과의 통합 등

  - 아키텍처 측면

   * 개념적 무결성 : 전체 시스템과 시스템을 이루는 구성요소들 간의 일관성 유지

   * 정확성, 완결성 : 요구사항과 요구사항을 구현하기 위해 발생하는 제약사항들을 모두 충족

   * 구축 가능성 : 모듈 단위로 구분된 시스템을 적절하게 분배, 유연하게 일정을 변경

   * 기타 속성 : 변경성, 시험성, 적응성, 일치성, 대체성 등

 

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

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

  - 시스템 타입 결정 : 시스템과 서브시스템의 타입을 결정하고 설계 목표와 함께 고려하여 아키텍처 패턴을 선택

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

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

  - 검토 : 아키텍처가 설계 목표에 부합하고 요구사항 반영, 설계의 기본원리를 만족하는지 등 검토

 

◈ 시스템 타입

  - 대화형 시스템 : 사용자의 요구 발생 시 시스템이 이를 처리하고 반응

  - 이벤트 중심 시스템 : 외부의 상태 변화에 따라 동작

  - 변환형 시스템 : 데이터 입력 시 정해진 작업들을 수행해 결과 출력

  - 객체 영속형 시스템 : DB를 사용해 파일을 효과적으로 저장, 검색, 갱신

 

021 아키텍처 패턴

◈ 아키텍처 패턴(Patterns)의 개요

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

  - 소프트웨어 시스템의 구조를 구성하기 위한 기본적인 윤곽을 제시

  - 서브시스템들과 역할을 정의, 서브시스템 사이의 관계와 여러 규칙, 지침 등을 포함

  - 아키텍처 스타일 또는 표준 아키텍처라고도 함

  - 아키텍처 패턴의 장점

   * 시행착오를 줄여 개발 시간 단축, 고품질의 소프트웨어 생산

   * 검증된 구조로 개발, 안정적인 개발

   * 이해관계자들이 공통된 아키텍처를 공유할 수 있어 의사소통 간편

   * 개발에 참여하지 않은 사람도 손쉽게 유지보수 가능

   * 시스템의 특성을 개발 전에 예측하는 것이 가능

 

◈ 레이어 패턴(Layers pattern)

  - 시스템 계층으로 구분하여 구성하는 고전적인 방법

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

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

  - 서로 마주 보는 두 개의 계층 사이에서만 상호작용이 이루어짐

  - 서로 마주보는 두 개의 계층만 영향을 미치므로 변경 작업이 용이

  - 특정 계층만 교체해서 시스템을 개선 가능

  - OSI 참조 모델

 

◈ 클라이언트-서버 패턴(Client-Sever Pattern)

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

  - 사용자는 클라이언트와만 의사소통함

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

  - 클라이언트나 서버는 요청과 응답을 받기 위해 동기화되는 경우를 제외하고 서로 독립적

※ 컴포넌트(Component) : 독립적인 업무 또는 기능을 수행하는 실행코드 기반으로 작성된 모듈

 

◈ 파이프-필터 패턴(Pipe-Filter Pattern)

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

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

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

  - 하나의 컴포넌트에서 처리가 끝나면 다음 컴포넌트가 결과물을 받아서 처리

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

  - UNIX의 쉘(Shell)

 

◈ 모델-뷰-컨트롤러 패턴(Model-View-Controller Pattern)

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

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

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

  - 컨트롤러(Controller) : 사용자로부터 받은 입력 처리

  - 각 부분은 별도의 컴포넌트로 분리되어 있어 서로 영향을 받지 않고 개발 작업 수행

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

 

◈ 기타 패턴

  - 마스터-슬레이브 패턴(Master-Slave Pattern)

   * 마스터 컴포넌트에서 슬레이브 컴포넌트로 작업 분할 후 슬레이브에게 처리된 결과물을 다시 돌려받음

   * 마스터 컴포넌트는 모든 작업의 주체이고 슬레이브 컴포넌트는 마스터 컴포넌트의 지시에 따라 작업을 수행 및 결과 반환

   * 장애 허용 시스템과 병렬 컴퓨팅 시스템에 주로 활용

  - 브로커 패턴(Broker Pattern)

   * 사용자가 원하는 서비스와 특성을 요청하면 요청에 맞는 컴포넌트와 사용자를 연결

   * 원격 서비스 호출에 응답하는 컴포넌트들이 여러 개 있을 때 적합

   * 분산 환경 시스템에 주로 활용

  - 피어-투-피어 패턴(Peer-To-Peer Pattern)

   * 피어를 하나의 컴포넌트로 간주하고 각 피어는 클라이언트가 될 수도 서버가 될 수도 있음

   * 클라이언트와 서버는 전형적인 멀티스레딩 방식

  - 이벤트-버스 패턴(Event-Bus Pattern)

   * 소스가 특정 채널에 이벤트 메시지를 발행하면 해당 채널을 구독한 리스너들이 메시지를 받아 이벤트를 처리함

   * 4가지 주요 컴포넌트

   ① 이벤트를 생성하는 소스

   ② 이벤트를 수행하는 리스너

   ③ 이벤트의 통로인 채널

   ④ 채널들을 관리하는 버스

  - 블랙보드 패턴(Blackboard Pattern)

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

   * 컴포넌트들은 검색을 통해 블랙보드에서 원하는 데이터를 찾음

   * 해결책이 명확하지 않은 문제를 처리하는데 유용

   * 음성 인식, 차량 식별, 신호 해석 등에 주로 사용

  - 인터프리터 패턴

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

   * 특정 언어로 작성된 프로그램 코드를 해석하는 컴포넌트를 설계할 때 사용

※ 장애 허용 시스템 : 시스템 일부가 결함 또는 고장으로 기능이 정지되더라도 해당 부분의 기능을 제외한 전체 시스템은 정상적으로 수행이 가능한 시스템

※ 멀티스레딩 : 프로세스를 두 개 이상의 실행 단위로 구분하여 공유하며 병렬로 수행

 

022 객체지향(Object-Oriented)

◈ 객체지향의 개요
  - 현실 세계의 개체(Entity)를 기계 부품처럼 하나의 객체(Object)로 만들어, 기계적인 부품들을 조립해 제품을 만들 듯

이 소프트웨어를 개발할 때에도 객체들을 조립해서 작성할 수 있는 기법

  - 구조적 기법의 문제점으로 인한 소프트웨어 위기의 해결책으로 사용

   * 구조적 기법의 문제점

   ① 유지보수 고려하지 않고 개발 공정에만 집중

   ② 개발이 시작된 이후 추가적인 요구사항에 대응하기 어려움

   ③ 재사용이 어려워 이전에 개발한 소프트웨어와 유사한 소프트웨어를 다시 개발할 때도 시간과 인력이 동일하게 소모

  - 소프트웨어의 재사용 및 확장 용이

  - 고품질의 소프트웨어를 빠르게 개발

  - 유지보수 쉬움

  - 복잡한 구조를 단계적, 계층적으로 표현

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

 

◈ 객체(Object)

  - 데이터와 데이터를 처리하는 함수를 묶어 놓은 하나의 소프트웨어 모듈

 1) 데이터

  - 객체가 가지고 있는 정보로 속성이나 상태, 분류 등을 나타냄

  - 속성, 상태, 변수, 상수, 자료구조

 2) 함수

  - 객체가 수행하는 기능, 객체가 갖는 데이터를 처리하는 알고리즘

  - 객체의 상태를 참조, 변경하는 수단이 되는 것으로 메소드, 서비스, 동작, 연산이라고도 함

 3) 특성

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

  - 객체가 가질 수 있는 조건을 상태(State)라고 하고 일반적으로 상태는 시간에 따라 변함

  - 객체와 객체는 상호 연관성에 의한 관계가 형성

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

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

  - 메소드는 다른 객체로부터 메시지를 받았을 때 정해진 기능 수행

 

◈ 클래스(Class)

  - 공통된 속성과 연산을 갖는 객체의 집합, 객체의 일반적인 타입을 의미

  - 클래스에 속한 각각의 객체들이 갖는 속성과 연산을 정의하고 있는 틀

  - 클래스에 속한 각각의 객체를 인스턴스(Instance)라고 함

  - 클래스로부터 새로운 객체를 생성하는 것을 인스턴스화(Instantiation)라고 함

  - 동일 클래스에 속한 각각의 객체들은 공통된 속성과 행위를 가지고 있으면서 그 속성에 대한 정보가 서로 달라 동일 기능을 하는 여러 가지 객체를 나타내게 됨

  - 최상위 클래스는 상위 클래스를 갖지 않은 클래스를 의미

  - 슈퍼 클래스(Super Class)는 특정 클래스의 상위(부모) 클래스를 의미

  - 서브 클래스(Sub Class)는 특정 클래스의 하위(자식) 클래스를 의미

 

◈ 캡슐화(Encapsulation)

  - 데이터와 데이터를 처리하는 함수를 하나로 묶은 것을 의미

  - 캡슐화된 객체는 인터페이스를 제외한 세부 내용이 은폐되어 외부에서의 접근이 제한적이기 때문에 모듈의 변경으로 인한 영향도 낮음

  - 캡슐화된 객체들은 재사용이 용이

  - 인터페이스가 단순함

  - 객체 간의 결합도가 낮아짐

 

◈ 상속(Inheritance)

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

  - 하위 클래스는 상위 클래스의 모든 속성과 연산을 자신의 클래스 내에서 즉시 자신의 속성으로 사용

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

  - 객체와 클래스의 재사용, 즉 소프트웨어의 재사용을 높이는 개념

※ 다중 상속(Multiple Inheritance) : 한 개의 클래스가 두 개 이상의 상위 클래스로부터 속성과 연산을 상속받는 것

 

◈ 다형성(Polymorphism)

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

  - 객체들은 동일한 메소드명을 사용하며 같은 의미로 응답

  - 응용 프로그램 상에서 하나의 함수나 연산자가 두 개 이상의 서로 다른 클래스의 인스턴스들을 같은 클래스에 속한 인스턴스처럼 수행할 수 있도록 함

 

023 모듈

◈ 모듈(Module)의 개요

  - 모듈화를 통해 분리된 시스템의 각 기능, 서브루틴, 서브시스템, 소프트웨어 내의 프로그램, 작업 단위 등과 같은 의미

  - 모듈은 단독으로 컴파일 가능, 재사용할 수 있음

  - 기능적 독립성은 각 모듈의 기능이 서로 독립됨을 의미하며 모듈이 하나의 기능만을 수행하고 다른 모듈과의 과도한 상호작용을 배제함으로써 이루어짐

  - 독립성이 높은 모듈일수록 모듈을 수정하더라도 다른 모듈들에게 거의 영향을 미치지 않고 오류가 발생해도 쉽게 발견하고 해결할 수 있음

  - 독립성은 결합도와 응집도에 의해 측정

  - 독립성을 높이려면 모듈의 결합도는 약하게, 응집도는 강하게, 크기는 작게 만들어야 함

 

◈ 결합도(Coupling)

  - 모듈 간에 상호 의존하는 정도, 두 모듈 사이의 연관 관계

  - 결합도가 약할수록 품질이 높고, 강할수록 품질이 낮음

  - 결합도가 강하면 유지보수 작업이 어려움

  - 강도(약 < 강)

   * 자료 결합도 < 스탬프 결합도 < 제어 결합도 < 외부 결합도 < 공통 결합도 < 내용 결합도

 1) 자료 결합도(Data Coupling)

  - 모듈 간의 인터페이스가 자료 요소로만 구성될 때의 결합도

  - 다른 모듈 호출 시 매개 변수나 인수로 테이터를 넘겨주고 호출받은 모듈은 받은 데이터에 대한 처리 결과를 다시 돌려줌

  - 모듈 간의 내용을 전혀 알 필요 없는 상태로 한 모듈의 내용을 변경하더라도 다른 모듈에는 전혀 영향을 미치지 않음

  - 가장 바람직한 결합도

 2) 스탬프 결합도(Stamp Coupling)

  - 모듈 간의 인터페이스로 배열이나 레코드 등의 자료 구조가 전달될 때의 결합도

  - 두 모듈이 동일한 자료 구조를 조회하는 경우의 결합도로 포맷이나 구조의 변화는 그것을 조회하는 모든 모듈 및 변화되는 필드를 실제로 조회하지 않은 모듈에게까지도 영향을 미침

 3) 제어 결합도(Control Coupling)

  - 다른 모듈 내부의 논리적인 흐름을 제어하기 위해 제어 신호를 이용해 통신, 제어 요소(Function Code, Switch, Tag, Flag)를 전달하는 결합도

  - 한 모듈이 다른 모듈의 상세한 처리 절차를 알고 있어 이를 통제, 처리 기능이 두 모듈에 분리되어 설계된 경우에 발생

  - 하위 모듈에서 상위 모듈로 제어 신호가 이동하는 구조라 권리 전도현상이 발생

 4) 외부 결합도(External Coupling)

  - 어떤 모듈에서 선언한 데이터를 외부의 다른 모듈에서 참조할 때의 결합도

  - 참조되는 데이터의 범위를 각 모듈에서 제한할 수 있음

 5) 공통 결합도(Common Coupling)

  - 공유되는 공통 데이터 영역을 여러 모듈이 사용할 때의 결합도

  - 공통 데이터 영역의 내용을 조금만 변경하더라도 이를 사용하는 모든 모듈에 영향을 미치므로 모듈의 독립성을 약하게 만듦

 6) 내용 결합도(Content Coupling)

  - 한 모듈이 다른 모듈의 내부 기능 및 그 내부 자료를 직접 참조하거나 수정할 때의 결합도

  - 한 모듈에서 다른 모듈의 내부로 제어가 이동하는 경우에도 내용 결합도에 해당

 

◈ 응집도(Cohesion)

  - 정보 은닉 개념을 확장한 것

  - 모듈이 독립적인 기능으로 정의되어 있는 정도를 의미

  - 응집도가 강할수록 품질이 높고, 약할수록 품질이 낮음

  - 강도(강 > 약)

   * 기능적 응집도 > 순차적 응집도 > 교환적 응집도 > 절차적 응집도 > 시간적 응집도 > 논리적 응집도 > 우연적 응집도

 1) 기능적 응집도(Functional Cohesion)

  - 모듈 내부의 모든 기능 요소들이 단일 문제와 연관되어 수행될 경우

 2) 순차적 응집도(Sequential Cohesion)

  - 모듈 내 하나의 활동으로부터 나온 출력 데이터를 그다음 활동의 입력 데이터로 사용할 경우

 3) 교환(통신)적 응집도(Communication Cohesion)

  - 동일한 입력과 출력을 사용하여 서로 다른 기능을 수행하는 구성 요소들이 모였을 경우

 4) 절차적 응집도(Procedural Cohesion)

  - 모듈이 다수의 관련 기능을 가질 때 모듈 안의 구성 요소들이 그 기능을 순차적으로 수행할 경우

 5) 시간적 응집도(Temporal Cohesion)

  - 특정 시간에 처리되는 몇 개의 기능을 모아 하나의 모듈로 작성할 경우

 6) 논리적 응집도(Logical Cohesion)

 - 유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들로 하나의 모듈이 형성되는 경우

 7) 우연적 응집도(Coincidental Cohesion)

  - 모듈 내부의 각 구성 요소들이 서로 관련 없는 요소로만 구성된 경우

 

◈ 팬인(Fan-In) / 팬아웃(Fan-Out)

  - 팬인은 어떤 모듈을 호출하는 모듈의 수

  - 팬아웃은 어떤 모듈에 의해 호출되는 모듈의 수

  - 팬인과 팬아웃을 분석해 시스템의 복잡도를 알 수 있음

  - 팬인이 높으면 재사용 측면에서 설계가 잘되었으나 단일 장애점이 발생할 수 있으므로 중점적인 관리 및 테스트가 필요

  - 팬아웃이 높으면 불필요한 호출을 하고 있는지 검토하고 단순화시킬 수 있는지 여부에 대한 검토가 필요

  - 시스템의 복잡도를 최적화하기 위해선 팬인은 높게, 팬아웃은 낮게 설계해야 함

※ 단일 장애점(SPOF; Single Point Of Failure) : 시스템의 구성 요소 중 동작하지 않으면 전체 시스템이 중단되어 버리는 요소를 의미

 

024 공통 모듈

◈ 공통 모듈의 개요

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

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

  - 모듈의 재사용성 확보, 중복 개발 회피를 위해 공통부분을 식별, 명세 작성

  - 공통 모듈 구현 시 다음의 명세 기법을 준수해야 함

   * 정확성(Correctness) : 시스템 구현 시 해당 기능이 필요하다는 것을 알 수 있도록 정확히 작성

   * 명확성(Clarity) : 해당 기능을 이해할 때 중의적으로 해석되지 않도록 명확하게 작성

   * 완전성(Completeness) : 시스템 구현을 위해 필요한 모든 것을 기술

   * 일관성(Consistency) : 공통 기능들 간 상호 충돌이 발생하지 않도록 작성

   * 추적성(Traceability) : 기능에 대한 요구사항의 출처, 관련 시스템 등의 관계를 파악할 수 있도록 작성

 

◈ 재사용(Reuse)

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

  - 누구나 이해할 수 있고 사용이 가능하도록 사용법 공개

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

  - 재사용 규모에 따른 분류

   * 함수와 객체 : 클래스나 메소드 단위의 소스 코드를 재사용

   * 컴포넌트 : 컴포넌트 수정 없이 인터페이스를 통해 통신하는 방식

   * 애플리케이션 : 공통된 기능을 제공하는 애플리케이션을 공유

 

◈ 효과적인 모듈 설계 방안

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

  - 모듈의 제어 영역 안에서 그 모듈의 영향 영역을 유지

  - 복잡도와 중복성을 줄이고 일관성 유지

  - 모듈의 기능은 예측이 가능해야 하며 지나치게 제한적이어서는 안 됨

  - 유지보수가 용이해야 함

  - 모듈 크기는 시스템의 전반적인 기능과 구조를 이해하기 쉬운 크기로 분해

  - 단일 입구와 단일 출구를 갖도록 설계

  - 모듈 인터페이스를 설계

 

025 코드

◈ 코드(Code)의 개요 

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

  - 코드는 정보를 신속, 정확, 명료하게 전달

  - 일정한 규칙에 따라 작성, 정보 처리의 효율과 처리된 정보의 가치에 영향을 미침

  - 코드의 주요 기능

   * 식별 기능 : 데이터 간의 성격에 따라 구분

   * 분류 기능 : 특정 기준이나 동일한 유형에 해당하는 데이터를 그룹화

   * 배열 기능 : 의미를 부여하여 나열

 

◈ 코드의 종류

 1) 순차 코드(Sequence Code)

  - 자료의 발생 순서, 크기 순서 등 일정 기준에 따라서 최초의 자료부터 차례로 일련번호를 부여하는 방법

  - 순서 코드 또는 일련번호 코드

  - ex) 1, 2, 3, 4...

 2) 블록 코드(Block Code)

  - 코드화 대상 항목 중에서 공통성이 있는 것끼리 블록으로 구분하고, 각 블록 내에서 일련번호를 부여하는 방법

  - 구분 코드

  - ex) 1001~1100 : 총무부, 1101~1200 : 영업부

 3) 10진 코드(Decimal Code) 

  - 코드화 대상 항목을 0~9까지 10진 분할하고, 다시 그 각각에 대하여 10진 분할하는 방법을 필요한 만큼 반복하는 방법

  - 도서 분류식 코드

  - ex) 1000: 공학, 1100 : 소프트웨어 공학, 1110 : 소프트웨어 설계

 4) 그룹 분류 코드(Group Classification Code)

  - 코드화 대상 항목을 일정 기준에 따라 대분류, 중분류, 소분류 등으로 구분하고, 각 그룹 안에서 일련번호를 부여하는 방법

  - ex) 1-01-001 : 본사-총무부-인사계, 2-01-001 : 지사-총무부-인사계

 5) 연상 코드(Mnemonic Code)

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

  - ex) TV-40 : 40인치 TV

 6) 표의 숫자 코드(Significant Digit Code)

  - 코드화 대상 항목의 성질의 물리적 수치를 그대로 코드에 적용시키는 방법

  - ex) 120-720-1500 : 두께*폭*길이가 120*720*1500인 강판

 7) 합성 코드(Combined Code)

  - 필요한 기능을 하나의 코드로 수행하기 어려운 경우 두 개 이상의 코드를 조합하여 만드는 방법

  - ex) KE-711 : 대한항공 711기, AC-253 : 에어캐나다 253기

 

◈ 코드 부여 체계

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

  - 각 개체에 유일한 코드를 부여해 개체들의 식별 및 추출을 용이하게 함

  - 코드를 부여하기 전에 각 단위 시스템의 고유한 코드와 개체를 나타내는 코드 등이 정의되어야 함

  - 코드 부여 체계를 담당하는 자는 코드의 자릿수와 구분자, 구조 등을 상세하게 명시해야 함

 

026 디자인 패턴

◈ 디자인 패턴(Design Pattern)의 개요
  - 각 모듈의 세분화된 역할이나 모듈들 간의 인터페이스와 같은 코드를 작성하는 수준의 세부적인 구현 방안을 설계할 때 참조할 수 있는 전형적인 해결 방식 또는 예제

  - 디자인 패턴은 재사용할 수 있는 기본형 코드들이 포함

  - 개발 과정 중에 문제가 발생하면 문제에 해당하는 디자인 패턴을 참고하여 적용

  - 한 패턴에 변형을 가하거나 특정 요구 사항을 반영하면 유사한 형태의 다른 패턴으로 변화되는 특징
  - GoF(Gang of Four)의 디자인 패턴은 가장 일반적인 사례에 적용될 수 있는 패턴들을 분류하여 정리
  - GoF의 디자인 패턴은 유형에 따라 생성 패턴 5개, 구조 패턴 7개, 행위 패턴 11개 총 23개의 패턴으로 구성됨 

  - 아키텍처 패턴 vs 디자인 패턴     

   * 아키텍처 패턴은 디자인 패턴보다 상위 수준의 설계에 사용됨 

   * 아키텍처 패턴 : 전체 시스템의 구조를 설계하기 위한 참조 모델 

   * 디자인 패턴 : 서브시스템에 속하는 컴포넌트들과 그 관계를 설계하기 위한 참조 모델 

   * 몇몇 디자인 패턴은 특정 아키텍처 패턴을 구현하는데 유용하게 사용됨

 

◈ 생성 패턴(Creational Pattern)

  - 객체의 생성과 관련된 패턴

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

 1) 추상 팩토리(Abstract Factory)

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

  - 연관된 서브 클래스를 묶어 한 번에 교체 가능

 2) 빌더(Builder)

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

  - 객체의 생성 과정과 표현 방법을 분리하여 동일한 객체 생성에서도 서로 다른 결과를 만들어 냄

 3)  팩토리 메소드(Factory Method)

  - 객체 생성을 서브 클래스에서 처리하도록 분리하여 캡슐화

  - 상위 클래스에서 인터페이스만 정의하고 실제 생성은 서브 클래스가 담당

 4) 프로토타입(Prototype)

  - 원본 객체를 복제하는 방법으로 객체를 생성

  - 일반적인 방법으로 객체를 생성하고 비용이 큰 경우 주로 이용

 5) 싱글톤(Singleton)

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

  - 클래스 내에서 인스턴스가 하나뿐이고 불필요한 메모리 낭비 최소화

 

◈ 구조 패턴(Structural Pattern)

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

  - 구조가 복잡한 시스템을 개발하기 쉽게 만들어 줌

 1) 어댑터(Adapter)

  - 호환성이 없는 클래스들의 인터페이스를 다른 클래스가 이용할 수 있도록 변환

  - 클래스를 이용하고 싶지만 인터페이스가 일치하지 않을 때 이용

 2) 브리지(Bridge)

  - 구현부에서 추상층을 분리해 서로가 독립적으로 확장할 수 있도록 구성

  - 기능과 구현을 두 개의 별도 클래스로 구현

 3) 컴포지트(Composite)

  - 여러 객체를 가진 복합 객체와 단일 객체를 구분 없이 다루고자 할 때 사용

  - 객체들을 트리 구조로 구성하여 복합 객체 안에 복합 객체가 포함되는 구조를 구현

 4) 데코레이터(Decorator)

  - 객체 간의 결합을 통해 능동적 기능들을 확장

  - 임의의 객체에 부가적인 기능을 추가하기 위해 다른 객체들을 덧붙이는 방식

 5) 퍼싸드(Facade)

  - 복잡한 서브 클래스들을 피해 더 상위에 인터페이스를 구성함으로써 서브 클래스들의 기능을 간편하게 사용

  - 서브 클래스들 사이의 통합 인터페이스를 제공하는 래퍼 객체 필요

 6) 플라이웨이트(Flyweight)

  - 인스턴스가 필요할 때마다 매번 생성하는 것이 아니고 가능한 한 공유해서 사용함으로써 메모리를 절약

  - 다수의 유사 객체를 생성하거나 조작할 때 사용

 7) 프록시(Proxy)

  - 접근이 어려운 객체와 여기에 연결하려는 객체 사이에서 인터페이스 역할 수행

  - 네트워크 연결, 메모리의 대용량 객체로의 접근 등에 사용

 

◈ 행위 패턴(Behavioral Pattern)

  - 클래스나 객체들이 서로 상호작용하는 방법이나 책임 분배 방법을 정의

  - 하나의 객체로 수행할 수 없는 작업을 여러 객체로 분배하면서 결합도를 최소화할 수 있도록 도와줌

 1) 책임 연쇄(Chain of Responsibility)

  - 요청을 처리할 수 있는 객체가 둘 이상 존재하여 한 객체가 처리하지 못하면 다음 객체로 넘어가는 형태

  - 요청을 처리할 수 있는 객체들이 고리로 묶여 있어 요청이 해결될 때까지 고리를 따라 책임이 넘어감

 2) 커멘드(Command)

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

  - 요청에 사용되는 각종 명령어들은 추상 클래스와 구체 클래스로 분리하여 단순화

 3) 인터프리터(Interpreter)

  - 언어에 문법 표현을 정의

  - SQL이나 통신 프로토콜과 같은 것을 개발 시 사용

 4) 반복자(lterator)

  - 자료 구조와 같이 접근이 잦은 객체 대해 동일한 인터페이스를 사용하

  - 내부 표현 방법이 노출 없이 순차적인 접근 가능

 5) 중재자(Mediator)

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

  - 객체 사이의 의존선을 줄여 결합도를 감소

 6) 메멘토(Memento)

  - 특정 시점에서의 객체 내부 상태를 객체화함으로써 이후 요청에 따라 객체를 해당 시점의 상태로 돌릴 수 있는 기능을 제공

  - Ctrl+Z와 같은 되돌리기 기능을 개발할 때 주로 사용

 7) 옵서버(Observer)

  - 한 객체의 상태가 변화하면 객체에 상속되어 있는 다른 객체들에게 변화된 상태를 전달

  - 분산된 시스템 간에 이벤트 생성, 발생, 수신해야 할 때 이용

 8) 상태(State)

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

  - 객체 상태를 캡슐화하고 이를 참조

 9) 전략(Strategy)

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

  - 클라이언트는 독립적으로 원하는 알고리즘을 선택하여 사용하고 클라이언트에 영향 없이 알고리즘 변경이 가능

 10) 템플릿 메소드

  - 상위 클래스에서 골격을 정의하고, 하위 클래스에서 세부 처리를 구체화하는 구조

  - 유사한 서브 클래스를 묶어 공통된 내용을 상위 클래스에서 정의함으로써 코드 양을 줄이고 유지 보수 용이

 11) 방문자(Visitor)

  - 각 클래스들의 데이터 구조에서 처리 기능을 분리하여 별도의 클래스로 구성

  - 분리된 처리 기능은 각 클래스를 방문하여 수행