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

Содержание:

Введение

В истории развития средств разработки программного обеспечения не раз происходили события, когда появление новых технологий разработки кардинально изменяло мировоззрение программистов и методы создания приложений и программных систем. Можно вспомнить в связи с этим возникновение методологии объектно-ориентированного программирования (ООП), теории и практики создания реляционных баз данных и т.д. Похоже, что в скором времени можно ожидать очередную подобную революцию, последствия которой будут, по-видимому, ничуть не меньшими по масштабу изменений в мире программирования. Речь идет о новейшей технологии создания программного обеспечения — 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.

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

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

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

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

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

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

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

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

Принципы ООП

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Различают:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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 — это, с одной стороны, среда разработки, позволяющая на этапе создания формировать объектное пространство (бизнес-уровень) и реализовывать бизнес-логику приложения, а с другой — программная система, обеспечивающая на этапе выполнения функционирование бизнес-уровня и его интеграцию с СУБД (уровнем данных) и графическим интерфейсом пользователя.

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

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

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

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

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

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

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

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

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

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

Как было сказано выше, для создания модели приложения я буду использовать программный продукт 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»).

Продолжение табл. 2.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

Продолжение табл. 2.2.

Продажа	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;

Импорт модели в 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 закончен, теперь осталось разработать графический интерфейс программы.

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

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

• 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	Возвращает список отделов магазина

Продолжение табл. 2.3.

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).

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

Рис. 2.4. Формы приложения

Рис. 2.5. Граф диалога форм приложения

Main_sc

Registr

Mainform

ВЫХОД

ChangePass

AddBase

ZakazForm

EditTovBase

My

В программе присутствуют следующие вкладки:

• Товары магазина – в данной вкладке осуществляется просмотр товара, редактирование цены, продажа товара;
• Сведения о магазине – в данной вкладке отображается информация о магазине, можно отредактировать эту информацию, а также управлять отделами магазина;
• Отделы магазина – здесь добавляются новые отделы, и производится управление группами отдела;
• Быстрые остатки – в данной вкладке отображается весь товар магазина;
• Закупочные базы – в данной вкладке осуществляется управление закупочными базами;
• Добавление нового товара – в данной вкладке осуществляется добавление нового товара в товарные базы;
• Заказ товара – осуществляется заказ товара в магазин из различных закупочных баз;
• Статистические данные – в данной вкладке отображается вся статистическая информация о магазине;
• Журнал продаж – отображается информация обо всех продажах магазина;
• Журнал закупок – отображается информация обо всех закупках магазина;
• Администраторы магазина – производится управление администраторами магазина.

2.2. Руководство пользователя

Установка и запуск

В данном разделе описаны основные инструкции по установке программы «Магазин бытовой техники»: системные требования и установка на одно рабочее место.

Для установки «Магазин бытовой техники» используется специальная программа установки, входящая в состав дистрибутива. Всегда выполняйте установку с установочного компакт–диска.

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

Для установки и работы программы «Магазин бытовой техники» необходимо:

1. ПК с процессором семейств Intel® Pentium®/Celeron®/Xeon™, AMD K6/Athlon™/Duron™/Sempron™ или совместимым с ними процессором, тактовая частота которого составляет не менее 500 МГц, или более мощным.
2. Операционная система Microsoft Windows 2003, Windows XP, Windows 2000.
3. Оперативная память – 128 МБ.
4. Свободное место на диске: 100 МБ для обычной установки.
5. Видеоплата и монитор с разрешением не менее 800x600 точек.
6. Клавиатура, мышь или другое указательное устройство.
7. Необходимо ПО: Microsoft Word, Microsoft Excel.

Установка программы «Магазин бытовой техники»

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

Чтобы установить «Магазин бытовой техники»:

1. Вставьте установочный компакт-диск в дисковод для компакт-дисков. Программа установки запустится автоматически.
2. Следуйте инструкциям программы установки.

В случае если программа установки не запустилась автоматически:

1. Нажмите кнопку Пуск на Панели задач и выберите пункт Настройка/Панель управления.
2. Дважды нажмите на значок Установка и удаление программ.
3. Выберите закладку Установка и удаление и нажмите кнопку Установить...
4. Далее следуйте инструкциям программы установки.

Запуск программы «Магазин бытовой техники»

Чтобы запустить программу «Магазин бытовой техники»:

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

Начало работы с приложением «Магазин бытовой техники»

После запуска программы появится окно заставки приложения (рис. 2.6).

Рис. 2.6. Окно заставки

После того, как полоса прогресса дойдет до конца, появится окно регистрации, в котором необходимо ввести пароль директора для доступа к программе (рис. 2.7).

Рис. 2.7. Окно регистрации

Если введенный пароль верен, то запустится основное окно программы (рис. 2.8).

Рис. 2.8. Основное окно программы

Работа с программой

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

Главное меню программы содержит следующие пункты:

• Файл
  • Смена пароля - смена пароля директора;
  • Выход - выход из программы;
• Магазин
  • Основные сведения - просмотр и редактирование сведений о магазине (название, класс и т.д.); просмотр, и редактирование отделов;
  • Статистика по магазину - просмотр статистических данных по магазину (количество товара, стоимость товара, количество отделов и групп товара и т.д.);
  • Добавить отдел/группу - добавление отдела; добавление, удаление и редактирование групп товара;
  • Добавить закупочную базу - добавление, удаление и редактирование закупочных баз;
  • Просмотр и редактирование списка администраторов;
• Товар
  • Операции с товаром - осуществление продажи товара; экспорт остатков товара в магазине в Excel; редактирование цены товара;
  • Быстрые остатки - просмотр списка всех товара магазина;
  • Внесение нового товара в базу - добавление нового товара;
  • Заказать товар в магазин - заказ товара в магазин;
• Отчет
  • Журнал продаж - просмотр списка проданного товара;
  • Журнал закупок - просмотр списка заказанного товара;
  • Остатки товара
    • В магазине - экспорт в Excel остатков товара в магазине;
    • На закупочных базах - экспорт в Excel остатков товара на базах;
• Помощь
  • Справка - запуск руководства пользователя;
  • О программе - вывод информации о программе и разработчике.

Панель инструментов дублирует почти все пункты главного меню программы (рис. 2.9).

Рис. 2.9. Панель инструментов

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

Сведения о магазине.

Для просмотра сведений о магазине необходимо в главном меню программы выбрать пункт Магазин -> Основные сведения или нажать на кнопку панели инструментов. После этого в средней части окна программы появится вкладка "Сведения о магазине" (рис 2.10).

Рис. 2.10. Сведения о магазине

В данной вкладке можно:

• Просматривать и редактировать сведения о магазине;
• Создавать, редактировать и удалять отделы магазина;

Чтобы изменить сведения о магазине, необходимо:

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

Управление отделами магазина.

Чтобы создать новый отдел необходимо:

• нажать на кнопку ;
• появится вкладка "Отделы магазина" (рис. 2.11) .

Рис. 2.11. Отделы магазина

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

Чтобы удалить существующий отдел необходимо:

• выбрать необходимый отдел из списка (рис. 2.10);
• нажать на кнопку ;
• подтвердить удаление.

Чтобы изменить название отдела необходимо:

• выбрать необходимый отдел из списка;
• нажать два раза мышью или нажать на кнопку ;
• внести необходимые изменения в поле "Название отдела";
• нажать на кнопку .

Чтобы закрыть вкладку "Сведения о магазине" необходимо нажать на кнопку в правом верхнем углу вкладки.

Управление товарными группами.

Для добавления товарной группы в отдел необходимо, чтобы отдел был уже создан. Чтобы добавить товарную группу необходимо:

• в главном меню выбрать пункт Магазин -> Добавить отдел/группу или нажать на кнопку ;
• в появившейся вкладке "Отделы магазина" (рис. 2.11) в списке отделов выбрать необходимый отдел (рис. 2.12);

Рис. 2.12. Выбор отдела

• в поле "Название группы товара" (рис. 2.13) ввести название группы

Рис. 2.13. Выбор отдела

• выбрать из выпадающего списка закупочную базу, на которой хранятся товары новой группы;
• нажать на кнопку .

Чтобы удалить товарную группу необходимо:

• в главном меню выбрать пункт Магазин -> Добавить отдел/группу или нажать на кнопку ;
• в появившейся вкладке "Отделы магазина" (рис. 2.11) в списке отделов выбрать необходимый отдел (рис. 2.12);
• в списке товарных групп отдела выбрать необходимую группу (рис. 2.14);

Рис. 2.14. Выбор товарной группы

• нажать на кнопку ;
• подтвердить удаление товарной группы.

Чтобы отредактировать товарную группу необходимо:

• в главном меню выбрать пункт Магазин -> Добавить отдел/группу или нажать на кнопку ;
• в появившейся вкладке "Отделы магазина" (рис. 2.11) в списке отделов выбрать необходимый отдел (2.12);
• в списке групп отдела выбрать необходимую группу (2.14);
• нажать на кнопку ;
• в поле "Название группы" ввести необходимые изменения;
• нажать на кнопку .

Просмотр статистики по магазину.

Чтобы просмотреть статистику по магазину необходимо в главном меню выбрать пункт Магазин ->Статистика по магазину или нажать на кнопку . После этого появится вкладка "Статистические данные" (рис. 2.15).

Рис. 2.15. Статистические данные

Общая статистика по магазину отображается в виде, как показано на рисунке 2.16.

Рис. 2.16. Статистика по магазину в целом

Чтобы просмотреть статистику по отделу, необходимо из выпадающего списка "Отдел" выбрать необходимый отдел. Чтобы просмотреть статистику по конкретной группе товара, необходимо из выпадающего списка "Отдел" выбрать необходимый отдел и в списке групп отдела выбрать необходимую группу.

Чтобы просмотреть экономические показатели магазина за определенный период времени необходимо в рамке "Экономические показатели" выбрать дату начала и конца периода (рис. 2.17) и нажать на кнопку .

Рис. 2.17. Экономические показатели магазина

Управление товарами.

Чтобы просмотреть весь список товара, имеющийся в магазине, необходимо в главном меню выбрать пункт Товар -> Быстрые остатки или нажать на кнопку панели инструментов. После этого появится вкладка "Быстрые остатки" (рис. 2.18).

Рис. 2.18. Быстрые остатки товара

В данной вкладке расположен список всех товаров, не разбитых по отделам и группам. Внизу вкладки также отображается общее количество товара, общая сумма товара по закупочной цене, общая сумма товара по цене реализации. По умолчанию в списке товаров не отображаются те товары, которые имеют нулевой остаток (т.е. количество товара равно нулю). Чтобы посмотреть все товары, включая с нулевыми остатками, необходимо поставить галочку в переключателе "С нулевыми остатками". Чтобы найти нужный товар необходимо ввести наименование товара или его часть в поле ввода «Наименование товара» и нажать на кнопку . Если вы ввели часть наименования товара, чтобы перейти к следующему подходящему по условию товару, необходимо повторно нажать на кнопку поиска и т.д.

Чтобы просмотреть товар и выполнить с ним необходимые действия необходимо, в главном меню выбрать пункт Товар -> Операции с товаром или нажать на кнопку панели инструментов. После этого появится вкладка "Товары магазина" (рис. 2.19).

Рис. 2.19. Товары магазина

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

Чтобы изменить цену реализации товара, необходимо:

• в списке товаров выбрать необходимый товар;
• нажать на кнопку ;
• подтвердить редактирование цены;
• в поле ввода ввести новую цену товара, она не должна быть меньше закупочной;
• нажать на кнопку ОК.

Чтобы отправить остатки товара магазина, необходимо нажать на кнопку в стандартном диалоговом окне сохранения файла ввести имя файла и нажать кнопку «Сохранить».

Чтобы осуществить продажу товара, необходимо:

• выбрать в главном меню пункт Товар -> Операции с товаром или нажать на кнопку панели инструментов;
• появится вкладка "Товары магазина" (2.19);
• в списке товаров выбрать необходимый товар;
• дважды щелкнуть мышью по нему или нажать на кнопку ;
• подтвердить продажу товара;
• в появившемся диалоговом окне указать количество единиц продаваемого товара и нажать на кнопку ОК;
• в списке товаров данный товар пометится другим цветом, это означает, что товар помечен на продажу (рис. 2.20);

Рис. 2.20. Пометка товара на продажу

• таким же образом пометить на продажу весь необходимый товар;
• когда весь необходимый товар помечен на продажу, необходимо нажать на кнопку ;
• подтвердить продажу товара;
• после этого появится запрос о создании накладной продажи;
• если отказаться от создания накладной, продажа товара завершена;
• если согласится, появится стандартное диалоговое окно сохранения файла, в котором необходимо ввести название файла и нажать на кнопку Сохранить;
• после этого продажа товара завершится и откроется накладная продажи в формате Microsoft Word.

Чтобы внести новый товар в закупочные базы, необходимо выбрать в главном меню пункт Товар -> Внесение нового товара в базу или нажать на кнопку панели инструментов. После этого появится вкладка "Добавление нового товара" (Рис. 2.21).

Рис. 2.21. Добавление нового товара

В данной вкладке в верхней части расположен список существующих товаров базы.

Чтобы добавить новый товар в закупочную базу, необходимо:

• в списке закупочных баз выбрать необходимую базу;
• в списке групп данной базы выбрать необходимую товарную группу;
• в рамке "Характеристики нового товара" заполнить все поля ввода (рис. 2.22);

Рис. 2.22. Характеристики нового товара

• нажать на кнопку ;
• подтвердить добавление товара.

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

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

Чтобы удалить товар из базы, необходимо:

• выбрать его в списке товаров;
• нажать кнопку ;
• подтвердить удаление товара .

Чтобы заказать товар в магазин, необходимо:

• выбрать в главном меню пункт Товар -> Заказать товар в магазин или нажать на кнопку панели инструментов;
• появится вкладка "Заказ товара" (рис. 2.23);

Рис. 2.23. Заказ товара

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

Рис. 2.24. Пометка на заказ

• таким же образом пометить весь необходимый товар;
• после того, как весь необходимый товар помечен на заказ, необходимо нажать на кнопку ;
• если заказанный товар уже существует в магазине, то его количество в магазине увеличится;
• если данного товара в магазине нет, то появится диалоговое окон задания цены реализации, в котором необходимо ввести цену реализации товара (она должна быть выше закупочной) и нажать на кнопку ОК;
• после этого появится информационное окно, сообщающее о завершении процесса заказа товара;
• затем появится запрос о создании накладной заказа;
• если отказаться от создания накладной, заказ завершен;
• если согласится, появится стандартное диалоговое окно сохранения файла, в котором необходимо ввести название файла и нажать на кнопку Сохранить;
• после этого заказ товара завершится и откроется накладная заказа в формате Microsoft Word.

Экспорт остатков товара.

Чтобы экспортировать остатки товара в магазине, необходимо:

• в главном меню выбрать пункт Отчет -> Остатки товара -> в магазине или нажать на кнопку панели инструментов;
• появится стандартное диалоговое окно сохранения файла, в котором необходимо ввести название файла и нажать на кнопку Сохранить;
• после этого экспорт товара завершится, и откроются остатки товара в формате Microsoft Excel.

Чтобы экспортировать остатки товара на базах, необходимо:

• в главном меню выбрать пункт Отчет -> Остатки товара -> на закупочных базах или нажать на кнопку панели инструментов;
• появится стандартное диалоговое окно сохранения файла, в котором необходимо ввести название файла и нажать на кнопку Сохранить;
• после этого экспорт товара завершится, и откроются остатки товара в формате Microsoft Excel.

Просмотр и редактирование списка администраторов.

Что просмотреть или изменить администраторов отделов магазина, необходимо в главном меню выбрать пункт Магазин -> Администраторы магазина. После этого появится вкладка «Администраторы магазина» (рис. 2.25).

Рис. 2.25. Администраторы магазина

В данной вкладке можно лишь просмотреть список всех администраторов магазина с указанием их отдела и отредактировать данные об администраторах. Удалить администратора нельзя, т.к. отдел не может существовать без администратора. Администратор удаляется вместе с удалением своего отдела.delotd

Чтобы отредактировать данные об администраторе, необходимо:

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

Управление закупочными базами.

Чтобы осуществить управление закупочными базами, необходимо в главном меню выбрать пункт Магазин -> Закупочные базы. После этого появится вкладка «Закупочные базы» (рис. 2.26).

Рис. 2.26. Закупочные базы

Чтобы создать новую закупочную базу, необходимо:

• нажать на кнопку ;
• в появившемся диалоговом окне заполнить все поля ввода в рамке «Новая база»;
• нажать на кнопку ;
• чтобы очистить поля ввода, необходимо нажать на кнопку ;
• чтобы отменить добавление базы, необходимо нажать на кнопку .

Чтобы удалить существующую закупочную базу, необходимо:

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

Чтобы отредактировать данные по базе, необходимо:

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

Заключение

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

Можно выделить следующие основные преимущества для разработчиков, которые дает технология MDA:

• Единый подход ко всем этапам разработки – от проектирования модели до разработки приложения, заключающийся в том, что разработчик на всех этапах работает с одними и теми же сущностями – объектами модели. Здесь отсутствует разрыв между красивой схемой-моделью и программированием приложения СУБД, так как разработчик «не опускается» на уровень базы данных, он даже может не знать, какова структура БД и какие таблицы в ней присутствуют.
• Полностью устраняется этап «ручного» создания базы данных. Все таблицы, поля, индексы, ключи генерируются автоматически в соответствии с моделью. Для использования конкретной СУБД достаточно подключить и настроить один из адаптеров баз данных, входящих в состав BMDA. Есть возможность создания собственных адаптеров баз данных.
• Модификация базы данных превращается в тривиальный процесс – после внесения необходимых изменений в модель достаточно просто сгенерировать новую базу данных. Становится не принципиально, какую именно СУБД использовать: при смене СУБД само приложение и его код не меняются.
• Использование языка OCL позволяет полностью абстрагироваться от SQL-диалекта конкретной СУБД.

В результате курсовой работы мной было разработано приложение «Магазин бытовой техники» с использованием технологии Borland MDA. Все поставленные цели и задачи были выполнены.

Список литературы

1. Грибачев К.Г., Delphi и Model Driven Architecture. Разработка приложений баз данных. – СПб.: Питер, 2004. – 348 с.: ил.
2. Буч Г., Объектно-ориентированный анализ и проектирование с примерами приложений на С++. Пер. с англ. М.: Бином, СПб.: Невский диалект, 1998. - 560 с.
3. Лесневский А.С., Объектно-ориентированное программирование для начинающих. – М.: Бином. Лаборатория знаний, 2005. – 232 с.: ил.
4. Иванова Г.С., Ничушкина Т.Н., Пугачев Е.К., Объектно-ориентированное программирование: Учеб. для вузов. – М.: Изд-во МГТУ им. Баумана, 2001. – 320 с.: ил.
5. Боггс У., Боггс М. UML и Rational Rose. М.: «Лори», 2000 г. – 582 с.
6. Трофимов С.А., CASE-технологии: Практическая работа в Rational Rose. – 2-е изд.–М.: Бином-Пресс, 2002.–288 с.
7. Вендров А.М., CASE – технологии. Современные методы и средства проектирования информационных систем, М., Фин. и статистика, 2000. – 368 с.: ил.
8. Кватрани Т., Rational Rose 2000. Визуальное моделирование. – M.: ДК, 2001. – 457 с.: ил.
9. Фаулер М., Скотт К., UML. Основы. – Пер. с англ. – Спб.: Символ-Плюс, 2002. – 192 с.: ил.
10. Леоненков А., Самоучитель UML. – СПб: Питер, 2001. – 158 с.: ил.
11. Буч Г., Рамбо Д., Джекобсон А., Язык UML. Руководство пользователя: Пер. с англ. - М.:ДМК, 2000. -432с.
12. Орлов С., Технологии разработки программного обеспечения: Учебник. – СПб.: Питер, 2002. – 464 с.: ил.
13. Бобровский С., Delphi 7. Учебный курс. – СПб.: Питер, 2003. – 736 с.: ил.
14. Глушаков С.В., Клевцов А.Л., Программирование в среде Delphi. Учебный курс. – 2-е изд., доп. и перераб. – Харьков.: Филио, 2003. 528 с.
15. Фаронов В.В., Программирование баз данных в Delphi 7. Учебный курс. – СПб.: Питер, 2006. – 459 с.: ил.
16. Корняков В.Н., Программирование документов и приложений MS Office в Delphi. – СПб.: БХВ-Петербург, 2005. – 496 с.: ил.
17. Ревич Ю.В., Нестандартные приемы программирования на Delphi. – СПб.: БХВ-Петербург, 2005. – 560 с.: ил.
18. Ков О., UML. Мета-язык проектирования и моделирования программного обеспечения/ О. Ков – www.metod.square.spb.ru, 2001.