Практикум для выполнения лабораторных работ состоит из семнадцати лабораторных работ по дисциплинам Спецификация, архитектура и проектирование программных систем
 Скачать 2.9 Mb.
|
|
Связи «супертип-подтип» В связи «супертип-подтип» (рис. 3.10) общие атрибуты типа определяются в сущности-супертипе, сущность-подтип наследует все атрибуты супертипа. Экземпляр подтипа суще- ствует только при условии существования определенного экземпляра супертипа. Подтип не может иметь идентификато- ра (он импортирует его из супертипа). Рис. 3.10. Сущность «супертип — подтип» Ход работы Поставлена задача: Разработать модель данных для ав- томатизированной системы (АС) «Курсы компьютерной гра- мотности». Организация занимается обучением с использованием компьютеров, объединенных в единую сеть. Компьютеры установлены на каждом учебном месте в нескольких классах. Каждый учащийся занимается в назначенное время по инди- видуальному плану, составленному преподавателем. Индиви- дуальные планы формируются на основе тем типовых курсов. В результате анализа процесса обучения можно обозна- чить несколько объектных областей. 26 1. Материальное обеспечение процесса обучения. Выде- лены следующие сущности: − класс — учебный класс, в котором проводятся занятия; − учебное место — входит в учебный класс и существует только в его составе; − единица оборудования — составная часть учебного места; − тип оборудования — тип, к которому относится едини- ца оборудования. 2. Методическое обеспечение процесса обучения. Выде- лены следующие сущности: − типовой курс — стандартный типовой курс обучения, может содержать 0 или более тем; − тема типового курса — составляющая часть типового курса; − индивидуальный план — программа обучения, составля- ется из различных типовых курсов; − плановое занятие — занятие, проводимое по конкрет- ной теме из типового курса. 3. Учебный процесс. Выделены следующие сущности: − учебный день — календарный день, в который прово- дится обучение, содержит академические часы; − академический час — урок, занятие, принадлежит опреде- ленному учебному дню, имеет время начала и время окончания; − занятие в классе — сущность, связывающая «плановое занятие» и «академический час». 4. Персонал и учащиеся. Выделены следующие сущности: − преподаватель — составляет индивидуальный план для учеников и проводит с ними занятия; − учащийся — ученик, занимающийся с преподавателем по индивидуальному плану. ER- диаграмма логической модели данных (подмножество Main) для АС «Курсы компьютерной грамотности» на уровне сущностей представлена на рис.3.11. 27 Рис. 3.11. ER-диаграмма логической модели данных для АС «Курсы компьютерной грамотности». Уровень сущностей Для трёх объектных областей на уровне атрибутов со- зданы ER-диаграммы подмножеств: Материальное обеспечение (рис. 3.12). Рис. 3.12. ER-диаграмма подмножества «Материальное обеспечение» логической модели данных 28 Методическое обеспечение (рис. 3.13). Рис. 3.13. ER-диаграмма подмножества «Методическое обеспечение» логической модели данных Учебный процесс (рис. 3.14). Рис. 3.14. ER-диаграмма подмножества «Учебный процесс» логической модели данных 29 Создание подмножеств позволило разделить работу по созданию модели между участниками проекта. На диаграммах подмножеств определены атрибуты и их характеристики для сущностей согласно табл. 3.1. Таблица 3.1 Атрибуты сущностей подмножества «Материальное обеспечение» Сущность Атрибут Ключ Тип Класс код класса число (number) адрес cтрока (string) номер корпуса cтрока (string) номер аудитории cтрока (st ring) телефон cтрока (string) примечание cтрока (string) Учебное место код учебного места число (number) номер учебного места cтрока (string) имя рабочей станции cтрока (string) Ip-адрес cтрока (string) примечание cтрока (string) Тип оборудования код типа оборудования число (number) наименование типа cтрока (string) Единица код единицы оборудования число (number) оборудования инвентарный номер cтрока (string) техническая характеристика cтрока (string) признак исправности число (number) 30 Окончание табл. 3.1 Сущность Атрибут Ключ Тип признак исправности число (number) признак исправности число (number) дата установки дата (datetime) примечание cтрока (string) Таблица 3.2 Атрибуты сущностей подмножества «Методическое обеспечение» Сущность Атрибут Ключ Тип Типовой курс код курса число (number) название курса cтрока (string) примечание cтрока (string) Тема типового курса код темы число (number) номер темы cтрока (string) признак раздела cтрока (string) примечание cтрока (string) Индивидуальный лан код плана число (number) дата составления дата (datetime) примечание cтрока (string) Плановое занятие код планового заня- тия число (number) номер планового занятия число (number) 31 Таблица 3.3 Атрибуты сущностей подмножества «Учебный процесс» Сущность Атрибут Ключ Тип Учебный день учебный день дата (datetime) примечание cтрока (string) Академический час номер академ. часа число (number) время начала дата (datetime) время конца дата (datetime) Таблица 3.4 Атрибуты сущностей подмножества «Персонал и учащиеся» Сущность Атрибут Ключ Тип Физическое лицо код физического лица число (number) фамилия cтрока (string) имя cтрока (string) отчество cтрока (string) категория число (number) Преподаватель Адрес cтрока (string) телефон cтрока (string) дата приема дата (datetime) примечание cтрока (string) Учащийся дата начала дата (datetime) дата окончания дата (datetime) дата выдачи дата (datetime) примечание cтрока (string) 32 Рис. 3.14. ER-диаграмма логической модели данных для АС «Курсы компьютерной грамотности» 33 Рис. 3.16. ER — диаграмма физической модели «Курсы компьютерной грамотности» Индивидуальные задания В соответствии со своим вариантом разработать модель ER. Примерный перечень индивидуальных заданий 1. Информационная система ВУЗа. 2. Информационная система проектной организации. 3. Информационная система библиотеки. 4. Информационная система аптеки. 5. Информационная система городской телефонной сети. 6. Информационная система фотоцентра. 7. Информационная система железнодорожной пасса- жирской станции. 8. Информационная система альпинистского клуба. 9. Информационная система поликлиники. 10. Информационная система Городской Думы. 11. Информационная система рыболовной фирмы. 12. Информационная система фирмы, проводящей аук- ционы. 13. Информационная система учета успеваемости сту- дентов. 14. Информационная система учета аудиторного фонда университета. 15. Информационная система учета происшествий. 16. Информационная система учета и проведения конфе- ренций. 17. Информационная система обслуживания склада. 18. Информационная система музыкального магазина. 19. Информационная система деканат. 20. Информационная система «отдел кадров университета». Контрольные вопросы 1. Что является целью моделирования данных? 2. Что такое сущность? 3. Что такое экземпляр сущности? 4. Что называют связью? 5. Что такое степень связи? 6. Что такое мощность и каких типов она бывает? 7. Какие типы связей бывают? 8. Какие виды идентификаторов существуют? 35 Лабораторная работа 4. Выгрузка модели данных в СУБД и реверс инжиниринг БД Цель работы Получить навыки выгрузки модели данных в СУБД. По- знакомиться с понятием реверс инжиниринга баз данных. Теоретические сведения Общие сведения о ERwin Продукт ERwin предназначен для разработчиков, проек- тировщиков БД, системных аналитиков. С помощью ERwin разработчик может сначала, используя визуальные средства, описать схему БД, а затем автоматически сгенерировать файлы данных для выбранной реляционной СУБД. Автоматически генерируются также триггеры, обеспечивающие ссылочную целостность БД. Поддерживаются хранимые процедуры. Воз- можна также обратная разработка — восстановление модели данных по имеющимся файлам БД. Методологическую основу ERwin составляют технология IDEF1X и ER диаграммы, или диаграммы «сущность-связь». Пользователь описывает структуру данных визуально. Он задает служащие прообразами реляционных таблиц сущности с их атрибутами и при помощи мыши «натягивает» между ними связи, которые являются прототипами реляционных отношений. Продукт ERwin не привязан к технологии какой-либо конкретной фирмы, поставляющей СУБД или средства разра- ботки. Он поддерживает различные серверы баз данных и настольные СУБД, а также может обращаться к базе данных через ODBC. ERwin позволяет по уже существующим файлам БД вос- станавливать логическую структуру данных. Обратная разра- ботка позволяет, во-первых, переносить структуру БД (но не данные!) из одной СУБД в другую и, во-вторых, исследовать старые проекты. Таким образом, использование ERwin существенно уско- ряет создание БД. 36 Обратное проектирование (Reverse engineering) Обратное проектирование, то есть восстановление ин- формационной модели по существующей базе данных, исполь- зуется при выборе оптимальной платформы (rightsizing) для существующей настольной (desktop) базы данных или базы данных на mainframe, а также при расширении (или модифи- кации) существующей структуры, которая была построена без необходимой сопроводительной документации. После завершения процесса восстановления модели ERwin автоматически «раскладывает» таблицы на диаграмме. Теперь можно выполнять модификации уже с использованием логиче- ской схемы — добавлять сущности, атрибуты, комментарии, связи и т. д. По завершении изменений одна команда — синхро- низировать модель с базой данных — актуализирует все прове- денные изменения. Построение модели может быть выполнено как на основании данных каталога базы данных, так и на основа- нии пакета операторов SQL, с помощью которого была создана база данных. Синхронизация с базой данных В процессе разработки информационной системы может возникнуть ситуация, когда структура базы данных и инфор- мационная модель не соответствуют друг другу. ERwin предо- ставляет возможность привести их в соответствие. Для этого предусмотрена функция синхронизации с ба- зой данных. После подключения к СУБД предлагается список несоответствий между существующей структурой данных и моделью. Например, если в базе данных создана новая таблица, то ERwin предложит провести включение ее в модель. Если в модель добавлена новая таблица, ERwin предложит создать ее в реальной базе данных. Аналогично, при добавлении колонок в базе данных или в модели ERwin предлагает провести соот- ветствующие операции по синхронизации. Интерфейсы к СУБД ERwin поддерживает прямой интерфейс с основными СУБД: DB2, Informix, Ingres, NetWare SQL, ORACLE, Progress, Rdb, SQL/400, SQLBase, SQL Server, Sybase System 10, Watcom SQL. 37 ERwin поддерживает также настольные (desktop) СУБД: Microsoft Access, FoxPro, Clipper, dBASE III, dBASE IV и Paradox. Проектирование на физическом уровне выполняется в терминах той базы данных, которую предполагается использо- вать в системе. Важно, что ERwin «известны» соответствия между возможностями СУБД различных производителей, вследствие чего возможна конвертация физической схемы, спроектированной для одной СУБД, в другую. Например, если при описании ссылочной целостности указана опция «on delete cascade», а СУБД не поддерживает такой режим, ERwin сгене- рирует соответствующий триггер. Для создания физической структуры БД может быть запрошена генерация DDL-скрипта (data definition language). При этом используется диалект SQL для выбранного типа и версии сервера. Хотя сгенерированный код не нуждается в модификации, имеется возможность его сохранить в файл или распечатать. Ход работы Для начала разработки необходимо создать базу данных для хранения информации. Результаты создания логической и физической моделей в среде ERwin представлены на рис. 4.1 и рис. 4.2. Рис. 4.1. Логическая модель базы данных 38 Рис. 4.2. Физическая модель базы данных 39 Далее необходимо создать пустую базу данных в MS SQL Management Studio. Для генерации базы данных необходимо выбрать тип СУБД в ERwin. Это можно сделать с помощью опции Database -> Choose Database. Генерация базы данных происходит с помощью опции Tools->ForwardEngineer/SchemaGeneration (рис. 4.3). Рис. 4.3. Генерация базы данных Далее генерируется скрипт создания БД, который необ- ходимо запустить в СУБД для создания базы данных. Индивидуальные задания Постройте модель базы данных в ERwin согласно вариан- ту предыдущей лабораторной работы. Выполните перенос разработанной базы данных в в MS SQL Management Studio. Контрольные вопросы 1. Для каких операций с базами данных предназначен ERwin? 2. Какие действия с базами данных позволяет выполнить обратная разработка? 3. Можно ли при помощи ERwin переносить между СУБД структуру баз данных? 4. Можно ли при помощи ERwin переносить между СУБД данные из таблиц? 5. В чем заключается обратное проектирование баз данных? 6. Какие действия необходимо выполнить для генерации базы данных из ERwin в СУБД? 41 Лабораторная работа 5. Построение функциональной модели Цель работы Получить навыки построения функциональной модели. Теоретические сведения Общие сведения Метод SADT разработан Дугласом Россом (SoftTech, Inc.) в 1969 г. для моделирования искусственных систем средней сложности. Данный метод успешно использовался в военных, про- мышленных и коммерческих организациях США для решения широкого круга задач, таких, как долгосрочное и стратегическое планирование, автоматизированное производство и проектиро- вание, разработка ПО для оборонных систем, управление финан- сами и материально-техническим снабжением и др. Метод SADT поддерживается Министерством обороны США, которое было инициатором разработки семейства стан- дартов IDEF (Icam DEFinition), являющегося основной частью программы ICAM (интегрированная компьютеризация произ- водства), проводимой по инициативе ВВС США. Метод SADT реализован в одном из стандартов этого се- мейства — IDEF0, который был утвержден в качестве федераль- ного стандарта США в 1993 г., его подробные спецификации можно найти на сайте http://www.idef.com. Метод SADT представляет собой совокупность правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функцио- нальная модель SADT отображает функциональную структуру объекта, т. е. производимые им действия и связи между этими действиями. Основные элементы этого метода основываются на сле- дующих концепциях: – графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаи- модействие блоков друг с другом описывается посредством 42 интерфейсных дуг, выражающих «ограничения», которые, в свою очередь, определяют, когда и каким образом функции выполняются и управляются; – строгость и точность. Выполнение правил SADT требует достаточной строгости и точности, не накладывая в то же время чрезмерных ограничений на действия аналитика. Пра- вила SADT включают: ограничение количества блоков на каж- дом уровне декомпозиции (правило 3–6 блоков — ограничение мощности краткосрочной памяти человека), связность диа- грамм (номера блоков), уникальность меток и наименований (отсутствие повторяющихся имен), синтаксические правила для графики (блоков и дуг), разделение входов и управлений (правило определения роли данных); – отделение организации от функции, т. е. исключение влияния административной структуры организации на функ- циональную модель. Метод SADT может использоваться для моделирования самых разнообразных процессов и систем. В существующих системах метод SADT может быть использован для анализа функций, выполняемых системой, и указания механизмов, посредством которых они осуществляются. Состав функциональной модели Результатом применения метода SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы — главные компо- ненты модели, все функции организации и интерфейсы на них представлены как блоки и дуги соответственно. Место соеди- нения дуги с блоком определяет тип интерфейса. Управляю- щая информация входит в блок сверху, в то время как входная информация, которая подвергается обработке, показана с левой стороны блока, а результаты (выход) показаны с правой стороны. Механизм (человек или автоматизированная систе- ма), который осуществляет операцию, представляется дугой, входящей в блок снизу (рис. 5.1). На рис. 5.2, где приведены четыре диаграммы и их взаи- мосвязи, показана структура SADT-модели. Каждый компонент модели может быть декомпозирован на другой диаграмме. Каждая диаграмма иллюстрирует «внутреннее строение» блока на родительской диаграмме. 43 Рис. 5.1. Функциональный блок и интерфейсные дуги Построение SADT-модели Построение SADT-модели заключается в выполнении следующих действий: – сбор информации об объекте, определение его границ; – определение цели и точки зрения модели; – построение, обобщение и декомпозиция диаграмм; – критическая оценка, рецензирование и комментирование. Построение диаграмм начинается с представления всей системы в виде простейшего компонента — одного блока и дуг, изображающих интерфейсы с функциями вне системы ( рис. 5.2). Поскольку единственный блок отражает систему как единое целое, имя, указанное в блоке, является общим. Это верно и для интерфейсных дуг — они также соответствуют полному набору внешних интерфейсов системы в целом. Затем блок, который представляет систему в качестве единого модуля, детализируется на другой диаграмме с по- мощью нескольких блоков, соединенных интерфейсными дугами. Эти блоки определяют основные подфункции исход- ной функции. Данная декомпозиция выявляет полный набор подфункций, каждая из которых показана как блок, границы которого определены интерфейсными дугами. Каждая из этих подфункций может быть декомпозирована подобным обра- зом в целях большей детализации. 44 Рис. 5.2. Структура SADT. Декомпозиция диаграмм Во всех случаях каждая подфункция может содержать только те элементы, которые входят в исходную функцию. Кроме того, модель не может опустить какие-либо элементы, т. е., как уже отмечалось, родительский блок и его интерфейсы обеспечивают контекст. К нему нельзя ничего добавить и из него не может быть ничего удалено. Модель SADT представляет собой серию диаграмм с сопро- водительной документацией, разбивающих сложный объект на составные части, которые изображены в виде блоков. Детали каждого из основных блоков показаны в виде блоков на других диаграммах. Каждая детальная диаграмма является декомпози- цией блока из диаграммы предыдущего уровня. На каждом шаге 45 декомпозиции диаграмма предыдущего уровня называется ро- дительской для более детальной диаграммы. Синтаксис диаграмм определяется следующими прави- лами: – диаграммы содержат блоки и дуги; – блоки представляют функции; – блоки имеют доминирование (выражающееся в их сту- пенчатом расположении, причем доминирующий блок распо- лагается в верхнем левом углу диаграммы); – дуги изображают наборы объектов, передаваемых меж- ду блоками; – дуги изображают взаимосвязи между блоками: – выход-управление; – выход-вход; – обратная связь по управлению; – обратная связь по входу; – выход-механизм. Дуги, входящие в блок и выходящие из него на диаграм- ме верхнего уровня, являются точно теми же самыми, что и дуги, входящие в диаграмму нижнего уровня и выходящие из нее, потому что блок и диаграмма изображают одну и ту же часть системы. На последующих рис. 5.3–5.4 приведены различные вари- анты выполнения функций и соединения дуг с блоками. Рис. 5.3. Одновременное выполнение функций 46 Рис. 5.4. Соответствие интерфейсных дуг родительской (а) и детальной (б) диаграмм Некоторые дуги присоединены к блокам диаграммы обо- ими концами, у других же один конец остается не присоеди- ненным. Не присоединенные дуги соответствуют входам, управлениям и выходам родительского блока. Источник или получатель этих пограничных дуг может быть обнаружен только на родительской диаграмме. Не присоединенные кон- цы должны соответствовать дугам на исходной диаграмме. Все граничные дуги должны продолжаться на родительской диа- грамме, чтобы она была полной и непротиворечивой. На SADT-диаграммах не указаны явно ни последователь- ность, ни время. Обратные связи, итерации, продолжающиеся процессы и перекрывающиеся (по времени) функции могут быть изображены с помощью дуг. Обратные связи могут вы- ступать в виде комментариев, замечаний, исправлений и т. д. ( рис. 5.5). 47 Рис. 5.5. Пример обратной связи Как было отмечено, механизмы (дуги с нижней стороны) показывают средства, с помощью которых осуществляется выполнение функций. Механизм может быть человеком, ком- пьютером или любым другим устройством, которое помогает выполнять данную функцию (рис. 5.6). Рис. 5.6. Пример механизма Каждый блок на диаграмме имеет свой номер. Блок лю- бой диаграммы может быть далее описан диаграммой нижнего уровня, которая, в свою очередь, может быть далее детализи- рована с помощью необходимого числа диаграмм. Таким обра- зом, формируется иерархия диаграмм. 48 Для того чтобы указать положение любой диаграммы или блока в иерархии, используются номера диаграмм. Например, А21 является диаграммой, которая детализирует блок А21 на диаграмме А2. Аналогично, диаграмма А2 детализирует блок А2 на диаграмме АО, которая является самой верхней диаграм- мой модели. На рис. 5.7 показан пример дерева диаграмм. Рис. 5.7. Иерархия диаграмм При построении иерархии диаграмм используются сле- дующие стратегии декомпозиции: 1) функциональная декомпозиция — декомпозиция в со- ответствии с функциями, которые выполняют люди или орга- низация. Может оказаться полезной стратегией для создания системы описаний, фиксирующей взаимодействие между людьми в процессе их работы. Очень часто, однако, взаимосвя- зи между функциями весьма многочисленны и сложны, поэто- му рекомендуется использовать эту стратегию только в начале работы над моделью системы; 2) декомпозиция в соответствии с известными стабиль- ными подсистемами — приводит к созданию набора моделей, по одной модели на каждую подсистему или важный компо- нент. Затем для описания всей системы должна быть построе- на составная модель, объединяющая все отдельные модели. Рекомендуется использовать разложение на подсистемы, 49 только когда разделение на основные части системы не меня- ется. Нестабильность границ подсистем быстро обесценит как отдельные модели, так и их объединение; 3) декомпозиция по физическому процессу — выделение функциональных стадий, этапов завершения или шагов выпол- нения. Хотя эта стратегия полезна при описании существующих процессов (таких, например, как работа промышленного пред- приятия), результатом ее часто может стать слишком последова- тельное описание системы, которое не будет в полной мере учитывать ограничения, диктуемые функциями друг другу. При этом может оказаться скрытой последовательность управления. Эта стратегия рекомендуется, только если целью модели являет- ся описание физического процесса как такового или только в крайнем случае, когда неясно, как действовать. |