Software Architecture Introduction

해당 강의는 대학교 “소프트웨어아키텍처” 수업 내용을 정리한 것입니다.

SA Definition

Software Architecture is a bridge

  • 비즈니스 목표를 만족시키는 시스템을 만들어내기 위한, 비즈니스 목표와 소프트웨어 시스템의 중간 다리
  • SA를 통해 시스템의 복잡성을 길들일 수 있고, 다루기 쉽게 만들 수 있다

용어 정리

  • scale : 규모
  • cost : 비용
  • schedule : 일정
  • stakeholders : 이해당사자들, 이해관계자들
  • skills of development teams : 팀원들의 능력
  • materials and technologies : 자원들, 기술들
  • risks : 위험 요소들
  • development process : 개방 공정
  • etc

The software architecture of a system

  • 소프트웨어 요소, 그 들 사이의 관계, 그리고 이 둘의 속성으로 구성되는 시스템에 대한 추론에 필요한 구조물들의 집합

  • 어떤 철학을 가지고 설계했는지 모두가 납득할만한 구조를 지니고 있어야 함

  • 소프트웨어 시스템은 많은 구조로 구성되어 있음

    1. Module

      구체적인 계산적 책임들이 부여된 것

      programming team (function, class, …) 에 대한 work assignment의 기초

      객체 지향 분석, 디자인, 클래스 다이어그램의 결과물

    2. Dynamic Structure

      런타임에서 각각의 요소가 서로 상호작용하는 방법에 초점을 둠

      런타임 구조는 C&C (component and connector) 라고 불림

    3. Mapping from Software structures to the system’s organizational, developmental, and execution environments.

      module은 개발을 위해 팀에 할당되고, 파일 구조에 배치되며, 구성 요소는 하드워드에 배치됨

      allocation structure

  • system 과 system의 properties에 대한 추론(reasoning)을 지원하는 structure은 건축적임

  • reasoning은 어떤 이해관계자에게 중요한 시스템의 속성에 관한 것이어야 함

    • 시스템이 달성한 기능
    • 고장이 발생한 경우 시스템의 유효성
    • 시스템을 구체적으로 변경하는 것의 어려움
    • 사용자 요청(request)에 대한 시스템의 응답성(response)

SA Structure

Architecture is an Abstraction

  • 소프트웨어의 전체적인 추상화를 아키텍처가 가지고 있어야 함
  • 아키텍처는 소프트웨어 요소들과 요소들이 서로 어떻게 연관되는지를 포함함
  • 아키텍처를 통해 복잡성을 다룰 수 있음
    • 요소에 대한 세부사항(내부 구현에만 관련된 세부사항)은 아키텍처가 아님
    • 추상화는 시스템의 복잡성을 길들이는 데 필수적

Architecture includes Behavior

  • 각 요소의 동작(behavior)은 요소가 서로 상호 작용하는 방식을 구현한 것임
  • 요소의 동작은 다른 요소에 영향을 미치거나 시스템 전체의 수용 가능성(acceptability)에 영향을 미침
  • 동작은 소프트웨어 아키텍처의 일부로서 고려되어야 하며, 문서화되어야 함

Every Software System has a Software Architecture

  • 모든 시스템은 어떤 종류의 추론(reasoning)을 뒷받침하기 위해 요소와 그들 사이의 관계를 구성하는 것으로 보여질 수 있음
  • 모든 시스템에 아키텍처가 있다고 해도, 그 아키텍처가 누구에게나 알려진 것은 아님. – 아키텍처는 설명이나 사양과 독립적으로 존재할 수 있음

SA Definition - 2

  • 아키텍처는 시스템의 구성 요소, 시스템의 상호관계, 환경과의 관계, 시스템의 설계와 진화를 안내하는 원리로 구현된 기본적인 조직임
    • [IEEE Standard on the Recommended Practice for Architectural Descriptions, 2000]

Goal of SA = Optimization

  • 최적화 문제는 주어진 제약 조건(constraint) 하에서 측정 가능한 최상의 성능(objective function)을 달성하기 위해 특정 매개 변수(design variable)를 결정해야 하는 문제임.
  • OOAD → 하나의 소프트웨어 설계
  • SA → 여러 소프트웨어 설계

Common Aspect in SA Problem

  • 문제에 대한 해결책은 여러 가지가 있으며, 최적의 해결책을 찾아 내야함.
  • 달성해야 할 목표가 하나 이상 존재하며 이러한 목표가 얼마나 잘 달성되었는지 측정할 수 있음 (measureable performance)
  • 다양한 형태(hard, soft)의 제약이 존재하며, constraint인지 parameter인지 판단해야 함
  • 영향을 미치는 주요 변수는 여러 가지가 존재함
    • 값의 변화는 “측정 가능한 성능”과 “제약 조건” 위반의 정도에 영향을 미침 (향상 or 악화)

SW 개발 패러다임 변화

소프트웨어 모델링 목적

  • 상호작용에 대한 공통적인 이해
  • 좋은 기능과 품질을 가진 소프트웨어 시스템 개발

SA View

Module Element in UML

  • abstract : 실행할 수 없는, 구조를 위해 짜여진 것
    • concrete : implement, 코드 실행 가능, 보통 구상 클래스로 번역
    • 추상(abstract) ↔ 구상(concrete)

Module Relations in UML

Structures and View

  • view는 structure를 표현한 것 !
  • view : 일관성 있는 일련의 아키텍처 요소를 시스템 이해관계자(stakeholder)가 작성하고 읽을 수 있도록 표현한 것
    • 일련의 요소들과 그들 사이의 관계들의 표현으로 구성됨
  • structure : 소프트웨어나 하드웨어에 존재하는 요소들 자체의 집합
  • module structure는 시스템의 모듈들 및 그 조직의 집합임
  • module view는 해당 구조를 표현한 것으로, 템플릿에 따라 선택된 표기법으로 문서화되고 일부 시스템 이해관계자가 사용함
  • Software Architect 들은 structure를 설계하고, 소프트웨어 설계자들은 그 structure들의 view들을 문서화함

Example : View of the same system

  1. layered architecture (stacked), 소프트웨어가 나눠지는 구조를 보여줌.
  2. 프로세스를 어디에 어떻게 배포할 지에 대한 view, 클라이언트와 서버 간의 연결관계 및 배치를 볼 수 있음

Modeling View

[4 + 1] Logical View

  • logical viewpoint는 에서는 시스템이 사용자에게 제공해야하는 서비스인 **기능적 요구사항(functional requirement)**을 지원함
  • 일반적으로 핵심 추상화(클래스와 그들 사이의 상호작용 등)를 보여줌

[4 + 1] Process View

  • 런타임 시 동시적 측면(task, threads, process 및 상호작용) 해결
  • 일부 비기능적 요구사항(non-functional requirement)을 고려함
    • 성능(performance), 시스템 가용성(system availability), 동시성 및 배포(concurrency / distribution), 시스템 무결성(system integrity) 및 내결함성(fault-tolerance) 등
  • 다중성의 종류
    • concurrent (동시성)
    • parallel (병렬성)

[4 + 1] Implementation View

  • implementation viewpoint는 소프트웨어 개발 환경에서 실제 소프트웨어 모듈의 구성에 초점을 맞춤.
  • 소프트웨어는 개발자에 의해 개발될 수 있는 프로그램 라이브러리 또는 서브시스템에 패키징된다.

[4 + 1] Deployment View

  • deployment viewpoint는 논리적 관점, 프로세스 관점 및 구현 관점에서 파악된 다양한 요소들이 네트워크, 프로세스, 작업 및 객체에 어떻게 매핑되어야 하는지를 정의함
  • 시스템 가용성, 신뢰성(내결함성), 성능(처리량), 확장성 등 시스템의 비기능적 요구사항을 고려함

[4 + 1] Scenario View (Use Case View)

  • scenario viewpoint는 위 네 가지 관점의 요소가 원활하게 함께 작동한다는 것을 보여주기 위해, use case를 사용하여 중요한 시나리오의 작은 부분집합으로 구성됨
  • scenario / use case viewpoint의 역할
    • architect design을 하는 동안 architect element들을 발견하는 것을 도와주는 driver 역할을 함
    • 문서상으로, 그리고 architecutal prototype의 테스트를 위한 시작점으로서 architecture design을 검증하고 설명함

4 + 1 View Model 요약

  • Logical
    • Focus: 시스템의 기능적 요구사항
    • Contents: Class diagrams, Sequence diagrams, Layer diagrams.
  • Implementation
    • Focus: 개발 환경에서 소프트웨어의 정적 구성
    • Contents: Component diagram, Package diagrams.
  • Process
    • Focus: 시스템의 런타임 동작 (processes, communication, concurrency, performance, scalability)
    • Contents: Activity diagrams.
  • Deployment
    • Focus: 시스템 토폴로지, 배치 및 통신을 살펴보는 엔지니어적 관점
    • Contents: Deployment diagrams.
  • Scenarios
    • Focus: 아키텍처를 설명하고 검증하기 위한 use case를 사용
    • Contents: Use case diagrams.