Software Architecture

S/W Architecture - 시스템 구조 설명 View

SW 아키텍처 문서 작성 시 다양한 관점(View)을 통해 시스템의 구조와 동작을 설명할 수 있는데, 주로 사용되는 View는 Context View, Module View, Behavior View, Deployment View입니다. 각 View는 서로 다른 측면에서 시스템을 분석하고 설명하는 역할을 하며, 차이점을 비교해보면 다음과 같습니다:1. Context View목적: 시스템의 외부 환경과 상호작용을 설명주요 내용: 시스템이 외부 엔티티(사용자, 다른 시스템 등)와 어떻게 상호작용하는지를 다룬다. 즉, 시스템의 경계를 정의하고 외부에서 시스템으로 들어오거나 나가는 데이터를 설명한다.예시: 시스템이 어떤 외부 서비스와 통신하는지, 사용자 인터페이스(UI)와의 상호작용은 어떤 방식으로 이루어지는지..

[SW Architecture] 불변의 법칙

고객은 본인이 원하는 결과물을 100프로 알지 못한다. 소프트웨어를 설계하기 위해 고객의 요구사항을 경청하고 정리하고 이끌어내는 과정은 매우 중요하다. 고객들 중 대다수는 자신이 원하는 결과물이 어떠한 형태로 만들어지고 어떠한 기능이 있어야 하는지 대략적으로만 설명하고, 중요한 기능들을 놓치는 경우도 많다. 이러한 요구사항을 최대한 이끌어내고 추후에 주어질 요구사항에 대비해야 하는게 소프트웨어 아키텍트로서의 중요한 자질이고 아키텍트로서의 즐거움일 것이다. 소프트웨어의 변화는 변하지 않는 불변의 법칙 고객의 요구사항은 항상 변경될 수 있고 추가 또는 제거될 수 있다. 이것은 소프트웨어 설계의 불변의 법칙 이다. 변하지 않는 소프트웨어는 없고, 발전되지 않는 소프트웨어는 존재하지 않는다. 만약 그렇다면 아키..

아키텍처 사고

Architecture Thinking 아키텍트는 개발자와는 다른 관점을 가지고 프로젝트를 바라봐야 합니다. 이때 가져야하는 관점, 사고를 아키텍처 사고라고 합니다. 아키텍트를 목표로 하는 개발자들이 아키텍처를 바라보는 시야, 관점은 모두다 다르지만, 너무 단순하게 생각하는 분들도 간혹 봐왔습니다. Fundamentals of Software Architecture 의 저자가 아키텍처 사고에 대해 잘 정리한 것 같아 참고하여 정리해보려 합니다. 해당 책의 저자는 아키텍처 사고를 크게 4가지로 나누고 있습니다. 첫째, 아키텍처와 설계의 차이를 이해하고 아키텍처 작업을 진행하려면 개발팀과 어떻게 협력해야 할지 아는 것 둘째, 어느 정도 기술 깊이를 유지하면서 폭넓은 기술 지식을 확보하는 것 셋째, 다양한 솔..

[Requirement Engineering] 설계 시 필요한 제약

아키텍처 핵심 요구사항에 꼭 필요한 부분은 제약사항이다. 제약은 소프트웨어 설계 시 꼭 검토해야 하는 사항입니다. "제약이란 이미 정해져서 변경이 불가능한 설계상의 의사결정" 을 의미합니다. 제약은 이해관계자들과의 논의 과정 중에서 발생할 수도 있고, 아키텍트 스스로 만들어 내는 제약도 존재합니다. 잘 선택한 제약은 소프트웨어 설계에 큰 도움이 된다. 제약은 아키텍트가 설계할 때 선택할 수 있는 다양한 구조를 제한하지만 요구사항 분석 과정에서 잘 정리된 제약은 문제를 단순화하고 좋은 아키텍처를 만드는데 큰 도움이 됩니다. 하지만 제약사항을 잘못 정의하는 경우에는 문제가 커질 수 있으며 또는 이해관계자들의 요구사항을 만족할 수 있는 경우가 발생하기도 합니다. 제약은 비지니스 모델과 설계에 필요로하는 기술에..

[Requirement Engineering] 이해관계자(Stakeholder)와의 대화

이해관계자(Stakeholder)는 어떠한 소프트웨어 시스템에 관심이 있거나 관여된 사람들을 말합니다. 고객이 될 수도 있고, 개발팀과 연관된 검증팀, 디자인팀, 기획팀의 사람이 이해관계자가 될 수도 있습니다. 이해관계자(Stakeholder)는 명확하게 자신이 원하는 바를 모를 수 있다. 소프트웨어 시스템 설계에 앞서 고객, 또는 시스템과 연관된 Stakeholder들과의 대화, 회의는 필수적입니다. 설계자가 이해관계자들과 대화없이 스스로 생각한 바를 설계해 나간다면 결과물은 이해관계자들의 생각과는 전혀 다른 방향이 될 수 있습니다. 그렇기에 이해관계자와의 대화는 매우 중요합니다. 이해관계자들과 대화를 하다보면 명확하게 어떤 결과물을 원하는지 모르는 경우가 많습니다. 특정 어플리케이션을 개발한다고 가정..

[S/W Architecture] Hierarchical Software Architecture

Hierarchical Software Architecture, 한국어로 계층적 소프트웨어 아키텍처라 불리는 아키텍처에 대해 정리하겠습니다. Hierarchical Architecture는 전체 시스템을 계층 구조적으로 나뉘어져 있으며 계층적으로 서로 다른 레벨의 서브시스템으로 구성되어 있습니다. Hierarchical Software Architecture는 매우 다양한 곳에서 사용되고 있습니다. 운영체제, 네트워크 프로토콜 계층들, 인터프리터, 그 외 다양한 곳에서 사용되고 있는데요, 이 아키텍처의 가장 대표적인 구조로서 여러분들이 가장 많이 접해본 아키텍처의 한 예가 안드로이드 일 것 같습니다. 위 안드로이드 아키텍처를 보시면 Applications, Application Framework, Lib..