Читать онлайн «Основы проектирования корпоративных систем». Страница 29

Система хранит в базе данных всю статическую информацию: данные о каждой продукции (наименование, цена, вес, описание, указатель URL к графическому файлу), данные о цене доставки по земле и по воздуху, данные о заказах

В качестве СУБД используется PostgreSQL версии 8.2.4

• Обеспечение связи с базой данных

Для обеспечения связи с базой данных разработан модуль связи с БД. Модуль реализован на языке Java (версия j2sdk 1.4.2). Доступ к БД обеспечен с помощью JDBC (используется драйвер JDBC для PostgreSQL, postgresql-8.2-506.jdbc4.jar)

Следует обратить внимание на то, что в этих требованиях уже частично прописаны сценарии использования, их можно проследить. Кроме того, мы оговариваем функции авторизованного пользователя, например возможность просмотреть историю всех своих и только своих заказов (как информацию по каждому заказу в отдельности, так и совокупно по всем заказам; возможно, имеет смысл предусмотреть сортировку заказов). В любом случае необходимо полно и однозначно сформулировать информацию, содержащуюся в заказе (т. е., по сути, поля таблицы БД): ключ – уникальный идентификатор заказа, по нему будет проводиться поиск и сортировка; дата; стоимость; наименования товаров с указанием их количества.

Теперь нужно сказать об используемых программных технологиях. На слайдах приводится один из возможных примеров. Исходя из того что будет выбрана объектно-ориентированная модель, выбирается объектно-ориентированный инструментарий на основе того, что магазин нужен не очень большой, но расширяемый, нужно выбрать инструментарий Java. Тогда возникают основные компоненты: СУБД, язык (логика программной работы и графический интерфейс), серверная часть (ее для простоты можно опустить) и технология связи с базой данных (при данном инструментарии это JDBC). При использовании тех или иных технологий также необходимо рассматривать ограничения. Сразу нужно сказать, что хорошим тоном является упоминание не только названий, но и версий продуктов, которые будут применяться, потому что можно протестировать совместимость этой версии как со средствами, которые имеются у пользователя, так и с элементами программного комплекса, которые мы планируем реализовать.

Важно рассмотреть глобальные элементы интерфейса с точки зрения архитектуры. В интерфейсе пользователя выделяется часть, связанная с графикой (формами, отчетами, командными кнопками, выпадающими списками, окнами и т. д.), и логическая часть, обеспечивающая поддержку сценариев взаимодействия пользователя с системой (обе они будут писаться на языке Java). Забегая вперед, скажем, что удобнее проектировать систему на. NET с помощью Visual Studio и использовать ряд готовых графических примитивов, которые мы можем с помощью мыши объединить, поместив на форму. При реализации на основе Java это будет чуть сложнее.

Что включает в себя графический интерфейс, мы можем определить на основе рис. 4.1. Графический интерфейс позволяет просматривать каталог продукции, данные по каждой позиции отдельно (здесь можно прямо указать соответствующий раздел технических требований). Кроме того, пользователь должен при помощи графического интерфейса иметь возможность отслеживать хронологию заказов, работать с корзиной (например, просто перебрасывать элементы каталога в корзину с помощью механизма drag&drop и посредством мыши и клавиатуры изменять количество элементов продукции в своем заказе), удалять и добавлять элементы в корзину.

Теперь опишем функционал логической части интерфейса пользователя. Логическая часть формирует запросы к БД (например, на языке SQL), передает их и получает ответ (с помощью JDBC). Кроме того, логическая часть позволяет обновлять информацию в БД и формировать заказы. Необходимо ограничить пользовательский интерфейс с учетом той программной платформы, которая используется, а также явно указать спектр версий, с которыми совместимо разрабатываемое ПО, для того чтобы не нести ответственность за тот широкий спектр версий Java, который потенциально может использовать заказчик.

Следует отметить, что графический интерфейс, который является частью решения, должен быть реализован с использованием технологий и библиотек Swing (здесь тоже лучше указать версию). Кроме того, среда разработки и средства также должны быть указаны: используем ли мы NetBeans, Eclipse или что-то другое. Например, в данном случае будем использовать среду разработки Idea 7.0.1. Это нужно четко указать для возможности дальнейших модификаций продукта.

Еще ряд важных технологических требований касается других элементов магазина. Во-первых, требования к БД. Прежде всего необходимо явно описать способ хранения данных. Так как объем хранимых данных достаточно велик, следует использовать СУБД, а не файлы. Программная система хранит в БД всю статическую информацию: каталог продуктов, заказы, служебная информация (имена и пароли пользователей, их адреса, ФИО). Что касается единиц продукции, нужно перечислить все атрибуты таблицы, где хранится каталог продукции: наименование, цена, вес, описание, указатель (URL) на изображение данного товара, цена доставки (по земле и по воздуху). Можно сослаться здесь на структуру данных о товаре из списка требований. Естественно, впоследствии при детализации требований необходимо в документации описать ER-диаграммы, которые будут описывать все структуры данных, поля и их типы, включая индексируемые, ключевые и т. д. Еще очень важно оговорить тип СУБД, ее название и версию: мы будем использовать реляционную СУБД PostgreSQL версии 8.2.4, и тогда у нас не возникнет сложностей с сопровождением и дополнительных конфликтов с заказчиков. Естественно, нужно обсудить с заказчиком используемый спектр программного обеспечения.

Третьей составляющей программной системы является обеспечение связи с БД. В данном случае, поскольку мы работаем с технологией Java, будем использовать JDBC. Мы четко указываем, что будем разрабатывать модуль связи с базой данных (отдельный класс). Отдельно указываем версию JDBC – 1.4.2 (как и версия Java). Далее указываем тот самый драйвер JDBC, который мы будем использовать. Естественно, он связан с PostgreSQL. Впоследствии у нас возникнет ряд документации по установке баз данных, да и всей программной среды. Будут указаны все каталоги, переменные окружения и т. д.

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