Из журнала Rational Edge: Подключаемый модуль для IBM Rational Unified Process (RUP) поддерживает основные принципы системного проектирования и управляемой моделями разработки систем ((Model-Driven Systems Development, MDSD). Этот модуль будет особенно полезен руководителям проектов разработки систем, а также всем, кто имеет дело с анализом и разработкой спецификаций систем, их архитектурой, реализацией и тестированием.
Из журнала The Rational Edge.
Системное проектирование - это междисциплинарный подход к обеспечению реализации успешных систем. Этот подход заключается в определении потребностей заказчиков и необходимых функциональных возможностей системы на ранних стадиях цикла разработки, при документировании требований и последующем проектировании и проверке системы с учетом всех составляющих задачи, в том числе операций, оценки затрат икалендарного планирования, производительности, обучения и сопровождения, тестирования, сдачи и запуска в промышленную эксплуатацию.
Системное проектирование объединяет все группы разработчиков в единую команду, создавая основу структурированного процесса разработки, который проходит через все стадии процесса - от выработки концепции до разработки и запуска в промышленную эксплуатацию. Имея целью предоставление качественного продукта, удовлетворяющего требованиям пользователей, системное проектирование учитывает как технические, так и бизнес-потребности всех заказчиков. Члены Международного совета по системному проектированию (International Council on Systems Engineering, INCOSE) выработали согласованные определения терминов "Система" и "Системное проектирование."
Управляемая моделями разработка систем (Model-Driven Systems Development, MDSD) поддерживает определения INCOSE. Она помогает в управлении сложностью проектирования системы. Обеспечение необходимого уровня детализации для каждого уровня модели - важный компонент MDSD. Для этого используется ряд практических приемов, которые можно назвать передовыми методами, а именно:
- декомпозиция не требований, а самих систем;
- использование как разделения, так и объединения ответственностей;
- системы и компоненты работают совместно; точно так же должны поступать коллективы разработчиков;
- спецификации пронизывают архитектуру на всех уровнях детализации;
- жизненный цикл следует базировать на устранении рисков и создании экономической ценности;
- организация процесса разработки должна соответствовать архитектуре продукта.
Реализация систем осуществляется путем:
- моделирования систем при помощи UML (Unified Modeling Language, унифицированного языка моделирования) и вариантов использования (Use Cases);
- создание общего представления проекта на основе использования Context Workshop;
- использование инструментария IBM Rational Software Architect и методологии на базе процесса IBM Rational Unified Process® (RUP®);
- итеративная организация работы с ориентацией на устранение рисков на ранних стадиях;
- внедрение организации программы, отражающей архитектуру целевой системы;
- обеспечение реализации архитектуры и проекта с оценкой технологической готовности.
Теперь, после выхода подключаемого модуля MDSD для RUP, самое время рассказать об MDSD. В этой статье будут рассмотрены основные принципы MDSD, включая уровни моделирования, уровни декомпозиции, а также принципы, использованные в MDSD для поддержки концепции Интеграции модели технологической зрелости Института разработки программного обеспечения (Capability Maturity Model Integration, CMMI).
Интуитивно мы мыслим абстрактными терминами. Осознаем мы это или нет, но процесс мышления включает использование моделей - упрощенных описаний (иногда только умозрительных) изучаемых предметов, а также декомпозиции - разделения этих предметов на составляющие их части. MDSD формализует идею абстракции через использование в системе разных уровней моделирования и декомпозиции.
В повседневной жизни мы используем абстракцию как вспомогательное средство при работе со сложными понятиями. Например, когда мы ведем автомобиль, мы обычно абстрагируемся от работы внутренних компонентов автомобиля и воспринимаем его в значительной степени как "черный ящик" с несколькими основными интерфейсами - рулевым колесом, педалями тормоза и газа. На том уровне представления, который мы используем при вождении автомобиля, мы скрываем внутреннюю реализацию этих функций и учитываем только их использование извне (отсюда сравнение с "черным ящиком" - мы не видим или не стремимся увидеть внутреннее устройство). Это позволяет поместить автомобиль в контекст его использования водителем и пассажирами.
И наоборот, механик местной мастерской, в которую мы обращаемся из-за того, что автомобиль "издает подозрительный шум", видит его совсем в другом ракурсе абстракции. Мы считаем автомобиль в целом "черным ящиком", тогда как механику тот же автомобиль представляется "белым ящиком" - набором компонентов, которые можно просматривать, изучать, ремонтировать или менять; при этом каждый компонент сам по себе представляет собой черный ящик. Механик наилучшим образом разбирается во взаимодействиях между компонентами, включая двигатель, трансмиссию, тормозную систему и т. п. Таким образом, модели, абстракции и уровни декомпозиции позволяют нам продумывать большие системы и подсистемы, а также их взаимосвязи, не заботясь о внутренней сложности.
"Уровнем декомпозиции" называется уровень детализации, на котором рассматриваются элементы системы. В приведенном выше примере механик рассматривает автомобиль на более низком уровне декомпозиции, чем его владелец; если механик передает некоторую деталь из автомобиля специалисту по ремонту, то этот специалист рассматривает данный отдельный компонент на еще более низком уровне декомпозиции по сравнению с механиком.
На любом уровне декомпозиции существует некий набор логических элементов системы, которые рассматриваются как "черные ящики". Имеющиеся в них элементы рассматриваются только на следующем уровне декомпозиции, на котором они предстают уже "белыми ящиками".
Таким образом, выбирая, какие уровни декомпозиции включить в модель, специалист по моделированию решает, какие элементы системы сделать видимыми. В свою очередь, это решение отчасти зависит от того, какой будет аудитория модели на этом уровне декомпозиции. Вероятно, все сталкивались с недостатками демонстрации слишком большого количества деталей аудитории, состоящей из руководящих лиц. Элементы системы, показываемые на данном уровне декомпозиции, должны быть легко узнаваемыми целевой аудиторией и называться терминами, которые ей знакомы.
Если, например, мы разговариваем с руководителями отделов и владельцами бизнес-функций в ипотечном банке, вряд ли будет разумным включать в модель на этом уровне такие элементы как обработчики сообщений и менеджеры баз данных, тогда как источник ссуды, кредит и право собственности будут допустимыми.
Ниже перечислены три важных фактора, которые следует учитывать, выбирая уровень декомпозиции:
- назначение и тип уровня модели (контекст, анализ, проект или реализация);
- какие элементы считаются "черными ящиками";
- показываемые и выделяемые взаимодействия.
Об этих факторах мы подробнее поговорим ниже.
Уровни моделей и их назначение
При разработке сложной модели многоуровневой системы, будь то самолет, проект разработки корпоративной информационной системы или новое бизнес-подразделение, основной задачей является выбор правильного набора уровней, при помощи которого будет создаваться модель. В MDSD выделяют четыре уровня моделирования, каждый из которых имеет свои задачи:
- контекстный;
- аналитический;
- проектный;
- уровень реализации.
Контекстный уровень модели, представляющий собой самый высокий (или корпоративный) уровень декомпозиции, позволяет увидеть систему в контексте ее использования бизнес-пользователями и внешними системами. Часто этот уровень соответствует управляемой коллективом области, или на одну ступень выше нее. Например, если мы моделируем новый вид светофора, то, возможно, захотим начать с уровня транспортной сети города, чтобы можно было поместить светофор в данный контекст. Таким образом, городская транспортная сеть будет нашим корпоративным, нулевым уровнем и началом нашей модели. Она станет частью контекстного уровня модели. Сложная система может иметь больше одного уровня декомпозиции на контекстном уровне, но на практике обычно бывает только один уровень.
Аналитический уровень модели конкретизирует функциональные возможности, логическую структуру и распределенность системы. На этом уровне мы создаем логические элементы, элементы распределения и функциональные наборы системы, а также моделируем их взаимодействия. Уникальность этого подхода заключается в том, что все взаимодействия существуют не изолированно, а являются производными вариантов использования системы, описанных на более высоких уровнях. Аналитический уровень моделирования представляет собой абстракцию над реальным проектом. Никто ничего не проектирует и не создает по моделям аналитического уровня. В приведенном выше примере с городской транспортной сетью аналитический уровень может, среди прочих, включать такие элементы системы как дорожная сигнализация, система распознавания движения, центральный пульт управления и блок управления ручной коррекцией.
На аналитическом уровне модели элементы, которые мы считаем "черными ящиками", являются логическими и распределительными элементами, состоящими из аппаратных и программных средств, трудовых ресурсов и информации в определенном сочетании. Они могут быть маленькими, как отдельная автоматизированная функция, или огромными, как армия. Мы выбираем их в качестве элементов нашей архитектуры, чтобы можно было судить об их взаимодействиях и обязанностях. Число создаваемых уровней определяется сложностью системы.
Проектный уровень моделирования отражает взаимодействия между элементами, входящими в проект. На этом уровне моделирования элементы обычно являются однородными, т. е. могут включать аппаратные, программные или трудовые ресурсы, но не их сочетание. Используя подход MDSD, мы назначим этим элементам ответственность за определенные операции, а проектировщики используют нашу спецификацию для создания элементов.
То, как происходит проектирование элемента, зависит от его типа. Программные элементы могут использовать реализации на основе UML или вариантов использования, - принцип, очень похожий на MDSD, но применяемый на уровне проекта программного обеспечения для создания технического проекта ПО. Проект электронного компонента, скорее всего, будет представлен в виде схематической диаграммы, тогда как для элементов типа "трудовые ресурсы" можно использовать организационные диаграммы и списки необходимых профессиональных навыков.
Уровень реализации модели описывает, как элементы, представленные на проектном уровне модели, будут создаваться в реальном мире. Для программного обеспечения он будет содержать структуру модулей программного кода, исполняемые файлы, библиотеки DLL и т. п., а для элементов аппаратного обеспечения - разводку цепей, макеты плат и т. п.
В MDSD мы, главным образом, имеем дело с контекстным и аналитическим уровнями модели, потому что наша главная задача - понять систему в ее контексте, проанализировать поведение всей системы и распределить работу, которая должна быть выполнена коллективами проектировщиков и разработчиков. Эти коллективы могут использовать RUP для создания программного обеспечения, а также другие специфические методы для проектирования аппаратных и трудовых ресурсов.
Давайте подробнее рассмотрим разницу между понятиями "черный ящик" и "белый ящик". Термины "черный ящик" и "белый ящик" описывают подход к представлению системы или компонента системы. Представление системы как "черного ящика" означает, что мы игнорируем ее внутреннее устройство и концентрируемся только на взаимодействиях с этой системой. Большинство людей практикуют такой подход в отношении, например, телевизора. Они не знают, как работает телевизор и из каких компонентов он состоит; их интересует только взаимодействие с ним при помощи устройств ввода (пультов управления, сетевых шнуров и т. п.) и вывода (экрана и динамиков). Представлять предмет в виде "черного ящика" - значит обращать внимание только на ввод и вывод и скрывать или игнорировать все внутренние компоненты.
Операцию переключения каналов на телевизионном приемнике можно описать, просто указав, что зритель нажимает кнопку "+", а телевизор переключает текущий канал. Обратите внимание на то, что здесь не упоминается экран или тюнер, потому что они являются внутренними элементами системы.
Представление в виде "белого ящика", наоборот, содержит информацию о двух дополнительных аспектах системы. Кроме функций ввода и вывода представление "белый ящик" описывает:
- внутренние процессы и функции;
- внутренние элементы системы.
В описании переключения каналов на телевизионном приемнике в виде последовательности типа "белый ящик" будет указано, что зритель нажимает кнопку "+" на пульте управления, а пульт управления передает сигнал в инфракрасном диапазоне электромагнитных волн телевизионному приемнику, после чего интерфейс управления телевизором дает команду тюнеру перенастроиться на другой канал, а контроллер дисплея выводит на экран изображение с нового канала после того как настройка закончена. Обратите внимание, что описание по принципу "белого ящика" не означает, что система полностью подвергается декомпозиции на самые низкоуровневые элементы. Это описание все еще содержит абстракции, которые считаются "черными ящиками" . "Интерфейс управления телевизором" на этом уровне декомпозиции является расширением представления "белого ящика", и, следовательно, считается "черным ящиком". На более низком уровне декомпозиции он также может быть описан через составляющие компоненты.
Следует отметить, что атрибуты черного или "белого ящиков" не являются собственными характеристиками элемента. Т. е. не существует "элементов черного ящика" или "элементов белого ящика". Можно говорить только о представлениях в виде "черного" и "белого" ящиков, и оба этих представления мы используем на всем протяжении процесса моделирования MDSD.
Взаимодействия между элементами
Самой значимой гранью каждого уровня декомпозиции являются взаимодействия, которые он скрывает или демонстрирует. Так как каждый элемент на уровне декомпозиции рассматривается только как "черный ящик", то демонстрируются только взаимодействия между этими элементами и пользователями системы. Взаимодействия с вложенными элементами в данном случае скрываются.
Недавно на занятиях группы, которая моделировала коммерческий самолет, мы столкнулись с забавным примером. На некотором уровне декомпозиции самолет выглядел как элемент и описывался как сущность, содержащая корпус, все бортовые системы и экипаж. Поскольку все это было включено в "черный ящик", обозначенный как "самолет", то на этом уровне модель не могла описывать ничего внутри данного "черного ящика". В описании того, как начинается полет для пассажиров, в данной модели говорилось, что самолет приветствует пассажиров и показывает им их места. Хотя это звучит странно, но только так в данном случае можно описать это поведение. Поскольку экипаж считается частью самолета, то приветствие пассажиров экипажем должно описываться как приветствие пассажиров самолетом. На самом деле, это чрезвычайно полезный подход, потому что проектное решение по поводу того, будут ли приветствовать пассажиров стюардессы или автоматизированная система просканирует отрывные талоны билетов и поприветствует их, не принималось на этом уровне декомпозиции.
В то же время, то, что подчеркивается на любом уровне декомпозиции - это взаимодействие между идентифицированными на этом уровне элементами. В приведенном выше примере это взаимодействие между пассажиром и самолетом, именно оно и описывается. То, какие взаимодействия являются важными для описания - это основной фактор в принятии решения о том, какие уровни декомпозиции использовать. Рассмотрим случай с пилотом нашего коммерческого самолета. Является ли пилот частью системы самолета или он рассматривается вне системы? Любой способ моделирования системы является корректным, и какой способ выбрать, зависит от того, какие взаимодействия важны в данной ситуации. Если важно то, как пилот взаимодействует с самолетом, т. е. если самолет считается "черным ящиком", а для взаимодействия с самолетом как с единым целым используется некоторый интерфейс, то в этом случае можно описать пилота как отдельную сущность на том же уровне, что и самолет. Это позволит описать взаимодействие между пилотом и самолетом как взаимодействие с "черным ящиком". С другой стороны, возможно, имеет смысл рассматривать пилота и самолет вместе как отдельный элемент системы, тем самым выделяя, скажем, взаимодействие диспетчерской вышки с элементом "самолет с пилотом". По некоторым соображениям, это может оказаться лучшим подходом. Если мы разрабатываем самолет, то нас, скорее всего, интересует то, как самолет в целом (включая экипаж) взаимодействует с внешними элементами, такими как диспетчерская вышка, пассажиры и наземные службы аэропорта.
Возможно, имеет смысл представить пилота как сущность, взаимодействующую с элементами или подсистемами внутри самолета, а не со всем самолетом в целом. Тем самым мы поместили бы пилота как отдельный элемент на более низкий уровень декомпозиции, на котором сам самолет представляется некоторым количеством отдельных элементов, включая пилота.
На практике вопрос о выборе элементов архитектуры решается, главным образом, исходя из опыта работы в данной предметной области. Выбор этих элементов является ключевым моментом проектирования архитектуры системы.
MDSD не была добавлена как отдельная дисциплина в RUP, что подчеркивает универсальный характер коллективов разработчиков и процессов разработки.
RUP без подключаемого модуля MDSD представляет собой процесс проектирования программного обеспечения. RUP с подключаемым модулем MDSD представляет собой процесс системного проектирования, для которого проектирование программного обеспечения (посредством использования RUP) является подмножеством.
Дисциплины, входящие в RUP по умолчанию (бизнес-моделирование, сбор требований, анализ и проектирование, реализация, тестирование, развертывание) и поддерживающие дисциплины (управление конфигурациями и изменениями, управление проектами и среда) в равной степени являются компонентами системного проектирования и проектирования ПО. MDSD добавляет новые задачи, артефакты и виды деятельности, а также изменяет некоторые из уже имеющихся, чтобы обеспечить поддержку более широкого масштаба жизненного цикла разработки и дополнительных аспектов системного проектирования.
На Web-сайте RUP системное проектирование не представлено явным образом в виде отдельной дисциплины. Тем не менее, технология MDSD, которая включает в себя существующие дисциплины RUP, представляет собой процесс жизненного цикла системного проектирования.
Важно также понять, как соотносится модуль MDSD с остальными дисциплинами RUP. MDSD предполагает, что системы состоят из подсистем, которые, в свою очередь, могут состоять из подсистем следующего уровня, и т. д. Системы в контексте MDSD определяются и обрабатываются как системы систем.
Процесс RUP с расширением MDSD применим на любом уровне в иерархии системы систем, в том числе на самом низком уровне, на котором (по крайней мере, для программного обеспечения) поведение подсистемы реализуется посредством совместной деятельности объектов ПО (и связей). Обратите внимание, что деятельность по разработке подсистемы с точки зрения ее разработчиков аналогична общей разработке систем в смысле требований к процессу: т. е. она должна иметь начальную фазу (Inception), фазу уточнения (Elaboration) и т. д. Поэтому, если мы рассмотрим общий план разработки системы, мы обнаружим последовательность фаз RUP, а углубившись на более детальный уровень, снова заметим фазы разработки в терминах RUP, или жизненные циклы, по одному на каждую подсистему.
Высокоуровневые деятельности представляют себе "свернутые" деятельности более низких уровней. В них входят требования, проекты и другие деятельности на каждом уровне вместе с отдельными логическими планами. Это позволяет составить простое описание процесса и одновременно не мешает создавать планы произвольной сложности путем рекурсивного применения жизненного цикла RUP. Впоследствии на любом уровне выбираются деятельности, задачи и шаги внутри задач, соответствующие вашей цели.
Стандарт интеграции Capability Maturity Model Integration (CMMI) для разработки
MDSD соответствует модели процесса CMMI-DEV v1.2, которая характеризует проектирование систем и системных инженеров следующим образом:
"Для преобразования набора потребностей, ожиданий и ограничений, предъявляемых заказчиком, в программное решение и для сопровождения этого решения на протяжении всего жизненного цикла продукта необходим междисциплинарный подход к управлению всеми техническими и административными работами. (См. также разделы "Проектирование аппаратного обеспечения" и "Проектирование программного обеспечения")
Сюда входит определение технических показателей производительности, интеграция всех работ по проектированию для создания архитектуры продукта и определение поддерживающих процессов жизненного цикла, которые позволяют найти баланс между затратами, производительностью и плановыми задачами."
Система, которая может содержать аппаратные устройства (компьютерные и не компьютерные), программное обеспечение и трудовые ресурсы, обеспечивает своим пользователям необходимые рабочие функции и сама может требовать для успешной работы поддерживающих систем. Системное проектирование должно учитывать не только спецификацию и создание продукта, но также эксплуатационную поддержку этого продукта (например, его обслуживание), позволяющую обеспечить бесперебойное использование.
Этот взгляд на систему расширяет представление о базовом RUP, в котором термин "система" используется для обозначения программного обеспечения и компьютерных аппаратных устройств, на которых она выполняется. Кроме того, известно, что очень часто применение MDSD требует от разработчиков большого объема работы, особенно если подсистемы, из которых состоит система, сами являются достаточно сложными системами. При этом подразумевается, что RUP (или MDSD) в процессе разработки систем может применяться не один раз.
Поэтому процесс системного проектирования должен иметь средства для работы с системами, имеющими произвольную сложность и размер и требующими междисциплинарного подхода к проектированию, разработке и сопровождению. В официальном документе The Rational Unified Process for Systems Engineering (Процесс RUP для системного проектирования) объясняются причины разработки процесса RUP для системного проектирования (RUP for Systems Engineering, RUP SE). MDSD представляет собой продукт эволюции RUP SE и дополняет модель процесса средствами, позволяющими решить проблемы сложности и размера (как требований и потребностей заказчика, так и проектных), качества сервиса и других особенностей проектирования, с которыми сталкиваются системные инженеры.
Подключаемый модуль RUP for MDSD будет также полезен руководителям проектов разработки систем, а также всем, кто имеет дело с анализом и разработкой спецификаций систем, их архитектурой, реализацией и тестированием.