소프트웨어 아키텍처 모델

Software architectural model
안 된다 혼동해서는컴퓨터 모델과.

아키텍처 모델(소프트웨어에서)은 풍부하고 엄격한 다이어그램으로, 이용 가능한 표준을 사용하여 작성되며, 주요 관심사는 시스템 또는 생태계의 구조와 설계에 내재된 특정한 트레이드오프를 설명하는 것이다.소프트웨어 설계자들은 다른 사람들과 의사소통하고 또래 피드백을 찾기 위해 건축 모델을 사용한다.아키텍처 모델은 소프트웨어 아키텍처의 관점을 표현하는 것이다.

소프트웨어 아키텍처 모델의 몇 가지 핵심 요소는 다음과 같다.

  • 리치: 문제의 관점에서, 그 지역을 자세히 설명하기에 충분한 정보가 있어야 한다.정보가 부족하거나 모호해서는 안 된다.오해는 최소화하는 게 목표지, 영구화하는 게 아니다.'주요 관심사'에 대한 아래 참고 사항을 참조하십시오.
  • 엄격함: 설계자는 이 특정 모델을 만들기 위해 특정한 방법론을 적용했고, 그 결과 모델은 특정한 방식으로 '비교적'했다.여기 엄격함의 테스트가 있다.서로 다른 도시에 있는 두 건축가가 동일한 것을 설명하고 있다면 결과 도표는 거의 동일할 것이다(시각적 레이아웃은 예외로 할 수 있음).
  • 다이어그램: 일반적으로 모델은 특정 관점을 설명하기 위해 무언가를 단순화하는 추상화를 가리킬 수 있다.이 정의는 특히 다이어그램으로 표현되는 모델 설명의 하위 집합에 '건축 모델'을 분류한다.
  • 표준: 표준은 모든 사람이 표준들을 알고 모든 사람이 표준들을 사용할 때 효과가 있다.이것은 각 다이어그램이 다른 다이어그램과 실질적으로 다를 때 달성할 수 없는 수준의 통신을 허용한다.UML은 가장 자주 인용되는 표준이다.
  • 일차적인 우려: 하나의 도표에 많은 다른 니즈를 포함시킴으로써 너무 상세해지는 것은 쉽다.이것은 피해야 한다.내용이 풍부해 이를 이해하려면 2년 과정의 학습 과정이 필요할 정도로 '메가 다이어그램'을 그리는 것보다 각 관점에 하나씩 복수의 다이어그램을 그리는 것이 좋다.기억하라: 집을 지을 때, 건축가는 많은 다른 도표를 전달한다.각각은 다르게 사용된다.종종 최종 계획 패키지에는 평면도를 포함한 도표가 여러 번 포함된다: 골조 계획, 전기 계획, 난방 계획, 배관 등.그들은 단지 도면이므로 도면에 들어갈 수 있는 정보의 100%를 도면에 넣어야 한다고만 말하지 않는다.배관 하청업자는 전기 기사가 신경 쓰는 세부 사항은 필요 없다.
  • 예시: 모델을 만드는 이면에 있는 아이디어는 의사소통하고 가치 있는 피드백을 찾는 것이다.다이어그램의 목적은 특정 질문에 대답하고 그 답을 다른 사람과 공유하여 (a) 그들이 동의하는지 확인하고 (b) 그들의 작업을 안내하는 것이어야 한다.경험의 법칙: 당신이 말하고 싶은 것이 무엇이며, 당신이 누구의 일로 영향을 미치려고 하는지를 알고 있다.
  • 구체적인 절충: 아키텍처 트레이드오프 분석 방법론(ATAM)은 소프트웨어 아키텍처가 적합성을 위해 상호 검토될 수 있는 프로세스를 설명한다.ATAM은 '모든 것을 하나로 맞추는' 설계는 없다는 기본 개념에서 출발하여 이것을 한다.우리는 일반적인 디자인을 만들 수 있지만, 그 다음엔 비즈니스 요구사항에 따라 특정 상황에 맞게 변경해야 해.사실상, 우리는 절충을 한다.도표는 그러한 특정 절충을 가시적으로 보여야 한다.따라서 설계자가 도표를 작성하기 전에, 이 모델에서 어떤 트레이드오프를 설명하려고 하는지를 말로 설명할 준비가 되어 있어야 한다.
  • 구조와 설계에 내재된 트레이드오프: 구성요소는 트레이드오프가 아니다.트레이드오프는 다이어그램에서 이미지로 변환되는 경우가 거의 없다.트레이드오프는 설계 모델을 생산한 첫 번째 원칙이다.건축가가 특정한 절충을 묘사하거나 방어하고자 할 때, 그 도표를 사용하여 위치를 방어할 수 있다.
  • 시스템 또는 생태계: 일반적으로 모델링은 다양한 추상화 수준에서 수행될 수 있다.요소와 상호작용으로 완성된 특정 애플리케이션의 아키텍처를 모델링하는 것이 유용하다.완전한 비즈니스 프로세스(예: 주문 대 현금)를 제공하는 데 필요한 애플리케이션 시스템을 모델링하는 것도 합리적이다.그러나 단일 요소와 그 클래스의 모델을 소프트웨어 아키텍처로 보는 것은 일반적으로 유용하지 않다.그 수준에서, 모델은 그 자체로 가치가 있지만, 구조보다 훨씬 더 설계를 잘 보여준다.

참고 항목

참조

외부 링크


Stub icon

이 소프트웨어 공학 관련 기사는 단조롭다.위키피디아를 확장하여 도울 수 있다.