소프트웨어 공학, 7장 설계원리

시스템 아키텍처 설계에 필수적인 요소

- 소프트웨어 컴포넌트

- 소프트 웨어 컴포넌트 사이의 관계를 나타내는 커넥터

*클래스 다이어그램 x E-R다이어그램 x

---

소프트웨어 아키텍처의 4+1 관점(view)

- 유스케이스 관점에서는 외부 행위자에 의해 인식되는 시스템 기능 요구사항을 보여준다.

- 논리적 관점은 시스템의 구성 요소와 그들 간의 관계에 초점을 맞춘다. 주요 관심사는 시스템이 수행하는 작업이나 기능이며, 이를 위해 소프트웨어의 추상화, 모듈화, 동작 방식 등을 고려한다.

- 프로세스 관점에서는 독자적인 제어 스레드를 가질 수 있는 액티브 클래스에 초점을 둔다.

- 배치 관점 물리적인 시스템을 구성하고 있는 각 부분들의 분산 형태와 설치에 초점을 둔다.

---

가용성(avaliavility)

시스템은 사용자에게 서비스를 제공하기 위해 동일한 기능을 수행하는 컴포넌트 A와 B, 이 외에 여러 컴포넌트로 구성된다. 컴포넌트 A가 동작 중에 실패가 발생하여 대기 중이던 컴포넌트 B가 A를 대신하여 계속 서비스를 제공한다.

가용성 (Availability):
가용성은 시스템이 사용 가능한 시간의 비율을 나타낸다. 즉, 시스템이 사용자에게 제공되는 서비스를 얼마나 오랫동안 제공할 수 있는지를 의미한다. 높은 가용성을 갖는 시스템은 시스템 장애 시간을 최소화하고 사용자가 언제든지 서비스에 접근할 수 있도록 보장한다.

 

상호운용성 (Interoperability):
상호운용성은 시스템이 다른 시스템이나 구성 요소와 상호 작용할 수 있는 능력을 나타낸다. 즉, 서로 다른 플랫폼, 프로토콜 또는 기술을 사용하는 시스템 간에 데이터나 서비스를 교환하고 상호 작용할 수 있는 능력을 의미한다.

성능 (Performance):
성능은 시스템이 얼마나 빠르고 효율적으로 작동하는지를 나타낸다. 이는 주로 응답 시간, 처리량, 처리 속도 등과 같은 요소들을 포함한다. 높은 성능을 갖는 시스템은 사용자의 요청을 신속하게 처리하고 효율적으로 리소스를 활용할 수 있다.

 

적응성 (Adaptability):
적응성은 시스템이 변화에 대응하고 적응할 수 있는 능력을 나타낸다. 시스템이 환경의 변화나 요구 사항의 변경에 대응하여 유연하게 조정할 수 있는 능력을 의미한다 이는 새로운 요구 사항이나 환경의 변화에 대응하여 시스템을 업데이트하거나 조정할 수 있는 능력을 말한다.

---

ISO/IEC 25010의 성능(Performance efficiency)과 관련 지표

- 동시 접속 가능한 사용자수

- 네트워크 Bandwidth 사용률

- 평균 소요 시간

- 단위 시간당 평균 처리량

지원 가능한 프로토콜 수 x

---

소프트웨어 아키텍처 스타일과 응용분야

- 클라이언트/ 서버 아키텍처 : 웹 기반의 수강 신청 시스템

- N-tier 아키텍처 : 운영체제

- MVC 아키텍처 : 모바일 애플리케이션

- 파이프라인 구조 : 센서와 데이터를 처리하는 프로세스로 구성된 신호 처리 시스템

- 저장소 구조 : 느슨하게 결합된 디자인 도구들

- 마이크로커널 아키텍처 : 분산 운영 체제

* 임베디드 시스템 아키텍처 : 마이크로웨이브 오븐 제어 소프트웨어 → 계층형 x

---

파이프 필터 형태의 소프트웨어 아키텍처

서브시스템이 입력 데이터를 받아 처리하고 결과를 다른 시스템에 보내는 작업이 반복된다.

파이프-필터 아키텍처는 데이터 처리를 일련의 단계로 분할하고 각 단계를 독립적인 프로세스 또는 컴포넌트로 구현하는 아키텍처 스타일이다. 각 단계는 입력 데이터를 받아들여 처리한 후 출력을 생성하며, 이러한 단계들은 일련의 파이프라인으로 연결된다.

파이프-필터 아키텍처는 각 단계가 독립적으로 구현되므로 유연성과 재사용성을 높일 수 있다. 또한, 각 단계의 성능이나 기능을 개선하거나 변경하기 쉽다.

---

아키텍처 유형

- 3 계층 구조는 클라이언트 서버 유형의 변형

- peer to peer 아키텍처 유형에서 각 서브시스템은 서비스를 제공하고 요청하는 능력이 있다.

- 계층 구조 유형에서는 하위 계층이 제공하는 서비스를 상위 계층의 서브시스템이 사용하도록 구성된다.

*CORBAR는 파이프 필터 유형의 아키텍처를 지원하지 않는다.

---

웹 기반 엔터프라이즈 응용에 계층형 아키텍처를 사용하는 적합한 이유

- 이식성

- 시스템 관리의 용이성

*코딩 x, 성능 x

 

---

데코레이터 패턴

상속을 사용하지 않고도 객체의 기능을 동적으로 확장할 수 있도록 해주는 패턴

데코레이터 패턴 (Decorator Pattern):
데코레이터 패턴은 객체에 새로운 기능을 추가할 때 상속을 사용하지 않고 객체를 확장하는 패턴이다. 이 패턴은 기존 객체를 수정하지 않고 동적으로 기능을 추가할 수 있도록 한다. 예를 들어, 파일 출력에 압축 기능을 추가하고 싶을 때, 파일 출력 클래스를 직접 수정하는 대신 데코레이터를 사용하여 압축 기능을 추가할 수 있다.

어댑터 패턴 (Adapter Pattern):
어댑터 패턴은 서로 다른 인터페이스를 가진 두 개의 클래스를 함께 동작할 수 있도록 하는 패턴이다. 어댑터 클래스를 사용하여 인터페이스를 변환하고, 클라이언트가 기존의 인터페이스를 변경하지 않고도 새로운 인터페이스를 사용할 수 있도록 한다. 예를 들어, 새로운 버전의 라이브러리나 프레임워크를 사용하려는데 이전 버전과의 호환성을 유지해야 할 때 어댑터 패턴을 사용할 수 있다.

 

중재자 패턴 (Mediator Pattern):
객체들 간의 상호 작용을 캡슐화하여 객체들이 직접 통신하는 것을 방지하고, 중재자 객체를 통해 상호 작용을 처리하는 패턴이다.

 

옵서버 패턴 (Observer Pattern):
옵서버 패턴은 객체 간에 일 대 다의 의존성을 정의하는 패턴으로, 한 객체의 상태가 변경될 때 그 객체에 의존하는 다른 객체들이 자동으로 알림을 받고 자신의 상태를 업데이트할 수 있도록 한다. 주로 MVC(Model-View-Controller) 패턴과 함께 사용되며, 주제(Subject)와 관찰자(Observer)의 관계로 구성된다.

컴포지트 패턴 (Composite Pattern):
컴포지트 패턴은 객체들을 트리 구조로 구성하여 개별 객체와 복합 객체를 동일한 방식으로 다룰 수 있도록 하는 패턴이다. 이 패턴은 클라이언트가 개별 객체와 복합 객체를 구분하지 않고 사용할 수 있게 한다. 예를 들어, 파일 시스템에서 디렉토리와 파일을 동일한 방식으로 처리하고자 할 때 컴포지트 패턴을 사용할 수 있다.

 

싱글톤 패턴 (Singleton Pattern):
애플리케이션 전역에서 오직 하나의 인스턴스만을 갖도록 보장하는 패턴이다. 이는 보통 인스턴스를 여러 개 생성하는 것을 방지하고, 공유 리소스에 대한 중복 액세스를 방지하기 위해 사용됩니다.

퍼사드 패턴 (Facade Pattern):
퍼사트 패턴은 서브시스템의 복잡한 인터페이스를 단순화시키고 클라이언트에게 간단한 인터페이스를 제공하는 패턴이다. 이 패턴은 서브시스템의 복잡한 내부 구조를 숨기고, 클라이언트가 서브시스템을 쉽게 사용할 수 있도록 한다. 예를 들어, 컴퓨터의 전원 버튼은 컴퓨터의 여러 하위 시스템을 시작하고 종료하는 복잡한 프로세스를 숨기고 단순한 인터페이스를 제공하는 퍼사트 패턴의 예시이다.

 

---

literator 패턴

이 패턴은 컬렉션의 내부 구조를 노출하지 않고도 컬렉션을 순회할 수 있도록 해준다. 이는 컬렉션의 구현 방식이 변경되어도 클라이언트 코드에 영향을 미치지 않고 순회 방식을 유지할 수 있게 한다.

- 집합 객체의 요소들에 대해 순서대로 접근하는 방법을 제공한다.

- 배열, 배열리스트, 해시 테이블과 같은 객체를 처리하는 데 사용하는 패턴이다.

- 서로 다른 집합 객체 구조에 대해 동일한 방법으로 순회할 수 있다.

*서로 다른 인터페이스를 사용하기 때문에 각가의 객체를 참조하기 위한 다형성 코드를 개발하는 것은 불가능하다 x

 

---

(가) target

(나) adapter

(다) adaptee

---

옵서버 패턴

일대 다의 객체 의존 관계를 정의하며, 한 객체의 상태가 변화되었을 때 의존 관계에 있는 다른 객체들에게 자동적으로 변화를 통지한다.

팩토리 메소드 패턴 (Factory Method Pattern):
팩토리 메소드 패턴은 객체를 생성하는 인터페이스를 정의하지만, 인스턴스화할 클래스를 서브클래스에서 결정하도록 하는 패턴이다. 이를 통해 객체 생성 과정을 캡슐화하고, 클라이언트가 구체적인 클래스에 대한 의존성을 줄일 수 있다.

 

데코레이터 패턴 (Decorator Pattern):
데코레이터 패턴은 객체에 추가적인 기능을 동적으로 덧붙이는 패턴이다. 기본 객체를 감싸는 데코레이터 클래스를 생성하고, 데코레이터 클래스는 같은 인터페이스를 구현한다. 이를 통해 클라이언트는 데코레이터를 통해 여러 기능을 추가할 수 있으며, 객체의 변화 없이도 기능을 확장할 수 있다.

전략 패턴 (Strategy Pattern):
전략 패턴은 알고리즘을 캡슐화하고, 이를 사용하는 클라이언트가 동적으로 선택할 수 있도록 하는 패턴이다. 전략 인터페이스를 정의하고, 이를 구현한 여러 전략 클래스를 생성합니다. 클라이언트는 전략 객체를 변경하거나 교체함으로써 동적으로 다양한 알고리즘을 사용할 수 있다.

---

디자인 패턴

- 여러 객체가 한 객체에 의존하여 이것이 변경될 때 영향을 받아 작업을 수행할 경우 옵서버 패턴이 권장된다.

- 오직 하나의 객체만을 생성하는 클래스의 경우에는 싱글톤 패턴이 권장된다.

- 동일한 역할은 하지만 다른 클래스의 객체를 생성할 때는 팩토리 패턴이 권장된다.

* 관련된 객체들의 패밀리 스타일 선택에 의해 생성할 때는 추상 팩토리 패턴(Abstract Factory Pattern)을 사용한다.

* 프로토타입 패턴(Prototype Pattern)은 객체를 복제(clone)하여 새로운 객체를 생성하는 패턴이다. 이 패턴은 객체 생성 비용이 높거나 복잡한 경우에 유용하며, 새로운 객체를 생성할 때 원본 객체의 복제본을 사용하여 초기화한다. 이를 통해 객체 생성 과정을 단순화하고, 불필요한 중복을 피할 수 있다.

---

Composit 패턴

컴포지트 패턴(Composite Pattern)은 객체들을 트리 구조로 구성하여 개별 객체와 복합 객체를 동일한 방식으로 다룰 수 있도록 하는 패턴이다. 이 패턴은 클라이언트가 개별 객체와 복합 객체를 구분하지 않고 사용할 수 있도록 한다.

 

---

Strategy 패턴

전략(Strategy) 패턴은 알고리즘을 캡슐화하고, 이를 사용하는 클라이언트가 동적으로 선택할 수 있도록 하는 디자인 패턴이다. 이 패턴은 알고리즘을 사용하는 클라이언트와 알고리즘을 정의하는 클래스를 분리하여, 코드의 유연성과 재사용성을 높인다.

 

차람 내비게이션 소프트웨어에서 GPS 신호를 수신하는 경우와 수신하지 못하는 경우에 따라 차량의 위치를 구하는 다른 알고리즘을 선택하고자 할 때 가장 적합한 설계 패턴

---

아키텍처 평가의 작업 순서

아키텍처 기술 → 시나리오 도출 → 시나리오 우선순위 매김 → 시나리오에 대한 아키텍처 평가 → 결과 해석 발표