[소프트웨어공학] #6 Architectural Design

11/28

 

Architecture란 뼈대, 골격 역할

Component: 가장 기본적 기능을 포함하는 단위. 명백한 역할을 가지고 독립적으로 존재할 수 있는 시스템의 부분.

Module: 문법구조에서 정의된 컴포넌트(클랫, 패키지, 메서드)

Subsystem: 여러개의 컴포넌트로 구성된. 여러 다른 방법으로 구현될 개체

 

6-1: Architectural Design

전체적 구조를 어떻게 구성하고 설계할지

설계와 요구사항 공학 사이의 중요한 연결점.(원래는 더 먼저 해야함)

-주요 구조적 component들을 식별하고 그들 사이의 관계를 정의

정형화된 틀이 없어서 자유로운 형식

 

전체적인 시스템 architecture는 구성하고 들어간다.(Agile 조차도)

Refactoring하는것은 엄청난 비용이 들어간다.

 

Architectural abstraction

(작은 경우) 독립적인 부분

(큰 경우) 여러 시스템이 맞물림

 

장점

Stakeholder communication: 시스템 stakeholder와 논의에 초점

System analysis: 비기능 요구사항이 실현 가능한지 분석

Large-scale reuse: 시스템 범위에서 재사용.

 

엔티티와 관계를 보여주는 비정형화 블록 다이어그램은 문서화 소프트웨어 Architecture를 사용

그러나 의미적인게 부족해질 수 있음. 엔티티 사이의 관계의 종류와 엔티티의 가시적인 property 같은..

architecture model의 사용에 의존

의사가 잘 전달되도록..

 

Box and line diagram

=엄청난 추상화(장점이자 단점)

-stakeholder와 소통에는 유용.

 

시스템 설계에 대한 facility discussion

-고수준의 architectural 관점. 시스템 stakeholder와의 소통 및 프로젝트 계획에 유용. 

-stakeholder는 시스템의 추상적인 관점 이해.

 

설계할 architecture에 대한 documenting

-다른 component들을 보여주는 완벽한 시스템 모델 생성을 목표로.

 

6-2: Architectural Design Decision

창의적인 일. 개발되는 시스템의 종류에 프로세스가 의존

많은 일반적인 결정들은 모든 설계 프로세스들을 생성하고, 이 결정들은 시스템의 비기능적  사항에 영향.

 

Architectural Reuse(재사용)

같은 도메인의 시스템은 도메인의 컨셉을 반영하여 비슷한 architecture를 가지게 됨.

Application 생성 라인들은 core architecture와 개별 고객 요구를 만족하는 다양한 것들로 이루어짐.

시스템의 architecture는 하나 이상의 architectural 패턴이나 'style'들로 설계된다.

 

성능/보안/안전/가용성/유지성/

 

6-3: Architectural View

view 또는 perspective는 시스템 architecture에 대한 문서화와 설계에 유용하다.

어떤 notation이 architectural model을 서술하는데 사용되는가.

각 model은 시스템의 한 view/perspective만 보여줌

-시스템이 어떻게 모델로 분해되는지.

-런타임 프로세스들이 어떻게 상호작용하거나 시스템 component들이 네트워크에 어떻게 분포하는지

-설계와 문서화 양쪽에 대해 소프트웨어 architecture의 다양한 관점을 볼 필요가 있을 때.

 

Logical View: 시스템 내의 객체 또는 객체 클래스로의 주요 추상화를 보여줌

Physical View: 런타임에서 어떻게 시스템이 상호작용 프로세스들을 구성하는지 보여줌

Process View : 소프트웨어가 개발로 어떻게 분해되는지 보여줌.

Development View: 시스템 하드웨어와 어떻게 소프트웨어 component가 시스템 내의 프로세서들에 분포하는지 보여줌.

 

Module view/component view/work assignment view

 

Architectural view의 표현

-UML이 좋다고 하는 사람도 있고

-저자는 UML이 고수준 시스템 서술에 대한 적절한 추상화를 포함한다고 생각하지 않음

-Architectural description languages(ADL)도 있으나 넓게 이용되진 않음.

 

 

 

6-4: Architectural Patterns

패턴이란, 표현되고, 공유되고, 재사용되는 지식을 의미.

Architectural pattern이란 좋은 설계 예제의 스타일화된 서술

패턴은 언제 유용하고 또 그렇지 않은지에 대한 정보를 포함.

 

MVC(Model View Controller) 패턴

-시스템 데이터에서 발표와 상호작용으로 나눔

-3개의 논리적 component들로 나눔.(서로 상호작용)

Model component: 시스템 데이터를 관리하고 그 데이터에 대한 관련 작업을 연결

View component: 어떻게 데이터가 사용자에게 표현되는지 정의하고 관리

Controller component: 사용자 상호작용을 관리하고 View와 Model에 이 상호작용을 전달

 

언제 사용하는가: 정의가 명확하지 않을 때(다양한 view와 상호작용 데이터로). 상호작용과 알수 없는 데이터 표현에 대한 미래의 요구사항이 사용될 때.

장점: 데이터를 독립적으로 바꿀 수 있음. 같은 데이터를 다른 방법으로 표현할 수 있음.

단점: 데이터 모델과 상호작용이 간단할 때, 추가적인 코드와 코드 복잡성이 포함될 수 있다.

Layered Architecture

sub 시스템과 상호작용하는 모델 사용

시스템을 layer의 집합으로 조직

sub시스템들을 다른 레이어에 증분적 개발 지원.

그러나 종종 인공적으로 이런 시스템을 구성

 

관련된 기능끼리 layer에 시스템을 조직.

layer는 위쪽 layer에 기능을 제공. 그리하여 lowest layer는 코어 서비스를 제공.

 

언제 사용하는가: 새로운 시설을 제작-존재하는 시스템 top에. 개발이 여러 팀에 뿌려져있을때, 각 팀이 기능적 레이어에 응답. 다중 레벨 보안 요구.

장점: 모든 layer들을 대체할 수 있음. 인터페이스는 유지. 각 레이어에 있는 중복 시설도 시스템의 의존성을 높임

단점: 명확한 layer의 구분이 어려움을 낳을수도. 높은 layer가 낮은 층에 바로 소통할 수 없음. 다 하려다가 overhead걸리기도.

 

Repository Architecture

sub시스템은 데이터를 반드시 교환한다.

두가지 형태로 이뤄짐

-공유된 데이터는 중앙 DB나 repo.에 있고, 모든 sub시스템이 접근 가능

-각 sub시스템은 고유의 DB를 유지하고, 데이터를 명시적으로 sub시스템에 보낸다.

너무 큰 데이터가 공유되면-공유되는 repository model은 이것을 일반적으로 사용. 효과적인 데이터 공유 메커니즘.

 

중앙 repo.가 필요할지도.

component는 직접적 소통이 없음. repo.를 통해서만 가능

 

언제 사용하는가: 큰 크기의 정보가 생성되고, 오래 저장되야하는 경우. data-driven 시스템에서 action이나 tool에 반응하여 repo.안에 데이터를 포함하려고 할 때.

장점: 나머지가 독립적이면 각 component의 구성은 알바가 아니다. 하나의 변경이 다른 것에 다 알려줘야하는 경우. 데이터가 일관성을 가지고 관리하는 경우

단점: repo가 실패의 한 부분->repo.의 문제가 전체 시스템에 영향. 모든 소통이 repo.를 통하는 것은 비효율적일수도. 여러 컴퓨터를 통해 repo.를 분산시키는 것은 어려움.

 

Client-Server

분산된 영역에서 서로 접근.

독립된 서버들의 집합으로 서비스 제공

client의 집합은 이 서버들을 호출 가능

네트워크가 client들이 서버에 접근하게 도움.

 

기능이 서버에 있다. client는 서버에 접근하여 서비스를 제공받음.

언제 사용하는가: 공유된 데이터. 지역적으로 흩어진 공간에서 같은 서비스를 제공하려 할 때.

장점: 서버가 분산되어있음. 일반적 기능이 필요는 하나 다 구현하지 않으려 할 때. 서버에 HW 용량을 몰빵.

단점: 서버 날라갈시 큰일난다. 성능이 보장되지 않음-네트워크 상태 및 시스템에 의존. 관리 문제.

 

Pipe and filter

기능적 형태

굉장히 일반적인 형태

반복적 시스템에는 그닥 안맞을 수도.

선형적인게 필요할 때. 단방향일 때 유용

 

시스템 내의 데이터 처리가 조직되어, 각 처리 component(filter)가 이산적이고 하나의 데이터 형태로 수행될 때.

한 component에서 다른 곳으로의 데이터 흐름(as in a pipe)이 처리될 때.

언제 사용하는가: 대용량 데이터 처리. 구분된 단계.

장점: 이해와 재사용이 쉬움. 많은 비즈니스 프로세스의 구조. 진화가 직렬적. sequential/concurrent 시스템처럼 구현할 수 있다.

단점: overhead 발생 가능. 적합하지 않은 데이터는 처리 못함.

 

6-5: Application Architectures

application: 대략 응용 프로그램

캠브릿지 사전에서는: 특별한 목적을 가지는 컴퓨터 프로그램

비슷한 요구사항은 패턴화

 

사용

시작지점이 만들어져있음->시작 지점 좋음

체크리스트 설계

개발팀 조직

재사용되는 component

용어사전도 그대로

 

종류

Data Processing: 데이터 처리 기반

Transaction processing: 데이터 기반+ 상호작용--쇼핑, 예약 등

Event Processing: 이벤트 기반. 이벤트 발생시의 변화

Language Processing: 언어처리 시스템--컴파일러, 인터프리터

 

Transaction: 하나의 동작처럼 실행되어야할 행동들의 집합

데이터 처리or요청

사용자의 다양한 동작을 처리할 수 있어야함.

 

Information System

레이어드 architecture

transaction 기반의 하나.

4개 단계(user interface/user communication/information retrieval/system database)

<예시 형태>

 

web-base information system

웹 기반으로 구현해야할 때.

인터넷 쇼핑몰

 

서버구현(사용자는 client로)

-웹 서버: 사용자의 소통

-어플리케이션 서버: 어플리케이션 특화 논리, 요청 검색

-DB: 정보 이동

 

Language processing system

자연어든 인공어든 하여튼 입력으로 받아서 원하는 결과 도출

컴파일러&인터프리터

문제를 해결하기 위한 알고리즘이나 시스템 데이터의 기술이 쉬운 경우에 사용

<구조>

 

컴파일러 구조

lexical analyzer: 입력된 언어 토큰들을 내부적 형태로 전환

symbol table: 정보를 담은 엔티티들 번역

syntax analyzer: 블록 구분

syntax tree: 트리를 어떻게 만들지

semantic analyzer: syntax tree나 syntax table에서 정보 이용하여 입력된 것과 의미가 같은지 확인

syntax tree: 코드 생성