Ход выполнения практической работы.

В ходе выполнения практической работы необходимо реализовать следующие этапы:

1. Описать функциональные и нефункциональные требования к разрабатываемому программному модулю.

Функциональные требования описываются посредством диаграммы прецедентов.

Диаграммы прецедентов составляют модель прецедентов (вариантов использования, use-cases). Прецедент - это функциональность системы, позволяющая пользователю получить некий значимый для него, ощутимый и измеримый результат. Каждый прецедент соответствует отдельному сервису, предоставляемому моделируемой системой в ответ на запрос пользователя, т. е. определяет способ использования этой системы. Диаграммы прецедентов чаще всего применяются для спецификации внешних требований к проектируемой системе или для спецификации функционального поведения уже существующей системы.

Нефункциональные требования - это описание таких свойств системы, как особенности среды и реализации, производительность, расширяемость, надежность и т. д.

Нефункциональные требования необходимо описать в неформализованном виде.

2. Создать функциональную модель программного модуля с помощью диаграммы IDEF0.

Методология IDEF0 может использоваться для моделирования широкого круга автоматизированных или неавтоматизированных "систем" или предметных областей, включая любые возможные комбинации аппаратного и программного обеспечения, машин, процессов и людей. При создании новых систем IDEF0 можно использовать сначала для задания требований к системе и ее функциям, а затем для разработки собственно системы, которая соответствует заданным требованиям и исполняет заданные функции. При работе с существующими системами с помощью IDEF0 можно анализировать выполняемые системой функции и документировать механизмы (средства), которыми это достигается.

Результатом применения IDEF0 является модель. Модель состоит из диаграмм, текста и словаря терминов, имеющих перекрестные ссылки друг на друга. Диаграммы - основной компонент модели. Все функции и взаимодействия отображаются на диаграммах в виде прямоугольников (функции) и стрелок (взаимодействия).

3. Определить классы программного модуля и создать диаграмму классов.

Классом называется именованное описание совокупности объектов с общими атрибутами, операциями, связями и семантикой. Графически класс изображается в виде прямоугольника. У каждого класса должно быть имя (текстовая строка), уникально отличающее его от всех других классов. При формировании имен классов в UML допускается использование произвольной комбинации букв, цифр и даже знаков препинания.

Диаграмма классов (class diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывать их внутреннюю структуру и типы отношений.

4. Разработать алгоритм выполнения функций программного модуля. Алгоритм оформить в виде диаграммы активностей (деятельности).

Диаграммы деятельности позволяют моделировать сложный жизненный цикл объекта, с переходами из одного состояния (деятельности) в другое. Так же этот вид диаграмм может быть использован и для описания динамики совокупности объектов. Они применимы и для детализации некоторой конкретной операции.

5. Определить последовательность передачи сообщений и команд между разными объектами и классами программного модуля. Создать диаграммы взаимодействия и DFD.

Диаграмма взаимодействия описывает последовательность, в которой объекты отправляют и получают сообщения.

DFD — Data Flow Diagrams — диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ.

6. Разработать и спроектировать Базу Данных.

Этап разработки и проектирования БД включает в себя:

• Определить сущности;

• Определить связи между сущностями;

• Построить ER-модели.

ER-модель (модель “сущность-связь”) – широко используемый инструмент разработки баз данных, представляющий собой формализованное графическое представление предметной области в виде прямоугольников, линий и специальных символов.

Преимуществом ER-модели заключается в том, что она понятна и разработчикам баз данных, и заказчикам, то есть будущим ее пользователям, и потому все возможные изменения в структуре данных согласуются между ними именно на уровне этой модели. ER-модель никак не связана ни с какой конкретной СУБД, этот выбор осуществляется впоследствии. В основе ER-модели лежат понятия “сущность”(“entity”) и “связь” (“relation”).

Сущность – совокупность объектов, а каждый объект этой совокупности – экземпляр сущности. Экземпляры должны быть различимы, то есть не должно быть двух экземпляров с одинаковыми наборами атрибутов. Каждая сущность имеет набор атрибутов, уникальный для каждого экземпляра сущности, называемый ключом.

Связи бывают трех типов:

• Связь “один к одному”. При этой связи один элемент первой сущности связан не более чем с одним экземпляром второй сущности. Этот тип связи встречается сравнительно редко.

• Связь “один ко многим” В этом случае один экземпляр первой сущности связан с несколькими экземплярами второй сущности, но один экземпляр второй сущности связан не более чем с одним экземпляром второй сущности. Первая сущность считается в данной связи основной, вторая – подчиненной.

• 3. Связь “многие ко многим”. В этом случае каждый экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, а каждый экземпляр второй сущности – с несколькими экземплярами первой.

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

7.Создать приложение-интерфейс для работы с базой данных. Приложение создается в выбранной среде. Функциональность приложения заключается в следующем:

• формирование запросов на вывод необходимой информации;

• удаление, добавление, изменение данных в БД;

• вывод данных на печать;

• вывод данных во внешний файл;

8. Интегрировать базу данных в приложение.

9. Выполнить тестирование программного модуля. Тестирование программного модуля проводится ручным методом.