Переход от моделирования к написанию кода

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

Диаграммы последовательностей содержат почти всю необходимую информацию для того, чтобы начать писать код. Естественно то, как будет выглядеть код реализации, зависит от опыта и применяемого языка программирования. Например, объекты Вакансия и КоллекцияВакансий представляют класс и коллекцию, содержащую объекты этого класса. В языке С# коллекция наследуется от класса System.Collections. CollectionBase и при этом выбор языка программирования определял бы вид реализации:

 

public class JobListing {…}

public class JobListingCollection: System.Collections.CollectionBase

{ public JobListing this [ int index] //индексатор

{ get { return (JobListing). List [index] };

set { List [index]= value; }

}

public int Add (JobListing arg)

{ return List. Add(arg); }

}

 

В приведенном фрагменте осуществлено наследование от специфической базовой коллекции и определены свойства this и метод Add, показанный на диаграмме последовательности.

Важно отметить, что спроектированная последовательность не указывает на наличие свойства this или родительского класса; в диаграммах последовательности этого нет. Использование языка реализации C# и библиотеки.NET Framework определили наличие этих деталей. Следует также обратить внимание, что класс вакансии ничего не содержит. Более того, объект Вакансия в диаграмме последовательности тоже не дает возможности увидеть детали реализации. Диаграммы последовательности не предназначены для определения особенностей реализации, то есть деталей. Но, тем не менее, мы определили интерфейсы классов. То, сколько кода на этом этапе может написать программист, во многом зависит от его опыта. Чем больше деталей, тем качественней будет происходить реализация. Для того – чтобы указать больше деталей, таких как свойства, поддерживаемые методы и связи наследования, можно использовать диаграммы классов.

Следует иметь в виду, что на этапе перехода от моделирования к написанию кода присутствует несколько неявных моментов.

Первое – необходимо помнить, что модель системы, скорее всего, будет изменяться.

Второе - такие вещи, как типизированные коллекции основаны на шаблонах, и, как было продемонстрировано в листинге кода, реализация во многом определяется языком и средой разработки.

Третье – существует много известных и популярных шаблонов проектирования – смотри, например книгу Эриха Гамма и др. “Приемы объектно-ориентированного проектирования”, и иногда можно просто указать, что используется шаблон; при этом не нужно создавать модели для известных общедоступных шаблонов.

И последнее, но не менее важное – существует такое понятие, как рефакторинг. Рефакторинг является методологическим средством упрощения кода[10]. Когда говорится о применении рефакторинга, на практике это может означать, что решения этапа проектирования могут быть улучшены по ходу реализации. Если результат рефакторинга лучше, чем старое решение этапа проектирования, тогда следует двигаться вперед и модифицировать код, обновляя модели для отражения внесенных изменений.

В примере с поиском вакансий, был продемонстрирован рефакторинг при описании объекта КритерийПоиска. Этот пример рефакторинга можно назвать “Введение объекта параметра”, просто заменяющего длинный список параметров одним экземпляром класса параметра, содержащего эти значения. Также был использован шаблон “Итератор”. Строго типизированная коллекция, являющаяся реализацией типизированной коллекции объектов Вакансия, наследуется от класса Collection.Base, имеющегося в.NET, который, в свою очередь, реализует применение шаблона IEnumerable (реализация шаблона “Итератор”).

Хорошие разработки и алгоритмы реализации основаны на шаблонах и рефакторинге!. Хорошие модели проектирования основаны на простом, точном и прямом использовании UML и объединяют шаблоны проектирования и рефакторинг!

Процесс ICONIX

Основные концепции процесса

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

Далее, следует уровень реализации. Процесс анализа требований, таким образом, должен синтезировать решения анализа, получаемые при моделировании предметной области и моделировании поведения системы, причем делать это на минимальном подмножестве моделей UML. Более того, когда говорят о UML, часто упоминают об MDA-архитектуре, то есть архитектуре, управляемой моделями. По сути дела, MDA представляет собой стандартный подход к использованию UML в качестве языка программирования. MDA разделяет процесс разработки на две основные части. Разработчики моделей представляют конкретное приложение, создавая PIM (Platform Independed Model – модель, не зависящая от платформы).

PIM – это модель UML, не зависящая от какой-то конкретной технологии. Затем, с помощью инструментов, можно превратить PIM в PSM (Platform Specific Model – модель, зависящая от платформы). PSM – это модель системы, нацеленная (специфицированная) на определенную среду выполнения. Другие инструменты берут PSM и генерируют код для этой платформы. В качестве PSM можно использовать UML, но это необязательно.

Поэтому если вы желаете создать конкретное приложение с использованием MDA, вам придется начать с единой модели PIM вашей системы. Затем, при желании запустить эту систему в J2EE или.NET, вы должны будете использовать инструменты каких-либо производителей для создания двух моделей PSM – по одной на каждую из этих двух платформ.

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

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

Приведенные рассуждения говорят о тенденции проектирования систем в MDA-архитектуре, с использованием UML в качестве языка программирования. Насколько это будет реально - покажет время. Первый шаг в этом направлении был предпринят ведущим специалистом в программной индустрии Айваром Якобсоном (Ivar Jacobson) в начале 90-х годов. Идеи Якобсона легли в основу процесса ICONIX, созданного Дугом Розенбергом (Doug Rosenberg).

Процесс ICONIX представляет собой нечто среднее между очень громоздким рациональным унифицированным процессом RUP (Rational Unified Process) и весьма компактной методологией программирования XP (eXtreme Programming). Процесс ICONIX, как и RUP, основан на вариантах использования, но не характеризуется множеством его недостатков. В этом процессе тоже применяется язык моделирования UML, однако основное внимание уделяется анализу и контролю требований. В главе 32 руководства по языку UML [4] говорится: “80% всех задач можно моделировать с помощью 20% UML”. Однако в книге не говорится о том, что это за 20%. Процесс ICONIX включает базовую нотацию (минимальное подмножество UML), которую должно хватить для большинства моделей.

Исходной информацией в процессе ICONIX являются представления о том, что должна делать система в виде прототипа графического интерфейса пользователя и некоторых выявленных сценариев или моделей вариантов использования. После этого можно приступать к анализу и проектированию. Говоря об уровне проектирования, следует иметь в виду такой уровень детализации, при котором полученная диаграмма классов может служить шаблоном для создания кода; она должна точно отражать организацию будущей программы. Таким образом, надо решить основную проблему – каким-то образом перейти от вариантов использования к диаграммам классов уровня проектирования.

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

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

Итак, мы располагаем следующими моделями: моделью интерфейса пользователя, моделью вариантов использования, моделью взаимодействия объектов, а также предварительной диаграммой классов на базе концептуальной модели предметной области. Основная сложность состоит в том, как перейти от модели вариантов использования к диаграммам последовательности. В большинстве случаев это не простая задача, так как варианты использования описывают систему на уровне требований, а диаграммы последовательности дают детальное представление с точки зрения проектирования. Во всех методиках по объектному проектированию много говорится и о вариантах использования и о диаграммах последовательности, но не уточняется, как преодолеть расстояние между ними. Преодоление этой пропасти между “что” и “как” - центральная тема в процессе ICONIX.

Следующий этап – переход от нечетких формулировок варианта использования к очень точным и детальным диаграммам последовательности, реализуется с помощью диаграмм пригодности (устойчивости). Они упрощают процесс перехода. Диаграммы пригодности появились в работе Айвара Якобсона и были утверждены в стандарте UML как дополнение (включены в UML лишь частично). Это определение включено в дополнительный документ под названием “Objectory Process Specific Extensions”.

Анализ пригодности - незаменимое средство для осуществления перехода между требованиями и проектом. Такой переход подразумевает одновременное выполнение нескольких видов деятельности. Сначала надо выявить классы, которые возможно не “проявились” на первых этапах проектирования системы (классы – сущности, при моделировании предметной области, классы управления, при разработке прототипа пользовательского интерфейса и классы-контроллеры, участвующие в сценариях вариантов использования). Возможно, прослеживая потоки данных на диаграммах пригодности, мы придем к выводу, что в классы надо добавить некоторые атрибуты и операции. Немаловажно еще и то, что по результатам работы над диаграммой пригодности уточняется словесное описание модели варианта использования . Другими словами, правильная работа с вариантами использования сводится к детальному описанию использования системы в контексте объектной модели. Поэтому суть процесса ICONIX, и анализа пригодности в частности, заключается в том, чтобы составлять варианты использования точными и недвусмысленными. Во многих источниках на данную тему варианты использования рассматриваются скорее как абстрактное средство изучения требований, цель же процесса ICONIX – оказать помощь разработчикам в переходе от вариантов использования к коду, что вполне согласуется с концепцией MDA.

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

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

На рис. 6.17 показано, как перейти от вариантов использования и прототипов пользовательского интерфейса к диаграммам классов уровня проектирования и исходному коду.

 

Диаграмма классов – это статическое описание организации кода, тогда как варианты использования описывают динамическое поведение системы во время выполнения.

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

 

 

Рис. 6.17. Укрупненная схема процесса ICONIX

 

Начнем с создания прототипов интерфейсов пользователей, которые достаточно просто нарисовать на экране.

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

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

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

Как видно из статической части схемы процесса ICONIX, первое представление об объектах мы получаем исключительно из описания пространства задачи. Один длинный цикл последовательных уточнений выполняется при анализе динамического поведения системы. Нужно во всех деталях понять, как должен выполняться отдельно взятый сценарий, а затем обновить диаграммы классов. Затем возвращаемся назад и снова анализируем то, как должна вести себя система.

На следующем шаге уточняем структуру программы. Этот подход, на 80% заимствованный из работы Айвара Якобсона [22, 19], позволяет разбить систему на части, определяемые границами вариантов использования, после чего результаты анализа вариантов использования используются для перехода на достаточно детальный для кодирования уровень объектной модели, то есть на уровень статической модели.

 

Особенности процесса

Приведенный рисунок схемы процесса изображает простой подход к разработке ПО, использующий минимальный набор UML - диаграмм, и ряд приемов, которые позволяют быстро и эффективно перейти от вариантов использования к коду. Этот подход обладает гибкостью и открытостью. К особенностям процесса следует отнести:

· Простое использование UML.

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

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

Построение хорошей модели намного упрощается, если есть намерение твердо искать ответы на следующие фундаментальные вопросы о создаваемой системе:

· каковы пользователи системы (акторы), и что они хотят от системы;

· что такое объекты «реального мира» (предметной области), и какие между ними ассоциации;

· какие объекты участвуют в каждом варианте использования;

· как учесть ограничения, налагаемые режимом реального времени;

· как будет выглядеть система на самом низком уровне.

Процесс ICONIX также как и любой объектно-ориентированный процесс разработки ПО должен следовать следующим этапам:

· выявление и описание всех сценариев использования системы;

· поиск повторно используемых абстракций (классов), участвующих в нескольких сценариях (повторно используемые компоненты);

· анализ предметной области и идентификация доменных классов. При этом, надо рассматривать возможность повторного использования этих классов за пределами системы;

· проверка выполнения всех функциональных требований;

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

Более того, к процессу предъявляются следующие требования:

· он должен быть достаточно гибким для адаптации к различным видам задач;

· он должен поддерживать реально применяемые способы организации труда (включая создание прототипов и инкрементную, итеративную разработку);

· он должен повышать производительность менее опытных сотрудников коллектива, не отвлекая по мелочам более сведущих сотрудников;

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

 

Основные этапы процесса

Этапы анализа функциональных требований

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

2. Создать приблизительный пользовательский прототип интерфейса системы, либо собрать всю доступную информацию об унаследованной системе, которую есть необходимость переработать.

3. Выявить варианты использования, используя для этой цели диаграммы вариантов использования.

4. Организовать варианты использования в группы. Изобразите группы в виде пакетов.

5. Распределить функциональные требования между вариантами использования и доменными объектами предметной области.

Этапы анализа и предварительного проектирования

6. Составить текстовые описания вариантов использования – главную последовательность и альтернативные последовательности событий.

7. Выполнить анализ пригодности при этом, для каждого варианта использования:

· выявить приблизительный набор объектов, которые выполняют описанный сценарий. Использовать следующие стереотипы: , , ;

· добавить вновь обнаруженные объекты вместе с атрибутами в диаграмму классов из модели предметной области.

8. Завершить модификацию диаграммы классов так, чтобы диаграмма отражала окончание фазы анализа в работе над проектом.

⇐ Предыдущая15161718192021222324Следующая ⇒

Поделиться: