Файл: Инфрам.pdf

192 управляемой моделями (MDD) [22]. Разработка, управляемая моделями,
– это такой стиль разработки программ, когда главными артефактами являются модели, а по ним генерируется код и другие прикладные ар- тефакты. В MDD вводится дополнительный критерий, состоящий в том, что модель должна читаться машиной. Возможность чтения машиной - необходимая предпосылка для генерации артефактов. Диаграмма, нари- сованная на доске, может удовлетворять другим критериям модели, од- нако до тех пор, пока она не переведена в форму, доступную для маши- ны, ее невозможно использовать ее в цепочке инструментов разработки, управляемой моделями.
Программные модели разрабатываются на унифицированном языке моделирования UML. Этот язык предоставляет нотацию и соответст- вующую семантику для моделей программных систем. В UML также есть стандартный метод сериализации в понимаемый машиной формат, что предоставляет возможности для автоматизации. Новая парадигма разработки программного обеспечения поддерживается методами архи- тектуры Model-driven Architecture (MDA) [26]. Этот подход к разработке
ПО создан командой Object Management Group (OMG).
MDA предоставляет ряд рекомендаций для структурирования спе- цификаций, представленных в качестве моделей, начиная с независимой от платформы модели (PIM), затем при выборе языка программирова- ния исходя из специфики разработки, и наконец, при трансформации модели в одну или несколько моделей, определяемых платформой, в рамках которой они реализуются (PSM). Количество платформ может быть любым, например: Java ™ 2 Platform, Enterprise Edition (J2EE)™,
CORBA или. Net, реализованные на одном из общепринятых языков программирования, таких как Java ™, C# или Python. MDA обычно вы- полняется при помощи автоматизированного инструментария, напри- мер, IBM® Rational® Software Architect. MDD-разработка, основанная на MDA, в основном занимается трансформацией моделей и генерацией кода (рис. 5.2).
Рис. 5.2. Трансформация моделей в технологии MDA

193
Основанный на создании кода подход, используемый MDD, имеет свои недостатки, связанные с ограничениями в сгенерированном коде, низкой компетентностью разработчиков и жесткой привязкой к конкретной модели.
Если компания полностью полагается на автоматическую генерацию кода, она оказывается ограниченной в возможностях тонкой настройки кода, особенно когда разработчикам приходится все изменения вносить только через изменение модели.
Разработка на основе шаблонов помогает решить эту проблему.
Шаблон – это решение периодически возникающей проблемы в рамках определенного контекста. Шаблоны инкапсулируют время, труд и знания разработчика, однажды уже понадобившиеся для решения проблемы. После многократного использования в различных проектах шаблон может приобрести статус эталона. Используя шаблон как отправную точку в проектировании, разработчики могут более гиб- ко контролировать генерируемый код, который не ограничен, т.к. осно- ван на абстрактной модели. Кроме того, MDD может автоматизировать реализацию шаблонов на основе трансформаций, что позволит исклю- чить повторение операций низкоуровневой разработки и отразить в коде опыт разработчиков, что должно повысить совместимость и удобство обслуживания.
Для применения рассмотренного подхода требуется интегрирован- ная среда разработки (IDE) с поддержкой следующих возможностей
[26]: моделирования на основе UML; инфраструктуры шаблонов; функций трансформации модели и генерации кода; инструмента проектирования и разработки для конкретной платфор- мы, а также среды для тестирования элементов.
Выше уже не раз упоминался инструмент Rational Software Architect, который обеспечивает все эти возможности. Это интегрированное сред- ство проектирования и разработки, которое использует преимущества
UML-разработки на основе моделей, позволяя создавать приложения и сервисы с практичной архитектурой. Использование UML-моделей в разработке ПО широко применялось и до появления MDD. Отличие заключается в том, что в MDD модели используются не как проекты или наброски, а как исходные артефакты, из которых путем трансформаций генерируются эффективные реализации. MDD подробно описанные предметно-ориентированные модели приложения играют главную роль при разработке новых компонентов ПС. Код и другие ар- тефакты области назначения генерируются с помощью трансформаций, в разработке которых участвуют как специалисты по моделированию, так и специалисты в конкретной области.
В
[26] приведен пример
(рис.
5.3), как с помощью
MDD коммерческая проблема преобразовывается в решение ПО. Биз- нес-проблема анализируется, а затем применяются общие бизнес- шаблоны. Таким образом, модель разработки частично заполняется, в ней появляются детали конкретной разрабатываемой бизнес-функции.

194
Далее внедряются независимые от платформы шаблоны разработки для трансформации модели разработки в ряд независимых от рабочего цикла компонентов. После этого выбирается исполняемая платформа и специфические для ее рабочего цикла шаблоны применяются для генерации артефактов.
Рис. 5.3. Трансформация моделей на основе шаблонов

195
Внешние спецификации будем обозначать SP
В
S
, внутренние обо- значим как SP
Вн
S
. Таким образом,
SP = SP
В
S
SP
Вн
S
(5.2)
Внешние спецификации, обращены к внешнему пользователю, заказ- чику, потребителю программы, внутренние спецификации обращены к внутреннему пользователю, т.е. к разработчику программы. В методе формализованных технических заданий предусматривается ряд проме- жуточных спецификаций. Благодаря такому положению спецификаций в разработке программ, так называемые языки проектирования про- грамм и языки разработки программ обычно либо оказываются языками спецификаций, либо включают в себя такие языки.
Вопрос в том, какая информация о задаче и в какой форме должна содержаться в спецификации. Многие авторы полагают, что специфи- кация в отличие от программы должна говорить, что надо сделать, а не как это делать, т.е. подчеркивают непроцедурный характер специфика- ций. При этом часто отмечают, что спецификация не должна содержать деталей реализации, навязывать программисту ту или иную реализацию.
Однако обязана ли спецификация быть всегда непроцедурной – вопрос дискуссионный, так как задача может быть процедурной по своей при- роде. Кроме того, непроцедурность и свобода от деталей реализации – вещи разные, так как процедурность может быть высокого уровня, да- лекой от реализации.
Другое часто упоминаемое желательное или обязательное свойство спецификации называют формальностью, однозначностью или точно- стью, причем диапазон требований здесь весьма широк: от полностью формализованного описания до слегка формализованного. Описание "на естественном языке" обычно считается неудовлетворительным, но ка- кие формальные средства или средства достижения точности следует использовать в спецификациях – вопрос тоже дискуссионный.
Еще одно отличительное свойство спецификаций называют понят- ностью, ясностью или читабельностью. Точность и понятность являют- ся двумя основными свойствами спецификации, причем второе должно отличать типичную спецификацию от типичной программы. В общем случае спецификация должна быть более понятным описанием задачи, чем программа, её должно быть легче написать и легче прочесть. Одна- ко важно отметить относительность понятия спецификации: имея дело с одной и той же задачей, одни люди в данной обстановке (включающей их знания, языки и т.д.) будут склонны считать спецификацией одно, а другие люди в другой обстановке – совсем другое. Понятность специ- фикации, легкость ее написания и чтения зависят от того, какими зна- ниями и средствами описания располагает данный человек.
Третье, основное, и часто неявно подразумеваемое свойство специ- фикации – это полнота описания задачи: ничто существенное не должно быть упущено. Следует отличать спецификацию от менее полного и точного, более эскизного и предварительного описания, которое будем называть требованиями к программе. Они упоминаются в ЕСПД (ГОСТ

196 19.201-78) в качестве раздела технического задания. То, что называется формализованным техническим заданием, соответствует понятию спе- цификации.
Между требованиями и внешней спецификацией помещаются еще "цели" программы и проекта. Таким образом, спецификацией является достаточно точное и достаточно полное описание задачи, которое чело- веку, участвующему в решении, легче написать, понять и прочесть, чем программу решения этой задачи на доступном ему языке программиро- вания. Средства спецификаций – это любые средства получения или построения таких описаний, а язык спецификаций – это рационально организованный и синтаксически оформленный набор таких средств.
Фактически языком спецификаций часто называют язык более высо- кого уровня, чем традиционный язык программирования. Если язык спецификаций реализован так, что. спецификации можно выполнять на машине, то он одновременно является и языком программирования.
Однако эффективность реализации такого языка спецификации, скорее всего, гораздо ниже, чем обычного языка программирования, и ниже, чем обычно требуется в производственных условиях. В языке специфи- кации ценна не эффективность реализации, а эффективность выраже- ния, высокая выразительность.
Первые языки спецификаций или языки проектирования программ появились, по-видимому, в конце 60-х - начале 70-х годов. Языки делят- ся на два основных класса: графические и текстовые. В первом глав- ную роль играет представление в виде графов и диаграмм (например,
HIPO, LOGOS и SA). Во втором классе спецификации представляют собой тексты, последовательности символов (например, псевдокод, PSL и PDL) и делятся на три подкласса в зависимости от того, как в них ис- пользуется естественный язык: неограниченно, с ограниченным синтак- сисом и семантикой, с дополнительной символикой.
Выделяются такие классы языков [27]: языки описания подсистем обработки данных (например, AXES и
SA); языки для "детального" описания (например, алгебраические специ- фикации абстрактных типов данных) и языки, ориентированные на описание "архитектуры"; языки, ориентированные на данные (например, HIPO и PSL); языки, ориентированные на управление (например, LOGOS и RSL ); языки для общего описания системы в целом (называемые языками oписания заданий); языки для описания конкретного функционирования на уровне под- систем (называемые языками описания проектов).
Ранее были выделены три класса спецификаций и соответственно средства их построения: алгебраические, аксиоматические, модельные.
Представляет интерес рассмотрение в основном модельных специ- фикаций, т.е. средств явного построения математических моделей. Их можно упорядочить в виде следующих классов: таблицы; равенства и системы подстановок; логические средства; графы, сети и диаграммы;

197 математические структуры и модули, типы, схемы и фреймы; операции, процедурные средства; средства именования; средства описания исклю- чительных и ошибочных ситуаций.
Языки спецификаций делятся на два класса: универсальные языки, или языки общего назначения и специализированные языки. Язык мо- жет быть специализированным в двух существенно разных смыслах: ориентирован на определенную предметную или проблемную об- ласть и может использовать разные и разнородные средства (напри- мер, язык описания АСУ в конкретной отрасли); основан на определенном средстве, методе описания и может ис- пользоваться в разных областях (например, язык, основанный на таблицах, или язык, основанный на равенствах).
Для каждого из классов средств можно указать специализирован- ный во втором смысле язык, основанный на средствах этого класса. Хо- тя нередко определенная область связана с узко специфическими сред- ствами, и тогда специализация "по области" совпадает со специализаци- ей "по средствам", представляется уместным различать эти два вида специализации. Классов предметно - или проблемно-ориентированных языков в принципе может быть так же много, как предметных или про- блемных областей. Среди них прежде всего следует выделить: языки, ориентированные на управление, языки, ориентированные на структуры данных.
К первым относятся языки описания систем реального времени
(или оперативной обработки информации), асинхронных и параллель- ных систем, ко вторым – языки описания задач обработки данных отно- сительно сложной структуры. Во вторых в отличие от первых, основ- ную роль играет структура обрабатываемых данных, а не взаимодейст- вие процессов обработки. В принципе можно представить себе задачи, объединяющие черты задач обоих этих классов, но реально языки спе- циализируется либо в ту, либо в другую сторону. Кроме этих двух клас- сов, особый интерес для программирования представляют задачи проек- тирования трансляторов и задачи проектирования баз данных (или сис- тем управления базами данных). Языки последнего класса тоже ориен- тированы на данные, как и языки упомянутого выше класса, но сущест- венно иначе. Все остальные предметно- и проблемно-ориентированные языки – это по существу многочисленные языки разнообразных пакетов или систем, прикладных программ.
Перейдем теперь к рассмотрению отдельных классов средств специ- фикации и языков, специализированных "по средствам". Очень удоб- ным средством спецификаций являются таблицы. Одной из черт хоро- шо организованной программы является легкость её модификации. Эта легкость тесно связана с применением систематического подхода при построении программы. Часто о наличии такого подхода говорит ис- пользование таблиц, потому что, как правило, элементы таблиц пред- ставляют собой меняющиеся значения параметров, которые могут быть использованы общим участком программы в различных ситуациях.