UML в эконометрическом проектировании

Размещено на http://www.allbest.ru/

Введение

В истории развития средств разработки программного обеспечения не раз происходили события, когда появление новых технологий разработки кардинально изменяло мировоззрение программистов и методы создания приложений и программных систем. Можно вспомнить в связи с этим возникновение методологии объектно-ориентированного программирования (ООП), теории и практики создания реляционных баз данных и т.д. Похоже, что в скором времени можно ожидать очередную подобную революцию, последствия которой будут, по-видимому, ничуть не меньшими по масштабу изменений в мире программирования. Речь идет о новейшей технологии создания программного обеспечения - Model Driven Architecture.

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

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

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

Несмотря на крайне высокую востребованность и присутствие в составе Delphi в течение уже без малого шести лет, технология Borland MDA продолжает оставаться практически неизвестной ни разработчикам, ни руководителям проектов, ни архитекторам приложений. Причиной этого является, с одной стороны, практически полное отсутствие публикаций книг об этой технологии, а с другой стороны, ее «нетрадиционность». Применение этой технологии требует преодоления определенных барьеров, одним из которых является присущий многим из нас консерватизм.

Цель исследования - изучить технологию создания объектно-ориентированных приложений - MDA и разработать программный продукт «Магазин бытовой техники» с использованием данной технологии. Для этого необходимо решить следующие задачи:

· рассмотреть основные вопросы об архитектуре MDA и ее базовом инструменте - языке UML;

· разработать UML-модель приложения «Магазин бытовой техники» в Rational Rose;

· создать приложение «Магазин бытовой техники» в среде Delphi с использованием Bold for Delphi.

1. Объектно-ориентированное проектирование приложений

1.1 Технология проектирования ООП

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

Взаимодействие программных объектов в такой системе осуществляется путем передачи сообщений (рис 1.1).

Рис. 1.1 - Архитектура программы при ООП

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

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

Основной недостаток ООП - некоторое снижение быстродействия за счет более сложной организации программной системы.

1.1.1 Принципы ООП

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

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

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

Ш интерфейс - совокупность доступных извне элементов реализации абстракции (основные характеристики состояния и поведения);

Ш реализация - совокупность недоступных извне элементов реализации абстракции (внутренняя организация абстракции и механизмы реализации ее поведения).

Ограничение доступа в ООП позволяет разработчику:

Ш выполнять конструирование системы поэтапно, не отвлекаясь на особенности реализации используемых абстракций;

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

Сочетание объединения всех свойств предмета (составляющих его состояния и поведения) в единую абстракцию и ограничения доступа к реализации этих свойств получило название инкапсуляции.

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

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

В ООП используются два вида иерархии.

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

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

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

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

Использование принципа типизации обеспечивает:

Ш раннее обнаружение ошибок, связанных с недопустимыми операциями над программными объектами (ошибки обнаруживаются на этапе компиляции программы при проверке допустимости выполнения данной операции над программным объектом);

Ш упрощение документирования;

Ш возможность генерации более эффективного кода.

Тип может связываться с программным объектом статически (тип объекта определен на этапе компиляции - раннее связывание) и динамически (тип объекта определяется только во время выполнения программы - позднее связывание). Реализация позднего связывания в языке программирования позволяет создавать переменные - указатели на объекты, принадлежащие различным классам {полиморфные объекты), что существенно расширяет возможности языка.

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

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

Реальный параллелизм достигается только при реализации задач такого типа на многопроцессорных системах, когда имеется возможность выполнения каждого процесса отдельным процессором. Системы с одним процессором имитируют параллелизм за счет разделения времени процессора между задачами управления различными процессами. В зависимости от типа используемой операционной системы (одно- или мультипрограммной) разделение времени может выполняться либо разрабатываемой системой (как в MS DOS), либо используемой ОС (как в системах Windows).

Устойчивость - свойство абстракции существовать во времени независимо от процесса, породившего данный программный объект, и/или в пространстве, перемещаясь из адресного пространства, в котором он был создан.

Различают:

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

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

Ш глобальные объекты, существующие пока программа загружена в память;

Ш сохраняемые объекты, данные которых хранятся в файлах внешней памяти между сеансами работы программы.

Все указанные выше принципы в той или иной степени реализованы в различных версиях объектно-ориентированных языков. Язык считается объектно-ориентированным, если в нем реализованы первые четыре из рассмотренных семи принципов.

1.1.2 Этапы разработки программных систем с использованием ООП

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

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

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

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

Ш физическое проектирование, при котором приходится принимать во внимание указанные факторы.

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

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

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

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

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

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

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

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

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

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

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

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

В основе 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.

1.2.2 Этапы разработки 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.

1.4 Bold - реализация MDA в Delphi

В настоящее время, производители программного обеспечения уже разработали несколько инструментов для реализации MDA-технологии в различных средах программирования. Среди этих инструментов имеется и программный продукт для реализации MDA в Delphi. Шведская компания BoldSoft MDE Aktiebolag, активный участник консорциума OMG, создала первую версию программного продукта Bold for Delphi в 1999 году, а в 2000-м в состав Borland Enterprise Studio 6 вместе с Delphi 6 вошла доработанная и расширенная версия Bold 3. В сентябре 2002 года в состав Delphi 7 Studio Architect вошла версия 4 Bold этого продукта. В начале октября фирма Borland приобрела шведскую компанию BoldSoft, так что в настоящее время Bold является продуктом фирмы Borland.

Основные возможности Bold for Delphi:

· встроенный текстовый редактор UML-моделирования для создания моделей приложения;

· возможность импорта и экспорта UML-моделей из Rational Rose - CASE-средства компании Rational Software;

· автоматическая генерация баз данных практически для всех реляционных СУБД, существующих в настоящее время (доступных через интерфейсы BDE, ADO, dbExpress);

· поддержка модификации базы данных с сохранением информации (DataBase Evolution);

· возможность хранения базы данных в XML-документе без использования СУБД;

· поддержка подмножества языка UML;

· автоматическая генерация программного кода на языке Object Pascal;

· автоматическая генерация экранных форм для просмотра и редактирования данных;

· поддержка создания многозвенных приложений и тонких клиентов на базе DCOM.

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

На практике использование Bold дает следующие преимущества:

· полностью устраняется этап ручного создания базы данных - все таблицы, поля, индексы, ключи генерируются автоматически в соответствии с моделью. Для использования конкретной СУБД достаточно подключить и настроить один из адаптеров баз данных, входящих в состав Bold. Есть возможность создания собственных адаптеров баз данных;

· модификация базы данных превращается в тривиальный процесс - после внесения необходимых изменений в модель следует только сгенерировать новую базу данных;

· использование языка OCL позволяет полностью абстрагироваться от SQL-диалекта конкретной СУБД. Язык SQL становится практически ненужным и используется редко, хотя возможность его применения сохраняется;

· автоматически генерируемые экранные формы избавляют разработчика от необходимости рутинного кодирования графического интерфейса для ввода и редактирования данных. При этом автоматически задействуется интерфейс drag&drop для перемещения мышью необходимых данных между таблицами.

Используя Bold, разработчик:

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

· работает не с таблицами, полями и ключами базы данных, а с объектами созданной им модели приложения - классами и их атрибутами;

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

· не пишет запросы на языке SQL, а формирует предложения на гибком и мощном диалекте языка OCL.

В этом случае разработка ведется на бизнес-уровне.

Принципиальным моментом при использовании Bold является трехуровневая схема создания приложения, которая включает уровень данных, бизнес-уровень и графический интерфейс пользователя. И в данном случае это - не абстракция, а реальность, воплощенная в конкретные наборы компонентов Bold, с которыми имеет дело разработчик. Так, если обычно при создании приложения баз данных в Delphi визуальные компоненты подключаются к полям или таблицам БД, то при работе с Bold все они подключаются к промежуточному слою - к объектам бизнес-уровня. Формирование бизнес-уровня приложения является одной из основных функций Bold. Другая важнейшая функция - обеспечение взаимодействия между бизнес-уровнем и уровнем данных (СУБД), то есть объектно-реляционное отображение и взаимодействие. Такое взаимодействие включает автоматическую, прозрачную для разработчика, трансляцию OCL в операторы SQL, выполнение операций с таблицами БД и т.д.

Bold работает не только на этапе разработки приложения, но и на этапе его исполнения. Именно это качество позволяет называть Bold инструментом реализации MDA. Любое CASE-средство, сколь бы совершенным оно ни было, предназначено для реализации только этапов проектирования и моделирования. Оно, конечно, может включать также возможности генерации кода и генерации базы данных, но после запуска приложения CASE-система уже не функционирует, ее «присутствие» на этом этапе по сути уже не ощущается. Функционирование же Bold коренным образом отличается от функционирования других CASE-средств: сохраняя модель приложения в исполняемом файле, Bold на этапе выполнения приложения использует эту модель для управления бизнес-уровнем, для контроля целостности объектного пространства, для управления взаимодействием бизнес-уровня с уровнем данных и графическим интерфейсом.

Bold - это не генератор кода, хотя такая возможность в него заложена. При использовании Bold в принципе не обязательно генерировать код классов модели.

В итоге можно сделать вывод, что Bold for Delphi - это, с одной стороны, среда разработки, позволяющая на этапе создания формировать объектное пространство (бизнес-уровень) и реализовывать бизнес-логику приложения, а с другой - программная система, обеспечивающая на этапе выполнения функционирование бизнес-уровня и его интеграцию с СУБД (уровнем данных) и графическим интерфейсом пользователя.

2. Разработка программного продукта

2.1 Проектирование приложения «Магазин бытовой техники»

Чтобы посмотреть на практике, как создаются приложения с использованием MDA-технологии, a также унифицированным языком моделирования UML, необходимо разработать программный продукт «Магазин бытовой техники».

Программная система "Магазин бытовой техники" предназначена для директора магазина бытовой техники. Данная система обеспечивает хранение сведений о магазине, об имеющихся в нем товарах, о торговых базах и товарах, хранящихся на этих базах. Магазин осуществляет закупку товара на разных базах. Магазин состоит из нескольких отделов. Каждым отделом управляет администратор. Каждый отдел включает несколько групп товара. Каждая группа товара закупается только на одной конкретной закупочной базе.

Магазин характеризуется названием, классом, номером, а также имеет другие сведения: юридический адрес, ИНН, электронный адрес.

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

Также, директор может узнать следующие сведения:

· какие товары имеются в магазине (на базе);

· какие товары, и в каком количестве имеются в отделе магазине, конкретной группе товаров;

· список отделов;

· список групп товара каждого отдела;

· список администраторов магазина;

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

· на каких базах, и в каких количествах есть товар нужного наименования.

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

2.1.1 Создание модели приложения

Как было сказано выше, для создания модели приложения я буду использовать программный продукт IBM Rational Rose Enterprise Edition 7.0. Учитывая все требования, предъявляемые к программной системе, создаем ее UML модель (рис. 2.1).

Рис 2.1 - UML-модель программной системы

Описание классов модели приложения:

Магазин - класс, содержащий сведения о магазине: название, класс магазина, номер, юридический адрес, ИНН, телефон, электронный адрес.

Отдел - класс, содержащий сведения обо всех отделах магазина, характеризуется названием.

Группа товаров - класс, содержащий сведения о товарных группах, характеризуется названием.

Товар - родительский класс для классов: «товар в магазине» и «товар на складе». Класс «товар» содержит общие сведения этих двух классов: наименование товара, цена закупки и гарантийный срок.

Товар в магазине - дочерний класс класса «товар», содержит сведения о товарах, хранящихся в магазине. Помимо родительских атрибутов, класс «товар в магазине» имеет атрибуты: количество товара, цена реализации, количество продажи, сумма. Атрибут «количество продажи» предназначен для хранения информации о количестве единиц товара, помеченного на продажу. Атрибут «сумма» - это вычисляемый атрибут. Он не хранится в базе данных, а автоматически вычисляется в приложении. Хранит информацию о стоимости данного наименования товара, т.е. это произведение количества товара на его цену реализации.

Товар на складе - дочерний класс класса «товар», содержит сведения о товарах, хранящихся на различных закупочных базах. Помимо родительских атрибутов, класс «товар на складе» имеет атрибуты: количество товара и количество заказа. Атрибут «количество заказа» предназначен для хранения информации о количестве единиц товара, помеченного на заказ в магазин.

Товарная база - класс, содержащий сведения о закупочных базах. Данный класс содержит атрибуты: название базы и адрес.

Администратор - класс, содержащий сведения об администраторах отделов. Данный класс имеет атрибуты: фамилия, имя, отчество, дата рождения.

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

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

Отсутствие связи двух последних классов с другими классами объясняется тем, что это журналы, которые хранят сведения о продажах и закупках когда-либо производимых в магазине. Если, например, устанавливать связь класса «продажа» с классом «товар в магазине», то при удалении товара в магазине из журнала продаж данный товар тоже удалится, а нам необходимо, чтобы продажа оставалась всегда.

Описание ассоциаций между классами приведено в таблице 2.1.

Таблица 2.1 - Описание ассоциаций между классами

Ассоциация	Описываемые бизнес правила
Магазин - Отдел	· магазин состоит из одного или нескольких отделов (размерность «1..n»); · каждый отдел принадлежит только одному магазину (размерность «1»).
Отдел - Группа товаров	· каждый отдел включает одну или несколько групп товара (размерность «1..n»); · каждая группа товара принадлежит только одному отделу (размерность «1»).
Отдел -Администратор	· каждый отдел управляется только одним администратором (размерность «1»); · каждый администратор заведует только одним отделом (размерность «1»).
Группа товаров - Товар в магазине	· каждая группа товаров содержит множество товаров, а может не содержать товар вообще (размерность «0..n»); · каждый товар принадлежит только одной группе товаров (размерность «1»).
Магазин -Товарная база	· магазин имеет одну и более товарных баз (размерность «1..n»); · каждая товарная база принадлежит только одному магазину (размерность «1»).
Товарная база - Группа товаров	· каждая товарная база хранит товар одной и более групп товара (размерность «1..n»); · каждая группа товаров закупается только на одной товарной базе (размерность «1»).
Товарная база - Товар на складе	· каждая товарная база содержит множество товара, а может не содержать ни одного товара (размерность «0..n»); · каждый товар хранится только на одной товарной базе (размерность «1»).
Группа товаров - Товар на складе	· каждая группа товаров хранит на складе множество товаров, а может ничего не хранить (размерность «0..n»); · каждый товар на складе принадлежит только одной группе товаров (размерность «1»).

Как видно из рисунка 2.1, при описании модели используются русскоязычные названия классов, атрибутов и ассоциаций. Это очень удобно использовать для наглядности модели. Чтобы при создании приложения в Delphi не возникало проблем, необходимы англоязычные названия классов, атрибутов и ассоциаций. Для этого необходимо настроить некоторые тег-параметры классов, атрибутов и ассоциаций:

· DelphiName - отвечает за преобразование имени класса, атрибута или ассоциации UML-модели в идентификатор класса, поля или связи используемых в среде Delphi;

· ExpressionName - отвечает за преобразование имени класса, атрибута или ассоциации модели в имя объекта, используемое для обозначения класса в выражениях на языке OCL;

· TableName - отвечает за преобразование имени класса модели в имя таблицы СУБД, используемой для хранения информации об объектах данного класса (только для класса);

· ColumnName - используется для обозначения столбца таблицы БД для атрибутов класса, а также этот тег параметр задействуется Borland MDA в случае единичной кратности роли для ассоциации.

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

Настройка тег-параметров привелена в таблице 2.2.

Таблица 2.2 - Настройка тег-параметров классов, атрибутов и ассоциаций

Имя класса, атрибута, ассоциации	Настройка тег-параметров
Магазин	DelphiName: TShop; ExpressionName, TableName: Shop
	Название	ColumnName, ExpressionName, DelphiName: Shname
	Класс	ColumnName, ExpressionName, DelphiName: Shclass
	Номер	ColumnName, ExpressionName, DelphiName: Shnumber
	Юридический адрес	ColumnName, ExpressionName, DelphiName: Shaddress
	ИНН	ColumnName, ExpressionName, DelphiName: ShINN
	Телефон	ColumnName, ExpressionName, DelphiName: Shphone
	Электронный адрес	ColumnName, ExpressionName, DelphiName: Shmail
Отдел	DelphiName: TOtdel; ExpressionName, TableName: Otdel
	Название	ColumnName, ExpressionName, DelphiName: Oname
Группа товаров	DelphiName: TGroup; ExpressionName, TableName: Group
	Название	ColumnName, ExpressionName, DelphiName: Gname
Товарная база	DelphiName: TBase; ExpressionName, TableName: Base
	Название	ColumnName, ExpressionName, DelphiName: Bname
	Адрес	ColumnName, ExpressionName, DelphiName: Baddress
Товар	DelphiName: TTovar; ExpressionName, TableName: Tovar
	Наименование	ColumnName, ExpressionName, DelphiName: Tname
	Цена закупки	ColumnName, ExpressionName, DelphiName: Tprice
	Гарантийный срок	ColumnName, ExpressionName, DelphiName: Tgarant
Товар в магазине	DelphiName: TTtov_mag; ExpressionName, TableName: Ttov_mag
	Количество	ColumnName, ExpressionName, DelphiName: Tmcount
	Цена реализации	ColumnName, ExpressionName, DelphiName: Tmprice
	Количество продажи	ColumnName, ExpressionName, DelphiName: Prodcount
	Сумма	ColumnName, ExpressionName, DelphiName: Tmsumma; DerivationOCL: Tmprice*Tmcount
Товар на складе	DelphiName: TTtov_base; ExpressionName, TableName: Ttov_base
	Количество	ColumnName, ExpressionName, DelphiName: Tbcount
	Количество заказа	ColumnName, ExpressionName, DelphiName: Zakazcount
Администратор	DelphiName: TAdmin; ExpressionName, TableName: Admin
	Фамилия	ColumnName, ExpressionName, DelphiName: Afam
	Имя	ColumnName, ExpressionName, DelphiName: Aname
	Отчество	ColumnName, ExpressionName, DelphiName: Asname
	Дата рождения	ColumnName, ExpressionName, DelphiName: Adr
Продажа	DelphiName: TProdazha; ExpressionName, TableName: Prodazha
	Номер	ColumnName, ExpressionName, DelphiName: Pnumber
	Дата продажи	ColumnName, ExpressionName, DelphiName: Pdate
	Наименование товара	ColumnName, ExpressionName, DelphiName: PZtov_name
	Количество	ColumnName, ExpressionName, DelphiName: Pcount
	Цена закупки	ColumnName, ExpressionName, DelphiName: Pprice
	Цена реализации	ColumnName, ExpressionName, DelphiName: PRprice
	Сумма	ColumnName, ExpressionName, DelphiName: Psumma; DerivationOCL: pRprice * pcount
Заказ	DelphiName: TZakaz; ExpressionName, TableName: Zakaz
	Номер	ColumnName, ExpressionName, DelphiName: Znumber
	Дата заказа	ColumnName, ExpressionName, DelphiName: Zdate
	Наименование	ColumnName, ExpressionName, DelphiName: Zname
	Количество	ColumnName, ExpressionName, DelphiName: Zcount
	Цена закупки	ColumnName, ExpressionName, DelphiName: Zprice
Магазин-Отдел	LinkClassName: LinkSostoitPrinadlezhit; (A) ColumnName, ExpressionName, DelphiName: Sostoit; DelуteAction: Cascade; (В) ColumnName, ExpressionName, DelphiName: Prinadlezhit;
Отдел-Группа товаров	LinkClassName: LinkVluchaetPrinadlezhit; (A) ColumnName, ExpressionName, DelphiName: Vkluchaet; DeleteAction: Cascade; (В) ColumnName, ExpressionName, DelphiName: Prinadlezhit;
Отдел-Администратор	LinkClassName: LinkZaveduetUpravlyaetsya; (A) ColumnName, ExpressionName, DelphiName: Zaveduet; DeleteAction: Cascade; (В) ColumnName, ExpressionName, DelphiName: Upravlyaetsya; DeleteAction: Cascade;
Магазин-Товарная база	LinkClassName: LinkImeetImeetsya; (A) ColumnName, ExpressionName, DelphiName: Imeet; DeleteAction: Cascade; (В) ColumnName, ExpressionName, DelphiName: Imeetsya;
Группа товаров-Товар в магазине	LinkClassName: LinkSostoitPrinadlezhit; (A) ColumnName, ExpressionName, DelphiName: Soderzhit; DeleteAction: Cascade; (В) ColumnName, ExpressionName, DelphiName: Prinadlezhit;
Товарная база-Группа товаров	LinkClassName: LinkZakupaetsyaHranit; (A) ColumnName, ExpressionName, DelphiName: Zakupaetsya; (В) ColumnName, ExpressionName, DelphiName: Hranit;
Товарная база-Товар на складе	LinkClassName: LinkSoderzhitHranitsya; (A) ColumnName, ExpressionName, DelphiName: Soderzhit; DeleteAction: Cascade; (В) ColumnName, ExpressionName, DelphiName: Hranitsya;
Группа товаров-Товар на складе	LinkClassName: LinkBHranitBPrinadlezhit; (A) ColumnName, ExpressionName, DelphiName: BHranit; DeleteAction: Cascade; (В) ColumnName, ExpressionName, DelphiName: BPrinadlezhit;

2.1.2 Импорт модели в Borland MDA

После того, как настроены тег-параметры наша модель готова к импорту в Delphi.

Далее разработка приложения ведется в среде Delphi. Создаем новое приложение Delphi и создадим в нашем приложении специальный модуль данных DataShop: TDataShop. На этом модуле необходимо разместить компоненты Bold, которые будут реализовывать основу «объектного пространства» нашего приложения:

· ShopModel: TBoldModel - обеспечивает хранение модели;

· BoldSystemHandleShop: TBoldSystemHandle - основной компонент-дескриптор объектного пространства;

· BoldSystemTypeInfoHandleShop: ТBoldSystemTypeInfoHandle - основной компонент-дескриптор типов моделей;

· BoldUMLRoseLinkShop: ТBoldUMLRoseLink - предназначен для связи с моделью Rational Rose;

· BoldPersistenceHandleFileXMLShop: ТBoldPersistenceHandleFileXML - обеспечивает хранение состояния объектного пространства в файле формата XML. Способ хранения данных в файле XML имеет свои преимущества: простота разработки, нет необходимости применять посторонние продукты (СУБД), настраивать подключение к БД и т.д.; простота использования - обеспечивается максимальная переносимость приложения, отсутствует необходимость инсталляции и настройки, возможен запуск приложения с любого носителя на любом компьютере.

Необходимо настроить свойства этих компонентов в соответствии с приведенной на рис. 2.2 диаграммой.

Рис. 2.2 - Компоненты модуля данных

Теперь все готово для импорта модели Rational Rose в среду Borland MDA. Для этого необходимо дважды щелкнуть по компоненту ShopModel и в открывшемся встроенном UML-редакторе Bold запустить импорт нажатием на кнопку панели инструментов Import via link. После этого произойдет импорт модели. Перед созданием графической части приложения необходимо сгенерировать код модели. Для этого во встроенном UML-редакторе Bold вызвать в главном меню Tools -> Generate Cod. Появятся последовательно два окна с предложением выбрать имена генерируемых файлов интерфейса и файла программы. В результате проведенной операции на диске образуются два файла:

· BusinessClasses_Interface.inc - файл описания внешних программных интерфейсов;

· BusinessClasses.pas - файл, содержащий код классов UML-модели.

При этом в секцию Uses нашего проекта автоматически добавится сгенерированный модуль BusinessClasses. На этом этап импорта модели в Borland MDA закончен, теперь осталось разработать графический интерфейс программы.

2.1.3 Создание графического интерфейса

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

· BoldListHanle - не визуальный компонент-дескриптор, используется в основном для таких визуальных компонентов, как BoldGrid, BoldSortingGrid, BoldListBox, BoldLabel, BoldEdit. В свойстве Expression необходимо ввести требуемые OCL выражения. Например, чтобы получить список всех отделов магазина, необходимо в свойстве Expression дескриптора ListOtdels: TBoldListHanle ввести OCL выражение: 'Otdel.allInstances';

· BoldSortingGrid - визуальный компонент, в котором отображается информация об экземплярах класса, данный компонент подключается к дескриптору. Например, если его подключить к дескриптору ListOtdels, то в таблице отобразятся все отделы магазина;

· BoldListBox, BoldLabel, BoldEdit - будут отображать различную информацию об объектном пространстве приложения. Также подключаются к дескрипторам;

· Также будут использоваться стандартные VCL-компоненты, такие как: MainMenu, GroupBox, PageControl, SpeedButton, Edit и другие компоненты.

Все компоненты-дескрипторы, используемые в приложении, представлены на рис. 2.3, а их описание в табл. 2.3.



Рис. 2.3 - Дескрипторы приложения

Таблица 2.3 - Описание дескрипторов приложения

Дескриптор	Предназначение
ListGroups	Возвращает список всех товарных групп магазина
ListShopName	Возвращает название магазина
ListAdmin	Возвращает список всех администраторов магазина
ListOtdels	Возвращает список всех отделов магазина
ListOtdelsGroups	Возвращает список товарных групп, принадлежащих текущему отделу
ListBases	Возвращает список всех товарных баз магазина
ListOtdelsGroupTovar	Возвращает список товаров, принадлежащих текущей товарной группе, которая в свою очередь принадлежит текущему отделу
ListGroupTovar	Возвращает список товаров, принадлежащий текущей товарной группе
ListShop	Возвращает все данные о магазине
ListShopOtdel	Возвращает список отделов магазина
ListBaseGroupTovar	Возвращает список товаров, принадлежащих текущей товарной группе, которая в свою очередь принадлежит текущей товарной базе
ListBaseGroup	Возвращает список товарных групп текущей товарной базы
ListTovar	Возвращает список всех товаров магазина
ListShopBase	Возвращает список всех товарных баз магазина
ListZakupka	Возвращает список всех закупок магазина
ListBaseTovar	Возвращает список всех товаров хранящихся на всех товарных базах
ListProdazha	Возвращает список всех продаж магазина
ListProdazhaOtchet	Возвращает список всех продаж магазина (для экспорта)
ListZakupkaOtchet	Возвращает список всех закупок магазина (для экспорта)

Программная система будет включать восемь форм (рис. 2.4):

· Mainform - основная форма, на которой будут расположены все основные компоненты;

· Main_sc - заставка программной системы;

· Registr - форма регистрации (ввод пароля директора перед запуском основной формы);

· ChangePass - форма смены пароля директора;

· AddBase - форма добавления новой товарной базы;

· EditTovBase - форма редактирования сведений о товарной базе;

· My - форма отображения информации о программе и разработчике;

· ZakazForm - форма указания количество единиц заказываемого товара.

Граф диалога форм приложения представлен на рисунке 2.5.

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