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

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

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

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

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

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

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

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

• — управляется прецедентами использования;
• — основан на архитектуре;
• — является итеративным и инкрементным.

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

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

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

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