[Software Architecture] SA Framework

개요

• Software Architecture Framework
  - Based on IEEE 1471-2000, IEEE (2000)

• Viewpoint Models
  - ISO RM-ODP - ISO(1994)
  - Siemens Four View Model - Soni, D. et al (1995)
  - 4 + 1 View Model - Kruchten, P. (1997)
  - SEI View Model, Clements, P. et al. (2002b)

 

 

---

 

IEEE 1471 Framework

• 아키텍처는 유연하고 확장성을 가져야 하며 이러한 아키텍처를 개발하기 위해서 아키텍처 프레임워크가 필요
• 중요성
  - 관련된 용어와 개념을 통일
  - 정해진 모델링 언어, 특정 방법론을 제시하지 않기 때문에 기술적 중립성을 가지고 있음
  - 기본적으로 대규모 프로젝트를 겨냥한 것이지만 프로젝트 규모에 따라 유연하게 적용가능한 프레임워크

 

주요 구성요소

• Mission
  - Environment 내에서 Stakeholder 들이 의도하는 시스템의 목적/사용/운영방법
• Environment
  - System에 영향을 주는 요인으로 개발, 운영, 정책변화 등의 외부 요인으로 시스템에 영향을 주는 요인
• System
  - 각 애플리케이션들, 서브 시스템들, 시스템의 집합, 제품라인, 제품군 등의 구현체
• Stakeholder
  - System에 대한 이해관계자 (다른 관점 소유, 개인/기관이 될 수 있음)
  - 각 이해관계자들은 각기의 성능, 품질에 대한 다른 의견 및 관점을 가짐
  - 이해관계자들의 의견을 조정하고 품질요구사항을 파악하는 것이 중요함
• Concerns (관심사항, 우려사항)
  - System의 성능, 유연성, 보안, 분배 등을 포함한 Stakeholder에게 중요한 System의 개발/운영 측면의 관심사항
• Architectural Description
  - System 구축 시 Environment에 적합하도록 추천하는 수행방법으로 Architecture 기록되는 방법
  - 아키텍처 문서는 하나 이상의 뷰로 구성
• View
  - 이해관계자들과 이들이 가지는 생각이나 견해로부터 시스템을 표현
• Viewpoint
  - View를 구성하기 위한 리소스나 규칙을 정의하는 패턴이나 템플릿
• Rationale (근거/이유)
  - 선택되어 설계된 아키텍처에 대한 논리적 근거
  - 요구사항
     > 복잡한 시스템에 많은 사람들이 참여하고, 사람마다 관점이 다르다는 현실 반영
     > 고객 또는 최종사용자인 경우 특히 이러한 특징이 강함
  - 특정 이해관계자를 기반으로 하는 많ㅇ느 비기능적 요구사항 측면
     > 구입을 위한 경제성, 유지보수를 위한 유지보수성
     > 사용자는 현재와 같은 시스템을 원함
  - 이해관계자의 관심사는 여러가지 View 등을 수립 및 정당화 하는데 사용

 

 

IEEE1471 아키텍처 작성 순서

1. 아키텍처 관련 문서 파악
2. 이해관계자의 역할 및 아키텍처 관심사항 파악
3. 뷰 포인트 선택 (시스템을 바로보는 관점)
4. 뷰의 명세 (Viewpoint를 가지고 시스템을 구성하는 요소와 그 요소들 간의 관계를 표현하는 것이 View)
5. 뷰들 간에 존재하는 불일치성 파악 및 기록
6. 선택되어 설계된 아키텍처에 대한 논리적 근거 (Rationale) 작성

 

---

 

 

 

Viewpoint Model - RM-ODP (Reference Model for Open Distributed Processing)

• 대규모 기업의 경영을 지원하기 위하여 분산시스템으로 구축되어야 하는 시스템인 엔터프라이즈 통합 시스템의
  아키텍처를 설계하고 문서화하는 방법을 정의한 표준 (ISO/IEC 10746)
• 이기존 시스템 사이의 상호 운용성을 높이고 분산환경에서 분산 투명성을 제공하는데 초점을 맞춘
  아키텍처 프레임워크
• Viewpoint
  - enterprise viewpint
     > 시스템의 목적, 범위 및 정책에 초점
     > 시스템이 만족시켜야하는 이해관계자들의 요구사항과 시스템이 제공해야 하는 서비스 정의
  - Information viewpoint (Data)
     > 시스템에서 관리하는 정보와 데이터의 구조 및 내용 유형 설명
     > 시스템이 정보를 다루는 규칙이나 정책을 정의
  - Conputational viewpoint (Application)
     > 시스템이 제공하는 기능과 기능적 분해에 대해 설명
     > 시스템의 구성요소인 분산객체들이 어떻게 상호작용해서 기능요구사항을 만족시키는지 정의
  - Engineering viewpoint (Runtime 관점)
     > APPL 기능과 정보를 관리하는 시스템에 의해 정의된 객체들이 분산환경에서 제대로 동작할 수 있는
        매커니즘과 분산투명성 제공방법을 특정기술에 종속되지 않게 정의
  - Technical viewpoint
     > 시스템 구현방식 (프로그래밍 언어, 미들웨어, OS, NT Protocol 등)
     > 특정기술을 적용하여 각 뷰를 실현시키는 방법을 설명함

 

 

Siemens Four View Model 

• Conceptual View
  
  • Application 도메인에 밀접하게 연관
  • 도메인에서 Problem과 Solution이 기본적으로 보여짐
  • HW나 특정 SW에 독립적이어야 함
• Module View
  • Conceptual View에서 정의된 컴퍼넌트나 커넥터가 서브시스템이나 모듈로 맵핑 됨
• Code View
  • 어떻게 Deployment component로 매핑할 것인가에 대한 문제를 다룸
  • 모듈뷰에서 정의된 모듈들이 소스 컴포넌트로 어떻게 매핑될 것인가에 대한 문제 다룸
• Execution View
  • 각 모듈들이 실행환경에 의해 제공되는 요소들이나 하드웨어에 매핑 될 부분을 정의
  • 중요한 부분은 제어의 흐름 (실행환경 제어의 흐름 / 논리적 제어의 흐름 = Conceptual View)

 

 

4 + 1 View Model

• 개요
  • 여러개의 Concurrent View 사용을 기반으로 하는 SW 집약적인 시스템의 아키텍처를 설명
  • 다양한 이해관계자의 관점에서 시스템을 설명하는데 사용
  • 4가지 View(논리적, 개발, 프로세스, 물리적 View) 사용 + Use case 를 포함
• Logical View
  • 최종 사용자에게 제공하는 기능을 구조적 구성요소와 역할로 분해하고 그 간의 관계를 명시
  • 추상화 레벨에 따라 다르게 표현 가능 -> 반복적인 구조설계의 과정을 거치며 상세화
  • UML DIagram은 논리적 뷰를 나타내는데 사용
• Process View
  • 개발자와 시스템 통합자에게 유용
  • 시스템의 동적 측면을 다룸 (시스템 프로세스와 통신방법 설명, 시스템의 런타임 동작에 중점)
  • 비기능 요구사항 (동시성, Fault-tolerant, Distrubuteion, Integrator, Performance, Scalability)
  • Sequence Diagram, Communication Diagram, Activity Diagram
• Development View
  • 개발팀에서 개발하는 물리적인 산출물의 관정에서 구조 표현
  • 물리적 시스템에서 사용하는 SW 서브시스템의 모듈(코드, 데이터파일, 컴퍼넌트, 실행파일) 
  • Package Diagram, Component Diagram
• Physical View (Deployment View)
  • 시스템 엔지니어 관점에서 시스템을 바라봄
  • 물리적 계층에 있는 SW 구성요소의 토폴로지와 이러한 구성요소 간의 물리적 연결에 초첨
  • Deployment Diagram
• Scenario (Use Case) View
  • 4개의 모든 View를 연결시켜주는 역할
  • 시나리오는 개체 간 및 프로세스 간의 상호 작용의 시퀀스로 설명
  • 아키텍처 요소를 식별하고 아키텍처 디자인을 설명하고 검증하는데 사용
    아키텍처 프로토타입 테스트를 위한 출발점 역할
  • Usecase Diagram

 

Zachman Framework vs 4+1 View Model의 결함

 

 

CMU SEI 3 View Model

• 개요
  • 시스템의 SW 아키텍처는 시스템에 대해 추론하는데 필요한 구조의 집합으로
    소프트웨어 구성요소와 속성으로 구성된다
  • 구조는 SW 또는 HW에 존재하는 요소의 집합
  • 뷰는 구조의 표현 / 뷰는 요소집합의 표현과 요소들간의 관계로 구성
  • 결론적으로 SA는 뷰들을 통해서 보여주고 문서화 되어진 구조의 집합이다
    그리고, 아키텍트는 구조를 설계하는데 뷰를 사용하는 것이다
• Application View
  • SA와 Environment를 매핑시키는 역할