Замечание. Под актерами могут подразумеваться не только физические лица, но и юридические, отделы организаций и

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

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

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

Для более полного представления о роли актеров в модели ИС, а также последующего уточнения процессов, рассмотрим представленную схему подробнее.

Покупатель стройматериалов

Может получить доступ к прайс-листу фирмы посредством Интернета. Кроме того, должен иметь возможность распечатать счет на оплату, сгенерированный в автоматическом режиме. При получении формы счета покупатель вводит свои реквизиты, и они сохраняются в БД.

После оформления счета выполняются следующие операции: проведение банковского платежа и получение товара со склада фирмы, либо посылка сообщения менеджеру о совершении перевода денег для доставки материалов транспортом фирмы.

Отделы фирмы

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

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

Варианты использования системы

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

Остановимся на каждом варианте использования.

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

Промежуточные итоги

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

Уточнение диаграммы вариантов использования

Для детального анализа разделим диаграмму на две составные части: клиентов фирмы и сотрудников. Поскольку нас интересует лишь функционирование магазина, то отбросим все варианты использования, не связанные с ним.

Варианты использования клиентами фирмы

Добавим к уже описанным вариантам, следующие вспомогательные:

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

Уточнение заказа. Это предоставление в развернутом виде информации о покупке.

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

Таким образом, после уточнения получаем диаграмму, изображенную на рис. 5.2.

Рис. 5.2. Диаграмма вариантов использования ИС покупателем

Варианты использования сотрудниками фирмы

Менеджер должен иметь возможность внести в БД продаваемых товаров новую позицию, а также при необходимости удалить информацию о продаваемом товаре. При этом обновится электронная витрина, и покупатель сможет выбрать продукцию из нового ассортимента. Кроме того, менеджер использует систему для установки цен на товары.

Диаграмма, отражающая эти варианты использования, представлена на рис. 5.3.

Таким образом, мы извлекли максимально обширные сведения из диаграмм вариантов использования. В этой главе мы представили эти материалы "как есть", т. е. без объяснений того, как они были получены. Описания вариантов использования должны быть сформулированы либо заказчиком системы, либо доверенным экспертом. Мы же создавали их, исходя из собственного опыта и на основании анализа работы подобных систем. Получив диаграммы, можно продолжать разработку системы, постепенно приближаясь к уровню описания кода.

Следующим этапом в проектировании системы будет использование диаграмм классов.

Рис. 5.3. Варианты использования ИС сотрудниками фирмы

Использование диаграмм классов

Диаграммы классов позволяют проводить анализ с нескольких позиций. Существуют три подхода к описанию диаграмм классов, выраженные следующими точками зрения: концептуальной, спецификации и реализации. Первый метод описания объектов системы предполагает идентификацию понятий предметной области с классами системы. Например, в физике материальному телу можно поставить в соответствие класс, экземплярам которого присваивается значение скорости, массы и т. д. Благодаря использованию такого подхода, легко добиться точного соответствия проектируемой системы и происходящих процессов, т. е. достаточно полно описать модель, которая будет соответствовать необходимым критериям точности, чтобы подготовить почву для непосредственной реализации ИС.

Второй метод позволяет оперировать с интерфейсами пользователя, а третий — отражает классы, используемые при программировании конечного программного продукта.

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

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

Прежде всего, следует учесть, что серверный модуль, который будет обеспечивать интерактивность сайта, запускается после обращения пользователя. Это может быть классический URL-адрес:

www.myserveг.ru/module.ехе

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

Очевидно, что процесс заказа товаров состоит их нескольких стадий. Кроме того, после завершения очередной стадии система должна сохранять некоторую служебную информацию для последующего применения. Такая информация может сохраняться несколькими способами, чтобы быть переданной последующему экземпляру серверного модуля: записываться в текстовый файл, заноситься в базу данных или специально предназначенное для этих целей поле hidden Web-страницы. Это поле может содержать произвольную информацию, которую туда записал серверный модуль, но оно не отображает ее пользователю. Использование такого метода позволяет существенно уменьшить нагрузку на сервер баз данных, что имеет с точки зрения оптимизации системы большое значение, и именно так мы и поступим.

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

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

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

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

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

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

Рис. 5.4. Диаграмма классов электронного магазина

Разумеется, она не вводится эмпирически, а является результатом анализа требований к ИС, диаграмм использования и т. д., но сам процесс анализа проходит в тесном диалоговом взаимодействии с заказчиком, и в связи с отсутствием такового мы позволим себе использовать упомянутую диаграмму.

Прежде всего, остановимся на условных обозначениях.

Класс, как вы уже, наверное, догадались, изображен в виде прямоугольника, разграниченного тремя разделительными линиями (рис. 5.5).

Рис. 5.5. Изображение класса на диаграмме

Линии, соединяющие классы и представленные на рис. 5.4, демонстрируют функциональные связи между объектами системы. Те из них, которые оканчиваются широкой стрелкой в виде треугольника, обозначают наследование в терминах классического объектно-ориентированного программирования. Однако следует заметить, что, как и в случае диаграмм вариантов использования, язык UML такое отношение между классами именует генерализаций или Обобщением. К Примеру, TCategoriesView наследуется ОТ TBasicView.

Линия с обычной стрелкой на конце означает, что один класс использует другой, как в случае двух классов — TPageProducer и TBasicView. Здесь приведены лишь простейшие соотношения между классами из тех, которые допускает язык UML, однако, как правило, их бывает достаточно для создания таких диаграмм.

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

Структура диаграммы классов

Здесь представлены несколько классов, которые имеют различное функциональное назначение.

Класс TWebModuie описан в библиотеке httpapp, входящей в поставку Delphi, и служит, с одной стороны, интерфейсом для взаимодействия с Web-сервером, а с другой — источником создания контейнера для невизуальных объектов, таких как TQuery или TPageProducer. В данной системе он используется только как предок класса TDispatcher, который слегка модифицирует логику обработки запроса. Это изменение заключается в собственном методе разбора данных запроса и анализа поведения системы.

Основным классом, который отвечает за динамическое формирование данных, впоследствии преобразовывающихся в Web-страницу, является TBasicview. Он содержит в себе методы, которые и создают это динамическое представление данных. Непосредственное использование данного класса осуществляется его наследниками: TCategoriesView, TDetailsView, TPositionView, TCartview, TOrderView, TBiiiview. Рассмотрим назначение этих классов:

• TCategoriesView — отображает список категорий товаров, доступных в базе данных магазина на момент его посещения клиентом. Предоставляемая информация извлекается из запроса к базе данных.
• TDetailsView — предоставляет детальное описание товаров, которые выбирает клиент.
• TPositionView — отвечает за отображение содержимого категорий, выбранных клиентом.
• TCartview — формирует представление корзины.
• TOrderView — предоставляет форму для заказа товара.
• TBillview — генерирует элементы счета.

Класс TFageProducer является классом, описанным в бибилиотеках Delphi, и преобразует данные из внутреннего представления системы в готовые Web-страницы, отправляемые клиенту объектами класса TDispatcher.

Для упрощения проекта здесь не приведены некоторые элементы, которые будут описаны в ходе дальнейшего изложения материала. Следует отметить, что нами при проектировании системы были использованы знания о структуре серверного приложеня в Delphi. Они будут описаны в гл. 10. Там же будет приведена реализация этой системы.

Здесь мы опустим описание интерфейсов классов, поскольку для его понимания нужно знать методологию написания серверных модулей и технологии, доступ к которым предоставляет Delphi. Этот материал также приведен в гл. 10.

База данных ИС фирмы "Два кирпича"

Для хранения данных будем использовать базу данных с двумя таблицами. В первой, под названием Products будет содержаться информация о продаваемых товарах (табл. 5.1).

Кроме этой таблицы, база данных должна содержать еще информацию о клиентах в таблице с названием Klients. Она будет использоваться для хранения информации о заказчиках, выполнивших печать платежных документов (табл. 5.2).

Таблица 5.1. Структура полей таблицы Products

Поле	Тип данных	Назначение
IDJTOBAPA	Числовой	Идентификатор товара в базе данных
МАРКА	Текстовый	Название товара
ПРОИЗВОДИТ	Текстовый	Производитель товара
ТЕХНИЧЕСКИ	Текстовый	Описание технических характеристик
ФОТОГРАФИЯ	Текстовый	Адрес к фотографии изделия
ЕДИНИЦА ИЗ	Текстовый	Единица, в которой измеряется количество данного товара
ЦЕНА_ЗА_ЕД	Числовой	Цена одной единицы товара, в рублях
ПРИМЕЧАНИЕ	Текстовый	Примечания, которые хочет оставить менеджер по данной позиции товара
КАТЕГОРИЯ	Текстовый	Название категории, к которой относится данный товар
ДАТА ВЫЛ	Текстовый	Дата выпуска товара в произвольном формате
СРОК_ХР	Текстовый	Срок хранения товара

Таблица 5.2. Структура полей таблицы Klients

Поле	Тип данных	Назначение
ID	Числовой	Идентификатор клиента
KlientsName	Текстовый	Название организации — заказчика или имя и фамилия частного лица
KlientsAddress	Текстовый	Адрес заказчика
KlientsBank	Текстовый	Банковские реквизиты клиента

Дата добавления: 2014-12-29