소프트웨어 아키텍처 설계

1. 아키텍처 설계 

 

 - 시스템 전체 구조를 설계 

 - 시스템의 주요 구조 컴포넌트(subsystem) 들과 상호작용하는 컴포넌트 간의 관계(interfaces)

 

주로 명시적 설계와 문서화를 통해 진행되며 상위 수준의 시스템 표현으로 이해당사자 간 의사소통에 도움을 주며 

비슷한 요구사항을 가진 시스템의 아키텍처를 재사용할 수 있다. 

 

2. 아키텍처와 시스템의 특성 

 

• 성능(performance) : 컴포넌트 간 통신을 줄임, 시스템 중복, 부하 분산
• 보안성(security) : 중요한 자산을 가장 안쪽 계층에 두는 계층구조 사용 
• 안전성(safety) : 안전 관련 작업을 소수의 컴포넌트에 배치하여 안전 검증과 대응을 간단하게 한다.
• 가용성(availability) : 중복 컴포넌트를 배치, 시스템 중단 없이 컴포넌트 교체 및 갱신
• 유지보수성(maintainability) : 변경이 용이한 독립적인 컴포넌트 사용 

 

3. 아키텍처 패턴

 

- 자주 발생하는 문제 (problem) 에 대한 해법(solution) 

 - 지식의 공유와 재사용을 목적으로 한다. 

EX) MVC 패턴 (Model-View-Controller) 

 

MVC 패턴

- 데이터로부터 표현과 상호 작용을 분리시켜 세 개의 논리적 컴포넌트로 구조화함, 모델은 데이터와 이에 대한 오퍼레이션을 관리, 뷰는 사용자에게 데이터를 표현하는 것을 관리, 제어기는 사용자 상호 작용을 관리하고 이를 뷰와 모델에 전달 

 

장점 

 - 데이터 표현과 무관하게 데이터를 변경할 수 있음, 동일한 데이터를 서로 다른 방법으로 표현하는 것을 지원, 뷰의 추가/변경이 쉽다.

 

단점

 - 데이터 모델과 상호 작용이 단순할 경우 불필요하게 코드가 복잡해질 수 있다.  

 

4. 소프트웨어 설계와 구현

 

 - 소프트웨어 설계와 구현은 실행 가능한 소프트웨어 시스템이 개발되는 소프트웨어 공학 프로세스 단계 

 

1. 설계 : 요구사항을 실현할 소프트웨어 컴포넌트들과 그들 간의 관계를 식별하는 행동 

2. 구현 :  설계를 프로그램으로 실체화시키는 활동 

 

• 결합도(coupling) : 컴포넌트간 의존도 ( 클래스, 함수, 모듈...), 개체 간 연결이 얼마나 강한지에 대한 척도 
• 응집도(cohesion) : 한 개체가 특정 목적 달성을 위하여 얼마나 집중하고 있는지에 대한 척도

소프트웨어 설계는 개체 간 낮은 결합도, 개체간 응집도를 높게 가지도록 설계하는 것이 좋다. 

 

결합도가 높은 경우 문제

1. 한 개체를 변경하였을 때 다른 개체들이 영향을 받을 가능성이 높다.

2. 시스템 유지보수 하기가 어렵다.

3. 한 개체를 분리하여 다른 곳에서 재사용하기 어렵다. 

 

응집도가 낮은 경우 문제

1. 특정 기능에 집중하지 않고 여러 기능이 모여있어 재사용이 어렵다.

2. 변화에 대하여 영향을 많이 받는다.

3. 개체의 응집도가 낮으면 다른 개체들과 결합도가 높아질 수 있다. 

 

5. 소프트웨어 테스팅 

 

 - 프로그램을 완성 후 사용하기 전에 결함을 발견하기 위함 

 

검증 테스팅(validation testing)	소프트웨어가 고객의 요구사항에 맞는지 테스트
결함 테스팅(defact testing)	소프트웨어의 버그에 의해 제대로 동작하지 않는 경우를 찾음

 

1. 소프트웨어 인스펙션

 - 요구사항, 설계, 소스코드를 분석하고 검사하여 문제를 찾음

 - 프로그램을 실행시키지 않고 확인한다. 

 

2. V & V 프로세스 ( Verification & Validation )

확인(validation)	소프트웨어가 고객의 기대에 맞는지 ( 요구사항 ) 보여준다.
검증(verification)	소프트웨어가 기능적/비기능적 요구사항 명세에 맞는지 점검

 

 

* 참고문헌 : (주)한티에듀 소프트웨어공학 제10판