소프트웨어공학 - 아키텍처 설계

소프트웨어 설계 : 어떠한 소프트웨어를 만들기 위해서 하는 모든 설계들 (아키텍처 설계 -> 인터페이스 설계 -> 컴포넌트 선택 및 설계, 데이터베이스 설계는 별도 병행)

 

현실적으로 위와 같은 순차적 설계는 어려움. 비기능 요구사항(성능,보안, 유지보수성)을 만족시키기 위해 설계 내용의 반복적 수정 필요

 

아키텍처 설계 : 시스템을 구성하는 주요 컴포넌트를 도출하고, 컴포넌트간의 관계를 정의 (시스템의 큰 구조)

 

1) 주요 컴포넌트를 도출하고

2) 컴포넌트 간 관계 정의

3) 구체적인 구조화 전략(아키텍처 스타일 또는 아키텍처 패턴 == 기능/비기능요구사항 달성을 위한 가장 기본적인 전략) 확립

 

포함되지 않는 것 : 각 컴포넌트의 구체적인 내부 구조

`시스템 모델링과의 차이?` :  아키텍처 설계 단계에서는 구체적인 구조화 전략(아키텍처 패턴)을 확립.

시스템 모델링 : 시스템이 해야할일과 외부내부 요소 간 상호작용 정리 -> 컨텍스트모델, 구조모델, 동작모델

 

소프트웨어 아키텍처 = sw 시스템의 고수준 구조. 주요 컴포넌트. 관계, 구조화 전략 표현. 아키텍처<->비기능요구사항 서로 영향

아키텍처 모델 : 최종 산출물, 설계 중 의사소통/ 설계 결과 문서화에 활용 using 블록 다이어그램(주요컴포넌트/관계), UML표준X

아키텍처 설계 정해진 방법은 없다. -> 시스템 유형/요구사항 고려하여 결정. 

 

# 아키텍처 패턴

다양한 소프트웨어 시스템에서 성공적으로 사용된 구조화전략에 대한 고수준 가이드

특정문제를 해결하는데 적합한 시스템 컴포넌트배치&관계설정에 대한 고수준 명세

전략, 적용 가능한 상황, 장점, 단점 등을 일반적인 수준(추상)에서 기술. => 구체적인 사례가 없다면 접근법 알 수 없다.

 

애플리케이션 아키텍처

특정 app 설계에 아키텍처 패턴 적용해 도출한 구체적인 설계 결과. 동유형 &유사 기능 app 설계에 재사용 가능

다만, 그대로 적용하는 것이 아닌 참고하되 특성맞게 변형하여 적용한다.

 

#1. 클라이언트-서버 아키텍처 패턴

서버들의 집합(서비스 제공), 클라이언트들의 집합(서비스요청), 네트워크(연결)의 세가지 컴포넌트로 시스템 구성

WHEN : 공유데이터베이스 여러지역의 접근, 시스템 부하 변동 클 때(서버 중복배치 부하분산)

 

`pros` :

분산 아키텍처 -> 확장성&유지보수성 좋음. 

네트워크 상에 분산되어있는 서버의 기능을 클라이언트가 활용 -> 클라이언트 개발 부하 감소

`cons` :

클라이언트-서버 간 통신속도&안정성 따라 전체시스템 성능 영향

서버가 서로 다른 기관에 있다면 관리/보안/유지보수 복잡

 

#2. MVC (Model View Controller) 패턴 : 현대적관점

데이터(Model), 데이터를 보여주는 방법(View), 사용자상호작용관리(Controller)의 세가지 컴포넌트로 분리해 구조화

WHEN : 같은 데이터를 보여주는 방식(View)가 여러가지 필요할때 (같은정보 -> 그래프,표,리스트 )

`pros` 

• 데이터(Model)와 화면(View)를 분리 ->  UI 변경이 비즈니스 로직에 영향 X
• Model은 다양한 Controller와 View에서 공유 또는 재사용 가능
• 각 레이어가 독립적이기 때문에 유지보수 용이
• 비즈니스 로직의 독립적 테스트 가능

`cons` 

• 구조가 단순한 프로그램에서는 부담 -> 코드가 복잡해지고 불필요하게 커짐

스스로 정리해보아욤

 

• M (Model): 데이터와 비즈니스 로직 담당. (Entity, Dto, Service)
• V (View): 사용자에게 보여지는 화면,
    Controller가 전달한 데이터를 렌더링해서 브라우저에 보여줌(HTML, CSS, JS, Thymeleaf, JSP
• C (Controller): 요청을 받아서 Model과 View를 연결해주는 역할
  클라이언트로부터 HTTP 요청->Service를 호출해 비즈니스 로직 수행->처리 결과를 Model에 담아 View로 전달 (또는 JSON 응답으로 반환)

예시1) 온라인 쇼핑몰 웹 애플리케이션

M : 상품정보객체, DB접근 객체, 장바구니 상태 및 주문 내역 관리기능

V : 서버측 View : 상품리스트/장바구니/주문확인화면 생성하는HTML템플릿 
    <=> 클라이언트측 View: 브라우저가 전송받은 HTML을 렌더링하여 사용자에게 보여주는 화면

C : 사용자가 버튼클릭->모델 갱신->모델에서 데이터 가져와 html 템플릿 적절히 넣어 완전하게 생성 -> 클라이언트 전달

 

 

뷰 는 서버와클라이언트양쪽에 존재. DB는웹애플리케이션과연동되는서브시스템으로, MVC 패턴의구성요소는아님

예시2 ) GUI 계산기 프로그램

M : 연산결과 데이터, 연산처리로직(서비스)

V : GUI 화면(버튼,디스플레이)

C : 버튼 클릭 이벤트를 받아 모델에 연산 수행 지시 & 모델 연산결과 기반 view 업데이트

작은규모의GUI → 컨트롤러는이벤트핸들러(독립컴포넌트 X)

큰규모의GUI (오피스등) →컨트롤러를명확한독립컴포넌트 O 분리가능.

 

예시3) 콘솔 주소록 프로그램

M : 연락처데이터 추가/삭제/수정/조회 로직

V : 콘솔화면 출력

C : 사용자 명령(추가,삭제 조회 등) 받아 모델 전달(단순조건문으로 구현), 모델 처리결과 view에 업데이트 전달

 

#3. 계층 아키텍처 패턴

시스템을 분리된 계층들로 구성. 각 계층은 관련기능 수행하며 상위 계층에 서비스를 제공. (== 상위계층은 하위 계층에 의존!!) (역은 성립하지않음)

가장 아래 계층은 시스템 전체에서 사용되는 핵심 서비스. 계층 간 인터페이스 명확하게 해 모듈화/유지보수성/재사용성 확보

 

WHEN : 새로운 기능을 기존 시스템 위에 구축할 때, 개발을 여러팀으로 하고 각 팀이 기능계층에 대한 책임이 있을 때. 다중수준 보안 필요할 때.

`Pros`

• 각 계층이 명확한 인터페이스를 제공 하면 특정 계층을 새 구현으로 바꿔도 나머지 계층은 영향X
  -> DB접근계층을 SQLite-->MySQL로 바꿔도 상위 애플리케이션 로직은 그대로 유지
• 안전성 확보를 위해 여러 계층에서 동일 기능 제공 가능 -> 인증을 매 계층마다 처리함으로써 안전성 확보

`Cons`

• 현실에서는 계층을 완전히 독립적으로 분리하는 것이 어려운 경우도 많음
• 상위 계층이 바로 아래의 하위 계층을 건너뛰고 다른 계층에 접근해야 하는 경우도 발생
• 서비스 요청이 여러 계층을 거치면서 처리되므로, 계층 수가 많으면 지연 발생 가능

계층 아키텍처 패턴은 목표시스템의 범위와 크기에 구애받지 않고 적용 가능

스마트워치 앱,웹 애플리케이션, 종합 소프트웨어 플랫폼 (OS, 런타임, 애플리케이션 프레임워크), 네트워크프로토콜 ...

예시1) 보행자.자전거 내비게이션, 스마트워치 인터페이스

예시2) iLearn 시스템 아키텍처

예시3) 안드로이드 플랫폼 아키텍처

예시4) 통신 프로토콜 스택

 

#4. 저장소 아키텍처 패턴

모든 데이터를 모든 컴포넌트들이 접근할 수 있는 하나의 중앙 저장소에서 관리 (논리적으로 하나로인식가능하다? 물리적으로 분산 DB 도입 가능)

각 컴포넌트들은 직접 서로 상호작용X, 저장소를 통해서만 데이터를 주고받음.

-> 저장소(DB)를 단순 데이터 저장용도로 사용하는게 아니다. 이는 저장소 아키텍처 패턴이 아님!!!

-> 컴포넌트 간의 '상호작용' or '통신'이 중앙저장소를 통해 이루어진다.

 

WHEN : 대량의 데이터를 장기간 저장하는 시스템 , 데이터 추가 시 다른컴포넌트가 자동으로 반응해야하는 시스템(데이터 주도 시스템)

 

`Pros`

• 각 컴포넌트가 다른 컴포넌트를 몰라도 됨(컴포넌트 독립성) -> 유지보수성 향상, 재사용성 증가, 테스트 용이, 시스템 확장성 확보
• 한 컴포넌트가 저장소의 데이터를 바꾸면, 다른 컴포넌트도 최신 데이터 이용 가능
• 모든 데이터가 한 곳에서 관리 -> 백업, 복제, 동기화 용이

`Cons`

• 저장소 문제 발생 시, 전체 시스템에 영향(저장소가 single point of failure)
• 모든 통신이 저장소를 거치므로 처리 지연 발생 가능
• 저장소를 여러 컴퓨터에 분산시키는 것이 복잡

예시1) 능동형 ECG 모니터링 시스템(개인작업, 실험용) -- MySQL 데이터베이스를 [빅데이터기반실시간학습시스템/딥러닝 기반 실시간 모니터링 시스템/ 이벤트폴링시스템]의 병행 동작 제어 자체에 활용

예시2) 모델주도공학을 지원하는 IDE -- 각 프로젝트 저장소가 각 컴포넌트 제어에 활용되는 것은 아님.(다만 컴포넌트 간 통신 발생 X, 각 컴포넌트가 저장소 스키마에 적합하게 동작함으로써 전체 IDE 기능 완성) 

예시3) 컴파일러 - 명시적인 데이터베이스가 아닌, 공유 데이터 구조에 기반한 저장소 아키텍처 설계도 가능하다!

 

 

#5. 파이프 필터 아키텍처 패턴

 데이터 처리과정을 독립적인 단계(필터)로 나누고, 데이터가 단계를 따라 처리되고 전달되어 흐르는(파이프) 구조. 

각 필터는 독립적인 컴포넌트로 간주

 

WHEN : 데이터가 연속적으로 처리되어야 할 때, 처리 단계가 독립적이며 재사용 가능할 때(컴파일러, 일괄 처리 시스템, 빅데이터 분석 파이프라인, 스트림 처리 등)

 

`Pros`

• 각 처리단계(필터)가 독립적 -> 재사용/ 유지보수 용이
• 데이터 흐름이 명확 -> 이해 및 확장 용이
• 단계의 추가/변경이 상대적으로 쉬움

`Cons`

• 각 단계(필터) 간 데이터 전달 비용(자원 사용, 포맷 변환 등) -> 성능 저하 우려
• 상태 공유나 복잡한 상호작용에는 부적합
• 필터 수가 많으면 관리 및 디버깅 어려움

 

예시1) 컴파일러

예시2) 송장 및 지불 일괄 처리 시스템

예시3) 빅데이터 분석 파이프라인(스파크 RDD 기반 스트림 처리 등)

 

======================================================================

이해되었나요?

1. 소프트웨어 설계 활동을 구성하는 세부활동과 특성?

=> 아키텍처 설계, 인터페이스 설계, 컴포넌트 설계, 데이터베이스 설계 특성: 순차적으로 이뤄지지않음? 상호 피드백이 존재한다?

2. 아키텍처 설계와 시스템 모델링의 차이는?

=> 아키텍처는 큰그림을 그리지만, 시스템 모델링은 각 모델이 수행하는 시스템적인 처리를 말한다. 

3. 아키텍처패턴과 애플리케이션아키텍처의개념?

=>아키텍처 패턴은 다양한 소프트웨어시스템에서 성공적으로 사용된 구조화전략의 고수준 가이드이다.

4. 대표적인아키텍처 패턴의종류, 용도, 장단점?

=> 클라리언트-서버 패턴 : 클라이언트, 서버, 네트워크 컴포넌트로 구성됨. 

=> MVC패턴

=> 계층 아키텍처 패턴

=> 저장소 아키텍처 패턴

=> 파이프 필터 아키텍처 패턴

5. 웹애플리케이션 동작 개요 및 아키텍 패턴 관점의이해?

얘는 모르겠는걸 모지