Проектирование ИС «Органайзер». Разработка вебприложения Онлайншкола английского языка
 Скачать 1.7 Mb.
|
|
Министерство науки и высшего образования Российской Федерации Федеральное государственное бюджетное образовательное учреждение высшего образования «Волгоградский государственный технический университет» Факультет электроники и вычислительной техники Кафедра «Системы автоматизированного проектирования и поискового конструирования» Курсовая работа по дисциплине: «Технологии разработки человеко-машинных интерфейсов» на тему: «Разработка веб-приложения Онлайн-школа английского языка» Выполнил: студентка группы АУЗ-362с Васильева Екатерина Номер зачетной книжки: 19113035 Проверил: Кизим Алексей Владимирович Волгоград 2022 г. Содержание Введение 3 Постановка задачи 5 Текстовое описание предметной области 6 Формализация задачи 7 Логическая модель 7 Диаграмма дерева узлов 8 Контекстная диаграмма 9 Физическая модель 10 Функциональная модель 10 Диаграмма «сущность-связь» 15 Спецификации процессов 17 Словарь проекта 18 Словарь данных 21 Диаграмма вариантов использования 27 Диаграмма Насси–Шнейдермана 35 Введение Информационная система. В широком смысле информационная система (ИС) — это совокупность аппаратного, программного и организационного обеспечения, а также персонала, предназначенная для обеспечения определенных людей нужной им информацией. ИС в узком смысле рассматривают как программно-аппаратную систему, предназначенную для автоматизации деятельности конечных пользователей, обеспечивающую, в соответствии с заложенной в неё логикой обработки, возможность получения, модификации и хранения информации. Основной задачей ИС является удовлетворение конкретных информационных потребностей в рамках конкретной предметной области. Современные ИС немыслимы без использования баз данных и СУБД, поэтому термин «информационная система» на практике сливается по смыслу с термином «система баз данных». [1] Органайзер. Данная курсовая работа посвящена проектированию информационной системы «Органайзер» с помощью различных CASE-средств. Средства автоматизации разработки программ (CASE-средства) — инструменты автоматизации процессов проектирования, разработки и поддержки жизненного цикла программного обеспечения и информационных систем для системного аналитика, разработчика и программиста. Органайзер — это программа, предназначенная для накапливания пользовательской информации (личные контакты, события), оперативного поиска по ней, организации дел, контроля над их выполнением, отслеживания определенных пользователем событий. Целевое назначение органайзера — помогать организовывать работу или времяпрепровождение своего владельца. Несмотря на бурное развитие электронной техники и ее очевидные преимущества, люди по-прежнему сильно привязаны к неэлектронным носителям информации. Актуальность и современность традиционных органайзеров подтверждают ведущиеся полиграфическими предприятиями разработки в этом направлении. Существуют модели органайзеров, совмещенных с записными книжками; блокнотов, разделенных на несколько частей и т. п. Однако традиционные органайзеры не способны в полной мере отвечать запросам современного делового человека — в значительной степени из-за своей примитивной структуры. Часто можно наблюдать, как нецелесообразно они используются. Информация записывается сплошной массой, без внесения в нее какого-либо порядка и/или структуры. Неразборчивый, иногда для самого хозяина, почерк и вырванные страницы довершают картину легкомысленного отношения к информации. Такое отношение уменьшает коэффициент полезного действия от работы с информацией. Часто в качестве органайзера используется ежедневник. Они полезны и удобны, но подходят только для чистого планирования своей деятельности на основе уже имеющихся планов, поставленных задач, фактов, направлений деятельности. По большому счету, ежедневники не подходят для использования их в качестве органайзера: в них тяжело отражать все процессы, связанные с полным объемом работы. Органайзер целесообразно использовать как отдельный инструмент, но в совокупности с ежедневником, записной книжкой и другими средствами. В работе многих специалистов наблюдается разрозненность информации. Наличие огромного количества исписанных бумажек — стикеров, расположенных на столах, стенах, дверях; информация на перекидных настольных календарях; информация в виде напоминаний на мобильном телефоне. Такая ситуация угрожает возможностью потери важных данных, и последствия этого тем хуже, чем выше ответственность и полномочия ее владельца. Потеря информации и невыполнение какой-либо функции одним человеком может негативно повлиять на многих людей. Целесообразно организовать работу так, чтобы вся информация была собрана и систематизирована в одном месте и всегда находилась под рукой. Это главная предпосылка для создания персонального органайзера, адаптированного к условиям работы своего владельца и призванного быть помощником в работе. В данной работе будет рассмотрен органайзер, содержащий ежедневник, адресную книгу и заметки, и позволяющий организовывать информацию о личных контактах и событиях. [2] Постановка задачи Целью данной работы является обеспечение комфортной работы с личными данными пользователя. Исходные данные — это события, заметки, личные контакты пользователя и различная информация о них. Априорные представления о модели. Информационная система будет обеспечивать возможность манипуляции личной информацией пользователя — такой, как контакты, события и заметки. Проектируемая система также должна включать в себя следующие возможности: создание новой учетной записи и вход в систему; хранение и изменение записей в базе, а также поиск по хранимым данным; добавление и удаление таблиц из базы данных и полей из таблиц; сортировка данных по имени, фамилии и дате рождения; смена режима отображения данных на табличный вид и вид по умолчанию. Режим отображения по умолчанию — в виде дерева (структуры). Результат — проект программного обеспечения, позволяющего пользователю хранить, редактировать и обрабатывать данные о личных контактах, событиях, заметках, осуществлять поиск по данным в базе. Критерии оценки результата. Цель будет достигнута, если процессы обработки, хранения и поиска личных данных пользователя упростятся и ускорятся. Текстовое описание предметной области При первом запуске программы «Органайзер» появляется форма выбора режима работы программы с двумя кнопками: «Регистрация нового пользователя» и «Работать с программой без учетной записи». Пользователь должен выбрать один из двух вариантов. Если пользователь переходит к регистрации новой учетной записи, форма выбора режима работы приложения замещается формой регистрации. Чтобы зарегистрироваться, пользователь должен ввести логин, e-mail, пароль и подтвердить пароль. После создания учетной записи, форма регистрации замещается формой входа в систему. Пользователь должен ввести логин и пароль, чтобы пройти авторизацию. Если пользователь не регистрируется, начальная форма выбора замещается формой работы с базой данных. В этом случае программа информирует его, что данные, с которыми он будет работать в программе, имеет возможность просмотреть и изменить любой пользователь, имеющий доступ к программе. При первом запуске без учетной записи или входе только что зарегистрированного пользователя база данных создается автоматически (детализацию БД см. в разделе «Диаграмма «сущность-связь», стр. 14). На форму работы с контактами, событиями и заметками загружаются данные из базы. Программа автоматически синхронизирует форму с базой данных — изменения, вносимые пользователем, записываются в файл базы. Пользователь имеет возможность поменять способ отображения данных на форме, выбрав представление в виде дерева (структуры) или в табличном виде. По умолчанию данные отображаются в виде дерева. Пользователь имеет возможность выбрать способ сортировки контактов: по имени, фамилии или дате рождения. Также, пользователь имеет возможность поиска по контактам, контактным данным или «везде» (по всем полям на форме). Формализация задачи Логическая модель Модель требований состоит из функциональной и информационной моделей. Система описана общей (IDEF0) и детализированными диаграммами потоков данных (DFD) для каждого процесса. IDEF0 (Integrated DEFinition) — методология функционального моделирования, предназначенная для формализации и описания бизнес-процессов. В IDEF0 рассматриваются логические отношения между процессами, а не их временная последовательность. DFD (Data Flows Diagrams) — методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ. IDEF3 (Integrated Definition for Process Description Capture Method) — методология, показывающая причинно-следственные связи между процессами и событиями. Представление процесса во всех перечисленных методологиях схожее: процесс представляется в виде «черного ящика» с входами, выходами, управлением, механизмом и вызовом. Вход — данные, требуемые процессу для получения выхода. Выход — данные, произведенные системой. Механизм — ресурсы, с помощью которых выполняется функция. Управление — правила и стандарты, определяющие условия, необходимые процессу для произведения правильного выхода. Вызов — указание на другую модель. [1][4] Диаграмма дерева узлов Диаграмма дерева узлов — это диаграмма, которая показывает иерархию диаграмм модели IDEF0, изображается в виде древовидной структуры и позволяет рассмотреть модель целиком, но не показывает взаимосвязи между узлами. Корень диаграммы соответствует контекстной диаграмме, а узлы, находящиеся на уровнях ниже — декомпозицию верхних уровней (разбиение на подпроцессы). [3] Диаграмма дерева узлов системы «Органайзер» (рис. 0) состоит из трёх уровней: контекстная диаграмма, обобщённое описание процессов работы с данными и их детализированное описание.  Рисунок 2. Диаграмма дерева узлов Контекстная диаграмма Контекстная диаграмма — вершина в иерархии диаграмм нотации IDEF0, описывающая систему и её взаимодействие с внешней средой на самом общем уровне. Диаграмма состоит из единственного блока, описывающего функцию верхнего уровня, ее входы, выходы, управления и механизмы. Этот единственный блок определяет границы моделируемой системы и показывает её основное назначение. Контекстная диаграмма должна содержать краткие утверждения, определяющие точку зрения лица, с позиции которого создается модель, и цель, для достижения которой ее разрабатывают. Эти утверждения помогают руководить разработкой модели и ограничить этот процесс определенными рамками. Точка зрения определяет, что и в каком разрезе можно увидеть в пределах модели. Изменение точки зрения приводит к рассмотрению других аспектов системы. Важные с одной точки зрения, они могут не появиться в модели, разрабатываемой с другой точки зрения на ту же систему. Стрелки на контекстной диаграмме отображают связи объекта моделирования с окружающей средой. Поскольку только один блок представляет весь проект, его имя — общее для всего проекта. [1][3] Проектируемая система в большинстве случаев рассматривается с точки зрения пользователя записной книжки для контактов. На приведённой далее контекстной диаграмме системы к единственному блоку «Органайзер» на вход поступают данные от пользователя (рис. 0). На выходе — данные для пользователя, проверенные, преобразованные для более удобного просмотра, и исправленные, если это необходимо.  Рисунок 4. Контекстная диаграмма IDEF0 Физическая модель Физическая модель — расширение логической модели, содержащее в себе спецификации процессов, которые представляют собой алгоритмы описания задач, выполняемых процессами. [1] С помощью логической модели информационной системы была построена физическая модель, описывающая функционал системы. Функциональная модель Процесс работы с базой данных состоит из четырех процессов (рис. 0): ввод данных о заметках, контактах, событиях и пр., проверка их на корректность, преобразование данных (для более удобного просмотра) и вывод данных на форму.  Рисунок 6. Детализация процесса работы с базой данных (DFD 1 уровня) Детализация процесса проверки данных (рис. 0) включает в себя два этапа: система проверяет, ввел ли пользователь значения корректной длины; затем, если длина значений находится в пределах допустимой, проверяется наличие лишних символов в этих значениях. Длина каждого значения в элементе управления не должна превышать максимальную длину соответствующего поля, определенную в диаграмме «сущность–связь». Лимиты длин и допустимые символы для каждого значения регламентируются индивидуально.  Рисунок 8. Детализация процесса проверки данных (DFD 2 уровня) Преобразование уже проверенных данных (рис. 0) производится в два этапа. На первом этапе определяется, нужно ли преобразовывать данные. Второй этап разделен на два подэтапа: первый — добавление символов в значения для более удобного просмотра и чтения, если это необходимо; второй — к значениям добавляются подписи, описывающие какие именно данные показаны. На выходе процесса — преобразованные данные.  Рисунок 10. Детализация процесса преобразования данных (IDEF3 2 уровня) Детализация процесса вывода данных (рис. 0) состоит из четырех этапов: формирование запроса; отправка запроса СУБД, его выполнение и получение данных из базы; запись полученных данных из базы в переменные; передача данных из переменных в элементы управления на форме.  Рисунок 12. Детализация процесса вывода данных на форму (DFD 2 уровня) Диаграмма «сущность-связь» Диаграмма «сущность–связь» (Entity Relationship Diagram, ERD) используется для проектирования баз данных. С ее помощью можно выделить ключевые сущности и показать связи, которые могут устанавливаться между ними. Логическая модель БД — детальное представление данных проекта (организации), независимое от технологий управления данными. Модель обычно изображается как диаграмма с сущностями и связями между ними. Физическая модель БД — представление проектных данных, которое описывает объекты (например, таблицы) и накладываемые с помощью СУБД ограничения. [1] Ниже приведена диаграмма «сущность–связь» (рис. 0), представляющая собой логическую модель базы данных, используемой в информационной системе.  Рисунок 14. Детализация базы данных (диаграмма «сущность–связь») Данные в базе делятся на служебную информацию (на диаграмме изображено красным цветом) — таблица «Пользователи» и таблицы «Фонд», и пользовательскую информацию (на диаграмме представлено зелёным цветом). Таблица «Пользователи» содержит регистрационные данные пользователей системы. Таблицы «Фонд» (телефонов, событий и пр.) служат для обеспечения связи «многие-ко-многим». Схема базы данных содержит 12 таких таблиц. Связь «многие-ко-многим» обеспечивает указание, например, нескольких телефонов или электронных адресов. Пользовательская информация — та, которую редактирует пользователь. Она, в свою очередь, делится на три части: 1) сведения о заметках, событиях и группах контактов; 2) сведения о контактах; 3) сведения о контактных данных. Первая часть состоит из трех таблиц соответственно — «Заметки», «События» и «Группы контактов». Вторая часть содержит одну таблицу «Контакты». Третья часть содержит восемь таблиц — «Электронные адреса», «Телефоны», «Организации», «Адреса» (физические), «Факсы», «Мессенджеры», «Социальные сети» и «Сайты». Кроме перечисленных восьми таблиц, в отдельную категорию можно определить ещё две: «Сервисы веб-почты» и «Операторы связи». При создании файла базы в эти таблицы заносятся исходные данные, которые используются приложением. Например, при вводе номера телефона рядом с ним показывается оператор связи, используемый абонентом (если системе удалось установить соответствие между номером телефона и оператором связи). Также, пользователь имеет возможность добавлять данные в эти две таблицы. Например, если системе не удалость определить абонентского оператора связи, пользователю предоставляется возможность указать оператора самому. Таким образом, если оператор связи добавлен в таблицу, впоследствии система самостоятельно сможет определить его у номера телефона, имеющего аналогичный код региона. Спецификации процессов Спецификации процессов используются для описания функционирования процесса, когда нет необходимости детализировать их с помощью диаграммы потоков данных. [1] Множество всех спецификаций представляет собой полную спецификацию системы. Примеры спецификаций нескольких процессов: Спецификация процесса 4.1 ФОРМИРОВАНИЕ ЗАПРОСА: @ВХОД = ПРЕОБРАЗОВАННЫЕ ДАННЫЕ @ВЫХОД = ПРОВЕРЕННЫЕ ДАННЫЕ @СПЕЦПРОЦ 4.1 ФОРМИРОВАНИЕ ЗАПРОСА При завершении ПРЕОБРАЗОВАНИЯ ДАННЫХ создать строковую переменную для запроса к СУБД. Добавить в переменную ШАБЛОН ЗАПРОСА и ДАННЫЕ, которые нужно получить из базы. @КОНЕЦ СПЕЦИФИКАЦИИ ПРОЦЕССА 4.1 ФОРМИРОВАНИЕ ЗАПРОСА Спецификация процесса 4.2 ОТПРАВКА ЗАПРОСА: @ВХОД = ПРЕОБРАЗОВАННЫЕ ДАННЫЕ @ВЫХОД = ПРОВЕРЕННЫЕ ДАННЫЕ @СПЕЦПРОЦ 4.2 ОТПРАВКА ЗАПРОСА При завершении ФОРМИРОВАНИЯ ЗАПРОСА создать переменную оператора SQL. Указать ЗАПРОС, который нужно отправить СУБД, и ИНФОРМАЦИЮ О СОЕДИНЕНИИ, через которое нужно отправить этот запрос. Выполнить ОПЕРАТОР SQL. @КОНЕЦ СПЕЦИФИКАЦИИ ПРОЦЕССА 4.2 ОТПРАВКА ЗАПРОСА Словарь проекта Словарь проекта описывает весь проект, перечисляя всё, что в нем содержится. Процессы обозначаются , внешние сущности — Ниже приведены объекты и потоки, которые содержит информационная система. Словарь данных Словарь данных — средство, которое позволяет при проектировании, эксплуатации и развитии БД поддерживать и контролировать информацию о данных. Словарь данных содержит информацию об источниках, форматах и взаимосвязях между данными, их описания, сведения о характере использования и распределении ответственности. Он уже сам по себе является базой «данных о данных», руководством по базе данных. [1] В таблице ниже приведен словарь данных информационной системы.
Таблица 1. Словарь данных системы Диаграмма вариантов использования Диаграмма вариантов использования (use case, прецедент, сценарий использования) служит для документирования функциональных требований к программным системам. Use case описывает некоторый целостный фрагмент поведения системы, не вдаваясь при этом в особенности внутренней структуры субъекта. Определение прецедента содержит все свойственные ему виды поведения: основную последовательность, различные варианты стандартного поведения и различные исключительные ситуации с указанием ответной реакции на них. [1] Ниже представлен use case (рис. 0) информационной системы «Органайзер», иллюстрирующий возможности пользователя системы.  Рисунок 16. Диаграмма вариантов использования системы Функции: Зарегистрировать нового пользователя. Войти в систему. Выйти из системы. Генерировать новый пароль к базе данных. Изменить режим отображения данных. Добавить таблицу. Удалить таблицу. Добавить запись в таблицу. Изменить запись в таблице. Удалить запись из таблицы. Добавить поле в таблицу. Изменить название поля таблицы. Зарегистрировать нового пользователя. Применяется, когда пользователь запрашивает регистрацию. Предусловие: необходимость регистрации нового пользователя. Постусловие: в системе зарегистрирован новый пользователь с возможностью входа в систему и выхода из нее, а также возможностью изменения данных в базе. Пользователь щелкает по кнопке «Зарегистрировать нового пользователя». Главная форма замещается формой регистрации с полями для ввода данных пользователя. Пользователь вводит данные в поля «Логин», «Пароль», «Электронная почта». Нажимает кнопку «Завершить регистрацию» или нажимает клавишу «Enter». Система проверяет данные на корректность. Если данные некорректны, система указывает пользователю, в каких местах он ошибся. Если данные корректны, система шифрует их. Формируется запрос на добавление строки в таблицу «Пользователи». Запрос отправляется СУБД и выполняется — зашифрованные данные учетной записи добавляются в базу. Форма регистрации замещается формой входа в систему. В строке состояния высвечивается сообщение о результате операции (в случае успеха — «Регистрация успешно завершена.», в случае неудачи — «Не удалось завершить регистрацию.» и причины неудачи). Войти в систему. Применяется при запуске программы (при условии, что в базе данных есть хотя бы один пользователь). Предусловие: необходимость войти в систему. Постусловие: пользователь вошел в систему и может работать с базой данных. На форме входа в систему пользователь вводит данные в поля «Логин» и «Пароль». Щелкает по кнопке «Войти в систему» или нажимает клавишу «Enter». Система проверяет данные на корректность. Если данные некорректны, система указывает пользователю, в каких местах он ошибся. Если данные корректны, система выполняет аутентификацию — сверяет введенные данные с данными имеющихся учетных записей. Если не найдено совпадений введенных данных ни с одной учетной записью, справа от элементов управления для ввода логина и пароля высвечивается сообщение «Не существует пользователя с такими данными.». Если данные совпали с одной из имеющихся учетных записей, выполняется вход пользователя в систему — форма входа скрывается и заменяется формой для отображения данных из базы. Устанавливается соединение с базой данных. На форму загружаются данные из базы. В строке состояния высвечивается сообщение о результате операции (в случае успеха — «Вход в систему выполнен. Данные из базы загружены.», в случае неудачи — «Не удалось выполнить вход в систему.» («Не удалось загрузить данные из базы данных.») и причины неудачи). Выйти из системы. Применяется, когда пользователь запрашивает выход из системы. Предусловие: необходимость выйти из системы. Постусловие: пользователь вышел из системы и никто не сможет работать с базой данных, пока пользователь снова не войдет в систему. Пользователь нажимает кнопку «Выход из системы». Показывается диалоговое окно с текстом «Вы уверены, что хотите выйти из системы?», флажком «Не показывать это сообщение в следующий раз» и вариантами выбора «Да» и «Нет». Если пользователь нажимает «Нет», действие отменяется (выход из системы не происходит). Система разъединяет приложение и базу данных. Форма с данными из базы замещается формой входа в систему. В строке состояния высвечивается сообщение о результате операции (в случае успеха — «Выход из системы выполнен.», в случае неудачи — «Не удалось выполнить выход из системы») и причины неудачи. Изменить пароль к базе данных. Применяется при взломе базы или пользовательском запросе смены пароля базы. Предусловие: необходимость генерации нового пароля к базе данных. Постусловие: пароль базы данных изменен. Пользователь щелкает по кнопке «Изменить пароль к базе». Генерируется новый пароль. Формируется запрос изменения пароля (включает старый и новый пароли). Запрос отправляется СУБД и выполняется ею. В строке состояния высвечивается сообщение о результате операции (в случае успеха — «Пароль успешно изменен.», в случае неудачи — «Не удалось изменить пароль.» и причины неудачи). Изменить режим отображения данных. Применяется, когда пользователь запрашивает смену режима отображения. Предусловие: необходимость изменения режима отображения данных. Постусловие: режим отображения данных изменен на соответствующий запросу пользователя (табличный или структурный). Пользователь выбирает способ отображения данных. Элемент управления с данными из базы, который отображается в текущий момент, становится невидимым. Видимым делается элемент управления, соответствующий режиму отображения, выбранному пользователем. В видимый элемент управления загружаются данные из базы. В строке состояния высвечивается сообщение о результате операции (в случае успеха — «Режим отображения данных успешно изменен.», в случае неудачи — «Не удалось изменить режим отображения данных.» и причины неудачи). Добавить таблицу. Применяется, когда пользователь запрашивает добавление таблицы. Предусловие: необходимость добавления таблицы. Постусловие: в базу данных добавлена новая таблица с названием, указанным пользователем. Пользователь нажимает на кнопку «Добавить таблицу». Пользователь вводит название таблицы. Система проверяет корректность введенного названия. Если название некорректно, в строке состояния показывается сообщение «Некорректное название таблицы.» с пояснением причины ошибки. Если название корректно, формируется запрос добавления таблицы. Запрос отправляется СУБД и выполняется. На форму добавляются элементы управления для заполнения строки таблицы. В строке состояния высвечивается сообщение о результате операции (в случае успеха — «Таблица успешно добавлена.», в случае неудачи — «Не удалось добавить таблицу.» и причины неудачи). Удалить таблицу. Применяется, когда пользователь запрашивает удаление таблицы. Предусловие: необходимость удаления таблицы. Постусловие: из базы данных удалена таблица, указанная пользователем, если она не является таблицей по умолчанию. Пользователь выбирает таблицу, которую нужно удалить. Нажимает на кнопку «Удалить таблицу». Система выполняет проверку, добавлена ли таблица пользователем (является ли она умолчальной). Если таблица не добавлена пользователем, в строке состояния высвечивается сообщение «Невозможно удалить эту таблицу, так как она является умолчальной.». Если таблица не умолчальная, система выполняет проверку, есть ли в таблице записи. Если таблица пуста, формируется запрос удаления таблицы. Если таблица не пуста, показывается диалоговое окно с текстом «Вы уверены, что хотите удалить непустую таблицу?», флажком «Не показывать это сообщение в следующий раз» и вариантами выбора «Да» и «Нет». Если пользователь нажимает «Нет», удаление отменяется. Если пользователь нажимает «Да», формируется запрос удаления таблицы. Запрос отправляется СУБД и выполняется. В строке состояния высвечивается сообщение о результате операции (в случае успеха — «Таблица успешно удалена.», в случае неудачи — «Не удалось удалить таблицу.» и причины неудачи). Добавить запись в таблицу. Применяется, когда пользователь запрашивает добавление строки в таблицу. Предусловие: необходимость добавления строки в таблицу. Постусловие: в таблицу добавлена строка, содержащая данные, введенные пользователем. Пользователь выбирает таблицу, в которую нужно добавить новую строку. Нажимает на кнопку «Добавить строку». Появляются элементы управления для ввода данных. Пользователь вводит данные в элементы управления. При вводе данных система проверяет их на корректность. Если данные некорректны, справа от элемента управления, содержащего некорректные данные, высвечивается сообщение с пояснением причины ошибки. Если данные корректны, формируется запрос добавления строки. Запрос отправляется СУБД и выполняется. В строке состояния высвечивается сообщение о результате операции (в случае успеха — «Запись успешно добавлена.», в случае неудачи — «Не удалось добавить запись.» и причины неудачи). Изменить запись в таблице. Применяется, когда пользователь изменяет данные в элементах управления, соответствующим ячейкам таблицы. Предусловие: необходимость изменения строки в таблице. Постусловие: в таблице изменена строка, введенная пользователем. Пользователь вводит данные в элементы управления. При вводе данных система проверяет их на корректность. Если данные некорректны, справа от элемента управления, содержащего некорректные данные, высвечивается сообщение с пояснением причины ошибки. Если данные корректны, формируется запрос изменения строки. Запрос отправляется СУБД и выполняется. В строке состояния высвечивается сообщение о результате операции (в случае успеха — «Запись успешно изменена.», в случае неудачи — «Не удалось изменить запись.» и причины неудачи). Удалить запись из таблицы. Применяется, когда пользователь запрашивает удаление строки из таблицы. Предусловие: необходимость удаления строки из таблицы. Постусловие: из таблицы удалена строка, указанная пользователем. Пользователь выбирает строку, которую нужно удалить. Нажимает на кнопку «Удалить строку». Система выполняет проверку, есть ли в строке значения. Если строка пуста, формируется запрос удаления строки. Если строка не пуста, показывается диалоговое окно с текстом «Вы уверены, что хотите удалить непустую строку?», флажком «Не показывать это сообщение в следующий раз» и вариантами выбора «Да» и «Нет». Если пользователь нажимает «Нет», таблица не удаляется. Если пользователь нажимает «Да», формируется запрос удаления строки. Запрос отправляется СУБД и выполняется. В строке состояния высвечивается сообщение о результате операции (в случае успеха — «Строка успешно удалена.», в случае неудачи — «Не удалось удалить строку.» и причины неудачи). Добавить поле в таблицу. Применяется, когда пользователь запрашивает добавление поля в таблицу. Предусловие: необходимость добавления поля в таблицу. Постусловие: в таблицу добавлено поле с названием, введенным пользователем. Пользователь выбирает таблицу, в которую нужно добавить новое поле. Нажимает на кнопку «Добавить поле». Появляются элемент управления для ввода названия поля. Пользователь вводит название. При вводе система проверяет данные на корректность. Если данные некорректны, справа от элемента управления высвечивается сообщение с пояснением причины ошибки. Если данные корректны, формируется запрос добавления поля. Запрос отправляется СУБД и выполняется. В строке состояния высвечивается сообщение о результате операции (в случае успеха — «Поле успешно добавлено.», в случае неудачи — «Не удалось добавить поле.» и причины неудачи). Изменить название поля таблицы. Применяется, когда пользователь изменяет данные в элементе управления, соответствующему названию поля таблицы. Предусловие: необходимость изменения названия поля таблицы. Постусловие: название поля таблицы изменено на введенное пользователем. Пользователь изменяет название поля. При вводе система проверяет данные на корректность. Если данные некорректны, справа от элемента управления высвечивается сообщение с пояснением причины ошибки. Если данные корректны, формируется запрос изменения названия поля. Запрос отправляется СУБД и выполняется. В строке состояния высвечивается сообщение о результате операции (в случае успеха — «Название поля успешно изменено.», в случае неудачи — «Не удалось изменить название поля.» и причины неудачи). Диаграмма Насси–Шнейдермана Диаграмма Насси–Шнейдермана — один из графических способов представления структурированных алгоритмов. Этот способ является аналогом блок-схемы, но имеет преимущества перед ней: 1. Диаграмма более компактна (между элементами не рисуются стрелки). 2. Описание алгоритма в виде диаграммы Насси–Шнейдермана гарантирует, что принципы структурного программирования соблюдены (при использовании блок-схем можно случайно получить неструктурированный алгоритм, если быть невнимательным). Последовательно выполняемые действия отображаются вертикально одно за другим. Простое ветвление представляет собой прямоугольник, разделенный вертикальной чертой, в верхней части располагается условие, в двух нижних треугольниках соответственно «да» и «нет». [1] Ниже изображена диаграмма Насси–Шнейдермана, описывающая процесс изменения пароля к базе данных (рис. 0).  Рисунок 18. Детализация процесса изменения пароля к БД (диаграмма Насси-Шнейдермана) Интерфейс системыПользовательский интерфейс — набор средств и методов, обеспечивающий взаимодействие пользователя с программой или устройством. [1] В системе «органайзер» используется графический пользовательский интерфейс, далее представлены некоторые аспекты работы приложения. Ниже показано главное окно приложения со списком контактов в недетализированном виде (рис. 0).  Рисунок 20. Главное окно программы. Список контактов в общем виде Пользователь имеет возможность просмотреть подробные данные каждого контакта (рис. 0).  Рисунок 22. Главное окно программы. Просмотр контактных данных Пользователь может редактировать данные своих контактов (рис. 0).  Рисунок 24. Главное окно программы. Редактирование контактных данных ЗаключениеВ данной курсовой работе было выполнено проектирование информационной системы «Органайзер» на основании методологии структурного системного анализа и проектирования. Выполненная работа представляет собой этап создания информационной системы, цель которой — помощь пользователю в организации своего времяпровождения и хранения, редактирования и обработки его личных данных, а также поиска по этим данным. Разработаны логическая и физическая (с элементами реализации) модели системы с помощью различных инструментов проектирования информационных систем и программного обеспечения: IDEF0, DFD, IDEF3, ERD, спецификации процессов, диаграммы Насси-Шнейдермана, диаграммы вариантов использования системы. Спроектированная система отвечает поставленным требованиям. Программа «Органайзер» является комфортной и простой в эксплуатации. Содержит и систематизирует личные данные пользователя в одном месте, так что не нужно листать бумажный ежедневник или записную книжку в поисках необходимой информации. Список литературыВикипедия, свободная электронная энциклопедия [Электронный ресурс]; Режим досутпа: http://www.wikipedia.org свободный STUDMAN [Электронный ресурс]; Режим доступа: http://studman.ru/ свободный ITstan [Электронный ресурс]; Режим доступа: http://www.itstan.ru/ свободный Лекции по дисциплине «Технологии проектирования информационных систем». 2022 |