6. Потребности, требования и архитектура

6.7. Набросок архитектуры

Ознакомьтесь с примером в первой строке таблицы. Обратите внимание, что мы не всегда можем полностью описать архитектуру.
Заполните пустые строчки после примеров, описав архитектуру приведенных систем.
Приведите примеры из рабочих и личных проектов: разбейте ваши системы на три-семь функциональных частей, покажите, как они реализуются физическими/конструктивными объектами, дайте замечания по компоновке, оцените стоимость или приведите принципы расчета.
Набросок архитектуры
0
Система
Функциональная часть
Конструктивные части, реализующие функцию
Компоновка/размещение
Стоимость
Заметки
1
Пример: Ножницы
Ножевой блок, Ручка
Половинка 1, Половинка 2, Винтик
Половинка 1 и 2 скрепляются в определенном месте винтиком.
50 рублей за 1 шт при массовом производстве от 1000 шт.
2
Пример: Жизненное мастерство
Мыслительное мастерство, Прикладное мастерство
Точно не знаем.
Где-то находится в мозге.
Сложно подсчитать, но расчет можно построить на стоимости обучения и примерном количестве инвестированных часов.
3
Автомобиль
4
Стол кухонный
5
Парк “Зарядье”, Средняя школа №12, Детский сад “Березка”, Магазин “Пятерочка”, ...
6
Приведите пример из рабочего проекта:
7
8
Приведите пример из личного проекта:
9
There are no rows in this table

Теория в учебнике

Самые важные решения по поводу системы называют архитектурными. Важность определяют как такое решение, которое в случае принятия его альтернативы вело бы к почти полному перепроектированию системы, полному изменению конструкции.
Архитектурные решения принимаются в ходе совмещения функционального («как работает») и конструктивного («из чего сделано») разбиения, с учётом вариантов компоновки и результирующей стоимости. В литературе для разных разбиений часто используют просто термин «структура», но нужно помнить, что это именно иерархия по какому-то виду разбиения: отношения элементов структуры — это обычно иерархия отношений «часть-целое» функциональных, конструктивных объектов, размещений, стоимостей и подобных им объектов.
Первое, что происходит в ходе размышления о будущей системе — это функциональная декомпозиция: функция и/или функциональные части разбиваются на более мелкие и делается попытка выбрать для них продукты/модули, сервисы которых могут выполнить функции этих функциональных частей. Помним, что функции системы формулируются на языке проектных ролей надсистемы, а сервисы — на языке проектных ролей системы.
Системное мышление сегодня выделяет четыре основных вида деления системы на части:
описание подсистем как функциональных объектов времени работы/эксплуатации/функционирования/операций системы (описание «как работает», его чаще всего и называют системным разбиением),
как конструктивных/физических модулей времени создания (описание «из чего собрано», продуктное/модульное разбиение), и
как мест в пространстве, где размещаются части системы (где во Вселенной находятся части системы, пространственное разбиение).
Как стоимостных частей (на что потребуется потратить деньги и иные ресурсы, стоимостное разбиение).
Минимально в системном подходе нужно выделить вниманием четыре основных вида/типа частей системы:
Функциональные части, обсуждение взаимодействия которых позволяет отвечать на вопрос о том, как работает система, чтобы она выполняла свою функцию в её надсистеме. Это обязательно будет обсуждение времени эксплуатации/работы/операций/использования/службы. Функциональные части выполняют свою функцию в системе через соединения с другими функциональными частями, меняя своё состояние от этого взаимодействия и меняя состояния других частей.
Модули/продукты/конструктивные части — этот вид частей позволяет отвечать на вопрос, из чего собрать и как соединить через интерфейсы модули системы, отвечают на вопрос «как собрать систему», обсуждается время создания.
Места, или размещения, которые позволяют отвечать на вопрос, где можно найти части системы, как она скомпонована в пространстве. Чаще всего эти места даются для run-time, а размещения делаются для определяемых в design-time модулей. Место/размещение тем самым важно для совмещения ролевых и физических объектов в run-time: если оба находятся в одном и том же месте в одно и то же время, то это один и тот же объект.
Стоимостные/затратные части, позволяющие обсуждать издержки/затраты на систему, причём не только на время разработки, но и на время всего жизненного цикла (на материалы, на работы по созданию, на работы и материалы времени эксплуатации, ремонта, модернизации, на работы по уничтожению выводимой из эксплуатации системы).

Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.