Принцип множества групп описаний - История изменений

Admin: /* Основные понятия */

2018-02-11T19:09:28Z

‎Основные понятия

Admin: /* Основные понятия */

2016-10-12T11:15:45Z

‎Основные понятия

Admin: /* Основные понятия */

2016-10-12T11:14:26Z

‎Основные понятия

Admin: /* Основные понятия */

2016-10-12T11:08:47Z

‎Основные понятия

Admin в 14:09, 18 мая 2016

2016-05-18T14:09:02Z

Admin в 07:07, 13 мая 2016

2016-05-13T07:07:52Z

Admin: Новая страница: «'''Множественность описания''' систем имеет гносеологические корни и связана с объектив…»

2015-12-18T11:26:25Z

Новая страница: «'''Множественность описания''' систем имеет гносеологические корни и связана с объектив…»

Новая страница

'''Множественность описания''' систем имеет гносеологические корни и связана с объективной потребностью познания человеком окружающего мира (получение объективных знаний), а также использования полученных знаний в повседневной практике (в частности, в интересах управления). Конечной целью описания чаще всего становится выявление, изучение и измерение интенсивности свойств системы и ее элементов, определение влияния этих свойств на окружающую среду (на надсистемы), а также влияния на свойства системы свойств окружающей среды.

Подход множественности описания ([https://en.wikipedia.org/wiki/View_model view model, viewpoints framework]) определяет набор согласованных групп описания (set of views) при построении системной архитектуры. Группа описания — это представление всей системы с определенной перспективы относительно набора интересов (set of concerns) различных стейкхолдеров.

== Основные понятия ==
* Группа описаний (View)
* [[Метод описания]] (Viewpoint)
* Modeling perspectives
* Viewpoint model
* Описание архитектуры (Architecture description)

== Модели представления архитектуры системы ==
=== Three schema approach ===
Трехсхемный подход это архитектурный подход в инженерии программного обеспечения используемый для построения информационных систем. Разработан в 70-ых годах прошлого столетия рабочей группой ANSI/SPARC под руководством Чарльза Бахмана.

До внедрения трехсхемного подхода существовал традиционный подход двух схем. Первый тип схем отображал модель данных с точки зрения пользователя, в контексте форм, отчетов, что соответствует внешней схеме. Второй тип соответствовал внутренней схеме, то есть то как данные хранятся и извлекаются из хранилища в компьютере.

Поскольку эта схема не совершена, точнее не позволяет моделировать семантическую целостность было решено группой Бахмана ввести третий, промежуточный уровень, именуемый концептуальным. Концептуальная схема объединяет то как видит и вводит информацию пользователь с тем как она хранится и извлекается в компьютере. Концептуальная схема позволяет понимать систему независимо от конкретных приложений и структур данных. Схема обозревает смысл обрабатываемой информации и взаимосвязи ее частей.

Подход использует три разных представления в виде схем для разработки систем, в процессе которой концептуальное моделирование рассмотрено как ключ к достижению интеграции данных.

Три используемых типа схем:
* Внешняя схема, отображающая то, как видит систему пользователь;
* Концептуальная схема, объединяющая множество внешних схем с множеством внутренних;
* Внутренняя схема, объявляющая структуры физического хранения данных;

В настоящее время на основе этого подхода разработаны другие методологии. К примеру, IDEF1X использует идею трех схем,а [[Матрица Захмана|фреймворк Закмана]] включает эти три схемы в виде слоев.

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

== Модели представления архитектуры предприятия ==
=== EA framework ===
* '''«Предприятие»''' является бизнес ассоциацией, состоящей из признанной совокупности взаимодействующих бизнес функций. Она способна работать как независимая, отдельная организация. Согласно такому определению, могут существовать предприятия в пределах предприятий. Например, организационная единица внутри общей корпоративной организации может быть рассмотрена как предприятие при наличии возможности независимого функционирования. Предприятие можно также рассматривать как «Расширенное предприятие (Extended Enterprise)»; это означает, что масштаб архитектуры предприятия может также включать взаимосвязи с внешними организациями. Такими как: поставщики, бизнес-партнеры и клиенты.
* '''«Архитектура»''' обеспечивает базовую концепцию. Она определяет и описывает платформу, необходимую предприятию для достижения своих задач и своего видения. Ее можно определить как: совокупность принципов, ориентиров, правил, моделей, стандартов и процессов, соответствующих требованиям бизнес стратегии и информации, направляющих выбор, создание и внедрение решений для будущих направлений бизнеса.

=== Zachman Framework ===
См. [[Матрица Захмана]]

=== RM-ODP views ===
Эталонная модель открытой распределенной обработки (Reference Model of Open Distributed Processing, RM-ODP) используется в информатике для описания исходной структуры открытой распределенной обработки с целью ее стандартизации.

Многочисленные концепции RM-ODP, под разными названиями, существуют уже долгое время. Они были тщательно описаны и объяснены в точной философии (например, в работах Марио Бунге), а также в [[Системный подход|системном подходе]] (например, в работах Фридриха Хайека). Некоторые из этих концепций, - абстракции, композиции, эмерджентности, - недавно получили твёрдое математическое обоснование в теории категорий.

RM-ODP имеет четыре основных черты:
* объектно-моделированный подход к спецификации системы;
* техническое описание системы с позиций отдельных, но взаимосвязанных точек зрения на спецификацию;
* способность системной инфраструктуры обеспечивать прозрачность распределения для системных приложений;
* критерии для оценки системы на соответствие стандартам.

Перечень рекомендаций и международных стандартов обозначает основные понятия, необходимые для определения открытых распределенных систем обработки, а также описывает структурные требования к архитектуре, предлагая спецификации для любых крупномасштабных систем, включая программные системы.

[[Категория: Подходы]]

@@ Строка 8: / Строка 8: @@
 * Перспектива (Modeling perspectives)
 * Модель метода описания (Viewpoint model)
-* Описание архитектуры (Architecture description)
+* [[Описание архитектуры]] (Architecture description)
 == Модели представления архитектуры системы ==

@@ Строка 15: / Строка 15: @@
 == Модели представления архитектуры предприятия ==
-* [[EA]]
+см. [[Архитектура предприятия#Подходы к описанию архитектуры предприятия|Архитектурные методологии/подходы]]
-* [[ZF]]
-* [[TOGAF]]
-* [[RM-ODP]]
 [[Категория: Подходы]]

@@ Строка 4: / Строка 4: @@
 == Основные понятия ==
-* Группа описаний (View)
+* Группа описаний, описание, представление (View)
 * [[Метод описания]] (Viewpoint)
 * Перспектива (Modeling perspectives)

@@ Строка 2: / Строка 2: @@
 Подход множественности описания ([https://en.wikipedia.org/wiki/View_model view model, viewpoints framework]) определяет набор согласованных групп описания (set of views) при построении системной архитектуры. Группа описания — это представление всей системы с определенной перспективы относительно набора интересов (set of concerns) различных стейкхолдеров.
 == Основные понятия ==
@@ Строка 10: / Строка 9: @@
 * Viewpoint model
 * Описание архитектуры (Architecture description)
 == Модели представления архитектуры системы ==
-=== Three schema approach ===
+* [[Three-schema approach]]
-Трехсхемный подход это архитектурный подход в инженерии программного обеспечения используемый для построения информационных систем. Разработан в 70-ых годах прошлого столетия рабочей группой ANSI/SPARC под руководством Чарльза Бахмана.
+* [[4+1]]
-−
-До внедрения трехсхемного подхода существовал традиционный подход двух схем. Первый тип схем отображал модель данных с точки зрения пользователя, в контексте форм, отчетов, что соответствует внешней схеме. Второй тип соответствовал внутренней схеме, то есть то как данные хранятся и извлекаются из хранилища в компьютере.
-−
-Поскольку эта схема не совершена, точнее не позволяет моделировать семантическую целостность было решено группой Бахмана ввести третий, промежуточный уровень, именуемый концептуальным. Концептуальная схема объединяет то как видит и вводит информацию пользователь с тем как она хранится и извлекается в компьютере. Концептуальная схема позволяет понимать систему независимо от конкретных приложений и структур данных. Схема обозревает смысл обрабатываемой информации и взаимосвязи ее частей.
-−
-Подход использует три разных представления в виде схем для разработки систем, в процессе которой концептуальное моделирование рассмотрено как ключ к достижению интеграции данных.
-−
-Три используемых типа схем:
-* Внешняя схема, отображающая то, как видит систему пользователь;
-* Концептуальная схема, объединяющая множество внешних схем с множеством внутренних;
-* Внутренняя схема, объявляющая структуры физического хранения данных;
-−
-В настоящее время на основе этого подхода разработаны другие методологии. К примеру, IDEF1X использует идею трех схем,а [[Матрица Захмана|фреймворк Закмана]] включает эти три схемы в виде слоев.
-−
-−
-=== 4+1 ===
-Модель предлагает простой и понятный способ описания архитектуры сложных систем, который состоит в использовании пяти различных групп описания (views):
-* '''Логическое представление'''. Является объектной моделью проектирования (в том случае, если используется объектно-ориентированная модель проектирования).
-*: описание функциональных требований: что система должна выполнять в терминах конечных пользователей. Для этого представления используются различные абстрактные конструкции, такие как объекты и классы объектов. Для их иллюстрирования могут применяться диаграммы классов (в нотации языка UML) либо, например, диаграммы "сущность-связь", если в разработке приложения доминируют данные.
-* '''Процессное представление'''. Описывает вопросы параллельного исполнения и синхронизации процессов.
-*: нефункциональные требования к системе, включая производительность и доступность. С помощью этого представления рассматриваются такие аспекты, как одновременное выполнение и распределение процессов, интеграция системы, устойчивость к сбоям, а также то, как основные объекты абстракции, рассмотренные на уровне логического представления, соответствуют архитектуре процессов. Архитектура процессов может быть представлена на различных уровнях абстракции. На самом высоком уровне система рассматривается как набор независимо выполняемых сетей взаимодействующих между собой программ. На более низких уровнях рассматриваются процессы и задачи.
-* '''Физическое представление'''. Описывает размещение программных компонент системы на аппаратных платформах и аспекты, связанные с физическим расположением системы.
-*: фактическая организация модулей системы, разделение ее на подсистемы, которые могут разрабатываться независимо.
-* '''Представление уровня разработки'''. Описывает статическую организацию программной системы в среде разработки.
-*: нефункциональные требования, такие как доступность, надежность, устойчивость, производительность, масштабируемость. Этот уровень описывает распределение различных элементов – сетей, процессов, задач и объектов – по различным узлам (элементам аппаратного обеспечения, объединенным в сеть).
-* '''Сценарии использования''' (use cases) объединяют все 4 представления вместе. Сценарии использования описываются как последовательность взаимодействия объектов и процессов. Они отражают наиболее важные требования, которым должна удовлетворять система. Это представление в каком-то смысле является избыточным и пересекается с четырьмя предыдущими, но оно важно по следующим причинам:
-** Сценарии использования позволяют идентифицировать элементы архитектуры, которые требуются для эффективно работающей системы.
-** С помощью сценариев можно выполнять проверку и иллюстрацию того, что архитектура является работоспособной и полной. Это также является основой для проведения тестирования архитектурного прототипа.
-−
 == Модели представления архитектуры предприятия ==
-=== EA framework ===
+* [[EA]]
-* '''«Предприятие»''' является бизнес ассоциацией, состоящей из признанной совокупности взаимодействующих бизнес функций. Она способна работать как независимая, отдельная организация. Согласно такому определению, могут существовать предприятия в пределах предприятий. Например, организационная единица внутри общей корпоративной организации может быть рассмотрена как предприятие при наличии возможности независимого функционирования. Предприятие можно также рассматривать как «Расширенное предприятие (Extended Enterprise)»; это означает, что масштаб архитектуры предприятия может также включать взаимосвязи с внешними организациями. Такими как: поставщики, бизнес-партнеры и клиенты.
+* [[ZF]]
-* '''«Архитектура»''' обеспечивает базовую концепцию. Она определяет и описывает платформу, необходимую предприятию для достижения своих задач и своего видения. Ее можно определить как: совокупность принципов, ориентиров, правил, моделей, стандартов и процессов, соответствующих требованиям бизнес стратегии и информации, направляющих выбор, создание и внедрение решений для будущих направлений бизнеса.
+* [[TOGAF]]
+* [[RM-ODP]]
-−
-=== Zachman Framework ===
-См. [[Матрица Захмана]]
-−
-−
-=== RM-ODP views ===
-Эталонная модель открытой распределенной обработки (Reference Model of Open Distributed Processing, RM-ODP) используется в информатике для описания исходной структуры открытой распределенной обработки с целью ее стандартизации.
-−
-Многочисленные концепции RM-ODP, под разными названиями, существуют уже долгое время. Они были тщательно описаны и объяснены в точной философии (например, в работах Марио Бунге), а также в [[Системный подход|системном подходе]] (например, в работах Фридриха Хайека). Некоторые из этих концепций, - абстракции, композиции, эмерджентности, - недавно получили твёрдое математическое обоснование в теории категорий.
-−
-RM-ODP имеет четыре основных черты:
-* объектно-моделированный подход к спецификации системы;
-* техническое описание системы с позиций отдельных, но взаимосвязанных точек зрения на спецификацию;
-* способность системной инфраструктуры обеспечивать прозрачность распределения для системных приложений;
-* критерии для оценки системы на соответствие стандартам.
-−
-Перечень рекомендаций и международных стандартов обозначает основные понятия, необходимые для определения открытых распределенных систем обработки, а также описывает структурные требования к архитектуре, предлагая спецификации для любых крупномасштабных систем, включая программные системы.
-−
 [[Категория: Подходы]]

Принцип множества групп описаний - История изменений

Admin: /* Основные понятия */

Admin: /* Основные понятия */

Admin: /* Основные понятия */

Admin: /* Основные понятия */

Admin в 14:09, 18 мая 2016

Admin в 07:07, 13 мая 2016

Admin: Новая страница: «'''Множественность описания''' систем имеет гносеологи­ческие корни и связана с объектив…»

Admin: Новая страница: «'''Множественность описания''' систем имеет гносеологические корни и связана с объектив…»