Модельно-ориентированная разработка систем

Модельно-ориентированная разработка систем

Как работают инженеры при создании реальных технических систем?

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

  • Отличие свойств фактических материалов от проектных;
  • Погрешности методов конструирования;
  • Эффекты масштабирования и т.д. [1].

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

  1. Каскадная модель
  2. Спиральная модель
  3. Итерационная модель

Каждая из этих моделей применима, и в конкретном случае является наилучшей, рассмотрим их подробнее.

Каскадная модель. Каскадная модель жизненного цикла («модель водопада») была предложена в 1970 г. Уинстоном Ройсом. Она предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. Требования, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.

Выделяют следующие этапы проекта в соответствии с каскадной моделью:

  1. Формирование требований;
  2. Проектирование;
  3. Реализация;
  4. Тестирование;
  5. Внедрение;
  6. Эксплуатация и сопровождение. [2]

Спиральная модель. Спиральная модель была разработана в середине 1980-х годов Барри Боэмом. Она основана на классическом цикле Деминга. При использовании этой модели ПО создается в несколько итераций (витков спирали) методом прототипирования. Каждая итерация соответствует созданию фрагмента или версии ПО, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются работы следующей итерации.

На каждой итерации оцениваются:

  • риск превышения сроков и стоимости проекта;
  • необходимость выполнения ещё одной итерации;
  • степень полноты и точности понимания требований к системе;
  • целесообразность прекращения проекта.

Один из примеров реализации спиральной модели — RAD (англ. Rapid Application Development, метод быстрой разработки приложений) [2,3].

Итерационная модель. Естественное развитие каскадной и спиральной моделей привело к их сближению и появлению современного итерационного подхода, который представляет рациональное сочетание этих моделей. Различные варианты итерационного подхода реализованы в большинстве современных технологий и методов (RUP, MSF, XP).

Это гарантирует совершенную точность программных моделей, так как модель и система, которую она моделирует – это одна и та же вещь (модель сама является реализацией) и развивается по циклу – «обрастает» функциями.

Часто бывает необходимо преобразовывать в другие представления системы на эквивалентном уровне абстракции (например, от структурного представления к представлению

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

Сегодня большинство разработчиков все еще используют подход только код. Они выражают модель системы непосредственно на языке программирования третьего поколения, типа Java, C++ или C# . Этот подход затрудняет понимание ключевых характеристик системы среди подробностей выполнения бизнес-логики, добавляет ненужных затрат на процессы связанные с написанием детализированной документации, и затрудняет внесение изменений в код, концепцию, и уж совсем останавливает работу при смене кадрового состава.

Усовершенствование этого способа может обеспечить визуализация кода в некоторой соответствующей нотации моделирования. Такое исполнение иногда называют моделью кода или моделью реализации. В инструментальных средствах, которые допускают такие модели (например, IBM WebSphere Studio и Borland Together/J), представление кода и представление модели могут быть отображены одновременно; и когда разработчик управляет любым представлением, другие с ним немедленно синхронизируются (преображаются в соответствии со сделанными в других представлениях изменениями). В этом подходе диаграммы – это представления кода. Они обеспечивают альтернативный способ рассмотрения и, возможно, редактирование модели, а значит и кода.

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

Центральная модель имеет степень детализации, допускающую генерацию реализации системы из модели. Процесс генерации объектного кода может применять ряд шаблонов преобразования модели в код, часто разрешая разработчику делать некоторый выбор в применении шаблонов (например, среди различных топологий развертывания). Инструментальные средства, использующие этот подход, обычно специализируются в генерации приложений специфических стилей (например, IBM Rational Rose Technical Developer для систем реального времени). Однако, во всех случаях модель – это первичный артефакт, создаваемый и управляемый разработчиками [1].

Дальнейшие преимущества моделирования доступны через прямое и обратное проектирование (roundtrip engineering – RTE), которое предлагает двунаправленный обмен между абстрактной моделью, описывающей системную архитектуру или проект, и кодом. Разработчик обычно разрабатывает проект системы до некоторого уровня детализации, затем создает реализацию первого прохода, применяя преобразование от модели к коду, обычно вручную. Например, группа, работающая над высокоуровневым проектом, предоставляет проектные модели группе, работающей над реализацией. Группа реализации преобразует этот абстрактный, высокоуровневый проект в детальный набор проектных моделей и реализует их на языке программирования. Итерации этих преобразований приводят к различиям, которые могут быть исправлены или в проекте или в коде. Без жесткой дисциплины абстрактные модели и модели реализации обычно быстро теряют согласованность.

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

Управляемая моделью архитектура. Осознание "замечательного свойства моделей ПО" (см. выше) и современный опыт использования моделирования не могли не натолкнуть специалистов индустрии разработки ПО на идею управляемой моделью архитектуры (Model Driven Architecture – MDA1).

MDA – это набор открытых стандартов OMG22. MDA предоставляет способ разработки систем, который наиболее точно удовлетворяет потребности клиентов и обеспечивает большую гибкость при разработке систем.

В основе представления OMG на MDA лежат четыре принципа:

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

Теория MDA простыми словами. В самом общем смысле, MDA занимается различными абстракциями моделей системы и четкими модельными преобразованиями между ними. Ниже перечислены основные идеи, управляющие использованием MDA сегодня:

  • Модели помогают людям понимать и сообщать сложные идеи.
  • В зависимости от контекста, может быть смоделировано много различных видов элементов. Модели предлагают различные представления реального мира, который, в конечном счете, должен быть понят.
  • Мы видим общее на всех уровнях этих моделей – и в анализе проблем и в предложении решений.
  • Применение идей относительно различных видов моделей и преобразований между представлениями обеспечивает четкий стиль разработки, допуская идентификацию и многократное использование общих подходов.
  • Для того, что называется MDA OMG(Object Management Group — некоммерческое объединение, разрабатывающее стандарты для создания интероперабельных (платформо- независимых) приложений) обеспечил концептуальную структуру и набор стандартов для выражения моделей, отношений между моделями и преобразований от модели к модели.
  • Инструментальные средства и технологии могут помочь реализовать этот подход и сделать его применение практичным и эффективным.

Поддержка концепции управляемой моделью архитектуры (Model Driven Architecture – MDA) – это главное отличие новой платформы IBM Rational для разработчиков.

Подход, основанный на семантике, предполагает создание единой модели системы. Каждое представление – это некоторая проекция полной модели. Разработка модели – это непрерывное усовершенствование и интеграция представлений с динамическим обнаружением несогласованностей!

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

Теперь обсудим высокоуровневые абстракции вне текущей технологии программирования.

Некоторые из этих абстракций революционизировали процесс разработки программного обеспечения. Это, прежде всего, прецеденты (Use Case). Сегодня трудно себе представить объектно- ориентированный проект, в котором не использовались бы прецеденты для определения требований, проектирования, тестирования и управления проектом. Это поддержка для определения межобъектного взаимодействия (последовательности и сотрудничество). Это машины состояний и диаграммы деятельности.

Расширяемость. Большим достижением UML был уход от синдрома PL\I (язык непрерывно "раздувается"). Стандарт UML декларировался как фундамент для "семейства языков" и содержал механизмы расширения: профили, стереотипы и т.д. Примером профиля является UML для моделирования систем реального времени. Примерами стереотипов являются стереотипы классов для бизнес-моделирования (бизнес-сущности и бизнес-работники) и классов анализа (граничный класс, контроллер, класс сущность) [1].

Недостатки UML 1.x.

Думаю, любой практик мог бы указать несколько недостатков UML 1.x. Остановимся только на недостатках, прямо касающихся возможностей применения UML для MDA. Это:

  • Семантические неточности
  • Неопределенные или отсутствующие определения (например, наследование)
  • Неформальные определения (не подходящие для генерации объектного кода или выполнимых моделей)
  • Неадекватные возможности
  • Моделирование процессов
  • Моделирование архитектуры
  • Сложность
  • Слишком много концепций
  • Накладывающиеся концепции
  • Наличие не используемых на практике концепций

MDA-требования к UML

Формальные требования к UML 2, сформулированные OMG, включали следующие интересующие нас разделы:

  • Требования к инфраструктуре (требования к внутренней организации UML)
  • Требования к суперструктуре (требования пользовательского уровня)

Требования к инфраструктуре

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

Полное соответствие MOF

MetaObject Facility (MOF) – это утвержденный OMG стандартный язык моделирования для описания языков моделирования. Полное соответствие MOF позволяет:

  • Обеспечить семантическую точность всех определений UML
  • Обеспечить возможность обмена моделями, выполненными с использованием инструментальных средств различных поставщиков

Для моделирования архитектуры сложных систем/подсистем используется концепция архитектурных объектов. Архитектурные объекты имеют внешнюю и внутреннюю структуру. Как архитектурный объект могут моделироваться класс, компонент или подсистема [1,3,4].

Внешняя структура. Архитектурные объекты имеют множество "фасадов", которые представляются точками взаимодействия: портами. Каждый порт специализирован для определенной цели и представляет интерфейс, соответствующий этой цели.

В различных отраслях данные принципы применяются по-разному и всё же главенство модели над процессом реализации должно сохраняться повсеместно.

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

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

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

) OMG (сокр. от Object Management Group — в русской траслитерации [о-эм-джи] ) — консорциум (рабочая группа), занимающийся разработкой и продвижением объектно-ориентированных технологий и стандартов. Это некоммерческое объединение, разрабатывающее стандарты для создания интер- операбельных, то есть платформо-независимых, приложений на уровне предприятия. С консорциумом сотрудничает около 800 организаций — крупнейших производителей программного обеспечения.[2]

) Model Driven Architecture (MDA) — создаваемая консорциумом OMG концепция модельно- ориентированного подхода к разработке программного обеспечения. Его суть состоит в построении абстрактной метамодели управления и обмена метаданными (моделями) и задании способов ее трансформации в поддерживаемые технологии программирования[2]

  1. Серия статей Л.Б. Новикова Новая платформа IBM Rational для разработчиков 4 части
  2. Wikipedia – свободная энциклопедия
  3. Стефан Бёргстрем , Лотта Роберг . Rational Unified Process –руководство по внедрению RUP изд-во Кудиц Образ Москва 2004 год - 254 стр.
  4. Руководство к RequisitePro
  5. Терри Квартани Джим Палистрант. Визуальное Моделировнаие с помощью IBM Software Architect и UML изд-во Кудиц Пресс Москва 2007 год - 174 стр

 

Год: 2011
Город: Алматы
loading...