Файл: Применение объектно-ориентированного подхода при проектировании информационной системы (УНИФИЦИРОВАННЫЙ ЯЗЫК МОДЕЛИРОВАНИЯ UML).pdf

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

Ассоциации представляют собой связи между экземплярами классов (лич­ность работает в компании, компания имеет ряд офисов).

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

Каждая ассоциация обладает двумя ролями; каждая роль представляет собой направление ассоциации. Таким образом, ассоциация между Клиентом и Заказом содержит две роли: одна от Клиента к Заказу, другая - от Заказа к Клиенту.

Роль может быть явно поименованная с помощью метки. Например, роль ассоциации в направлении от Заказа к Строкам заказа называется «позиция заказа». Если такая метка отсутствует, роли присваивается имя класс – цели – та­ким образом, роль ассоциации от Заказа к Клиенту может быть названа Клиент (термины «начало» (source) и «цель» (target) употребляются для обозначения классов, являющихся соответственно начальным и конечным для ассоциации).

2.2. ДИАГРАММЫ ВЗАИМОДЕЙСТВИЯ

Диаграммы взаимодействия (interaction diagrams) являются мо­делями, описывающими поведение взаимодействующих групп объ­ектов.

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

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

• Окно Ввода Заказа посылает Заказу сообщение "приготовиться".

• Заказ посылает данное сообщение каждой Строке заказа в дан­ном Заказе.

• Каждая Строка заказа проверяет состояние определенного Запа­са товара:

Если данная проверка удовлетворяется (результат - true), то Стро­ка заказа удаляет соответствующее количество товара из Запаса.

В противном случае количество Запаса снижается до уровня по­вторного заказа, и Запас запрашивает новую поставку то­вара.

Существуют два вида диаграмм взаимодействия: диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration dia­grams).

На диаграмме последовательности объект изображается в виде прямоугольника на вершине пунктирной вертикальной линии (рис.3).

Эта вертикальная линия называется линией жизни (lifeline) объек­та. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия. Такую форму представления впервые ввел Ивар Якобсон.

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

запас

Строка

заказа

заказ

Окно

Ввода

Заказа

Объект

Сообщение

Приготовится ()

условие

Проверка ()

Приготовится ()

[Проверка = “true”]

удалить()

Нужен повторный заказ ()

интерация

самоделигирование

Возврат

[Нужен повторный заказ = “true”]

новый

Повторный заказ

[проверка = “true”]

новый

(self-delegation) — сообщение, которое объект посылает самому себе, при этом стрелка сообщения указывает на ту же самую линию жизни.

Из всей возможной управляющей информации два ее вида име­ют существенное значение. Во-первых, это условие, показываю­щее, когда посылается со­общение (например, [нуженПовторныйЗаказ = "true"]). Сообщение посылается только при выполнении дан­ного условия. Другой полезный управляющий мар­кер - это мар­кер итерации, показывающий, что сообщение посылается много раз для множества объектов-адресатов (например,* пригото­виться).

Диаграммы последовательности очень просты и наглядны (в этом заключается самое большое их достоинство) и существенно помога­ют разобраться в процессе поведения системы.

Диаграмма (см. рис. 3) содержит возврат, означающий не но­вое сообще­ние, а возврат из сообщения. На диаграмме возврат отли­чается от обычных сообщений тем, что его стрелка не сплошная, а имеет вид пары линий.

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

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

рис.4 Параллельные процессы и активизации

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

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

• создавать новую ветвь процесса (в этом случае оно связано с самой верхней частью активизации);

• создавать новый объект;

• устанавливать связь с уже выполняющейся ветвью процесса.

Удаление объекта показано с помощью большого знака "X". Объекты могут выполнить самоуничтожение или могут быть унич­тожены посредством еще одного сообщения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

как она выполняется.

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

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

ЗАКЛЮЧЕНИЕ

Хотелось бы отметить, что на примере налоговой инспекции мы воочию убедились в целесообразности использования объектно–ориентированного подход. Но это не предел и перспектива развития объектно–ориентированного метода проектирования велика. Его отличает следующее: «объектно-ориентированные системы более открыты и легче поддаются внесению изменений, по­скольку их конструкция базируется на устойчивых формах. Это дает возможность системе развиваться постепенно и не приводит к полной ее переработке даже в случае существенных изменений исходных требований». К недостаткам относятся: некоторое снижение производительности функционирования программного обеспечения и высокие начальные затраты, эти недостатки не столь существенны в целом и на чаше весов перевес будет в сторону плюсов.

СПИСОК ЛИТЕРАТУРЫ

1. Вендров А. М. Проектирование программного обеспечения экономических информационных систем М., 2000.
2. Ефимова О. В. Курс компьютерных технологий М.,1998.
3. Грэхем И. Объектно-ориентированные методы. Принципы и практика. (Object-Oriented Methods: Principles & Practice). – 3-е изд. – М.: «Вильямс», 2004.
4. Синтес А. Освой самостоятельно объектно-ориентированное программирование за 21 день (Sams Teach Yourself Object-Oriented Programming in 21 Days). – М.: «Вильямс», 2002.
5. Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на C++. – 2-е изд. – М.: «Бином», 1998.
6. Бобровский С. История объектно-ориентированного программирования. http://www.computer-museum.ru/histsoft/oophist.htm.
7. Усов А. С. Внутри Объектной Технологии: Теория, Архитектура, Концепции (цикл статей). http://www.alexus.ru/russian/articles.htm.
8. Коцюба И.Ю., Чунаев А.В., Шиковосновы А.Н. Проектирование информационных систем. Учебное пособие. – СПб: Университет ИТМО, 2015. – 206 с.
9. Инюшкина О.Г. Проектирование информационных систем (на примере методов структурного системного анализа). Учебное пособие, - Екатеринбург: «Форт-Диалог Исеть», - 2014. 240 с.