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

Architecture Design

Architecture Design : WHAT

• software design의 목표
  • 모든 고객의 요구사항을 충족시키고 성공적인 구현으로 이어지는 모델을 구축하는 것
• WHAT is architecture design ?
  • 소프트웨어의 주요한 구조적 요소 사이의 관계를 정의함
  • 시스템에 대해 정의된 요구사항을 달성하기 위해 사용될 수 있는 아키텍처 스타일과 설계 패턴, 그리고 아키텍처가 구현될 수 있는 방식에 영향을 미치는 제약조건
  • 아키텍처 설계 표현은 시스템 요구사항 규격과 분석 모델에서 도출됨

Architecture Design : WHO

• 소프트웨어 아키텍처와 설계자는 소프트웨어 시스템 요구사항을 아키텍처 설계로 변환함 (mapping)
• 이들은 변환 과정에서 어플리케이션의 도메인 복잡성을 분할하고 정복하며, 소프트웨어 아키텍처를 해결하기 위한 다양한 설계 전략을 적용함

Architecture Design : WHY

• 설계가 불량하면 시스템 요구사항을 충족하지 못하거나, 미래 요구사항 변경에 적응하지 못하거나, 재사용할 수 없거나, 예측 불가능한 동작을 나타내거나, 성능이 나쁜 제품이 될 수 있음
  • 아키텍처 설계 단계에서 적절한 계획이 없다면, 소프트웨어 생산은 시간과 비용 측면에서 매우 비효율적일 수 있음
• 대조적으로, 좋은 소프트웨어 설계는 소프트웨어 제작과 관련된 위험을 줄이고, 개발팀이 질서 있는 방식으로 함께 작업할 수 있도록 지원하며, 시스템을 구현 및 테스트를 위해 추적 가능하게 만들며, 더 높은 품질 속성을 가진 소프트웨어 제품으로 이어짐

Architecture Design : WHEN

Software Development Life Cycle (SDLC)

• software requirements analysis stage
• software design (architecture and detailed) stage (early phase)
• software development and implementation stage
• testing and quality assurance, maintenance, and evolution stage

Architecture Design : OUTPUT

➡️ 구축할 소프트웨어의 전체적인 표현

• The IEEE Std 1016-IEEE Recommended Practice for Software Design Descriptions (SDD)
  • design overview, purpose, scope
  • decomposition description (module, data, process)
  • dependency and connection description (between modules, data, and processes)
  • attributes
  • user interface description
  • detailed design (module and data)

IEEE standard for software life cycle

• SQA – Software quality assurance IEEE 730
• SCM – Software configuration management IEEE 828
• STD – Software test documentation IEEE 829
• SRS – Software requirements specification IEEE 830
• V&V – Software verification and validation IEEE 1012
• SDD – Software design description IEEE 1016
• SPM – Software project management IEEE 1058
• SUD – Software user documentation IEEE 1063

Software requirements specification (SRS)

요구사항 모델링

• information domain modeling, data modeling
• function modeling, behavioral modeling
• user interface modeling

요구사항 설명

• UML use-case specifications
• Data Flow Diagrams (DFD)
• State Transition Diagrams (STD)

두가지 측면

• Functional requirement: the functionality of the software system
• Nonfunctional requirement: system qualities, constraints, and behaviors

Architecture Design Guidelines

Software Architect’s Task

• 시스템을 정적 분할(static partition) 및 하위 시스템으로 분해(decomposition)하고 하위 시스템 간 통신을 수행
• 데이터 흐름, 제어 흐름 조정 또는 메시지 발송 측면에서 서로 다른 서브시스템 간에 동적 제어 관계(dynamic control relationships)를 설정함
• 아키텍처 스타일을 선택하는 동안 품질 속성 및 기타 비기능 요구사항에 대한 절충 분석을 수행함

Architecture Styles

• 유사한 설계 집단의 공통 속성을 추상화 함
• 시스템을 요소와 커넥터의 집합으로 구성하는 방법에 대한 일련의 규칙, 제약 조건, 패턴이 포함됨
• 구성 요소 유형의 전반적인 구조 설계 패턴과 흐름 제어 및 데이터 전송의 런타임 상호 작용을 제어함

Key Component of an architecture style

• element : 시스템에 필요한 기능을 수행
• connector : 요소 간의 의사소통, 조정, 협력을 가능하게 함
• constraint : 어떻게 요소를 통합하여 시스템을 구성할건지 정의함
• attributes : 선택한 structure의 장단점을 설명

Software Architecture Design Guidelines

• 어떻게해야 할지 생각하기 전에 무엇을 해야 할지 생각해라.
  • 아키텍처 및 세부 설계 작업을 수행하기 전에 기능적 및 비기능적 요구사항을 식별, 검증 및 검증해야 함
• 구체적인 디자인을 생각하기 전에 추상적인 디자인을 생각해라.
  • 구성 요소의 인터페이스와 추상 데이터 유형을 지정하는 추상 설계부터 시작해야 함
• 설계 프로세스 초기 비기능적 요구사항을 생각해라.
  • 기능 요구사항을 아키텍처 설계에 매핑할 때는 비기능 요구사항도 고려해야 함
• 소프트웨어 재사용성과 확장성을 가능한 한 많이 생각해라
  • 새로운 시스템의 신뢰성과 비용 효율성을 높이기 위해 기존 소프트웨어 구성 요소를 재사용하는 방법을 고려해야 함
• 각 요소 내에서 높은 응집력(high cohesion)과 요소 간의 느슨한 결합(loose coupling)을 촉진하도록 노력해라.
• Tolerate refinement of design
  • 프로토타이핑과 반복을 사용하여 디자인을 다듬어야 할 수도 있음
• 애매모호한 설계와 지나치게 상세한 설계는 피해라.
  • 모호한 설계는 제약 조건이 부족하고 과도한 세부 설계는 구현을 제한함

Models for Software Architecture

소프트웨어 아키텍처는 decomposition, composition, architecture styles, quality attributes을 사용함으로써 높은 수준의 소프트웨어 시스템 추상화를 명시함

• Software Architecture
  • 구성 요소의 집합과 연결에 대해 설명함
  • 이들 구성요소들 사이의 상호작용을 설명함
  • 모든 구성 요소 및 연결의 배포 구성을 구체화함
  • 프로젝트의 기능적 및 비기능적 요구사항을 준수함

Ways to describe Software Architecture

• Box-and-line diagram
  • Boxes - business concept diagram
  • Lines - relationship among components
• UML
  • Structural (Static) Diagrams
  • Behavioral (Dynamic) Diagrams
• Architecture View Models
  • 4+1 view model
• Architecture Description Language (ADL)