Сергей Зыков - Основы проектирования корпоративных систем

• Название: Основы проектирования корпоративных систем
• Автор: Сергей Зыков
• Жанр: Управление, подбор персонала
• Год: 2012
• ISBN: 978-5-7598-0862-6

В монографии рассматриваются важнейшие аспекты разработки прикладных программных систем для корпораций – крупных распределенных индустриальных структур, объединенных общими бизнес-целями. Особенностью подхода является исследование всего комплекса архитектурных уровней, необходимых для построения таких систем, – от моделей жизненного цикла и методологий их реализации до технологических платформ и инструментальных средств. Приведен ряд примеров, иллюстрирующих особенности применения современных технологий (в первую очередь, разработанных корпорацией Microsoft) для реализации и внедрения крупномасштабных программных систем в различных отраслях народного хозяйства.

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

---

Порядок объема базы данных – сотни мегабайт. Если предусмотреть дополнительные или более высококачественные фотографии размером порядка мегабайта и если товаров порядка сотни, то размер БД будет порядка гигабайта. Сейчас это предварительные соображения, но в документ с требованиями необходимо внести данные о том, какого рода ограничение должно быть на объем данных сверху. Для определения интенсивности транзакций нужно сделать предположение, насколько сложные запросы к базе данных возможны, какова интенсивность транзакций, каков их механизм, какова пропускная способность интернет-канала, который будет узким местом в системе. Поэтому имеет смысл предусмотреть различные механизмы представления информации. Ряд пользователей будет заинтересован в более качественных фотоизображениях, поэтому необходимо оговорить тот порог, который предусматривается для пропускной способности, просто чтобы обезопасить себя от изменения факторов, за которые мы не можем отвечать. Если пропускная способность сети падает ниже возможностей модема, можно говорить о том, что система не сможет работать стабильно. Можно обсуждать с заказчиками скорость порядка десятков мегабит. В любом случае нужно четко описать и это количественное ограничение.

В примитивном интернет-магазине безопасность находится на низком уровне. Можно будет применить простую систему шифрования имен и паролей, введя ограничения на их длину. Едва ли будет смысл использовать что-то более серьезное. Если же речь пойдет об интернет-платежах, потребуется более высокий уровень надежности (специальные токены, сервер авторизации, протоколы обмена, цифровая подпись и т. д.). Но без этого говорить о серьезной безопасности не приходится. Итак, в списке требований нужно отразить ограничения на длину имени и пароля и их сложность.

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

Теперь посмотрим, каким образом можно сделать набросок первичных требований к системе в форме списка требований (requirements checklist). Он, конечно, не будет настолько всеобъемлющим, как техническое задание, но для относительно простого и небольшого интернет-магазина с этого документа вполне можно начать.

Особенности механизма авторизации. Система должна иметь возможность авторизации пользователей. Для простоты: пока есть один тип пользователей – покупатели. Каждый пользователь характеризуется именем пользователя и паролем. Пользователь может задать свое имя и свой пароль (возможно, полезна будет автогенерация паролей), сменить пароль в любое время сеанса работы с системой. Формулируются понятия авторизованного и неавторизованного пользователя: если пользователь не пытался войти в систему или ввел при входе некорректные имя и пароль, пользователь получает статус неавторизованного. В противном случае пользователь становится авторизованным. Это важные понятия, потому что в зависимости от состояния пользователя система предоставляет ему различные сервисы. Можно оговорить еще и количество попыток ввода имени и пароля. Также система должна выдавать адекватное сообщение об ошибке. Авторизованный пользователь должен иметь возможность выйти из авторизованного режима. Сохранять ли состояние корзины, нужно обсуждать с заказчиком.

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

Каталог продукции содержит список наименований, детальное описание продукта, изображение и цену. Нужно указать, всю ли линейку товаров поддерживает система и чем ее ассортимент ограничивается. Например, весь ассортимент продукции заказчика с ограничением на длину и вес.

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

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

Важным является понятие сессии: продукция в корзине пользователя хранится только в ходе одной сессии. Началом сессии можно считать вход в систему, концом – закрытие браузера или нажатие кнопки «Выход». Между этими двумя событиями происходит сессия. После окончания сессии пользователь становится неавторизованным и из корзины все удаляется.

Другое важное функциональное требование – способ оформления заказа. Естественно, оформление заказа возможно только после того, как пользователь выбрал необходимое количество товаров в корзине и нажал на кнопку «Оформить заказ». Таким образом, оформление заказа также доступно только для авторизованных пользователей – это явно указывается в документе. Заказ включает в себя всю продукцию из корзины и свойства доставки – эти атрибуты автоматически переносятся из корзины в заказ. Если нажата кнопка «Оформить заказ», он автоматически попадает в БД и не может быть отменен. Также важно, что после оформления заказа сессия продолжается, но вся продукция из корзины удаляется автоматически. Это тоже нужно явно отметить.

Список требований к системе по программным технологиям может выглядеть так:

Требования к системе: Технологии

• Интерфейс пользователя

Пользовательский интерфейс состоит из графического интерфейса пользователя и логической части

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

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

Пользовательский интерфейс реализован как Java-приложение (версия j2sdk 1.4.2). Графический интерфейс реализован с использованием Swing

Среда разработки – Idea 7.0.1

• База данных

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

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

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

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

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