Проектирование программного обеспечения экономических информационных систем

Объектно-ориентированный подход

171

Screen

CashDispenser

Рис. 3.23. Диаграмма компонентов для клиента

файлу тела класса Screen на языке C++ (файл с расширением .СРР). Невыделенный компонент также называется спецификацией пакета, но соответствует заголовочному файлу класса языка C++ (файл с расширением .Н). Компонент Client.exe является исполняемой программой.

Компоненты соединены штриховой линией, что соответствует зависимостям между ними. Например, класс CardReader зависит от класса Screen. Это означает, что, для того чтобы класс CardReader мог быть скомпилирован, класс Screen должен уже существовать. После компиляции всех классов может быть создан исполняемый файл Client.exe.

172

Глава 3

В данном примере система включает два исполняемых файла. Один из них — это клиент Client.exe, он содержит компоненты CashDispenser, CardReader и Screen. Второй файл — это сервер, включающий в себя компонент Account. Диаграмма компонентов для сервера показана на рис. 3.24.

Server.exe

Account

Account

Рис. 3.24. Диаграмма компонентов для сервера

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

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

Объектно-ориентированный подход

173

3.9. ДИАГРАММЫ РАЗМЕЩЕНИЯ

Диаграмма размещения (deployment diagram) отражает физические

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

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

На рис. 3.25 изображен персональный компьютер (ПК),связанный с UNIX-сервером посредством протокола TCP/IP (Transmission Control Protocol / Internet Protocol —протокол управления передачей

— протокол Интернет). Связи между узлами показывают коммуникационные каналы, с помощью которых осуществляются системные взаимодействия.

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

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

Компонент может иметь более одного интерфейса, в этом случае видно, какие компоненты взаимодействуют с каждым интерфейсом. На рис. 3.25 ПК включает два компонента: пользовательский интерфейс и клиентскую часть приложения. Клиентская часть приложе-

174

Глава 3

		Сервер Диабетического
		Отделения
Связь	TCP/IP	Объектная
		База Данных
		1 Медицинская
		Помощь

Сервер Отделения ЗаболеванийПечени

				Конфигурация
Объектная	Коммуникация			Отделения
				Заболеваний
База Данных
				Печени
	Медицинская
	Помощь		Конфигурирование
Приложение			Медицинской
Сервера	Е.	5=	Информации
Отделения
Заболеваний	Конфигурация
Печени			Конфигурирование
Интерфейс			Пользователей
TCP/IP
ПК под управлением Windows		\	у , р л	Встроенный
			узел	объект
Клиентская Часть				Компонент
Отделения

Заболеваний

Печени

Пользовательский

Интерфейс

Отделения

Заболеваний

Печени

Рис. 3.25. Диаграмма размещения

Объектно-ориентированный подход

175

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

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

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

3.10. ПРИМЕР ИСПОЛЬЗОВАНИЯ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА

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

На начальной стадии (или стадии формированиятребований) строится начальная диаграмма вариантов использования (рис. 3.26).

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

•Кто использует систему непосредственно?

•Кто отвечает за эксплуатацию системы?

•Какое внешнее оборудование используется системой?

•Какие другие системы взаимодействуют с данной системой?

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

176

Глава 3

Проверить

документы

Налогоплательщик

Сформировать

свидетельство о постановке на учет

Налоговый

инспектор

Зарегистрировать

налогоплательщика

Подсистема приема отчетности

Зарегистрировать и проверки платежей расчетный счет

Рис. 3.26. Начальная диаграмма вариантов использования

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

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

Объектно-ориентированный подход

177

Структура программной системы описывается с помощью нескольких диаграмм классов, главная из которых представляет собой диаграмму пакетов (подобную диаграммам, представленным на рис. 3.9 и 3.10), а остальные диаграммы раскрывают содержимое каждого из пакетов. При построении диаграммы классов предметной облас-

Форма регистрации Налогоплательщик

Залоговый налогоплательщика инспектор

открыть форму()

запросить данные()

ввести данные ()

проверить регистрацию () i проверка

• регистрации ()

регистрация проверена ()

запросить регистрацию ()

<. [

присвоить ИНН ()	I	| регистрация ()
	зарегистрировать ()

регистрация выполнена ()

подтвердить регистрацию ()

•4	•	1
	закрыть форму {)	I

Рис. 3.27. Диафамма последовательности для варианта использования "Зарегистрировать налогоплательщика"

178

Глава3

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

•в описании исходных данных выделяются кандидаты в классы— существительные, которые потенциально могут соответствовать классам (при этом следует помнить, что существительные могут также относиться к объектам, ассоциациям или атрибутам классов);

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

ляется характерным признаком неудачного выделения класса. Рассматривается каждая возможная пара классов и устанавлива-

ется существование ассоциации между ними (по аналогии с установлением связей между сущностями в процессе моделирования данных). Присваиваются наименования ролям ассоциаций и определяется их множественность.

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

Определяются действия (операции), выполняемые каждым классом. При определении операций нужно учитывать следующие рекомендации:

•каждая операция должна выполнять одну простую функцию;

•название операции должно отражать результат функции, а не то, как она выполняется.

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

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

Объектно-ориентированный подход

179

Налогоплательщикорганизация

ИНН

КПП

Наименование организации Юридический адрес Фактический адрес КодФС

КодОПФ

Код ОКПО Код ОКОНХ

Код вида деятельности Руководитель

проверить регистрацию!) зарегистрировать))

1	Счет
	налогоплательщика
	Номер счета
Учредитель	Тип счета
	открыть счет()
ИНН	закрыть счет()

Юридическое	Физическое	Банк
лицо	лицо
		Наименование
КодОПФ	Номер паспорта	БИК
Код вида	Серия паспорта	Кор. счет
деятельности		Адрес
Наименование		Руководитель
Адрес		Телефон

Рис. 3.28. Диаграмма классов предметной области

180

Глава3

3.11. СОПОСТАВЛЕНИЕ И ВЗАИМОСВЯЗЬ СТРУКТУРНОГО И ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДОВ

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

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

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

Данные по сравнению с процессами являются более стабильной и относительно редко изменяющейся частью системы. Отсюда следует главное достоинство объектно-ориентированного подхода, которое Гради Буч сформулировал следующим образом: объектно-ори-

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