Transcript 패턴과 소프트웨어 아키텍처

패턴과 소프트웨어
아키텍처
아꿈사 스터디
POSA1
2008. 8. 23 박진욱
순서

입문


소프트웨어 아키텍처의 패턴


소프트웨어 아키텍처에 대한 전반적인 이해
객체지향 분석, 설계, 프로그래밍
소프트웨어 아키텍처의 원천 기법들

소프트웨어 개발에 필요한 몇가지 기본 원칙
입문

내용







소프트웨어 아키텍처(software architecture)
컴포넌트(component)
관계(relationship)
뷰(view)
기능적 특성(functional property)
비기능적 특성(non-functional property)
소프트웨어 설계(software design)
아키텍처
이분은 매트릭스에 나오셨던 아키텍트(Architect)
아키텍처


The software architecture of a program or computing
system is the structure or structures of the system, which
comprise software elements, the externally visible properties
of those elements, and the relationships among then.
“프로그램 또는 연산 시스템의 소프트웨어 아키
텍처는 소프트웨어 구성요소와 외부로 보이는
속성, 그리고 그 구성요소 간의 관계로 이루어
진 구조 또는 시스템의 구조이다”
아키텍처

소프트웨어 아키텍처



소프트웨어 시스템을 구성하는 서브 시스템과 컴포
넌트, 그리고 그것들의 관계를 나타내는 용어
서브시스템과 컴포넌트는 소프트웨어 시스템의 기
능적 특성(functional property)와 비기능적 특성
(non-functional property)을 구현하기 위해 각기
다른 뷰(view)로 기술
시스템의 소프트웨어 아키텍처는 하나의 산출물로
서, 소프트웨어 설계 과정의 결과물에 해당
컴포넌트
컴포넌트




소프트웨어 시스템 내에 캡슐화된 부분
인터페이스가 포함
시스템 구조의 빌딩 블록 역학을 함
프로그래밍 레벨에서는

모듈, 클래스, 함수 등등이 모두 모듈이라고 할 수
있음
컴포넌트의 분류

[PW92]




프로세스 요소(processing element)
데이터 요소(data element)
연결 요소(connecting element)
또 다른 분류






컨트롤러 컴포넌트
조정자 컴포넌트(coordinator)
인터페이스 컴포넌트
서비스 제공자 컴포넌트(service provider)
정보 저장자 컴포넌트(information holder)
구조화 컴포넌트(structuring componet)
관계
관계


컴포넌트간의 연결
정적 관계




동적 관계




소스코드 상에서 직접 알 수 있음
아키텍처 내에서 컴포넌트의 배치
집합(aggregation)과 상속(inheritance)
소스코드에서는 찾기 힘듬
컴포넌트 간의 일시적인 연결
동적인 상호 작용
소프트웨어 아키텍처 성능과 품질에 영향
뷰(View)
뷰(View)
뷰(View)

특정 소프트웨어 시스템의 고유한 특성
(property)를 드러낼 수 있도록 소프트웨어 아
키텍처의 일부 측면을 표시
뷰(View)

[SNH95]의 4 가지 뷰





개념적 아키텍처
모듈 아키텍처
코드 아키텍처
실행 아키텍처
[Kru95]의 4 가지 뷰




논리적 뷰
프로세스 뷰
물리적 뷰
개발 뷰
cf) 뷰 패킷
기능적 특성
기능적 특성


시스템 기능의 특정 측면을 다루며 대체로 엄밀
하게 정의된 기능적 요구사항과 연관되어 있음
사용자에게 직접적으로 특정 기능을 수행하기
위한 알고리즘처럼 보여지기도 함
비기능적 특성


기능적으로 구현하거나 표현할 수 있는 범위를
벗어나는 시스템의 특징
신뢰성, 호환성, 비용, 편의성, 유지보수, 개발
과 관련된 측면
소프트웨어 설계


시스템의 소프트웨어 아키텍처를 구축하기 위
해서 소프트웨어 개발자가 수행하는 행위를 말
함
1)소프트웨어 시스템의 컴포넌트와 2) 그 컴포
넌트들 간의 관계에 대해 관심을 가짐
소프트웨어 아키텍처에서의 패턴




방법론
소프트웨어 공정
아키텍처 스타일
프레임워크
방법론

책 406P. 마이클 잭슨의 말



제임스 코플리언의 말


문제를 명확히 밝히지 않고 방법론이 모든것을 해결
해주리라 믿지 말라
방법론이 일반화될수록 그 가치는 하락한다
“패턴은 단지 설계 영역중에 어떤 작은 빈틈을 매워
주는 역할”
방법론은 고품질 소프트웨어를 구축하기 위한
유용한 단계와 가이드라인을 제공하며 소프트
웨어 구현에 도움이 되는 패턴을 활용할 수 있
음
소프트웨어 공정



소프트웨어 프로세스
패턴을 적용함으로써 개발 단계들이 엄격히 분
리되지 않고 점진적으로 공정을 진행시키는데
에 도움이 되길 바람
개발의 어떤 시점에 패턴을 사용해야 하나?

정답은 없다- _-+
아키텍처 스타일



소프트웨어 시스템들을 그 구조에 따라 몇가지
유형들로 추성화하여 구분하는 역할
1)컴포넌트 2)컴포넌트들 간의 관계 3)관련되는
구성및 설계 규칙에 대해 서술
1)아키텍처의 사용 시점 2)아키텍처의 불변 속
성과 특수화 속성 3)아키텍처 응용의 결과 등에
대한 정보로 이루어짐
Ex) Multi-phase 아키텍처 스타일

컴파일러를 위한 Multi-phase 스타일




프로세스 요소 : 렉서, 파서, 의미 분석기, 최적화기
데이터 요소 : 문자, 토큰, 구(phrase), 관련구, 주석
연결요소 : 프로시져 호출, 매개변수
cf) SAIP에서 제안했던 Software Structure?




Module
Component and Connector
Allocation
얘네들이 전부 아키텍처 스타일로 볼수 있지 않나?
아키텍처 스타일

아키텍처 스타일이 패턴과 구분되는 특징


애플리케이션을 위한 구조적인 프레임워크 전체만
을 서술
각 스타일은 각각 독립적


패턴은 다른 패턴에 포함될수도 있고, 다른 패턴을 포함
할수도 있는 것처럼 서로 관계가 있음
패턴은 문제지향적
프레임워크




인스턴스화할 목적으로 제작된 소프트웨어 (서
브)시스템
(서브)시스템군에 대한 아키텍처를 정의하며 (
서브)시스템들을 구성하는 기본 빌딩 블록을 제
공
특정 기능을 추가로 적용 시킬수 있도록 지원하
는 여건이나 환경을 제공
객체지향의 경우, 프레임워크는 추상 클래스와
구체 클래스로 구성됨
프레임워크

프로즌 스팟(frozeon spot)과 핫스팟(hot spot)

프로즌 스팟




핫 스팟



시스템의 전체 아키텍처를 정의
기본 컴포넌트들과 그 기본 컴포넌트들 간의 관계를 정의
인스턴스화 하더라도 변하지 않고 유지되는 부분
개발 소프트웨어 시스템에 맞춰 변경되는 부분
일반화되어 설계
이 두가지를 구별해 내고 잘 선별하는 것이 프
레임워크 설계에 가장 중요하다고 할수 있음
소프트웨어 아키텍처의 원천기법들

추상화(abstration)

캡슐화(encapsulation)

정보숨김(information hiding)

모듈화(modularization)

역할의 분리(separation of concerns)

결합도(coupling)와 응집도(cohesion)

충분함, 완전함, 단순함

정책과 구현의 분리

인터페이스와 구현의 분리

참조의 단일 지점(single point of reference)

분할 정복(Divide and Conquer)
아키텍처의 비기능적 특성






가변성(changeability)
상호운용성(interoperability)
효율성(efficiency)
신뢰성(reliability)
테스트용이성(testability)
재사용성(reusability)
가변성


시스템의 아키텍처가 수정되고 발전되기 용이
하도록 미리 대비하는 것이 관건
소프트웨어 노후화의 이유들




운동부족 : 자주 업데이트를 하지 않으면 노후화
무지한 상태의 수술 : 설계를 이해하지 못한 사람들
이 소프트웨어에 변형을 가함
소프트웨어가 애초에 유연하지 않음
설명서가 작성되지 않음(Documentation)
가변성

4 가지 측면의 가변성




유지보수성 : 수정
확장성 : 추가/제거
재구성 : 관계를 다시 구성
이식성 : 다른 플랫폼(OS, 하드웨어, PL 등등)
상호운용성



다른 시스템이나 자체 환경과의 상호 작용
외부에 노출되는 기능과 데이터 구조에 효과적
으로 접근할 수 있도록 잘 설계되어야 함
Broker 패턴
효율성



리소스 사용 문제
정교한 알고리즘과 적절한 책임분배, 적절한 결
합을 가진 아키텍처를 구축
.... 도대체 어떻게 해야 적절한거임- _-+
신뢰성


장애, 옳지 못하게 사용되거나 예기치 않게 사
용되는 상황에, 소프트웨어 시스템의 기능을 온
전히 유지하기 위한 능력
장애 허용성(Fault toleance)


오류 발생시 동작을 보정하고 교정
저항성(Robustness)

오류 발생시 미리 정의된 상태로 유지시키는 능력
테스트용이성


정확성을 쉽게 평가할 수 있도록 아키텍처 수준
의 지원이 필요
테스트용이성을 지원하는 소프트웨어 구조를
채택하면 더 나은 장애 검출과 수정을 수행할
수 있으며 디버깅 코드와 디버깅 컴포넌트를 일
시적으로 통합할 수 있게 됨
재사용성



소프트웨어 시스템에 투여되는 비용과 개발 시
간단축, 더 나은 품질을 보장
“이미 있었던 것의 도움으로 원하는 것을 얻는
행위”
재사용을 통해 소프트웨어를 개발하는 방식


CBD
재사용을 위해 소프트웨어를 개발하는 방식

미래에 재사용 할 수 있게 컴포넌트 역할을 고려
그냥 참조

SAIP에서의 품질 특성






Availabilty
Modifiability
Performance
Security
Testabilty
Usability
결론

이 책에서 우리가 가져가야 할 것

소프트웨어 개발에 필요한 패턴은.






아키텍처 패턴
디자인 패턴
이디엄
개발과정에서 패턴의 역할
우리가 어느 시점에 저런 패턴을 사용할 수 있을까
설명은 대충하고 넘어갔지만 원천기법을 항상 기억
하자