Методы и средства разработки И. Томский политехнический университет р. В. Ковин, Е. А. Мирошниченко
 Скачать 2.85 Mb.
|
|
Проектирование БД. Логическая модель ЦЕЛЬ РАБОТЫ Изучение и получение навыков логического проектирования для реляционной модели базы данных. Введение Логическое проектирование — это следующий после концептуального этап проектирования базы данных. На этапе логического проектирования учитывается специфика конкретной модели данных (реляционной, иерархической, сетевой и т.д.), но не учитываться специфика конкретной СУБД. В данной лабораторной работе рассматривается процесс создания логической модели в среде Toad Data Modeler. В свою очередь логическая модель данных является основой для следующего этапа — физического проектирования. 7.1. ТЕОРЕТИЧЕСКАЯ ЧАСТЬ 7.1.1. Toad Data Modeler Toad Data Modeler — это инструмент проектирования баз данных, позволяющий визуально создавать, поддерживать и документировать новые или существующие системы баз данных. Основные особенности Toad Data Modeler: Поддержка нескольких баз данных — подключение несколько баз данных одновременно, включая Oracle, SAP, MySQL, SQL Server, PostgreSQL, DB2, Ingres и Microsoft Access. Инструмент моделирования данных — создание структур базы данных или автоматическое внесение изменений в существующие модели и предоставление документации на нескольких платформах. Логическое и физическое моделирование — создание сложных моделей логических и физических сущностей. Отчетность — создание подробных отчетов о существующих структурах базы данных. 49 В данной лабораторной работе будут использованы средства и инструменты логического и физического моделирования. Для создания новой логической модели нужно выполнить команду из основного меню File→New →Model. В появившемся окне New Model переключитесь на вкладку Logical Data Model и подтвердите создание модели. Интерфейс пользователя Toad Data Modeler имеет классическую компоновку: основное меню , панели инструментов , информационные панели и основную рабочую область (рис. .10.1). Рис. 7.1. Основное окно Toad Data Modeler В системе поддерживается иерархическая структура элементов проекта. В одном проекте может находиться произвольное число логических и физических моделей. Каждая модель в проекте располагается на отдельной вкладке. Эта вкладка состоит из Обозревателя модели и основной рабочей области . Обозреватель модели позволяет просматривать и модифицировать её структуру. В рабочей области в виде отдельных вкладок отображаются диаграммы. Элементы модели показываются в Обозревателе модели и на графически на диаграммах. 7.1.2. Создание и настройка сущностей Добавление сущности на диаграмму осуществляется из панели Model Object c помощью 1 2 3 4 50 инструмента Entity . Для добавления новой сущности активируйте инструмент и щелкните на диаграмме. Новая сущность создается без атрибутов. Для изменения имени сущности дважды щелкните инструментом выбора по сущности на диаграмме или используйте команду Edit в контекстом меню фигуры или узла сущности в Обозревателя (рис. 7.2). Рис. 7.2. Основные свойства сущности У сущности кроме имени (Name) есть подпись (Caption) На панели Display можно настроить как отображать сущности (рис. 7.3. Рис. 7.3. Параметры отображения сущности Изменение атрибутов сущности реализуется также в окне свойств сущности, во вкладке Attributes (рис. 7.4). Как и у самой сущности, у атрибута кроме имени (Name) есть подпись (Caption). Для каждого атрибута задается тип данных (Data Type) и обязательность (Mandatory). Изменение свойств атрибута выполняется для каждого атрибута отдельно в окне свойств атрибута (рис. 7.5). 51 Рис. 7.4. Атрибуты сущности Рис. 7.5. Свойства атрибута В окне свойств сущности во вкладке Unique Identifiers настраиваются уникальные идентификаторы. 52 7.1.3. Создание и настройка связей Добавление связей (отношений) между сущностями на диаграмму осуществляется из панели Model Object c помощью инструментов: Non-identifying Relationship Не идентифицирующая связь Identifying Relationship Идентифицирующая связь Self Relationship Связь сущности с самой собой Для добавления связи активируйте соответствующий инструмент и щелчками соедините две нужные сущности. После создания связи дважды щелкните инструментом выбора по связи на диаграмме или используйте команду Edit в контекстом меню связи. Настройка свойств связи осуществляется в окне свойств связи (рис. 7.5). а) б) Рис. 7.5. Свойства связи 7.1.4. Удаление элементов диаграммы Одна и та же сущность или связь может быть представлена на разных диаграммах. Поэтому при удалении элемента из диаграммы нужно указывать: удаляется сам элемент (сущность или связь) из модели или только её графическое отображение (рис. 7.6). 53 Рис. 7.6. Удаление элемента из диаграммы В первом случае выбранный элемент удаляется только как графический элемент из диаграммы, но в модели он остается. И его позже можно будет вновь добавить на диаграмму. Во втором случае элемент удаляется из модели и, как следствие из диаграмм(ы). 7.1.5. Проверка модели Toad Data Modeler имеет встроенные средства проверки корректности модели. Для запуска проверки выполните команду Model→Verify Model. В появившемся окне Verification можно настроить параметры проверки: объекты для проверки и параметры самой проверки. По умолчанию проверке подлежат все сущности и связи модели со всеми типа проверок (ошибки, предупреждения, подсказки), их можно менять. После подтверждения операции система запускает проверку модели. Результаты проверки показываются в панели Verification Log (рис. 7.7). Рис. 7.7. Результаты проверки После исправления всех ошибок текущий проект необходимо сохранить — он понадобиться для выполнения следующей лабораторной работы. 54 7.2. ПРАКТИЧЕСКАЯ ЧАСТЬ 7.2.1. Практическое задание В качестве практического задания необходимо создать логическую модели базы данных системы, разрабатываемой студентом. При выполнении задания использовать результаты лабораторной работы №6. 7.2.2. Список контрольных вопросов для самопроверки 1. Какая нотация ER-модели используется в Toad Data Modeler? 2. Если сущность графически представлена на двух диаграммах, то что будет если сущность удалить на одной из диаграмм? 3. Можно ли использовать Toad Data Modeler совместно с какой-либо системой управления версиями? 7.3. ТРЕБОВАНИЯ К ОТЧЕТУ Отчет должен содержать следующие разделы: 1. Титульный лист, оформленный согласно утвержденному образцу. 2. Цели и задачи выполняемой лабораторной работы. 3. Пошаговое описание выполняемых заданий лабораторной работы: 4. Ответы на контрольные вопросы. 5. Заключение. 55 8. ЛАБОРАТОРНАЯ РАБОТА №8. Проектирование БД. Физическая модель ЦЕЛЬ РАБОТЫ Изучение и получение навыков физического проектирования БД для реляционной СУБД. Введение Физическое проектирование — это следующий после логического этап проектирования базы данных. На этапе физического проектирования, в отличие от логического, учитывается специфика конкретной СУБД, для которой создается модель. В данной лабораторной работе рассматривается процесс создания физической модели в среде Toad Data Modeler. 8.1. ТЕОРЕТИЧЕСКАЯ ЧАСТЬ 8.1.1. Подходы к созданию физической модели В Toad Data Modeler предлагает два подхода к созданию физической модели: • создание физической модели с нуля; • преобразование логической модели в физическую. В первом случае техника создания физической модели эквивалента созданию логической модели. Второй подход используется при наличии логической модели. В нашем случае логическая модель была создана при выполнении предыдущей лабораторной работы. Для создания физической модели на основе логической сначала нужно открыть проект, содержащий нужную логическую модель. Напомним, что в Toad Data Modeler проект может содержать произвольное число логических и физических моделей. 8.1.2. Создание физической модели из логической Для создания физической модели из логической необходимо активировать вкладку с нужной логической моделью и выполнить команду Model→Convert Model. Это приведет к запуску мастера Model Conversion. На первом шаге нужно выбрать целевую СУБД (рис. 8.1). 56 Рис. 8.1. Мастер преобразования модели. Выбор целевой СУБД На втором шаге задаются настройки преобразования. На третьем – объекты логической модели, которые будут использованы в процессе. Можно настроить какие именно объекты использовать, а какие нет. По умолчанию система предлагает использовать все объекты. В режиме расширенных настроек можно указать какие именно объекты и какие их свойства необходимо переносить в физическую модель (рис. 8.2). 57 Рис. 8.2. Мастер преобразования модели. Выбор типов объектов Рис. 8.2. Мастер преобразования модели. Ввод имени физической модели 8.1.3. Коррекция физической модели После запуска процесса преобразования система генерирует физическую модель и открывает ее в виде отдельной вкладки (рис. 8.3). 58 Рис. 8.3. Результат преобразования логической модели в физическую При преобразовании система анализирует связи между сущностями и автоматически формирует необходимые внешние ключи. При этом в качестве имени внешнего ключа используется имя первичного ключа связанной сущности. Если у двух связанных сущностей идентифицирующие атрибуты имели одинаковые имена, то после преобразования в имя первичного ключа будет совпадать с именами внешних ключей (рис. 8.4)! Рис. 8.4. Сгенерированные внешние ключи Поэтому такую ситуацию нужно исправить вручную через свойства атрибута. Для этого необходимо зайти в свойства таблицы (в терминологии системы Entity 59 Properties), вкладка атрибутов (Attributes) и переименовать их, так чтобы названия внешних ключей были уникальными (рис. 11.5). Рис. 8.5. Скорректированные имена внешних ключей Подобную коррекцию нужно выполнить для всех таблиц, где есть подобная проблема. Обратите внимание, что система автоматически формирует ключи, индексы и другие элементы. При необходимости их можно скорректировать. 8.1.4. Проверка модели Проверка физической модели выполняется аналогично проверке логической модели (см. п.п 7.1.5). 8.1.5. Генерация скрипта создания базы данных Toad Data Modeler позволяет сгенерировать скрипт для создания базы данных в целевой СУБД. Для этого необходимо выполнить команду Model→Generate DDL Script→Run…Далее в появившемся окне (рис. 8.6) при необходимости изменить 60 настройки и нажать кнопку Generate. Результат можно показать, нажав кнопку Show Code (рис. 8.7) или открыв скрипт во внешнем редакторе. Рис. 8.6. Настройки генерации скрипта 61 Рис. 8.7. Сгенерированный скрипт 8.2. ПРАКТИЧЕСКАЯ ЧАСТЬ 8.2.1. Практическое задание В качестве практического задания необходимо преобразовать логическую модель базы данных, разработанную на лабораторной работе №7, в физическую. Целевая СУБД должна выбираться студентом исходя из проектных решений, зафиксированных в Техническом проекте (лабораторной работе №11). Также нужно проверить модель на корректность и после устранения всех ошибок сгенерировать скрипт создания БД. Выполнить сгенерированный скрипт в целевой СУБД. 8.2.2. Список контрольных вопросов для самопроверки 1. Какие способы создания физической модели БД существуют в Toad Data Modeler? 2. Как в Toad Data Modeler обнаружить ошибки в модели? 3. Как в Toad Data Modeler исправить ошибки в модели? 62 8.3. ТРЕБОВАНИЯ К ОТЧЕТУ Отчет должен содержать следующие разделы: 1. Титульный лист, оформленный согласно утвержденному образцу. 2. Цели и задачи выполняемой лабораторной работы. 3. Пошаговое описание выполняемых заданий лабораторной работы: 4. Ответы на контрольные вопросы. 5. Заключение. 63 9. ЛАБОРАТОРНАЯ РАБОТА №9. Инструменты проектирования интерфейса пользователя ЦЕЛЬ РАБОТЫ Изучение и получение навыков проектирования интерфейсов пользователя с без применения цифровых инструментов. Введение Проектирование интерфейсов пользователя является важной составной частью процесса разработки программного обеспечения. Для проектирования могут использоваться различные инструменты, начиная с обычной ручки и листа бумаги и заканчивая специальными программными системами, позволяющими быстро создавать не только эскизы интерфейсов пользователя, но и интерактивные прототипы. В данной лабораторной работе упор делается на получение навыков разработки черновых эскизов интерфейсов пользователя без применения цифровых инструментов. 9.1. ТЕОРЕТИЧЕСКАЯ ЧАСТЬ 9.1.1. Общие сведения о проектировании UI При проектировании пользовательских интерфейсов как части человеко- машинного взаимодействия используются следующие аббревиатуры: • UI — user interface / пользовательский интерфейс; • UX — user experience / опыт взаимодействия. При важно понимать, что эти термины не эквиваленты и их не следует путать: пользовательский интерфейс (UI) не является опытом взаимодействия (UX). Процесс проектирования UI состоит из следующих этапов (рис. 9.1): 1. Создание эскиза 2. Создание эскиза интерфейса пользователя 3. Создание прототипа 4. Создание макета 5. Программная реализация 64 Рис. 9.1. Процесс проектирования UI Назначение каждого этапа и используемые на этапе инструменты показаны в таблице: Этап Описание Используемые инструменты Эскиз Базовый концепт того, как будет работать (выглядеть) система в пользовательском интерфейсе. Детали и специфика не важны. Бумага и карандаш Доска и маркер Цифровые графические инструменты Схема интерфейса Детально проработан концепт. Детали и специфика важны. Цифровые графические инструменты Цифровые инструменты для UI Прототип Полностью продуманное поведение. Упрощение графики и контента, полное отсутствие бекэнда. Ключевая особенность – интерактивность. Цифровые инструменты прототипирования UI Макет Финальный дизайн графики и контента Цифровые инструменты графического дизайна Код Готовый продукт Среды разработки К проектированию UI имеют отношения разные специалисты и роли. В целом процесс проектирования UI по ролям представлен на рис. 12.2. 65 Рис. 9.2. Процесс проектирования UI по ролям 9.1.2. Целевые платформы UI При проектировании UI важно понимать для какой целевой платформы он разрабатывается (рис. 9.3). Рис. 9.3. Типовые платформы В таблице показаны ключевые показатели типовых платформ: 66 Платформа Экран Средства ввода Размер Ориентация Настольная 13” и выше Альбомная Клавиатура Мышь Веб 13” и выше Альбомная* Клавиатура Мышь Мобильная Смартфоны 4” — 6” Книжная* Сенсорный экран Планшеты 7” — 10” Альбомная* Сенсорный экран * Типовая При проектировании UI важно учитывать эти показатели, прежде всего с точки зрения эргономики. 9.2. ПРАКТИЧЕСКАЯ ЧАСТЬ 9.2.1. Практическое задание В качестве практического задания необходимо без применения цифровых инструментов создать эскизы интерфейса пользователя для системы, создаваемой студентом в рамках индивидуального задания на дисциплину. Эскизы должны создаваться для той платформы, которая соответствует индивидуальному заданию: • настольное приложение для OC Windows; • настольное приложение для OC MacOS; • настольное приложение для OC Linux; • мобильное приложение для OC Android; • мобильное приложение для OC iOS; • веб-приложение; • другие (AR/VR, Smart Watch…). Проектированию подлежат (при наличии): • главное окно; • главное меню; • система навигации; 67 • все диалоговые окна. Результаты проектирования должны быть зафиксированы ручкой на листах бумаги или маркером на доске. Все созданные эскизы должны быть сфотографированы и добавлены в отчет по лабораторной работе. 9.2.2. Список контрольных вопросов для самопроверки 1. Какие основные преимущества имеют цифровые инструменты проектирования пользовательских интерфейсов по сравнению с «бумажным» подходом? 2. Существуют ли недостатки цифровых инструментов проектирования пользовательских интерфейсов по сравнению с «бумажным» подходом? 9.2.3. ТРЕБОВАНИЯ К ОТЧЕТУ Отчет должен содержать следующие разделы: 1. Титульный лист, оформленный согласно утвержденному образцу. 2. Цели и задачи выполняемой лабораторной работы. 3. Пошаговое описание выполняемых заданий лабораторной работы: 4. Ответы на контрольные вопросы. 5. Заключение. 68 10. ЛАБОРАТОРНАЯ РАБОТА №10. Проектирование интерфейса пользователя ЦЕЛЬ РАБОТЫ Изучение и получение навыков проектирования интерфейсов пользователя с помощью специализированного цифрового инструмента. Введение Проектирование интерфейсов пользователя является важной составной частью процесса разработки программного обеспечения. Для проектирования могут использоваться различные инструменты, начиная с обычной ручки и листа бумаги и заканчивая специальными программными системами, позволяющими быстро создавать не только эскизы интерфейсов пользователя, но и интерактивные прототипы. В данной лабораторной работе упор делается на получение навыков разработки черновых эскизов интерфейсов пользователя. |