рефераты конспекты курсовые дипломные лекции шпоры

Реферат Курсовая Конспект

Анализ и обоснование методологии разработки, управления, применяемых инструментальных средств.

Анализ и обоснование методологии разработки, управления, применяемых инструментальных средств. - раздел Право, Анализ и обоснование методологии разработки, управления, применяемых инструментальных средств…………………………………………………….12 Семейство Программных Продуктов Powersoft Powerdesigner Является Современным ...

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

Продукт PowerDesigner фирмы Powersoft адресован разработчикам информационных систем. Это графический инструмент для проектирования структуры реляционных баз данных. PowerDesigner реализует популярную методологию информационного моделирования, основанную на представлении информационных объектов и взаимосвязей между ними в виде ER-диаграммы ("сущность-связь"). Используемая в PowerDesigner нотация - IE (Information Engineering).

В S-Designer эффективно реализована связь как со множеством современных СУБД, так и со средствами разработки приложений. По завершении разработки модели данных PowerDesigner генерирует пакеты SQL-предложений для широкого набора СУБД, включая Oracle, Ingres, Informix, Sybase, RDB, SQL Server, DB2, AS/400, SQLBase, Access и Paradox. Имеется встроенный ISQL. Для поддерживаемых СУБД автоматически генерируются триггеры, обеспечивающие ссылочную целостность. Предусмотрена возможность редактировать хранимые процедуры непосредственно при подготовке физической модели. Для обеспечения сопровождения существующих систем PowerDesigner позволяет проводить восстановление модели по структуре базы данных (БД). В течение всего цикла разработки модели данных (рисунок 21) с помощью PowerDesignor могут быть получены разнообразные отчеты по модели.

На этапе проектирования модели данных PowerDesigner дает возможность определить элементы пользовательского интерфейса будущих приложений, работающих с проектируемой базой данных. Это достигается редактированием репозиториев систем 4GL. В качестве средств разработки поддерживается PowerBuilder, TeamWindows, Progress, Uniface и другие.

PowerDesigner работает в среде Microsoft Windows и Windows NT. В PowerDesigner присутствуют элементы, характерные для программ редактирования - линейка инструментов, интерфейс "drag-and-drop", импорт/экспорт графических файлов, инструменты для создания стандартных графических элементов, управление цветом и шрифтовым выделением.

При работе с PowerDesigner сразу заметны очень высокая скорость отрисовки диаграммы и эффективная реализация интерфейса к СУБД.

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

Цикл разработки в PowerDesigner

При проектировании в PowerDesigner используется двухуровневый подход. Первый уровень - концептуальная модель данных (ER-диаграмма). Второй уровень - физическая модель данных. При переходе на второй уровень PowerDesigner автоматически генерирует соответствующую физическую модель данных для заданной СУБД, учитывая специфику последней.

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

Рисунок 2 - Цикл разработки в PowerDesigner

Особенность реализации цикла разработки в PowerDesigner заключается в том, что он позволяет выполнять "сквозное проектирование". Это значит, что разработав концептуальная модель можно автоматически сгенерировать физическую и после этого выполнить генерацию структуры БД. При обратном проектировании последовательность действий прямо противоположная. Можно получить физическую модель на основе структуры БД и после этого автоматически сгенерировать концептуальную модель. Разумеется на каждом этапе можно вносить изменения в модели концептуального и физического уровней.

PowerDesigner четко отслеживает соответствие между концептуальным и физическим уровнем и "помнит" не только изменения в структуре объектов модели (уточнения связей, выполненные при переходе на физический уровень), но и их расположение на ER- диаграмме. При генерации этим "учетом изменений" можно управлять. Таким образом, автоматическая генерация - процесс, выполняемый в PowerDesigner очень эффективно и качественно.

Последовательность проектирования модели данных в PowerDesigner

Процесс построения информационной модели данных состоит из следующих шагов:

- определение сущностей;

- определение зависимостей между сущностями;

- задание первичных и альтернативных ключей;

- определение атрибутов сущностей;

- переход к физическому описанию модели (выполняется автоматически);

- редактирование имен таблиц и их атрибутов на физическом уровне (если в модели имеются, например, связи "многие ко многим" или иерархические рекурсивные связи и их надо уточнить);

- проектирование триггеров, процедур и ограничений;

- генерация базы данных.

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

Графические элементы диаграммы концептуальной модели

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

Связь (relationship) изображается линией, соединяющей сущности. Мощность связи показывается окончаниями линии. Мощность "один" изображается простой линией, мощность "много" - разветвленной линией. Если связь присутствует для всех экземпляров сущности, то линия перечеркивается, в противном случае - изображается окружностью на линии. Треугольник на линии связи обращен вершиной к родительской сущности (рисунок 22).

Рисунок 22 - Элементы диаграммы концептуальной модели

 

Создание физической модели данных

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

Рисунок 23 - Связь один ко многим на диаграмме физической модели

Связь "многие ко многим" (рисунок 24) порождает новую таблицу. Таким образом обеспечивается автоматическая нормализация модели. Идентификаторы сущностей, участвующих в связи, мигрируют в новую таблицу. При этом первичный ключ новой таблицы объединяет колонки первичных ключей таблиц, участвующих в связи.

Рисунок 24 - Исходная концептуальная модель

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

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

Рисунок 25 - Результат автоматического преобразования в физическую модель

 

Описание ссылочной целостности

В PowerDesigner существует несколько вариантов правил, которые могут применяться для обеспечения ссылочной целостности.

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

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

Запрет удаления - запрещается удаление тех записей из родительской таблицы, на которые существуют ссылки из дочерней таблицы.

Запрет модификации - запрещается модификация значения ключа в родительской таблице для записи, на которую существуют ссылки из дочерней таблицы.

Установка пустого значения: атрибуты внешнего ключа в дочерней таблице устанавливаются в NULL при удалении соответствующих записей из родительской таблицы.

– Конец работы –

Эта тема принадлежит разделу:

Анализ и обоснование методологии разработки, управления, применяемых инструментальных средств…………………………………………………….12

На сайте allrefs.net читайте: Анализ и обоснование методологии разработки, управления, применяемых инструментальных средств…………………………………………………….12...

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

Что будем делать с полученным материалом:

Если этот материал оказался полезным ля Вас, Вы можете сохранить его на свою страничку в социальных сетях:

Все темы данного раздела:

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

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

Формальные модели предметной области
распределение денег [1.3] оплата услуг [1.3.4] оповещение фирм о требовании услуг [1.3.5] получение денег [1.3.3] проверка платежеспособности [1.3.2] составление счетов клиентов

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

Структурный анализ.
Для разработки своей БД я использовала структурный метод анализа. Структурный системный анализ проводится на начальном этапе разработки программного обеспечения – при создании спецификаций требован

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

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

Модель «сущность-связь» (ER-модель).
Как любая модель, модель «сущность-связь» имеет несколько базовых понятий, которые образуют исходные кирпичики, из которых строятся уже более сложные объекты по заранее определённым правилам.

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

Словарь данных.
Управленческим инструментарием разработки при проектировании БД является словарь данных (СД). Внедрение БД на любом предприятии занимает довольно продолжительное время. Её расширение проис

Требования к составу выполняемых функций
ИСГК должна выполнять следующие функции: · создавать базу данных о предоставляемых услугах; · база данных должна хранить следующие данные: личные данные клиентов (имя, фамилия, от

Требования к редактированию базы данных
При редактировании базы данных ИСГК должна выполнять следующие функции: · вводить символы в информационное поле, отмеченное курсором; · осуществлять навигацию по программе с помощ

Требования к оказанию дополнительных услуг.
· Своевременное оказание услуг; · Контроль за качеством выполнения;   Способность к взаимодействию: ИСГК должна функционировать на П

Требования к надежности
Надежность ИСГК должна быть обеспечена правильностью алгоритмических решений и программирования. Время восстановления ИСГК после отказа не должна превышать 0,5 часа. ИСГК в состав

Требования к составу и параметрам технических средств.
ИСГК должна функционировать на ПЭВМ со следующими характеристиками · процессор не хуже Pentium III или AMD Duron/Athlon 500МГц; · объем ОЗУ не менее 64 Мб; · НГМД 3,5 (1,

Требования к информационной и программной совместимости.
В качестве языков программирования ИСГК должен быть использован язык программирования Си++. ИСГК должен функционировать на ПЭВМ с одной из операционных систем MS Windows NT, MS Windows 200

Требования к транспортировке и хранению
Требования к транспортировке ИСГК должна транспортироваться: - в составе ПЭВМ, записанный на НЖМД ПЭВМ; - на НГМД. Условия транспортировки ИСГК в составе ПЭВМ до

Перечень сокращений
НГМД - накопитель на гибких магнитных дисках НЖМД - накопитель на жестких магнитных дисках

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

Календарный план реализации проекта
№ Наименование работ Номера этапа Сроки Анализ предметной области, анализ требований к системе, анализ тр

Хотите получать на электронную почту самые свежие новости?
Education Insider Sample
Подпишитесь на Нашу рассылку
Наша политика приватности обеспечивает 100% безопасность и анонимность Ваших E-Mail
Реклама
Соответствующий теме материал
  • Похожее
  • Популярное
  • Облако тегов
  • Здесь
  • Временно
  • Пусто
Теги