Эксперт

Сергей

Задать вопрос

Мы готовы помочь Вам.

Определиться с предметной области и сформулировать тему для проектирования информационной системы (желательно чтобы тема совпадала с темой будущей дипломной работы). Пример темы: “Разработка информационной подсистемы автоматизации работы аптечного пункта”. Проектируемая информационная система обязательно должна обрабатывать информацию из базы данных. Провести анализ предметной области и сформулировать требования к программе. Описать подробно техническое задание к проектируемой системе, включающее требования к программе как функционального (не менее 10 основных функций) так и технического характера, требования к исходным данным и получаемым на выходе (как состав данных так и формат представления), требования к совместимости с существующими программными средствами, определить основных пользователей системы (не менее 2). Объем задания должен составлять не менее 2 страниц. Задание должно быть очень четким и подробным и отражать все аспекты и тонкости работы системы.

Техническое задание на проектирование информационной системы должно включать следующие разделы:

• Цель (цель, описание предметной области).
• Назначение системы (определение функциональных требований, анализ основных категорий пользователей, определение основных ограничений).
• Детализация функциональных требований.
• Требования к данным.
• Требования к программным решениям.
• Требования к программному средству (требования к интерфейсу, производительности, безопасности).
• Состав программного обеспечения.
• Функциональные требования к СУБД.
• Требования к аппаратному обеспечению.
• План график выполнения работ (этапы и сроки выполнения).

Ознакомится с такими CASE-инструментариями как Rational Rose и Together и выбрать одно из них для проектирования Вашей информационной системы. Возможно использование средства ModelMaker (поддержка языка Паскаль), ArgoUML (поддержка php), Enterprise Architect 7.1 (Поддержка C++, C#, Java, Delphi, VB.Net, Visual Basic, ActionScript, PHP и Python).

С помощью языка UML формализовать функциональные требования к системе в виде диаграммы вариантов использования. Разработанная Вами диаграмма вариантов использования будет является исходным концептуальным представлением или концептуальной моделью системы в процессе ее проектирования и разработки.  Общее количество актеров в модели  не менее 2 и  не более 20, а вариантов использования не менее 10 и не более 50. Варианты использования будут представлять собой основные сервисы представляемые системой. Реализовать несколько стандартных видов отношений между актерами и вариантами использования. Обязательно должны использоваться отношения ассоциации, расширения, включения и обобщения (рис 23 а,б,в,г — соответственно).  Чтобы очертить рамки действий системы, следует положить на рабочее поле компонент System Boundary (рис 23 д).

В качестве средств реализации языка UML использовать выбранный Вами CASE-инструментарий Rational Rose или Together.

В случае выбора среды Together сначала необходимо создать проект (рис. 24).

Рис. 27. Внешний вид специальной панели инструментов для диаграммы вариантов использования

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

 Разработать диаграмму классов. При разработке диаграммы исполь-зовать рекомендации, указанные в данных методических указаниях. Количе-ство классов должно быть не менее 12 и принадлежать они должны как ми-нимум 2 разным пакетам. Основные классы можно определить исходя из технического задания, разработанного в лабораторной работе №1, выделяя существительные. Несколько классов должны представлять собой модели представления данных. Реализовать различные отношения между классами (не менее 2 различных типов отношений). Классы должны иметь имена, ко-торые отражали бы их суть. Классы должны иметь поля (атрибуты, свой-ства) разных типов и с разными спецификаторами доступа и методы (опера-ции) . Несколько методов (более 4-х) должны иметь параметры и возвращать результат, то есть не быть void. Имена полей и методов должны соответство-вать общепринятым правилам(смотреть ниже). Все классы должны быть от-комментированы для дальнейшего использования утилиты javadoc (Правила комментирования кода смотреть ниже).
Правила именования классов, интерфейсов, переменных (полей), и кон-стант:
Именование переменных, классов, интерфейсов и констант должно производится в соответствии со следующим правилам:
• Все имена за (исключением имен вспомогательных переменных) должны максимально четко отображать смысл переменной, класса, интер-фейса или константы. Не допускается именование транслитерацией (русские слова английскими буквами), все имена должны быть английскими.
• Имя переменной начинается с символов в нижнем регистре, име-на классов и интерфейсов – с символа в верхнем регистре.
• Если имя переменной состоит более чем одного слова, образую-щие слова связываются между собой без пробела, каждое слово, следующее после первого, начинается с символа в верхнем регистре.
• Использование символа подчеркивания для разделения слов в имени допустимо, но предпочтительней использовать его только в именах констант. Имена констант образуются из слов в верхнем регистре, связанных символом подчеркивания.
Примеры имен переменных:
currentUser
itemCounter
delimeter
Примеры имен классов:
BufferedReader
ConsistencyCheacker
ExternalUser
Примеры имен констант:
MAX_ITEMS_NUMBER
TIMER_DELAY
Правила именования методов близки к правилам именования перемен-ных:
• Имена всех методов класса должны максимально четко отобра-жать смысл действий, производимых этим методом. Первое слово, образу-ющее имя метода, по возможности должно быть глаголом, описывающим действие.
• Имя каждого метода должно начинаться со слова в нижнем реги-стре
• Если имя метода образуется более чем из одного слова, то обра-зующие слова связываются между собой без пробела, и каждое слово, сле-дующее после первого, начинается с символа в верхнем регистре.
Примеры имен методов:
close
checkUserRigths
readNextLine
getProperty
setProperty
Правила комментирования кода:
Документированию с использованием специальных комментариев (для дальнейшего использования утилиты javadoc) в обязательном порядке под-лежат все пакеты, классы, входящие в состав пакета, основные поля класса, а так же все входящие в класс методы.
Комментарии должны включать в себя:
• краткое описание класса или метода
• описание отдельных параметров метода
В случае использования среды Together для создания диаграммы клас-сов необходимо выбрать эту диаграмму в соответствующем меню (рис. 28).