Процесс разработки архитектурных моделей для каждой подсистемы и последующего получения требований для каждого компонента подсистемы выглядит так же, как и описанный выше процесс разработки архитектурной модели для самой системы. В конечном итоге все сводится к тому, что необходимо разработать архитектурные модели для каждой подсистемы и для всех входящих в них компонентов, как это показано на рис. 2.1. [c.27]
Описанный процесс разработки также показывает, что разработка системы происходит на разных уровнях, и что на каждом из них выполняются различные действия. Так рис. 2.1 демонстрирует, что процесс разработки на каждом уровне поддерживается моделями (модель использования, абстрактная модель, архитектурные модели), но природа моделей на каждом из уровней существенно отличается. Это пример распространенного подхода -на каждом уровне разработки используется своя модель. Последующие разделы данной главы описывают другие общие идеи, на которых базируется общий процесс разработки требований. [c.28]
На любых уровнях ниже такие проблемы возникают реже. Разработка тут проводиться уже в контексте конкретных архитектурных решений, где проектировщики и разработчики чувствуют себя достаточно комфортно, поскольку вовлекаются в процесс определения, как именно система будет работать. Но даже на любом из этих уровней необходимо уделять должное внимание тому, чтобы степень детализации соответствовала именно этому уровню разработки. Соответственно, и в отношении архитектурных моделей, представленных в виде набора компонентов системы, функционирующих вместе, необходимо внимательно следить за тем, чтобы эти компоненты определялись в терминах того, какие функции они должны выполнять, без подробностей относительно того, каким образом они должны это делать. Иными словами, необходимо следить за тем, чтобы компоненты представляли собой черные ящики , выполняющие сформулированные в требованиях задачи, при отсутствии описания их внутренней реализации. [c.132]
Разработан и внедрен проект Автоматизированные технологические линии проектирования строительной части промышленных зданий (ТЛП-ПЗ) , являющийся подсистемой САПР-ПИ промышленного профиля. Структурная модель ТЛП-ПЗ состоит из пяти проектирующих и трех обеспечивающих подсистем. Рассмотрим подсистему Архитектурно-строительное проектирование , являющуюся ведущей проектирующей подсистемой ТЛП-ПЗ, так как в ней определяется основная структура объекта и разрабатываются задания для остальных проектирующих подсистем ТЛП. В этой подсистеме решается комплекс архитектурно-планировочных задач, которые могут быть условно разделены на два этапа поисковый и дета-лировочный. На поисковом этапе большое место занимает взаимодействие с заказчиками проектов, системами более высокого ранга, смежными проектирующими подсистемами ТЛП. На этом этапе также решаются задачи сбор справочно-нормативной информации формирование результатов предварительной проработки проекта в графическом и табличном видах (первые промежуточные результаты) формирование вариантов компоновочных и конструктивных решений, их оценка и выбор оптимальных проектных решений формирование заданий смежных подсистем ТЛП. Решаемые задачи на этом этапе требуют большого участия проектировщиков. Технические средства на поисковом этапе используются в основном для обработки информации по решениям, которые принимает архитектор. На деталировочном этапе решаются следующие основные задачи сбор нагрузок выбор несущих и ограждающих конструкций проектирование узлов и элементов изготовление и выпуск проектной документации и подготовка задания на разработку смежной документации. На этом этапе появляется возможность программного решения всех перечисленных выше задач. Однако этот этап не может производиться автоматически, без участия человека, за которым остаются функции контроля, корректировки и оценки получаемых результатов. [c.250]
Смотреть главы в:
Разработка и управление требованиями -> Разработка архитектурной модели системы