Применение объектно-ориентированного подхода при проектировании информационной системы (Обзор и анализ основных принципов и особенностей объектно-ориентированного подхода)

Содержание:

Введение

Актуальность исследования заключается в том, что из существующих подходов к проектированию информационных систем объектно-ориентированный в настоящее время считается наиболее эффективным т.к. оперирует абстракциями реальных объектов и операций. Т.е. при построении модели имеющейся предметной области, выделении бизнес-процессов и пр. строится и модель будущей информационной системы (ИС). К тому же одной из важных особенностей объектно-ориентированного подхода является унифицированность процесса разработки ИС, неотъемлемой частью которого является унифицированный язык моделирования UML. Данная особенность обеспечивает упорядоченный подход к распределению задач и обязанностей при проектировании ИС, охватывающий весь ее жизненный цикл. Именно поэтому основы объектно-ориентированного подхода, а также принципы унифицированного моделирования широко используются при проектировании автоматизированных информационных систем.
Объектом исследования данной работы является объектно-ориентированный подход к проектированию информационных систем. Предметом исследования является унифицированный язык моделирования.
Цель данной работы является обзор и анализ основных принципов и особенностей объектно-ориентированного подхода, а также его неотъемлемого инструмента унифицированного языка моделирования (UML).
Задачи работы:
• Обзор основных понятий и концепций объектно-ориентированного подхода
• Выявление преимуществ и недостатков объектно-ориентированного подхода
• Обзор основных структур унифицированного языка моделирования
• Использование UML на примере.

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

1. Сущность объектно-ориентированного подхода

Объектно-ориентированные концепции играют огромную роль в анализе и проектировании программного обеспечения, поскольку касаются фундаментальных вопросов адаптации развития. На протяжении некоторого времени существовало множество разнообразных нотаций и методов объектно-ориентированного анализа и проектирования программных систем, но потом появился унифицированный язык моделирования (UML^[1]), который предоставляет стандартизованную нотацию для описания таких моделей. Однако UML лучше использовать в сочетании с методами объектно-ориентированного анализа и проектирования.

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

Термин «объектно-ориентированный» появился в связи с объектно-ориентированным программированием вообще и языком Smalltalk в частности, хотя концепции сокрытия информации и наследования были известны и раньше. Идея сокрытия информации и ее применения для проектирования программ впервые встречается в работе Парнаса, предложившего сокрытие информации для создания замкнутых модулей, которые можно было бы изменять, не затрагивая (или почти не затрагивая) другие модули. Концепции классов и наследования были введены в языке Simula 67, но получили широкое распространение только с появлением языка Smalltalk. В этом разделе я опишу объектно-ориентированные концепции на уровне задачи (анализ) и решения (проект).

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

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

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

Объект (называемый также экземпляром класса) - это единичная сущность, например, автомобиль Джона или счет Мери. Класс (или класс объектов) - это набор объектов с одинаковыми характеристиками, скажем счет, служащий, автомобиль, клиент.

Атрибут - это значение, хранящееся в объекте класса. У каждого объекта могут быть разные значения одного и того же атрибута.

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

Сокрытие информации - это базовая концепция объектно-ориентированного проектирования.^[2] Она используется при проектировании объектов и, в частности, при решении вопроса о том, какая информация должна быть доступной, а какая - скрытой. Те аспекты объекта, которые не должны быть видны другим объектам, прячутся. Следовательно, если в процессе развития внутреннее устройство объекта изменится, это отразится только на данном объекте. Для описания сокрытия объектом информации применяется термин инкапсуляция

Наследование - это механизм разделения и повторного использования одного и того же кода в разных классах. Класс-потомок наследует свойства (инкапсулированные данные и операции) от родительского класса. Но он может модифицировать структуру (то есть инкапсулированные данные) и поведение (операции) своего родителя. Родительский класс называется суперклассом или базовым классом, класс-потомок - подклассом или производным классом. Адаптация родительского класса для нужд потомка называется специализацией. Классы-потомки можно специализировать и дальше, создавая иерархии классов, или иерархии обобщения/специализации

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

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

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

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

2. Преимущества и недостатки объектно-ориентированного подхода.

Преимущества объектно-ориентированного можно выразить в следующем:

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

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

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

Недостатки объектно-ориентированного подхода можно выразить в следующем:

• Т.к. объектная декомпозиция сильно отличается от функциональной, поэтому переход на новый подход тесно связан как с дополнительными финансовыми затратами, так и с преодолением психологических трудностей
• Сложность реализации. Проекты, построенные с помощью объектно-ориентированного языке, приводят к построению более сложной и требовательной к ресурсам программы, в следствии чего требуют больших временных затрат. Поэтому классические методы для некоторых задач могут оказаться более эффективными
• Усложнение методологии. Применение данного подхода требует использования дополнительных наглядных способов представления информации об текущей области. Язык UML включает в себя более 100 условных обозначений. Поэтому использование данного инструмента требует наличие дополнительного уровня квалификации у сотрудников.
• На настоящий момент все еще продолжается формирование объектно-ориентированного языка моделирования UML, и по сравнению со средствами, поддерживающими структурный подход количество САSЕ-средств, поддерживающих объектно-ориентированный подход, невелико. Кроме того, диаграммы, отражающие специфику объектного подхода (диаграммы классов и т.п.), гораздо менее наглядны и плохо понимаемы непрофессионалами.

Структура и основные понятия унифицированного языка моделирования (UML)

Унифицированный язык моделирования (UML) стал в настоящий момент является стандартом де-факто при документировании (описания) результатов проектирования и разработки объектно-ориентированных систем.^[3] Начало разработки UML было положено в 1994 г. Гради Бучем и Джеймсом Рамбо, работавшим в компании Rational Software. Осенью 1995 г. к ним присоединился Ивар Якобсон и в октябре того же года была выпущена предварительная версия 0.8 унифицированного метода (англ. Unified Method). С этого времени было выпущено несколько версий спецификации UML, две из которых носят статус международного стандарта. Со временем нотация UML расширялась, и теперь в ней поддерживается много различных диаграмм. Далее я рассмотрю возможности нотации UML.

В нотации UML поддерживаются девять видов диаграмм:

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

2.1. Диаграммы прецедентов

Актер (actor) объявляет прецедент. Прецедент (use case) описывает последовательность взаимодействий между actor и системой. На диаграмме прецедентов Actor отображается в виде силуэта человека, система — в виде прямоугольника, а внутри этого прямоугольника эллипс — это прецедент. Actor связывается с прецедентами с помощью коммуникационных ассоциаций. Эти ассоциации могут иметь отношения extend (расширяет) и include (включает). Пример данной диаграммы представлен на рисунке 1.

Рисунок 1. Диаграммы прецедентов в нотации UML.

На рисунке 2 прямоугольниками показано как в UML изображаются классы и объекты. В прямоугольнике класса всегда вноситься имя этого класса. Дополнительно указываются атрибуты (параметры) и операции данного класса. Если присутствуют все три блока, то верхней части прямоугольника вписывают имя класса, в среднюю — атрибуты, а в нижнюю — операции. Чтобы отличить класс от объекта (экземпляра класса) его имя подчеркивается. Например объект может обозначаться как оbject, anotherObject:Class или :Class. Классы и объекты повсеместно встречаются в различных диаграммах UML

Рисунок 2. Объекты и классы в UML.

2.2. Диаграммы классов

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

Ассоциация, данная связь (бинарная ассоциация) между двух классов изображается в виде линий, соединяющей их прямоугольники. У нее имеется имя, и стрелка, объясняющая в каком направлении следует прочитать имя. На каждом конце ассоциативной связи отображается кратность — это число обозначающее, сколько экземпляров класса 'A' связано с одним экземпляром класса 'Б'. В дополнении, на каждом конце связи может присутствовать стрелка, указывающая вектор навигации вдоль текущей ассоциации. Возможны следующие кратности:

• 1 - ровно один,
• 0..1 - присутствие экземпляра класса необязательно,
• * - нуль или более,
• 1..* - один или более,
• m..n - точное задание числа экземпляров классов;

Рисунок 3. Нотация UML для связей на диаграмме классов

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

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

Видимость означает, доступен ли экземпляр класса вне самого класса. Пример отображен на рисунке 4. Изображение видимости на диаграмме является необязательным. Символом «+» (плюс), отображается открытая видимость, и она означает, что элемент виден извне класса. Символом «-» отмечается закрытая видимость, она свидетельствует, что элемент скрыт от других классов, и виден только внутри которого он был определен. Символ «#», говорит о том, что используется защищенная видимость, и значит, что элемент виден внутри класса, и во всех подклассах этого класса.

Рисунок 4. Обозначение видимости на диаграмме классов

2.3. Диаграммы взаимодействия

В ULM существуют следующие виды диаграмм взаимодействия: диаграммы кооперации (collaboration diagram) и диаграммы последовательности (sequence diagram). Они эквивалентны семантически. Далее представлены главные свойства данных диаграмм.

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

Рисунок 5. Диаграмма кооперации в нотации UML

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

Рисунок 6. Диаграмма последовательности в нотации UML

2.4. Диаграммы состояний

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

Рисунок 7. Диаграмма состояний. Надсостояние с последовательными подсостояниями.

Над дугой, показывающей переход, изображают условие перехода в виде «Событие [условие] / Действие». Событие влечет за собой переход в новое состояние. Если существует необязательное булевое условие, то переход будет осуществлен, только если оно истинно. В конце перехода может быть выполнено какое-либо действие. Вместе со состоянием ассоциируются:

• событие при входе в состояние,
• действие, выполняемое во время нахождения внутри состояния,
• событие при выходе из состояния;

На рисунке 7 изображено подсостоянние А, состоящих из двух последовательных подсостояний - А1 и А2. В данном случае диаграмма в определенный момент времени сможет находиться только в одном уникальном состоянии, то есть сначала будет выполнен вхож в подсостояние А1, а затем - в подсостояние А2. На рисунке 8 изображено надсостояние В, состоящих из двух параллельных подсостояний - ВС и BD. Здесь объект, описываемый диаграммой состояний, одновременно находится в каждом из подсостояний ВС и BD. Дальше оба параллельных подсостояний раскладываются на последовательные. В итоге, вход в надсостояние В сопровождается одновременным входом в подсостояния В1 и ВЗ.

Рисунок 8. Диаграмма состояний: надсостояние с параллельными подсостояниями

2.5. Пакеты

В нотации UML пакетом является группа элементов модели, которые используются в изображении системы или подсистемы. На рисунке 9 такая группа показана в виде большого прямоугольника, над которым находится прямоугольник поменьше — это так называется пиктограмма капки. Пакеты могут содержать классы, объекты, прецеденты. Они могут быть вложенными, также между ними может существовать отношения зависимости и обобщения или специализации.

Рисунок 9. Нотация UML для пакетов

2.6. Диаграммы параллельной кооперации

В нотации UML обычно объект либо задача показываются в форме прямоугольника с толстой границей. Активный объект обладает своим собственным потоком для управления и его исполнение происходит всегда параллельно с прочими объектами. В этом его главное отличие от объекта пассивного, который не наделен своим собственным потоком управления. Активизация пассивного объекта происходит только при условии, что другой объект (либо пассивный, либо активный) вызовет его операцию. Мы условно дадим имя активному объекту – задача, а пассивному – объект. Задачи обычно показываются на диаграммах параллельной кооперации, где можно наглядно показать параллелизм в системе. На подобной диаграмме задача представлена в виде прямоугольника с толстой границей. Пассивный объект показывается с помощью прямоугольника с тонкой гранью. На рисунке 10 показана также нотация для множества объектов, получающихся во время порождения нескольких объектов одного класса.

Рисунок 10. Пример активных и пассивных объектов

Интерфейс, с помощью которого происходит обмен сообщениями на диаграмме параллельной кооперации может представляться либо слабо связанным (loosely coupled), либо сильно связанным (tightly coupled).^[4] В виде сильно связанном – производитель отправляет сообщение потребителю для моментального подтверждения. Существует два вида сильно связанных обменов. Первый вид, когда имеет место сильно связанный обмен сообщениями с ответом или сильно связанный обмен сообщениями не имеющий ответа. Нотация UML для нескольких видов обмена сообщениями представлена на рисунке 11.

Рисунок 11. Нотация UML для сообщений

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

Рисунок 12. Нотация UML для параллельной диаграммы кооперации

А на рисунке 13 мы видим узлы двух разных видов. Первый – банкомат, в этом случае каждый подобный клиент использует только один узел. Он подключен к банковскому серверу. Тот в сою очередь находится также в одном узле. В кубе, где мы видим узел, могут быть также представлены объекты, которые находятся в данном узле. Второй вид – вид, в котором, несколько клиентов и серверов имеют связь по локальной сети, а данная сеть так же представлена в виде узла. Данная нотация применима в таких случаях, когда к сети подключены более двух узлов-компьютеров.

Рисунок 13. Нотация UML для диаграммы развертывания

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

2.7. Пример системы электронной коммерции спроектированной с помощью языка UML.

Система электронной коммерции представляет собой сильно распределенное приложение в среде World Wide Web. В предлагаемом решении в качестве посредников между клиентами и серверами будут применяться агенты. В задаче электронной коммерции есть покупатели и поставщики. Каждый покупатель имеет контракт на закупку с определенным поставщиком, а также один или несколько банковских счетов, с помощью которых он расплачивается. Каждый поставщик предоставляет каталог товаров, принимает заказы от покупателей и ведет с ними расчеты. Покупатель может просматривать размещенные в Internet каталоги поставщиков с помощью браузера и отбирать нужные ему товары. Заказ покупателя необходимо сверить с хранящимися документами, чтобы убедиться в наличии контракта, по которому будет производиться оплата. С каждым контрактом ассоциирован операционный лимит. Если контракт заключен и лимит не превышен, то создается заказ, который посылается поставщику. Поставщик подтверждает получение заказа и вводит планируемую дату отгрузки. Система следит за заказами и уведомляет поставщика и покупателя о задержке. При отгрузке заказа покупателю посылается извещение. Покупатель подтверждает получение заказа, после чего его состояние обновляется. Когда товар получен, дается разрешение на выставление счета-фактуры. Счет-фактура сверяется с контрактом, лимитом средств и состоянием заказа, затем производится оплата.

Рисунок 14. Система электронной коммерции. Прецеденты

Модель прецедентов для системы электронной коммерции изображена на рисунке 14. В ней есть три актера: «Покупатель», «Поставщик» и «Банк». Покупатель инициирует три прецедента: «Просмотреть Каталог», «Разместить Заявку» и «Подтвердить Доставку». Поставщик также инициирует три прецедента: «Обработать Заказ», «Подтвердить Отгрузку» и «Послать Счет-Фактуру.» Это основные прецеденты; менее значимые прецеденты, такие как запросы к серверам и отслеживание выполнения заказа, для краткости опущены. Опишем вышеупомянутые прецеденты. В прецеденте «Просмотреть Каталог» покупатель просматривает различные размещенные в Internet каталоги и выбирает из них товары. В прецеденте «Разместить Заявку» клиент отмечает товары из каталога и делает па них заявку. Система должна найти такой контракт покупателя с поставщиком, где есть достаточный операционный лимит. Если контракт найден, система авторизует заявку и посылает заказ поставщику. В прецеденте «Обработать Заказ» система находит заказ, проверяет, есть ли на складе нужное количество товара для его выполнения, и передает заказ поставщику. В прецеденте «Подтвердить Отгрузку» поставщик вручную формирует партию товаров и затем подтверждает ее отгрузку. В прецеденте «Подтвердить Доставку» покупатель подтверждает факт доставки товара. Из операционного лимита резервируется сумма для его оплаты. После того как доставка подтверждена, бухгалтерия покупателя дает разрешение на оплату, и в банк получателя уходит платежное поручение.

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

В системе электронной коммерции^[5] есть клиентские агенты двух типов: «Агент Покупателя» (один экземпляр для каждого покупателя) и «Агент Поставщика» (один экземпляр для каждого поставщика). Серверных агентов три, и каждый может существовать в нескольких экземплярах^[6]:

• «Агент Заявок», по одному экземпляру для каждой заявки;
• «Агент Заказов», по одному экземпляру для каждого заказа;
• «Агент Счетов-Фактур», по одному экземпляру для каждого счета-фактуры

«Агент Покупателя» - это клиентский агент, действующий от имени человека-покупателя. Он помогает покупателю, который хочет заказать товары по каталогу. «Агент» принимает запрос покупателя и взаимодействует с серверными агентами, которые берут на себя дальнейшую обработку заказа и отслеживание его состояния. «Покупатель» может выбрать из каталога несколько товаров. Когда выбор сделан, «Агент Покупателя» инициирует определенные действия от имени покупателя, в частности посылает запрос «Агенту Заявок». «Агент Заявок» - это серверный агент, который обращается к различным базам данных и взаимодействует с разными агентами для обработки размещенной покупателем заявки. Точнее, он получает информацию из баз данных заявок, контрактов и операционных лимитов, а также взаимодействует с «Агентом Покупателя». Базе данных заявок посылается сообщение с целью определить, имеется ли подходящий контракт. Из базы данных операционных лимитов серверный агент получает информацию о наличии необходимого лимита. Если ответы на оба запроса положительные, то «Агент Заявок» авторизует заявку и посылает ее статус «Агенту Покупателя», который, в свою очередь, направляет запрос. «Агенту Заказов». «Агент Поставщика» - это клиентский агент, предназначенный для работы с поставщиком. Он получает заказ у «Агента Заказов» и помогает поставщику его выполнить. «Агент» обновляет базу данных запасов и посылает статус заказа «Агенту Заказов» и «Агенту Покупателя». В конечном итоге покупатель подтверждает получение товара, и в заказе проставляется дата доставки. «Агент Поставщика» посылает счет-фактуру «Агенту Счетов-Фактур», находящемуся на стороне покупателя. Когда «Агент Счетов-Фактур «получает от «Агента Заказов» уведомление о получении товара, он обращается к базе данных контрактов и базе данных операционных лимитов. Если ответы положительны, то «Агент Счетов-Фактур» авторизует платеж и посылает счет-фактуру в базу данных счетов к оплате, а затем отправляет электронное платежное поручение в банк покупателя.

В этом приложении используется несколько унаследованных баз данных. Каждая из них автономна и хранится на большой ЭВМ. Необходимо интегрировать имеющиеся базы в единое приложение электронной коммерции с помощью брокеров объектов - таких, например, как предлагает технология CORBA^[7]. На стороне покупателя унаследованными будут базы данных контрактов, операционных лимитов, заявок, счетов-фактур и счетов к оплате. На стороне поставщика таковыми являются базы данных каталога, запасов и заказов. Чтобы все это интегрировать, серверные объекты, осуществляющие доступ к данным, должны быть обертками базы данных, то есть должны

инкапсулировать детали чтения и обновления конкретных баз. Соответствующие объекты-обертки таковы: «Сервер Заявок», «Сервер Контрактов», «Сервер Операционных Лимитов», «Сервер Счетов к Оплате», «Сервер Счетов-Фактур», «Сервер Каталогов», «Сервер Заказов» и «Сервер Запасов». Дополнительно, чтобы обеспечить слабую связанность клиентов, агентов и серверов, используется брокерская служба имен, цель которой - хранить информацию о местонахождении различных сервисов. Серверы и агенты регистрируются у брокера объектов. Когда требуется некий сервис, его расположение легко определить, послав запрос брокеру.

На рисунке 15 показано, как «Агент Покупателя» узнает у «Брокера» местонахождение серверного «Агента Заказов». После этого «Агент Покупателя» работает с «Агентом Заказов» напрямую.

Рисунок 15. Брокер объектов в системе электронной коммерции на базе агентов

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

наличие множества частных решений. Однако с помощью брокеров объектов и технологии оберток удается найти систематический подход к интеграции плохо совместимых баз. На рисунке 16 представлены классы для наиболее важных сущностей предметной области, а также связи между ними. В их число входят: «Заявка», «Контракт», «Операционный Лимит», «Платеж», «Счет-Фактура», «Каталог», «Заказ» и «Запасы». Атрибуты классов показаны на рисунке 17.

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

Рисунок 17. Классы в системе электронной коммерции на базе агентов

Для каждого прецедента разрабатывается диаграмма кооперации, на которой изображены объекты, принимающие участие в этом прецеденте, и последовательность сообщений, которыми они обмениваются. Модель кооперации для первого прецедента «Просмотреть Каталог» показана на рисунке 18.

В диаграмме кооперации для прецедента «Разместить Заявку» (рисунок 19) «Агент Заявок» посылает запрос «Серверу Контрактов» с целью выяснить, существует ли контракт. Затем он обращается с «Серверу Операционных Лимитов», чтобы узнать, выделен ли лимит. Если оба ответа положительны, то «Агент Заявок» авторизует заявку и передает ее статус «Агенту Покупателя», который отправляет запрос на закупку «Агенту Заказов».

Рисунок 18. Диаграмма кооперации для прецедента «Просмотреть Каталог»

Рисунок 19. Диаграмма кооперации для прецедента «Разместить Заявку»

В модели кооперации^[9] для прецедента «Обработать Заказ» (рисунок 20) «Агент Поставщика» просит у «Агента Заказов» новый заказ, а «Агент Заказов» выбирает заказ. «Агент Поставщика» проверяет уровень запасов и выводит заказ и информацию о запасах поставщику с помощью его интерфейса.

Рисунок 20. Диаграмма кооперации для прецедента «Обработать Заказ»

В диаграмме кооперации для прецедента «Подтвердить Отгрузку» (рисунок 21) поставщик вручную готовит партию товаров к отгрузке. Затем он подтверждает факт отгрузки, вводя необходимые данные, в том числе дату отгрузки. «Агент Поставщика» обновляет уровни запасов и передает статус заказа «Агенту Заказов» и «Агенту Покупателя», который отображает эти

сведения на экране.

Рисунок 21. Диаграмма кооперации для прецедента «Подтвердить Отгрузку»

В диаграмме кооперации для прецедента «Подтвердить Доставку» (рисунок 22) покупатель подтверждает факт получения товара и обновляет заказ, вписывая дату доставки. Кроме того, посылается извещение «Агенту Заявок».

Рисунок 22. Диаграмма кооперации для прецедента «Подтвердить Доставку»

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

Заключение

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

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

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

Список используемой литературы

1. ГОСТ 34.003-90. Автоматизированные системы. Термины и определения.
2. ГОСТ 34.601-90. Автоматизированные системы. Стадии создания.
3. ГОСТ Р ИСО/МЭК 12207–02. Информационная технология. Процессы жизненного цикла программных средств.
4. ГОСТ Р ИСО/МЭК 15271–02. Руководство по ИСО/МЭК 12207 (процессы жизненного цикла программных средств).
5. ОРММ ИСЖТ 2.01–00. Требования к составу, содержанию и оформлению документов при создании ИС. – М. : ВНИИАС МПС России, 2000. – 62 с.
6. ОРММ ИСЖТ 5.03–00. Процессы жизненного цикла ИС и программных средств – М. : ВНИИАС МПС России, 2000. – 48 с.
7. Баркер, Р. CASE*Method. Моделирование взаимосвязей между сущностями / Р. Баркер. – М., 2014. – 233 с.
8. Боггс, У. UML и Rational Rose / У. Боггс, М. Боггс. - М.: Издательство «ЛОРИ», 2015. - 582 с.
9. Буч, Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++ / Г. Буч. – М. : Бином, 2014. – 560 с.
10. Буч, Г. Язык UML. Руководство пользователя / Г. Буч, Дж. Рамбо, А. Якобсон. - СПб.: Питер, 2014. - 432 с.
11. Вендров, А.М. CASE-технологии. Современные методы и средства проектирования информационных систем / А.М. Вендров. – М. : Финансы и статистика, 2015. – 176 с.
12. Крачтен, Ф. Введение в Rational Unified Process / Ф. Кратчен. - М.: Издательский дом «Вильямс», 2016. - 240 с.
13. Ларман, К. Применение UML и шаблонов проектирования: Уч. Пос / К. Ларман. - М.: Издательский дом «Вильямс», 2014. - 496 с.
14. Леоненков, А.В. Самоучитель UML 2 / А.В. Леоненков. – СПб.: БХВ - Петербург, 2014. – 576с.
15. Орлов, С.А. Технологии разработки программного обеспечения: учеб. / С.А. Орлов. – СПб. : Питер, 2014. – 464 с.
16. Петров, В.И. Информационные системы / В.Н. Петров. – СПб. : Питер, 2013. – 688 с.
17. Терра-Лексикон: Иллюстрированный энциклопедический словарь. – М.: ТЕРРА, 2015. - 672 с.
18. Элиенс, А. Принципы объектно-ориентированной разработки программ / А. Элиенс. – М.: Издательский дом «Вильямс», 2014. – 496 с.
19. Якобсон, А. Унифицированный процесс разработки программного обеспечения / А. Якобсон, Г. Буч, Дж. Рамбо. - СПб.: Питер, 2014. - 496 с.
20. Леоненков, А.В. Визуальное моделирование в среде IBM Rational Rose. – www.intuit.ru
21. Леоненков, А.В. Объектно-ориентированный анализ и проектирование с использованием UML – www.intuit.ru
22. UML спецификация. – www.omg.com

1. Боггс, У. UML и Rational Rose / У. Боггс, М. Боггс. - М.: Издательство «ЛОРИ», 2015. - 582 с. ↑

2. Буч, Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++ / Г. Буч. – М. : Бином, 2014. – 560 с. ↑

3. UML спецификация. – www.omg.com ↑

4. Баркер, Р. CASE*Method. Моделирование взаимосвязей между сущностями / Р. Баркер. – М., 2014. – 233 с. ↑

5. ОРММ ИСЖТ 5.03–00. Процессы жизненного цикла ИС и программных средств – М. : ВНИИАС МПС России, 2000. – 48 с. ↑

6. Леоненков, А.В. Самоучитель UML 2 / А.В. Леоненков. – СПб.: БХВ - Петербург, 2014. – 576с. ↑

7. Якобсон, А. Унифицированный процесс разработки программного обеспечения / А. Якобсон, Г. Буч, Дж. Рамбо. - СПб.: Питер, 2014. - 496 с. ↑

8. Леоненков, А.В. Объектно-ориентированный анализ и проектирование с использованием UML – www.intuit.ru ↑

9. Леоненков, А.В. Объектно-ориентированный анализ и проектирование с использованием UML – www.intuit.ru ↑