[정처기] 소프트웨어 아키텍처

1. 소프트웨어 아키텍처

• 소프트웨어의 골격이 되는 기본 구조이자, 소프트웨어를 구성하는 요소들 간의 관계를 표현하는 시스템의 구조 또는 구조체이다.
• 소프트웨어 개발 시 적용되는 원칙과 지침이며, 이해 관계자들의 의사소통 도구로 활용
• 좋은 품질을 유지하면서 사용자의 비기능적 유구사항으로 나타난 제약을 반영하고, 기능적 요구사항을 구현하는 방법을 찾는 해결 과정이다.

 

2. 아키텍쳐 설계의 기본원리

 

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

• 자주 사용되는 계산식이나 사용자 인증과 같은 기능들을 공통 모듈로 구성하여 프로젝트의 재사용성을 향상 시킨다.
• 모듈 크기를 너무 작게 나누면 개수가 많아져 모듈간의 통합 비용이 많이 들고, 너무 크게 나누면 개수가 적어 통합비용은 적게 들지만 모듈 하나의 개발비용이 많이 든다.

2. 추상화 : 문제의 전체적이고 포괄적인 개념을 설계한 후 차례로 세분화하여 구체화 시켜 나가는 것

 

과정 추상화	자세한 수행 과정을 정의하지 않고, 전반적인 흐름만 파악할 수 있게 설계하는 방법
데이터 추상화	데이터의 세부적인 속성이나 용도를 정의하지 않고, 데이터 구조를 대표할 수있는 표현으로 대체하는 방법
제어 추상화	이벤트 발생의 정확한 절차나 방법을 정의하지 않고, 대표할 수 있는 표현으로 대체하는 방법

3. 단계적 방법 : 하향식 설계전략, 문제를 상위의 중요 개념으로부터 하위의 개념으로 구체화 시키는 분할 기법

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

 

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

 

4. 정보은닉 : 한 모둘 내부에 포함된 절차와 자료들의 정보가 감추어져 다른 모듈이 접근하거나 변경하지 못하도록 하는 기법

 

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

 

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

 

시스템측면

품질 속성	내용
성능	사용자의 요청과 이벤트가 발생했을 때. 이를 적절하고 빠르게 처리하는 것
보안	허용되지 않은 접근을 막고, 허용된 접근에는 적절한 서비스를 제공
가용성	장애 없이 정상적으로 서비스를 제공
기능성	사용자가 요구한 기능을 만족스럽게 구현
사용성	사용자가 소프트웨어를 사용하는데 헤매지 않도록 명확하고 편리하게 구현
변경 용이성	소프트웨어가 처음 설계목표와 다른 하드웨어나 플랫폼에서도 동작할 수 있도록 구현하는 것
확장성	시스템의 용량, 처리능력 등을 확장 시켰을 때 이를 효과적으로 활용할 수 있도록 구현
기타속성	테스트 용이성, 배치성, 안전성 등

 

비즈니스 측면

품질속성	내용
시장 적시성	정해진 시간에 맞춰 프로그램을 출시
비용과 혜택	개발비용을 더 투자하여 유연성이 높은 아키텍처를 만들 것인지를 결정하는 것 유연성이 떨어지는 경우 유지보수에 많은 비용이 소모될 수 있다는 것을 고려
예상 시스템 수명	시스템을 얼마나 오랫동안 사용할 것인지를 고려 수명이 길어야 한다면 시스템 품질의 변경용이성, 확장성을 중요하게 고려
기타 속성	목표시장, 공개일정, 기존 시스템과의 통합 등이 있다

아키텍쳐 측면

품질속성	내용
개념적 무결성	전체 시스템과 시스템을 이루는 구성요소들 간의 일관성을 유지하는 것
정확성, 완결성	요구사항과 요구사항을 구현하기 위해 발생하는 제약사항들을 모두 충족 시키는 것
구축 가능성	모듈 단위로 구분된 시스템을 적절하게 분배하여 유일하게 일정을 변경할 수 있도록 하는것
기타 속성	변경성, 시험성, 적응성, 일치성, 대체성 등이 있다

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

설계목표설정 -> 시스템 타입 결정 -> 아키텍처 패턴 적용 -> 서브시스템 구체화 -> 검토

 

 

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

 

장점

•  시행착오를 줄여 개발 시간을 단축시키고, 고품질의 소프트웨어를 생산할 수 있다.
•  검증도니 구조로 개발하기 때문에 안정적인 개발이 가능하다.
•  이해관계자들이 공통된 아키텍처를 공유할 수 있어 의사소통이 간편해진다.
•  시스템의 구조를 이해하는 것이 쉬워 개발에 참여하지 않은 사람도 손쉽게 유지보수를 수행할 수 있다.
•  시스템의 특성을 개발 전에 예측하는 것이 가능해진다.

 

아키텍처 패턴의 종류

레이어 패턴 (Layers pattern)	▶ 시스템을 계층(Layer)으로 구분하여 구성하는 고전적인 방법중의 하나 ▶ 각각의 서브 시스템들이 계층 구조를 이루며, 상위 계층은 하위 계층에 대한 서비스 제공자가 되고, 하위 계층은 상위 계층의 클라이언트가 된다. ▶ 서로 마주보는 두개의 계층 사이에서만 상호작용이 이루어지며, 변경 사항을 적용할 때도 서로 마주보는 두개의 계층에만 영향을 미치므로 변경 작업이 용이 ▶ 특정 계층만을 교체해 시스템을 개선하는것이 가능
클라이언트-서버 패턴 (Client-Server Pattern)	▶ 하나의 서버 컴포넌트와 다수의 클라이언트 컴포넌트로 구성되는 패턴이다 ▶ 클라이언트나 서버는 요청과 응답을 받기 위해 동기화 되는 경우를 제외하고는 서로 독립적
파이프-필터 패턴 (Pipe-Filter Pattern)	▶ 데이터 스트림 절차의 각 단계를 필터 컴포넌트로 캡슐화 하여 파이프 통해 데이터 전송 ▶ 재사용성이 좋고, 추가가 쉬워 확장이 용이 ▶ 데이터 변환, 버퍼링, 동기화 등 주로 사용
모델-뷰-컨트롤러 패턴 (Model-View-ControllerPattern	▶ 서브시스템을 3개의 부분으로 구조화하는 패턴 ▶ 모델 - 서브시스템의 핵심 기능과 데이터를 보관 ▶ 뷰 : 사용자에게 정보를 표시 ▶ 컨트롤러 : 사용자로부터 받은 입력을 처리