Архитектура - История изменений

Admin: /* Практики архитектурного проектирования */

2019-08-17T14:49:15Z

‎Практики архитектурного проектирования

Admin в 14:36, 17 августа 2019

2019-08-17T14:36:59Z

Admin: /* Состояния альфы */

2017-02-01T14:54:20Z

‎Состояния альфы

Admin: /* Рабочие продукты описания архитектуры */

2017-02-01T14:53:26Z

‎Рабочие продукты описания архитектуры

Admin: /* Относительность архитектуры */

2016-12-23T19:13:16Z

‎Относительность архитектуры

Admin: /* Анализ альтернатив */

2016-12-23T19:11:08Z

‎Анализ альтернатив

Admin: /* Анализ альтернатив */

2016-12-23T19:09:17Z

‎Анализ альтернатив

Admin: /* Примечания */

2016-12-23T19:08:33Z

‎Примечания

Admin: /* См. также */

2016-12-23T19:08:05Z

‎См. также

Admin: /* Субъективность архитектуры */

2016-12-23T19:03:36Z

‎Субъективность архитектуры

@@ Строка 37: / Строка 37: @@
 == Практики архитектурного проектирования ==
 # '''Общие подходы'''
-#* иерархическое проектирование систем и декомпозиционные подходы
+#* иерархическое проектирование систем и декомпозиционные подходы;
-#* модульное проектирование
+#* модульное проектирование;
 #* проектирование на основе матрицы проектной структуры ([[DSM]], Design Structure Matrix) - метод разбиения системы на модули;
-#* проектирование на основе многокритериального принятия решений (см. [[СППР]])
+#* проектирование на основе многокритериального принятия решений (см. [[СППР]]);
-#* морфологический анализ
+#* морфологический анализ;
-#* объектно-ориентированное проектирование
+#* объектно-ориентированное проектирование;
-#* проектирование на основе компонентов
+#* проектирование на основе компонентов.
 # '''Формальные подходы к системному проектированию'''
-#* аксиоматическое проектирование
+#* аксиоматическое проектирование;
-#* формальные методы проектирования
+#* формальные методы проектирования.
 # '''Оптимизация'''
-#* многодисциплинарная оптимизация
+#* многодисциплинарная оптимизация;
-#* методы смешанного целочисленного нелинейного программирования
+#* методы смешанного целочисленного нелинейного программирования;
-#* различные методы глобальной оптимизации
+#* различные методы глобальной оптимизации;
-#* нелинейная многоцелевая оптимизация
+#* нелинейная многоцелевая оптимизация;
-#* многоцелевая эволюционная оптимизация, включающая генетические алгоритмы
+#* многоцелевая [[Эволюционные алгоритмы|эволюционная оптимизация]], включающая генетические алгоритмы.
 # '''Подходы на основе методов [[AI|искусственного интеллекта]]'''
-#* специальные [[Экспертная система|экспертные системы]] и системы на основе [[База знаний|баз знаний]]
+#* специальные [[Экспертная система|экспертные системы]] и системы на основе [[База знаний|баз знаний]];
-#* проектирование на основе грамматических описаний систем, включая подходы к проектированию составных систем
+#* проектирование на основе грамматических описаний систем, включая подходы к проектированию составных систем;
-#* методы проектирования на основе многоагентных подходов
+#* методы проектирования на основе многоагентных подходов;
-#* методы проектирования на основе задач выполнимости (constraint satisfaction problems)
+#* методы проектирования на основе задач выполнимости (constraint satisfaction problems).
 # '''другое...'''
 #* [[ТРИЗ]] как метод совмещения логической и физической архитектур;

@@ Строка 63: / Строка 63: @@
 #* архитектурные расчёты, в которых принципиальная схема “живая” и по ней можно вести мультифизические расчёты. Например акаузальный язык мультифизического моделирования [[Modelica]];
 #* product lines (например, [http://www.sei.cmu.edu/productlines/frame_report/what.is.a.PL.htm подход для software product line practice, версия 5]);
-#* [[SBSE|поиск-ориентированная инженерия]];
+#* [[Системная инженерия на основе поиска]];
 #* http://www.cfin.ru/management/controlling/sys_project.shtml

@@ Строка 110: / Строка 110: @@
 ! style="text-align: center; font-weight: bold;" | State
 ! style="text-align: center; font-weight: bold;" | Описание
-! style="text-align: center; font-weight: bold;" | Контрольные вопросы
+! style="text-align: center; font-weight: bold; width: 35%;" | Контрольные вопросы
 |-
 | 1

@@ Строка 102: / Строка 102: @@
 ** осмысление изменений конфигурации при модификации системы.
-== Рабочие продукты описания архитектуры ==
+== Состояния альфы ==
-'''Архитектурные описания''' (представления, views) - рабочие продукты для описания архитектуры.
+[[OMG Essence]] определяет следующие состояния для альфы "Архитектуры" и контрольные вопросы для проверки каждого состояния:
-Современный тренд в архитектурных описаниях — это использование формальных (понимаемых компьютером) моделей и задание формализмов в качестве метода описания. В архитектурные описания обязательно входят ещё и [[Обоснование архитектуры|архитектурные обоснования]] (резоны, по которым были приняты те или иные архитектурные решения — '''architecture rationale''').
+{| class="wikitable" style="font-size: 9pt;"
-В архитектурных описаниях могут присутствовать и не-модели, например:
+❑ Any constraints that apply to the architecture have been identified and described.
-* '''Архитектурные текстовые эссе''' оказываются очень полезными для краткого описания того, что было положено в основу моделей архитектурных описаний (выбор метода моделирования), краткого обзора архитектуры в целом как совокупности моделей. Эти же эссе могут быть использованы для пояснений того, как именно были связаны архитектурные модели, а также особенностей моделирования.
-* '''Инфографика''' (а хоть и слайды в PowerPoint) может показать основные архитектурные идеи для не-инженеров (менеджеров, заказчиков, пользователей) — ибо формальные модели могут быть для них непонятны.
-'''Знания''' — это повторноиспользуемая в разных ситуациях информация, т.е. можно говорить об архитектурных знаниях.
+❑ A set of scenarios which demonstrate that the architecture meets its goals has been identified and described.
-'''Архитектурные решения''' – это чаще всего накопленные человечеством, отраслью, организацией, конструктором/проектировщиком знания. Тем не менее лидерство в инженерии обычно определяется предложением новых архитектур — новых инженерных решений, т.е. связано с развитием инженерного знания.
+❑Decisions have been made regarding the implementation platform and the major technologies to employ.
 == Подходы к конструированию описаний ==

@@ Строка 84: / Строка 84: @@
 Системный архитектор или команда системных архитекторов должны предложить сразу несколько разных архитектурных решений (вариантов компонентной структуры/модулей для реализации компонент/разного размещения в пространстве). Лучшие из этих архитектурных решений выбираются при помощи процедуры, известной как [[Анализ компромиссов|trade-off studies]]<ref>Общепринятый русский перевод "''анализ компромиссов''" намекает на взаимные уступки, здесь же выбирается один из вариантов в ущерб других, поэтому более удачные переводы - "''выбор альтернативы''" или "''прохождение развилок''”.</ref>. По этой процедуре готовятся таблицы, в которых баллами оцениваются свойства альтернативных вариантов, а затем подсчитывается сумма с учётом каких-то коэффициентов. В реальной жизни решения обычно принимаются содержательным обсуждением, а затем таблицы для trade-off studies оформляются задним числом для отчётности и демонстрации наличия вариантов, учтённых в работе — это как бы “объективация” субъективно принимаемых решений. Если рассматривалась только одна архитектура, то это считается не слишком хорошей работой системного архитектора.
-== Относительность архитектуры ==
+== Границы архитектуры ==
 '''Относительность архитектуры''' - необходимость разделения архитектурной и неархитектурной частей.

@@ Строка 82: / Строка 82: @@
 * Если предложить разным системным архитекторам спроектировать какую-то систему, то разные системные архитекторы также предложат разные архитектуры — но в данном случае они их “придумают”, а не “выявят”.
-Системный архитектор или команда системных архитекторов должны предложить сразу несколько разных архитектурных решений (вариантов компонентной структуры/модулей для реализации компонент/разного размещения в пространстве). Лучшие из этих архитектурных решений выбираются при помощи процедуры, известной как [[Анализ компромиссов|trade-off studies]]<ref>Общепринятый русский перевод "''анализ компромиссов''" намекает о взаимных уступках, здесь же выбирается один из вариантов в ущерб других, поэтому более удачные переводы - "''выбор альтернативы''" или "''прохождение развилок''”.</ref>. По этой процедуре готовятся таблицы, в которых баллами оцениваются свойства альтернативных вариантов, а затем подсчитывается сумма с учётом каких-то коэффициентов. В реальной жизни решения обычно принимаются содержательным обсуждением, а затем таблицы для trade-off studies оформляются задним числом для отчётности и демонстрации наличия вариантов, учтённых в работе — это как бы “объективация” субъективно принимаемых решений. Если рассматривалась только одна архитектура, то это считается не слишком хорошей работой системного архитектора.
+Системный архитектор или команда системных архитекторов должны предложить сразу несколько разных архитектурных решений (вариантов компонентной структуры/модулей для реализации компонент/разного размещения в пространстве). Лучшие из этих архитектурных решений выбираются при помощи процедуры, известной как [[Анализ компромиссов|trade-off studies]]<ref>Общепринятый русский перевод "''анализ компромиссов''" намекает на взаимные уступки, здесь же выбирается один из вариантов в ущерб других, поэтому более удачные переводы - "''выбор альтернативы''" или "''прохождение развилок''”.</ref>. По этой процедуре готовятся таблицы, в которых баллами оцениваются свойства альтернативных вариантов, а затем подсчитывается сумма с учётом каких-то коэффициентов. В реальной жизни решения обычно принимаются содержательным обсуждением, а затем таблицы для trade-off studies оформляются задним числом для отчётности и демонстрации наличия вариантов, учтённых в работе — это как бы “объективация” субъективно принимаемых решений. Если рассматривалась только одна архитектура, то это считается не слишком хорошей работой системного архитектора.
 == Относительность архитектуры ==

@@ Строка 133: / Строка 133: @@
 == Литература ==
 * М. Левин [http://www.mslevin.iitp.ru/Levin-bk-Nov2013-071.pdf «Технология поддержки решений для модульных систем»].
 == См. также ==
 * [[Инженерия системной архитектуры]]
 [[Категория:Концепции]]
 [[Категория:Альфы]]

@@ Строка 77: / Строка 77: @@
 # повторяют пп.2-4 до тех пор, пока логическая и физическая архитектуры не окажутся согласованы между собой.
-== Субъективность архитектуры ==
+== Анализ альтернатив ==
 '''Субъективность архитектуры''' - необходимость выбора одного из альтернативных вариантов архитектуры.
 * Если попросить для уже готовой системы разных инженеров сделать архитектурные описания, то они будут разными — как по предложенным структурам системы, так и по той границе, которую проводят разные инженеры между “важным” и “неважным”, исходя из своего опыта.
 * Если предложить разным системным архитекторам спроектировать какую-то систему, то разные системные архитекторы также предложат разные архитектуры — но в данном случае они их “придумают”, а не “выявят”.
-Системный архитектор (или команда системных архитекторов) должны предложить сразу несколько разных архитектурных решений (вариантов компонентной структуры/модулей для реализации компонент/разного размещения в пространстве). Лучшие из этих архитектурных решений выбираются при помощи процедуры, известной как [[Анализ компромиссов|trade-off studies]] ("прохождение развилок”) — готовятся таблицы, в которых баллами оцениваются свойства альтернативных вариантов, а затем подсчитывается сумма с учётом каких-то коэффициентов. В реальной жизни решения обычно принимаются содержательным обсуждением, а затем таблицы для trade-off studies оформляются задним числом для отчётности и демонстрации наличия вариантов, учтённых в работе — это как бы “объективация” субъективно принимаемых решений. Если рассматривалась только одна архитектура, то это считается не слишком хорошей работой системного архитектора.
+Системный архитектор или команда системных архитекторов должны предложить сразу несколько разных архитектурных решений (вариантов компонентной структуры/модулей для реализации компонент/разного размещения в пространстве). Лучшие из этих архитектурных решений выбираются при помощи процедуры, известной как [[Анализ компромиссов|trade-off studies]]<ref>Общепринятый русский перевод "''анализ компромиссов''" намекает о взаимных уступках, здесь же выбирается один из вариантов в ущерб других, поэтому более удачные переводы - "''выбор альтернативы'''\" или "''прохождение развилок''”.</ref>. По этой процедуре готовятся таблицы, в которых баллами оцениваются свойства альтернативных вариантов, а затем подсчитывается сумма с учётом каких-то коэффициентов. В реальной жизни решения обычно принимаются содержательным обсуждением, а затем таблицы для trade-off studies оформляются задним числом для отчётности и демонстрации наличия вариантов, учтённых в работе — это как бы “объективация” субъективно принимаемых решений. Если рассматривалась только одна архитектура, то это считается не слишком хорошей работой системного архитектора.
 == Относительность архитектуры ==