Software Architecture

    [S/W Architecture] Pipe and Filter Architecture

    [S/W Architecture] Pipe and Filter Architecture

    Data flow Architecture에는 Batch Sequential, Pipe and Filter, Process Control Architecture 로 3가지로 분류할 수 있습니다. 그 중 Pipe and Filter Architecture에 대해 정리해보려 합니다. Pipe and Filter Architecture는 데이트 스트림을 처리하는 시스템을 위한 구조를 제공합니다. 데이터를 처리하는 각 프로세싱 단계는 Filter 컴포넌트 내부에 포함되어 있습니다. 데이터는 Filter 사이를 Pipe를 통해 전달되게됩니다. 이러한 구조로 인해 Pipe and Filter Architecture는 Batch Sequential Architecture와 많이 비교됩니다. Batch Sequentia..

    [S/W Architecture] Batch Sequential Architecture

    Batch Sequential Architecture에 대해 정리해보겠습니다. Batch Sequential Architecture는 이전 글에서 정리한 Data Flow Software Architecture 중 하나입니다. 참고가 필요하신 분은 해당 글을 확인해주세요. 2019/03/10 - [Developer's Delight/Software Architecture] - [S/W Architecture] Data Flow Software Architectures Batch Sequential Architecture는 1950~70년대에 많이 사용된 데이터 처리 모델입니다. 데이터는 하나의 서브시스템에서 다음 서브시스템으로 데이터로 전달됩니다. 각 데이터 전송 서브시스템 또는 모듈은 이전 서브시스템의..

    [S/W Architecture] Data Flow Software Architectures

    Data Flow Software Architecture에 대해 정리해보고, 해당 아키텍처에 속하는 이키텍처들을 정리해 보려합니다. 주제에서 알 수 있듯이 데이터의 흐름에 대한 소프트웨어 아키텍처입니다. Data Flow Software Architecture는 전체 소프트웨어 시스템을 연속적인 데이터 집합에 대한 일련의 변환으로 봅니다. 소프트웨어 시스템은 데이터가 데이터 연산 처리 순서를 지시하고 제어하는 데이터 처리 요소로 분리 될 수 있습니다. 각 컴포넌트는 입력으로 데이터를 받고, 출력으로 연산된 데이터를 출력합니다. 이렇게 출력된 연산 데이터는 다음 컴포넌트의 입력이 됩니다. 이 부분이 Data Flow Software Architecture 들의 가장 큰 특징입니다. 데이터를 처리하는 각 서..

    [Requirements Engineering] #3 Feasibility

    Feasibility Study Why a Feasibility Study?Feasibility(실행가능성)는 시스템 개발 프로젝트를 할 수 있는지 없는지는 판단하기 위함입니다. 프로젝트 시작 전 이 프로젝트를 우리가 할 수 있는가? 다른 가능한 대안이 있는가?에 대해 질문을 던지는 것입니다. 위 질문을 답하기 위해 충분한 정보를 수집하여 알고있어야 합니다. Feasibility Study 이후에 이 프로젝트의 START/STOP 여부를 결정하게 됩니다. Content of Feasibility Study(실행가능성 판단을 위한 컨텐츠)Feasibility 판단을 위해 파악해야 할 항목은 여러 가지입니다. 항목은 아래 리스트를 참고하세요.- 존재하는 시스템들- 현재 시스템의 문제- 새로운 시스템을 위한 ..

    [Requirements Engineering]  #1 Overview

    [Requirements Engineering] #1 Overview

    시스템 아키텍쳐에서 필수적인 것이 무엇을 설계할 것인가 입니다. 막연히 뭘 설계 개발해야할지 모르는 상황에서 컴퓨터 앞에 앉는 행위는 어리석은 행동입니다. 클라이언트가 어떠한 것을 요청하는지 파악해야 설계를 할 수 있습니다. 아래는 많이 보셨을 그림입니다. 고객이 설명한 것을 시스템에 관련된 이해관계자들이 이해하고 만들어나가는 과정입니다. 실제로 고객이 원하는건 나무에 타이어 하나 매달아 그네를 쓰고자 했는데 결과물은 전혀 다른 것이 나왔습니다. 이 그림은 시스템 개발 시 발생할 수 있는 문제를 웃음으로 승화시킨 그림인데요, 정말 웃고 지나갈만한 일일까요? 위와 같은 문제는 자주 발생할 수 있습니다. 이러한 문제를 방지하고 영향을 최소화 하기위해 요구공학이란 학문이 존재합니다. 실제로 클라이언트와의 미팅..

    [Design Pattern] Adapter Patter

    [Design Pattern] Adapter Patter

    Adapter Pattern은 wrapper라고도 많이 불립니다. 어댑터라는 용어는 많이 들어보셨을 겁니다. '돼지코' 를 크게 예로 들 수 있을텐데요. 위키피디아에 설명된 정의는 아래와 같습니다. 어댑터 패턴(Adapter pattern)은 클래스의 인터페이스를 사용자가 기대하는 다른 인터페이스로 변환하는 패턴으로, 호환성이 없는 인터페이스 때문에 함께 동작할 수 없는 클래스들이 함께 작동하도록 해준다. Adapter 패턴은 기존에 지원하는 인터페이스 이외 다른 인터페이스 형태로 맞춰주기 위해 자주 사용됩니다. 클라이언트가 사용하는 타겟 인터페이스와 다른 인터페이스를 제공하는 모듈을 사용하고자 할 때 중간에 Adapter를 추가하여 기존에 사용하던 인터페이스와 동일한 형태로 제공받아 사용할 수 있습니다..