Моделирование системы "База рецептов кулинарных блюд"

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

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

на тему: Моделирование системы «База рецептов кулинарных блюд»

1. Описание предметной области модели «База рецептов кулинарных блюд»

2. Разработка модели «База рецептов кулинарных блюд»;

2.1 Диаграмма прецедентов модели «База рецептов кулинарных блюд»;

2.2 Диаграмма классов модели «База рецептов кулинарных блюд»;

2.3 Реляционная модель «Базы рецептов кулинарных блюд»;

3. Реализация модели «База рецептов кулинарных блюд»;

4. Литература.

1. Описание предметной области модели «База рецептов кулинарных блюд»

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

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

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

В данной системе используются следующие сущности:

Ингредиенты - продукты, используемые для приготовления блюд;

Рецепты - характеристика блюд;

Способ приготовления - способ приготовления блюд.

Два типа пользователей: пользователь и администратор.

Подразумевается, что рядовой пользователь имеет права на авторизацию; просмотр и поиск нужной информации. Администратор помимо прав пользователя имеет возможность редактировать данные.

С учетом введенных терминов разрабатываемая систем должна обеспечивать:

· организацию полного и достоверного учета всех рецептов кулинарной книги;

· устранение дублирования при вводе информации и, возникающих при этом механических ошибок;

· удобный интерфейс пользователю;

· разграничение полномочий рядовых пользователей и администратора.

2. Разработка модели «База рецептов кулинарных блюд»

UML - это не просто набор графических символов. За каждым из них стоит хорошо определенная семантика (см. "The Unified Modeling Language Reference Manual"). Это значит, что модель, написанная одним разработчиком, может быть однозначно интерпретирована другим - или даже инструментальной программой.

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

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

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

В UML различают восемь основных типов диаграмм:

1. Диаграмма прецедентов или вариантов использования (Use Case Diagram);

2. Диаграмма видов деятельности (Activity Diagram);

3. Диаграмма взаимодействия (Interaction Diagram);

4. Диаграмма классов (Class Diagram);

5. Диаграмма состояний (State Diagram);

6. Диаграмма кооперации (Collaboration Diagram);

7. Диаграмма компонентов (Component Diagram);

8. Диаграмма развертывания (Deployment Diagram).

2.1 Диаграмма прецедентов модели «База рецептов кулинарных блюд»

база диаграмма информация пользователь

Диаграмма прецедентов или вариантов использования (Use Case Diagram) предназначена для предварительного определения наиболее важных сущностей системы на уровне общения с пользователями. Диаграмма прецедентов обычно не привязывается к конкретным аспектам реализации системы. Она активно применяется, прежде всего, для формализации выдвигаемых заказчиком требований и синхронизации его взгляда на систему с взглядом исполнителя. Разработка сложного приложения с нуля обычно всегда начинается с построения диаграмм прецедентов.

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

Актер представляет собой связное множество ролей, которые пользователи прецедентов исполняют во время взаимодействия с ними. Обычно актер представляет роль, которую в данной системе играет человек, аппаратное устройство или даже другая система. В разрабатываемой системе «База рецептов кулинарных блюд» актерами являются администратор и пользователь.

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

Элементы диаграммы прецедентов (прецеденты и актеры) связаны отношениями. В данной диаграмме использованы отношения ассоциации и отношения включения.

рис. 1 Диаграмма прецедентов «Базы рецептов кулинарных блюд»

2.2 Диаграмма классов модели «База рецептов кулинарных блюд»

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

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

На данной диаграмме изображены два класса: рецепт и калорийность. Класс Рецепт имеет атрибуты: название блюда, способ приготовления, время приготовления, ингредиенты. Для класса Рецепт определен специфический класс T_VidBluda посредством него определяется специфический атрибут ВидБлюда через перечисление (первое блюдо, второе блюдо, закуска, салат, выпечка, соус, напиток, десерт, для малышей).

Используются связи обобщения, зависимости и ассоциации.

Рис. 2 Диаграмма классов «Базы рецептов кулинарных блюд»

2.3 Реляционная модель «Базы рецептов кулинарных блюд»

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

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

В соответствии разработанной объектно-ориентированной моделью определим таблицы на базе классов, соответствующих основным концептуальным сущностям информационной системы. Каждой соответствующей таблице дадим имя, начинающиеся на букву «Т» и включающие имя соответствующего класса, например, Т_Recept, Т_Kalorii. Таблицы UML являются стереотипными классами со стереотипом «Table», вид пиктограммы может регулироваться опцией Stereotype Display.

Рис. 3 Реляционная модель «Базы рецептов кулинарных блюд»

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

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

Используя UML, разработчик практически не зависит от организации процесса программирования; он не привязан к какому-либо конкретному циклу изготовления программного продукта. Тем не менее, разработчиками UML рекомендуется применять процесс, который:

- управляется прецедентами использования;

- основан на архитектуре;

- является итеративным и инкрементным.

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

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

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

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

3. Реализация модели «База рецептов кулинарных блюд»

Модель «База рецептов кулинарных блюд реализована в Borland Delphi 7.0, таблицы базы в Microsoft Access 2002.

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

Внешний вид среды программирования Delphi отличается от многих других из тех, что можно увидеть в Windows. Среда Delphi следует спецификации, называемой Single Document Interface (SDI), и состоит из нескольких отдельно расположенных окон.

Основные составные части Delphi:

· Дизайнер Форм (Form Designer)

· Окно Редактора Исходного Текста (Editor Window)

· Палитра Компонент (Component Palette)

· Инспектор Объектов (Object Inspector)

· Справочник (On-line help)

Дизайнер Форм в Delphi интуитивно понятен и прост в использовании визуального интерфейса. Дизайнер Форм первоначально состоит из одного пустого окна, которое заполняется всевозможными объектами, выбранными на Палитре Компонент.

Палитра Компонент позволяет выбрать нужные объекты для размещения их на Дизайнере Форм. Для использования Палитры Компонент нужно щелкнуть мышкой на один из объектов, а потом на Дизайнере Форм. Выбранный объект появится на проектируемом окне и им можно манипулировать с помощью мыши. Палитра Компонент использует постраничную группировку объектов. Внизу Палитры находится набор закладок - Standard, Additional, Dialogs и т.д. Принцип разбиения на страницы широко используется в среде программирования Delphi и его легко можно использовать в своей программе. (На странице Additional есть компоненты для организации страниц с закладками сверху и снизу).

Инспектор Объектов состоит из двух страниц, каждую из которых можно использовать для определения поведения данного компонента. Первая страница - это список свойств, вторая - список событий. Если нужно изменить что-нибудь, связанное с определенным компонентом, то обычно это делается в Инспекторе Объектов. К примеру, можно изменить имя и размер компонента TLabel изменяя свойства Caption, Left, Top, Height, и Width.

Последняя важная часть среды Delphi - Справочник (on-line help). Для доступа к этому инструменту нужно просто выбрать в системном меню пункт Help и затем Contents. На экране появится Справочник. Справочник является контекстно-зависимым; при нажатии клавиши F1, можно получить подсказку, соответствующую текущей ситуации. Если в любой момент работы в среде Delphi возникает неясность или затруднение - нужно нажать F1 и необходимая информация появится на экране.

На главной форме «Базы рецептов кулинарных блюд» размещено 10 кнопок:

· Первые блюда - ButtonBludo1

· Вторые блюда - ButtonBludo2

· Для малышей - ButtonMal

· Салаты - ButtonSalat

· Соусы - ButtonSous

· Выпечка - ButtonMuch

· Напитки - ButtonNapit

· Десерты - ButtonDesert

· Закуски - ButtonZak

· Выход - ButtonEnd

Рис. 4 Главная форма «Базы рецептов кулинарных блюд»

Все кнопки, кроме кнопки «выход» (посредством неё осуществляется выход из программы), предназначены для перехода на соответствующие формы реализованные в Microsoft Access 2002. Так, например, при нажатии кнопки «Первые блюда» осуществляется переход на форму «Первые блюда».

Рис. 5 Форма «Первые блюда» «Базы рецептов кулинарных блюд»

При нажатии кнопки «Вторые блюда» осуществляется переход на форму «Вторые блюда».

Рис. 6 Форма «Первые блюда» «Базы рецептов кулинарных блюд»

Кнопка «Выпечка» предназначена для перехода на форму «Выпечка» и т.д.

Рис. 7 Форма «Выпечка» «Базы рецептов кулинарных блюд»

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

Рис. 8 Форма «Калорийность» «Базы рецептов кулинарных блюд»

Итак, были рассмотрены базовые этапы разработки информационной системы: разработка концепции, вида с точки зрения прецедентов, вида с точки зрения проектирования, реляционного профиля баз данных. А также этап непосредственно связанный с программированием в конкретной системе программирования.

Перспективы дальнейшего развития UML связаны со становлением и интенсивным развитием новой парадигмы объектно-ориентированного анализа -- компонентной разработки приложений (Component-Based Development -- CBD). В этой связи развернута работа над дополнительной спецификацией языка UML применительно к технологиям CORBA и СОМ+. Речь идет о разработке так называемых профилей, содержащих нотацию всех необходимых элементов для представления в языке UML компонентов соответствующих технологий. При этом интенсивно используется механизм расширения языка UML за счет добавления новых стереотипов, помеченных значений и ограничений.

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

В частности, для моделирования бизнес-процессов могут быть использованы: применительно к подсистемам -- стереотипы "organization unit" и "work unit", для классов -- стереотипы "worker", "case worker", "internal worker". При этом, например, стереотип "worker" служит для обозначения класса, который представляет абстракцию человека, выполняющего определенную деятельность или работу в бизнес-системе. Работник или сотрудник взаимодействует с другими сотрудниками подсистемы в процессе выполнения отдельных операций, образующих бизнес-логику процесса.

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

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

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

Возможно со временем язык UML станет тем "эсперанто", на котором смогут общаться математики, системные аналитики, физики, программисты, менеджеры, экономисты и специалисты других профессий, представляя свои профессиональные знания в унифицированном виде. Ведь, по существу, каждый из специалистов оперирует модельными представлениями в своей области знаний. И именно этот модельный аспект может быть специфицирован средствами языка UML.

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

4. Литература

1. Червенчук И.В. Моделирование информационных систем с помощью UML: Учебное пособие по курсу «Информационные системы и процессы, моделирование и управление». - Омск: Изд.-во ОГИС, 2006. - 48с.

2. С.И. Бобровский «Система UML моделирования ModelMart»;

3. Уэнди Боггс, Майкл Боггс «UML и Rational Rose. Упражнения.»;

4. А.М. Вендров «Практикум по проектированию программного обеспечения экономических информационных систем», 2002.

5. А. Леоненков «Самоучитель UML. 2-е издание», 2004.

Размещено на Allbest.ru