[소프트웨어 공학] - 아키텍처 설계
소프트웨어 설계와 구현은 소프트웨어 공학 프로세스의 단계로, 실행 가능한 소프트웨어 시스템이
개발되는 단계이다.
설계와 구현활동은 분리된 활동이 아닌, 항상 상호간섭되는 활동이다.
설계는 고객의 요구에 기반하여 소프트웨어 구성 요소와 그들의 관계를 식별하는 활동이고,
구현은 설계를 프로그램으로 구체화하는 과정이다.
즉 두 개를 분리할 수 없다.
객체지향 설계과정은 조직에 따라 다양한 방식으로 이루어지지만,
일반적인 활동은 다음과 같다.
- 시스템의 context와 사용 용도를 정함.
- 시스템 아키텍처를 설계
- 주요한 시스템 객체를 식별
- 설계 모델 개발
- 객체 인터페이스 명세
소프트웨어와 외부 환경 간의 관계를 이해하는 것은 필수적이다.
왜냐하면, 필요한 시스템을 제공하고, 외부환경과의 통신을 위해 어떻게 구성할지 결정해 주기 때문.
System Context 모델은 개발중인 시스템의 환경에 있는 다른 시스템을 보여주는 구조적 모델이다.
상호작용 모델은 사용되는 동안 시스템이 환경과 어떻게 상호작용하는지 보여주는 동적인 모델이다.
시스템과 그 환경 간의 상호작용을 이해한 후에 이 정보를 이용하여 시스템 설계를 하는 것이 일반적이다.
시스템을 구성하는 주요 구성 요소와 그들의 상호작용을 식별한 다음, layer 또는 client-server 모델과 같은
아키텍처 패턴을 사용하여 구성요소를 조직화 할 수 있다.
객체 클래스를 식별하는 것은 어렵고, 공식이 없다.
따라서 개발자의 기술, 경험에 의존하는 과정이다.
식별에 대한 4가지 접근 방식이 있다.
- 문법 기반 접근 : 시스템에 대한 자연어 설명을 기반으로 한다.
문장에서 나타내는 것들을 분석하여 객체를 식별 - 응용 도메인에서 실체가 있는 것을 기반으로 식별(구체적 사물, 개념)
- 행위 기반 접근 : 행위에 참여하는 객체를 식별(동작,기능)
- 시나리오 기반 분석 : 시나리오에서 객체, 속성 및 메서드를 식별(상황과 관련된 객체를 식별)
설계모델은 객체와 객체 클래스, 이러한 개체들 간의 관계를 보여준다.
구조적 모델
- 객체 클래스와 관계를 통해 시스템의 정적인 구조를 설명
- 객체들 간의 정적인 관계와 속성을 나타내는 다이어그램을 사용하여 시스템의 구조를 표현
동적 모델
- 객체들 간의 동적인 상호작용을 설명
즉 설계모델은 시스템의 구조와 동작을 시각화하고 이해하는데 도움을 준다.
구조적 모델은 정적인 특성, 동적모델은 상호작용을 이해하는데 유용하다.
설계 모델의 예시
- 서브시스템 모델 : 객체들을 논리적으로 구성된 서브시스템으로 그룹화한 모델이 시스템을 더 작은 부분으로 나누어,
구성 요소 간의 관계와 상호작용을 보여줌. - 시퀀스 모델 : 객체들 간의 상호작용 순서를 보여줌
객체들 간에 상호작용이나 호출 순서를 시간에 따라 표현해서 시각화 - 상태 머신 모델 : 개별 객체가 이벤트에 응답하여 상태를 변경하는 방식에 대한 모델
다이어그램을 통해 ->객체의 동작을 이해
시퀀스 모델
- 객체 간 발생하는 상호작용의 순서를 보여줌.
- 특징
- 상호작용은 화살표로, 제어시간은 직사각형으로 상호작용을 주도하는 시간임.
객체 간의 상호 작용의 시각적인 순서를 시각화해서 시스템의 동작을 이해하고 디자인할 수 있도록 도와준다.
이를 통해 개발자들은 객체 간의 메시지 교환과 상호작용을 파악, 시스템의 동작을 검증, 문제를 해결함.
State diagrams
- 객체가 다양한 서비스 요청에 어떻게 응답하고, 이러한 요청에 의해 발생하는 상태 전이를 보여주는 데 사용
- 시스템의 모든 객체에 대해 필요한 것은 아님.
객체의 상태 다이어그램은 주로 시스템의 핵심 객체나 중요한 동작을 모델링하는 데 사용.
디자인 패턴
- 문제와 그 해결책에 대한 추상적인 지식을 재사용하는 방법
- 패턴은 문제와 그 해결책의 요약을 설명하는 것
- 다양한 상황에서 재사용할 수 있도록 충분히 추상적이어야 함.
- 패턴 설명은 일반적으로 상속과 다형성과 같은 객체지향 특성을 활용
객체 간의 상호작용과 구조를 재사용가능한 방식으로 조직화하는데 도움을 준다.
Patterns
- 패턴과 패턴 언어는 다른 사람들이 이러한 경험을 재사용할 수 있는 방식으로 최상의 실천방법, 좋은 디자인을
설명하고 경험을 기록하는 방법
패턴의 구성요소는 이름, 문제 설명, 해결책 설명, 결과가 있다.
옵서버 패턴
- 객체의 상태 표시를 개체 자체에서 분리하는 패턴
- 상태의 여러 표시가 필요한 경우 사용
옵저버 패턴은 관찰 대상 객체와 관찰자 객체 간의 느슨한 결합을 통해 객체 상태의 변경을 전달하고 관찰자는 필요한
상태 업데이트를 수신하여 독립적으로 동작
디자인 문제를 해결하기 위해서는 해당 문제에 적용할 수 있는 관련 패턴을 인식해야 함.
- 여러 개의 객체에게 상태 변경을 알리려면 옵서버패턴
- 여러 개의 관련된 인터페이스를 정리하고자 할 때 Facade
- 컬랙션 내 요소에 접근하는 표준화된 방법 iterator 패턴 활용
- 기존 클래스의 기능을 런타임에 확장 -> Decorator 패턴
구현 이슈
중점은 프로그래밍이 아니라 다른 구현에 있다.
재사용
- 재사용하는 것이 일반적이고, 가능한 기존의 코드를 최대한 활용하는 것이 유리하다.
구성 관리
- 개발 과정에서 각 소프트웨어 구성 요소의 여러 다른 버전을 구성관리 시스템에서 추적해야 한다.
- 구성 요소의 변경을 관리하고, 제어하며 버전을 추적하여 일관성을 유지
호스트 타깃 개발
- 크로스플랫폼 호환성, 하드웨어 종속성, 배포 전략에 대한 고려를 필요로 한다.
초기에는 재사용을 하지 않았다. 그나마 해도 함수와 객체의 재사용정도.
하지만 소프트웨어의 규모가 점점 커짐에 따라, 재사용은 필수적이다.
재사용 수준
- 추상화
- 소프트웨어를 직접적으로 재사용하지 않고, 성공적인 추상화에 대한 지식을 활용
- 객체 수준
- 직접 라이브러이에서 객체를 재사용
- 컴포넌트
- 컴포넌트는 객체와 객체 클래스의 집합으로, 응용 프로그램 시스템에서 재사용된다.
- 시스템 수준
- 이 수준에서는 전체 응용 프로그램 시스템을 재사용
재사용 비용
- 재사용을 위해 소프트웨어를 탐색하고 여부를 평가하는 시간이 곧 비용
- 해당하는 경우, 재사용 가능한 소프트웨어를 구매하는 비용
- 재사용 가능한 소프트웨어 구성 요소 또는 시스템을 개발 중인 시스템의 요구사항을 반영하기 위한 적응
및 구성 비용 - 새 코드와 통합 비용
구성 관리
- 변화하는 소프트웨어 시스템을 관리하는 일반적인 과정을 가리키는 용어
- 구성 관리는 소프트웨어 개발 및 시스템 운영에 있어서 일관성, 품질, 추적성 등을 보장하기 위한 핵심적인 활동으로 간주됩니다. 이를 통해 구성 항목들을 효율적으로 관리하고, 변경 사항을 관리하며, 문제를 해결하고, 프로젝트의 투명성과 안정성을 확보할 수 있습니다.
- 버전관리는 소프트웨어 구성 요소의 다른 버전을 추적하기 위한 지원이 제공되는 기능.
- 시스템 통합은 개발자들이 각 시스템 버전을 생산하는데 구성요소의 버전을 정의하는 데 도움이 되는 지원이 제공
- 문제추적은 사용자가 버그 및 기타 문제를 보고하고, 이러한 문제를 해결하는 개발자와
해결일정은 모든 개발자가 볼 수 있도록 하는 기능
요약
- 소프트웨어 설계와 구현은 서로 교차하는 활동이다.
- 설계의 세부 수준은 시스템의 유형과 개발 방법에 따라 다르다.
- 객체지향 설계 과정에는 시스템 아키텍처를 설계하고 시스템 내의 객체를 식별하며, 다양한 객체 모델을 사용하여 설계를
기술하고 컴포넌트 인터페이스를 문서화하는 활동이 포함됨. - 객체지향 설계 괴정에서 다양한 모델이 생성될 수 있다.
- 정적 모델 : 클래스, 일반화
- 동적 모델 : 시퀀스 state
- 컴포넌트 인터페이스는 다른 객체가 사용할 수 있도록 정확하게 정의
- 소프트웨어를 개발할 때는 구성요소, 서비스 또는 완전한 시스템으로서 기존 소프트웨어의 재사용 가능성을 항상 고려해야 한다.
- 구성관리는 진화하는 소프트웨어 시스템의 변경사항을 관리하는 프로세스