Файл: Моделирование предметной области «Учет товаров» с помощью UML (Объектно-ориентированное проектирование приложений).pdf

Проектирование. Различают:

• логическое проектирование, при котором принимаемые решения практи­чески не зависят от условий эксплуатации (операционной сис­темы и используемого оборудования);
• физическое проектирование, при котором приходится принимать во вни­мание указанные факторы.

Логическое проектирование заключается в разработке структуры классов: определяются поля для хранения составляющих состояния объектов и алго­ритмы методов, реализующих аспекты поведения объектов. При этом исполь­зуются рассмотренные выше приемы разработки классов (наследование, компо­зиция, наполнение, полиморфизм и т.д.). Результатом является иерархия или диаграмма классов, отражающие взаимосвязь классов, и описание классов.

Физическое проектирование включает объединение описаний классов в модули, выбор схемы их подключения (статическая или динамическая компо­новка), определение способов взаимодействия с оборудованием, с операцион­ной системой и/или другим программным обеспечением (например, базами дан­ных, сетевыми программами), обеспечение синхронизации процессов для сис­тем параллельной обработки и т.д.

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

Использование поэтапной реализации существенно упрощает тестирова­ние и отладку программного продукта.

Модификация. Это процесс добавления новых функциональных воз­можностей или изменение существующих свойств системы. Как правило, изме­нения затрагивают реализацию класса, оставляя без изменения его интерфейс, что при использовании ООП обычно обходится без особых неприятностей, так как процесс изменений затрагивает локальную область. Изменение интерфейса – также не очень сложная задача, но ее решение может повлечь за собой необхо­димость согласования процессов взаимодействия объектов, что потребует из­менений в других классах программы. Однако сокращение количества пара­метров в интерфейсной части по сравнению с модульным программированием существенно облегчает и этот процесс.

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

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

1.2. MDA-архитектура

В настоящее время существует новейшая технология создания программ­ного обеспечения — Model Driven Architecture.

Model Driven Architecture (MDA) дословно переводится как «архитектура, управляемая моделью». Концепция MDA разрабатывается консорциумом OMG (Object Management Group), в который сегодня входит более 800 компаний — производителей программного и аппаратного обеспечения.

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

Модель приложений и типы моделей

В основе MDA лежит идея выделения в качестве самостоятельного и обя­зательного этапа разработки логики функционирования приложения (бизнес-логики). Согласно концепции MDA разработка приложения должна начинаться с этапа создания модели приложения, которая определяет состав, структуру и поведение будущего программного продукта. Такая модель создается не на языке программирования, а посредством языка унифицированного моделиро­вания (Unified Modelling Language, UML) и является платформенно-независи­мой (Platform Independent Model, PIM), то есть при ее создании разработчик полностью абстрагируется от особенностей конкретных программных и аппа­ратных средств реализации приложения.

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

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

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

Следует отметить, что MDA не является, по замыслу OMG, конкурентом какой-либо из существующих технологий (платформ) создания приложений (CORBA, .NET, J2EE, Sun ONE и т.д.). MDA находится на более высоком уровне обобщения процесса разработки, позволяя на этапе создания PIM-мо­дели абстрагироваться от этих платформ, на следующем этапе выбрать одну или несколько платформ разработки и создать соответствующий набор PSM-моделей и, наконец, на этапе генерации кода получить приложение, функцио­нирующее на этих платформах. Консорциум OMG полагает, что данный подход можно будет применять не только для существующих в настоящее время тех­нологий разработки, но и для любых будущих технологий при условии созда­ния для них соответствующих адаптеров (PSM-моделей).

Таким образом, OMG считает архитектуру MDA не просто новой техно­логией, а скорее «метатехнологией» создания приложений, которая отныне будет единственно актуальной, независимо от развития и появления новых средств разработки, которые MDA уже «заранее интегрировала» в себя.

Преимущества, которые дает MDA разработчикам, очевидны: локализа­ция всей логики приложения в одном месте (то есть в модели), автоматическая генерация кода и баз данных, а в перспективе — и графического интерфейса пользователя. Если заглянуть дальше, то сценарий создания приложений будет выглядеть примерно так: создается модель, которая поступает на вход специ­альной программы, а на выходе генерируются готовое приложение и база дан­ных. При необходимости изменения вносятся в модель, и затем процедура ге­нерации повторяется, причем без внесения изменений в код приложения. Из этого следует, что само понятие «разработчик программного обеспечения» может при внедрении MDA довольно сильно видоизмениться. Вследствие сме­щения акцента на создание модели разработкой приложений будут заниматься не столько программисты, сколько специалисты, владеющие описываемой предметной областью. При этом языком описания является унифицированный язык моделирования UML.

Этапы разработки MDA-приложений

Циклограмма разработки MDA-приложений в общем виде включает три основных этапа (рис. 1.2). На первом этапе разработки, исходя из поставленной задачи, формируется платформенно-независемая PIM-модель. При ее создании необходимо полностью абстрагироваться от особенностей конкретных программных или аппаратных средств. На втором этапе создаются одна или несколько платформенно-зависимых моделей PSM, которые являются своеобразными «адаптерами» или «драйверами», обеспечивающими интеграцию PIM с одной или несколькими технологиями разработки программных продуктов.

Рис. 1.2. Этапы создания MDA-приложения

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

1.3. Унифицированный язык моделирования UML

Причиной появления Unified Modelling Language (UML) стала необходи­мость унифицированного подхода к описанию моделей бизнес-приложений в начале 90-х годов ХХ века. К тому времени появилось несколько десятков ва­риантов инструментария для создания подобных моделей, но все они были не согласованы между собой, что мешало разработке CASE-средств и вносило некоторую путаницу. У истоков разработки языка UML стояла компания Rational Software, разработавшая одно из первых CASE-средств — Rational Rose. В 1995 году консорциум OMG включился в работу по стандартизации UML, затем к разработке языка активно подключились и другие компании, и, после выхода нескольких промежуточных версий, в 1997 году появилась версия UML 1.0.

В настоящее время последней стандартизованной OMG версией является UML 1.4, завершается разработка версии 2.0. Развитие UML сегодня координи­рует консорциум OMG, который считает разработку и продвижение этого языка своим стратегическим направлением.

Перечислим характерные свойства UML:

• UML является языком визуального моделирования, то есть обеспечи­вает наглядное графическое представление модели в виде одной или нескольких схем;
• UML не является языком программирования и не содержит алгорит­мов и операторов в обычном смысле — он в первую очередь является средством описания;
• UML, являясь платформенно-независимым языком, абстрагируется от специфики конкретных языков программирования и средств разра­ботки.

Язык UML базируется на объектно-ориентированном подходе и включает диаграмму классов для описания структуры и состава модели. Диаграмма клас­сов является основой для формирования модели приложения и играет важней­шую роль при работе с продуктом Bold for Delphi.

Тщательно продуманная диаграмма классов содержит основной объем необходимой информации о бизнес правилах, в значительной степени определяющих конкретное функционирование будущего приложения. Термин «бизнес-правила» означает условия и ограничения, накладываемые моделью на всю совокупность понятий моделируемого приложения окружающего мира. Любое бизнес правило можно сформулировать и на естественном языке, но в рамках UML существует и развивается формальный язык для тексто­вого описания условий, накладываемых на классы модели, т.е. описания бизнес-правил. Он получил назва­ние OCL (Object Constraint Language — язык объектных ограничений). OCL также играет чрезвычайно важную роль при практическом использовании MDA.

В настоящее время существует большое количество инструментов, обеспечивающих разработку UML-моделей. Самым первым из них был программный продукт Rational Rose, созданный в 1998 году. Он далеко не потерял своей актуальности, и активно применяется многими разработчиками и по сей день. Rational Rose представляет собой универсальный CASE-инструмент для моделирования и разработки приложений, имеющих чрезвычайно развитые программные интерфейсы с различными языками и средами программирования. Разработчиком Rational Rose является компания Rational Software, состоящая у истоков создания языка UML. В 2002 г. она была приобретена фирмой IBM. Далее в данной курсовой для создания модели приложения я буду использовать данный CASE-инструмент – IBM Rational Rose Enterprise Edition 7.0.

Следует отметить, что после включения в версию 4 Bold for Delphi полной поддержки функций импорта и экспорта модели в формате XML (XML Metadata Interchange – язык обмена метаданными XML) в принципе появилась возможность разрабатывать модели приложений для Borland MDA в любом UML-редакторе, поддерживающем этот формат (например, в PowerDesigner компании Sybase). Кроме того, в состав Delphi 7 Studio входит инструмент ModelMaker, также включающий в себя развитые средства UML-моделирования и некоторые средства интеграции с Bold. Тем не менее, с большой долей уверенности можно утверждать, что на настоящий момент именно Rational Rose остается наиболее удобным средством разработки UML-моделей для Borland MDA. Дело в том. что в качестве инструмента создания модели для Bold CASE-система Rational Rose занимает особое место среди программных средств, обладающих графическим UML-редактором. Взаимодействие с Rational Rose заложено в Borland MDA начиная с ранних версий продукта Bold for Delphi, и заложено достаточно основательно. Это взаимодействие реализуется посредством технологии COM (Component Object Model – модель компонентных объектов).

С точки зрения COM, Rational Rose является сервером автоматизации, выполняющим запросы клиента— среды разработки Borland MDA. Благодаря такому тесному механизму взаимодействия обеспечиваются следующие полезные функциональные возможности:

• автоматический запуск Rational Rose по запросу из среды Delphi;
• импорт UML-моделей и тег-параметров из Rational Rose в Bold;
• экспорт UML-моделей и тег-параметров из Bold в Rational Rose;
• доступ к тег-параметрам Bold при разработке модели в Rational Rose;
• адаптация Rational Rose к конкретным версиям Bold.

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