Logo GenDocs.ru

Поиск по сайту:  


Загрузка...

Курсовой проект - Объектно-ориентированное проектирование приложений с использованием UML - файл ОО проектирование приложений с использованием UML (ПЗ).doc


Курсовой проект - Объектно-ориентированное проектирование приложений с использованием UML
скачать (8226.2 kb.)

Доступные файлы (56):

About.dcu
About.ddp
About.dfm
About.pas
Ad_change_pass.dcu
Ad_change_pass.ddp
Ad_change_pass.dfm
Ad_change_pass.pas
Ad_reg.dcu
Ad_reg.ddp
Ad_reg.dfm
Ad_reg.pas
BusinessClasses.dcu
BusinessClasses_Interface.inc
BusinessClasses.pas
Data.dcu
Data.ddp
Data.dfm
Data.pas
EditTovarBase.dcu
EditTovarBase.ddp
EditTovarBase.dfm
EditTovarBase.pas
help.cnt
HELP.GID
HELP.HLP
Main.dcu
Main.ddp
Main.dfm
Main.pas
NewBase.dcu
NewBase.ddp
NewBase.dfm
NewBase.pas
password.psw
Sc_trial.dcu
Sc_trial.ddp
Sc_trial.dfm
Sc_trial.pas
Shifr.dll
shop.bmp
Shop.cfg
Shop.dof
Shop.dpr
shop.ico
shop.mdl
Shop.res
Shop.xml
Thumbs.db
ZakazTov.dcu
ZakazTov.ddp
ZakazTov.dfm
ZakazTov.pas
Накладная заявки.dot
Накладная продажи.dot
ОО проектирование приложений с использованием UML (ПЗ).doc18564kb.18.06.2009 09:53скачать

содержание
Загрузка...

ОО проектирование приложений с использованием UML (ПЗ).doc

  1   2   3   4   5   6   7
Реклама MarketGid:
Загрузка...
ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ

Государственное образовательное учреждение высшего профессионального образования

«ЧЕЛЯБИНСКИЙ ГОСУДАРСТВЕННЫЙ ПЕДАГОГИЧЕСКИЙ УНИВЕРСИТЕТ»

Кафедра информатики и методики преподавания информатики

ОБЪЕКТНО-ОРИЕНТИРОВАННОЕ ПРОЕКТИРОВАНИЕ ПРИЛОЖЕНИЙ С ИСПОЛЬЗОВАНИЕМ uml

Курсовая работа

Исполнитель:

студент группы ИМ-492

Морцинкевич А.Ю.
Научный руководитель:

старший преподаватель кафедры

Боровская Е.В.
Зав. кафедрой ИМПИ

кандидат педагогических наук

Леонова Е.А.

Дата допуска к защите

__________/__________

Челябинск, 2009

Оглавление


Введение 3

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

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

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

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

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

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

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

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

1.4. Bold — реализация MDA в Delphi 18

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

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

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

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

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

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

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

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

2.2.3. Работа с программой 37

Заключение 54

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

Приложение 57


Введение



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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Различают:

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

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

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

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

Все указанные выше принципы в той или иной степени реализованы в различных версиях объектно-ориентированных языков. Язык считается объ­ектно-ориентированным, если в нем реализованы первые четыре из рассмотрен­ных семи принципов.
^ 1.1.2. Этапы разработки программных систем с использованием ООП
Процесс разработки программного обеспечения с использованием ООП включает четыре этапа: анализ, проектирование, эволюция, модификация.

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

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

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

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

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

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

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

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

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

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

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


  1   2   3   4   5   6   7



Скачать файл (8226.2 kb.)

Поиск по сайту:  

© gendocs.ru
При копировании укажите ссылку.
обратиться к администрации
Рейтинг@Mail.ru