ГЛАВА 5

Информационная система фирмы "Два кирпича"

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

Для иллюстрации материала, излагаемого в книге, рассмотрим Интернет-ориентированную ИС малого предприятия "Два кирпича".

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

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

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

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

Определение целей ИС

При проектировании ИС и последующей ее программной реализации будем преследовать следующие цели:

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

Все эти цели будем реализовывать, создавая единую информационную систему, которая будет работать на основе Web-интерфейсов.

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

Постановка задач

На основании анализа поставленных целей определим основные задачи ИС.

1. Разработать БД, в которой будет храниться информация о продаваемых товарах.

2. Обозначить группы пользователей ИС.

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

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

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

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

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

Функциональная модель работы фирмы

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

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

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

Итак, перейдем к анализу ИС.

Анализ ИС с помощью вариантов использования

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

Рис. 5.1. Диаграмма вариантов использования

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

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

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

 Замечание 

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

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

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

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

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

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

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

Отделы фирмы

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

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

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

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

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

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

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

 Замечание 

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

Диаграмма сайта

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

Рис. 5.6. Диаграмма сайта фирмы "Два кирпича"

Диаграмма электронного магазина фирмы "Два кирпича" представлена на рис. 5.6.

Здесь прямоугольниками обозначены Web-страницы, а стрелками — ссылки между ними.

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

Некоторые страницы должны быть статическими (определите какие?), а другие — генерироваться серверным модулем.

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

Подведение итогов

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

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

Базы данных будут размещены на SQL-сервере, а сам сайт — на Apache-сервере.

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