А.М. Вендров - Объектно-ориентированный анализ и проектирование, страница 12

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кооперация имеет статическую и динамическую части.В статической части (на диаграмме классов) описываются роли, которыемогут играть объекты и связи в экземпляре данной кооперации.Динамическая часть состоит из одной или более диаграмм взаимодействия,показывающих потоки сообщений, которыми обмениваются участникикооперации. Кроме того, любой образец содержит стандартную диаграммуклассов под названием "Participants" ("Участники"), на которой63изображается сам образец в виде кооперации с его именем и наборклассов, участвующих в реализации образца.В качестве примера приведем образец бизнес-моделирования подназванием Employment (Занятость).Проблема заключается в моделировании различных форм занятости впределах организации. Данная задача решается в контексте системыпланирования ресурсов предприятия.Решение: занятость моделируется как контракт между личностью иорганизацией, указывающий выполняемые обязанности, контрактныеусловия, даты начала и конца работы.

Личность характеризуется набороматрибутов (имя, адрес и дата рождения), может занимать более чем однудолжность в одной и той же организации.На рис. 1.24 приведена диаграмма "Участники" для данного образца.Она содержит кооперацию Employment и набор из пяти классов:Employee Profile (Служащий) - описание служащего с набороматрибутов.Organization Profile (Организация) - описание самой организации.Employment (Занятость) - описание связи между служащим иорганизацией.Position (Должность) - описание должности со своими атрибутами(такими, как должностной оклад и должностные инструкции).Position Assignment (Назначение на должность) - описание связимежду служащим и занимаемыми должностями.<<business entity>>Employment<<business entity>>Employee Profile<<business entity>>Organization ProfileM<<pattern>>Employment<<business entity>>Position Assignment<<business entity>>PositionРис.