4+1 — различия между версиями

м
 
(не показано 7 промежуточных версий этого же участника)
Строка 1: Строка 1:
Модель '''4+1''' предлагает простой и понятный способ описания [[Архитектура|архитектуры]] сложных [[система|систем]], который состоит в использовании пяти различных [[Принцип множества групп описаний|групп описания]] (views):
+
Модель '''4+1''' (Philippe Kruchten, Rational Software Corp., 1995) предлагает простой и понятный способ описания [[Архитектура|архитектуры]] сложных [[система|систем]], который состоит в использовании пяти различных [[Принцип множества групп описаний|групп описания]] (views):
 
* '''Логическое представление'''. Является объектной моделью проектирования (в том случае, если используется объектно-ориентированная модель проектирования).
 
* '''Логическое представление'''. Является объектной моделью проектирования (в том случае, если используется объектно-ориентированная модель проектирования).
*: описание функциональных [[требований]]: что система должна выполнять в терминах конечных пользователей. Для этого представления используются различные абстрактные конструкции, такие как объекты и классы объектов. Для их иллюстрирования могут применяться диаграммы классов (в нотации языка [[UML]]) либо, например, диаграммы "сущность-связь", если в разработке приложения доминируют данные.
+
*: описание функциональных [[Требования|требований]]: что система должна выполнять в терминах конечных пользователей. Для этого представления используются различные абстрактные конструкции, такие как объекты и классы объектов. Для их иллюстрирования могут применяться диаграммы классов (в нотации языка [[UML]]) либо, например, [[ERD|диаграммы "сущность-связь"]], если в разработке приложения доминируют данные.
 
* '''Процессное представление'''. Описывает вопросы параллельного исполнения и синхронизации процессов.
 
* '''Процессное представление'''. Описывает вопросы параллельного исполнения и синхронизации процессов.
 
*: нефункциональные требования к системе, включая производительность и доступность. С помощью этого представления рассматриваются такие аспекты, как одновременное выполнение и распределение процессов, интеграция системы, устойчивость к сбоям, а также то, как основные объекты абстракции, рассмотренные на уровне логического представления, соответствуют архитектуре процессов. Архитектура процессов может быть представлена на различных уровнях абстракции. На самом высоком уровне система рассматривается как набор независимо выполняемых сетей взаимодействующих между собой программ. На более низких уровнях рассматриваются процессы и задачи.
 
*: нефункциональные требования к системе, включая производительность и доступность. С помощью этого представления рассматриваются такие аспекты, как одновременное выполнение и распределение процессов, интеграция системы, устойчивость к сбоям, а также то, как основные объекты абстракции, рассмотренные на уровне логического представления, соответствуют архитектуре процессов. Архитектура процессов может быть представлена на различных уровнях абстракции. На самом высоком уровне система рассматривается как набор независимо выполняемых сетей взаимодействующих между собой программ. На более низких уровнях рассматриваются процессы и задачи.
 
* '''Физическое представление'''. Описывает размещение программных компонент системы на аппаратных платформах и аспекты, связанные с физическим расположением системы.
 
* '''Физическое представление'''. Описывает размещение программных компонент системы на аппаратных платформах и аспекты, связанные с физическим расположением системы.
 
*: фактическая организация модулей системы, разделение ее на подсистемы, которые могут разрабатываться независимо.
 
*: фактическая организация модулей системы, разделение ее на подсистемы, которые могут разрабатываться независимо.
* '''Представление уровня разработки'''. Описывает статическую организацию программной системы в среде разработки.
+
* '''Представление уровня разработки'''. Описывает статическую организацию [[программная система|программной системы]] в среде разработки.
 
*: нефункциональные требования, такие как доступность, надежность, устойчивость, производительность, масштабируемость. Этот уровень описывает распределение различных элементов – сетей, процессов, задач и объектов – по различным узлам (элементам аппаратного обеспечения, объединенным в сеть).
 
*: нефункциональные требования, такие как доступность, надежность, устойчивость, производительность, масштабируемость. Этот уровень описывает распределение различных элементов – сетей, процессов, задач и объектов – по различным узлам (элементам аппаратного обеспечения, объединенным в сеть).
* '''Сценарии использования''' (use cases) объединяют все 4 представления вместе. Сценарии использования описываются как последовательность взаимодействия объектов и процессов. Они отражают наиболее важные требования, которым должна удовлетворять система. Это представление в каком-то смысле является избыточным и пересекается с четырьмя предыдущими, но оно важно по следующим причинам:
+
* '''Представление сценариев''' объединяет все 4 представления вместе.
 +
*: [[Сценарий использования|Сценарии использования]] (use cases) и [[Пользовательские истории]] (user stories) описываются как последовательность взаимодействия объектов и процессов. Они отражают наиболее важные требования, которым должна удовлетворять система. Это представление в каком-то смысле является избыточным и пересекается с четырьмя предыдущими, но оно важно по следующим причинам:
 
** Сценарии использования позволяют идентифицировать элементы архитектуры, которые требуются для эффективно работающей системы.
 
** Сценарии использования позволяют идентифицировать элементы архитектуры, которые требуются для эффективно работающей системы.
 
** С помощью сценариев можно выполнять проверку и иллюстрацию того, что архитектура является работоспособной и полной. Это также является основой для проведения тестирования архитектурного прототипа.
 
** С помощью сценариев можно выполнять проверку и иллюстрацию того, что архитектура является работоспособной и полной. Это также является основой для проведения тестирования архитектурного прототипа.
 +
 +
 +
[[Файл:4_pluss_1_view_of_sw_architecture.PNG|center]]
 +
 +
== Ссылки ==
 +
* [http://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf Architectural Blueprints—The “4+1” View Model of Software Architecture]
  
 
[[Категория:Архитектурные подходы]]
 
[[Категория:Архитектурные подходы]]

Текущая версия на 11:07, 3 сентября 2019

Модель 4+1 (Philippe Kruchten, Rational Software Corp., 1995) предлагает простой и понятный способ описания архитектуры сложных систем, который состоит в использовании пяти различных групп описания (views):

  • Логическое представление. Является объектной моделью проектирования (в том случае, если используется объектно-ориентированная модель проектирования).
    описание функциональных требований: что система должна выполнять в терминах конечных пользователей. Для этого представления используются различные абстрактные конструкции, такие как объекты и классы объектов. Для их иллюстрирования могут применяться диаграммы классов (в нотации языка UML) либо, например, диаграммы "сущность-связь", если в разработке приложения доминируют данные.
  • Процессное представление. Описывает вопросы параллельного исполнения и синхронизации процессов.
    нефункциональные требования к системе, включая производительность и доступность. С помощью этого представления рассматриваются такие аспекты, как одновременное выполнение и распределение процессов, интеграция системы, устойчивость к сбоям, а также то, как основные объекты абстракции, рассмотренные на уровне логического представления, соответствуют архитектуре процессов. Архитектура процессов может быть представлена на различных уровнях абстракции. На самом высоком уровне система рассматривается как набор независимо выполняемых сетей взаимодействующих между собой программ. На более низких уровнях рассматриваются процессы и задачи.
  • Физическое представление. Описывает размещение программных компонент системы на аппаратных платформах и аспекты, связанные с физическим расположением системы.
    фактическая организация модулей системы, разделение ее на подсистемы, которые могут разрабатываться независимо.
  • Представление уровня разработки. Описывает статическую организацию программной системы в среде разработки.
    нефункциональные требования, такие как доступность, надежность, устойчивость, производительность, масштабируемость. Этот уровень описывает распределение различных элементов – сетей, процессов, задач и объектов – по различным узлам (элементам аппаратного обеспечения, объединенным в сеть).
  • Представление сценариев объединяет все 4 представления вместе.
    Сценарии использования (use cases) и Пользовательские истории (user stories) описываются как последовательность взаимодействия объектов и процессов. Они отражают наиболее важные требования, которым должна удовлетворять система. Это представление в каком-то смысле является избыточным и пересекается с четырьмя предыдущими, но оно важно по следующим причинам:
    • Сценарии использования позволяют идентифицировать элементы архитектуры, которые требуются для эффективно работающей системы.
    • С помощью сценариев можно выполнять проверку и иллюстрацию того, что архитектура является работоспособной и полной. Это также является основой для проведения тестирования архитектурного прототипа.


4 pluss 1 view of sw architecture.PNG

Ссылки