7. Задание на курсовую работу
Этап №1.
Определиться с предметной области и сформулировать тему для проектирования информационной системы (желательно чтобы тема совпадала с темой будущей дипломной работы). Пример темы: “Разработка информационной подсистемы автоматизации работы аптечного пункта”. Проектируемая информационная система обязательно должна обрабатывать информацию из базы данных. Провести анализ предметной области и сформулировать требования к программе. Описать подробно техническое задание к проектируемой системе, включающее требования к программе как функционального (не менее 10 основных функций) так и технического характера, требования к исходным данным и получаемым на выходе (как состав данных так и формат представления), требования к совместимости с существующими программными средствами, определить основных пользователей системы (не менее 2). Объем задания должен составлять не менее 2 страниц. Задание должно быть очень четким и подробным и отражать все аспекты и тонкости работы системы.
Техническое задание на проектирование информационной системы должно включать следующие разделы:
Цель (цель, описание предметной области).
Назначение системы (определение функциональных требований, анализ основных категорий пользователей, определение основных ограничений).
Детализация функциональных требований.
Требования к данным.
Требования к программным решениям.
Требования к программному средству (требования к интерфейсу, производительности, безопасности).
Состав программного обеспечения.
Функциональные требования к СУБД.
Требования к аппаратному обеспечению.
План график выполнения работ.
Ознакомится с такими CASE-инструментариями как Rational Rose и Together и выбрать одно из них для проектирования Вашей информационной системы. Возможно использование средства ModelMaker (поддержка языка Паскаль), ArgoUML (поддержка php).
С помощью языка UML формализовать функциональные требования к системе в виде диаграммы вариантов использования. Разработанная Вами диаграмма вариантов использования будет является исходным концептуальным представлением или концептуальной моделью системы в процессе ее проектирования и разработки. Общее количество актеров в модели не менее 2 и не более 20, а вариантов использования не менее 10 и не более 50. Варианты использования будут представлять собой основные сервисы представляемые системой. Реализовать несколько стандартных видов отношений между актерами и вариантами использования. Обязательно должны использоваться отношения ассоциации, расширения, включения и обобщения (рис 3. а,б,в,г - соответственно). Чтобы очертить рамки действий системы, следует положить на рабочее поле компонент System Boundary (рис 3 д).
Рис. 3. Выбор типа отношений в диаграмме вариантов использования
В качестве средств реализации языка UML использовать выбранный Вами CASE-инструментарий Rational Rose или Together.
В случае выбора среды Together сначала необходимо создать проект (рис. 4).
Рис. 4. Внешний вид панели инструментов для создания проекта.
Затем необходимо ввести имя проекта (рис. 5).
Рис. 5. Окно ввода имени проекта.
После этого необходимо выбрать разрабатываемую диаграмму (Use Case Diagrams) (рис. 6).
Рис. 6. Окно выбора разрабатываемой диаграммы.
Затем приступить к построению диаграммы, используя соответствующую панель (рис. 7).
Рис. 7. Внешний вид специальной панели инструментов для диаграммы вариантов использования
Результатом выполнения этого этапа должно быть, сформированное техническое задание на проектируемую информационную систему и построенная диаграмма вариантов использования с описанием основных сущностей и вариантов использования.
Этап №2.
Разработать диаграмму классов. При разработке диаграммы использовать рекомендации, указанные в данных методических указаниях. Количество классов должно быть не менее 12 и принадлежать они должны как минимум 2 разным пакетам. Основные классы можно определить исходя из технического задания, разработанного в лабораторной работе №1, выделяя существительные. Несколько классов должны представлять собой модели представления данных. Реализовать различные отношения между классами (не менее 2 различных типов отношений).
33
Классы должны иметь имена, которые отражали бы их суть. Классы должны иметь поля (атрибуты, свойства) разных типов и с разными спецификаторами доступа и методы (операции) . Несколько методов (более 4-х) должны иметь параметры и возвращать результат, то есть не быть void. Имена полей и методов должны соответствовать общепринятым правилам(смотреть ниже). Все классы должны быть откомментированы для дальнейшего использования утилиты javadoc (Правила комментирования кода смотреть ниже).