Файл: Архитектура информационных.pdf

53
 единый способ получения экземпляров объектов: в системе обеспечивается механизм создания объектов без необходимости идентификации определенных типов классов в программном коде;
 простота создания объектов: разработчик полностью избавлен от необходимости написания большого и сложного программного
Кода для получения экземпляра объекта;
 учет ограничений при создании объектов.
Паттерны параллельного программирования ориентированы на обеспечение корректного взаимодействия асинхронно протекающих процессов и ориентированы на решение двух основных задач (совместное использование ресурсов и управление доступом к ресурсам):
 совместное использование ресурсов. Если конкурирующие операции обращаются к одним и тем же данным или к общему ресурсу, то они могут конфликтовать друг с другом, если эти операции осуществляют доступ к ресурсу в один и тот же момент.
Чтобы обеспе чить корректное выполнение таких операций, их нужно ограничить таким образом, чтобы доступ к общему ресурсу в конкретный момент времени получала только одна операция, однако чрезмерное ограничение операций может привести к их взаимной блокировке;
 управление доступом к ресурсам. Если операции получают доступ к общему ресурсу одновременно, возникает необходимость в том, чтобы они обращались к общему ресурсу в определенном порядке, например, объект не может быть удален из структуры данных до тех пор, пока данный объект не будет добавлен в некоторую другую структуру данных.
Для разных типов паттернов могут использоваться разные способы описания. Чаще всего используется описание, предложенное в [16], в соответствии с которым полное описание паттерна выглядит следующим образом:

54
 название и тип;
 назначение;
 другие названия (если имеются);
 мотивация — какие проблемы можно решить с помощью данного паттерна;
 условия, при которых целесообразно применять данный паттерн;
 структура паттерна (в объектно-ориентированной нотации);
 объекты и паттерны, используемые в данном паттерне;
 результаты работы паттерна;
 рекомендации по применению;
 пример кода;
 примеры использования;
 родственные паттерны.
Как указывалось выше, паттерны — это классы проверенных практикой проектных решений, использование которых приводит к положительным результатам.
Вместе с паттернами существуют так называемые антипаттерны.
Антипаттерны (antipatterns), также известные как ловушки (pitfalls) — это классы наиболее часто внедряемых плохих решений проблем. Они изучаются как категория, в случае, когда их хотят избежать в будущем, и некоторые отдельные случаи их могут быть распознаны при изучении неработающих систем [1].
Частью хорошей практики программирования является избегание антипаттернов.
Данная концепция также прекрасно подходит к машиностроению, строительству и другим отраслям. Несмотря на то что термин нечасто используется вне программной инженерии, концепция является универсальной.
Следует отметить, что общепринятой классификации антипаттернов не существует. Применительно к ИС можно выделить следующие типовые группы антипаттернов: в управлении разработкой ПО, антипаттерны в разработке

55
ПО,
в
объектно-ориентированном
проектировании,
в
области
программирования, методологические и организационные антипаттерны.
6. ФРЕЙМВОРКИ
Фре́ймворк, иногда фреймво́рк (англицизм, неологизм от framework
«остов, каркас, структура») — заготовки, шаблоны для программной платформы, определяющие структуру программной системы; программное обеспечение, облегчающее разработку и объединение разных модулей программного проекта.
Уместно использование термина «каркас». Некоторые авторы используют его в качестве основного, не опираясь на англоязычный аналог. Можно также говорить о каркасном подходе, как о подходе к построению программ, где любая конфигурация программы строится из двух частей:
1. Постоянная часть — каркас, не меняющийся от конфигурации к конфигурации и несущий в себе гнёзда, в которых размещается вторая, переменная часть;
2. Сменные модули (или точки расширения).
«Фреймворк» отличается от понятия библиотеки тем, что библиотека может быть использована в программном продукте просто как набор подпрограмм близкой функциональности, не влияя на архитектуру программного продукта и не накладывая на неё никаких ограничений.
«Фреймворк» же диктует правила построения архитектуры приложения, задавая на начальном этапе разработки поведение по умолчанию — «каркас», который нужно будет расширять и изменять согласно указанным требованиям.
Пример программного фреймворка — C.M.F. (Content Management Framework), а пример библиотеки — модуль электронной почты.
Также, в отличие от библиотеки, которая объединяет в себе набор близкой функциональности, «фреймворк» может содержать большое число разных по тематике библиотек.

56
Другим ключевым отличием «фреймворка» от библиотеки может быть инверсия управления: пользовательский код вызывает функции библиотеки
(или классы) и получает управление после вызова. Во «фреймворке» пользовательский код может реализовывать конкретное поведение, встраиваемое в более общий — «абстрактный» код фреймворка. При этом
«фреймворк» вызывает функции (классы) пользовательского кода.
Фреймворк программной системы - это каркас программной системы
(или подсистемы). Может включать: вспомогательные программы, библиотеки кода, язык сценариев и другое ПО, облегчающее разработку и объединение разных компонентов большого программного проекта. Обычно объединение происходит за счёт использования единого API.
В качестве примеров можно указать веб-каркасы, такие как Rocket на
Rust, Zend Framework и Symfony на PHP, Django, написанный на Python.
Одно из главных преимуществ при использовании «каркасных» приложений — «стандартность» структуры приложения. «Каркасы» стали популярны с появлением графических интерфейсов пользователя, которые имели тенденцию к реализации стандартной структуры для приложений. С их использованием стало гораздо проще создавать средства для автоматического создания графических интерфейсов, так как структура внутренней реализации кода приложения стала известна заранее. Для обеспечения каркаса обычно используются техники объектно-ориентированного программирования
(например, части приложения могут наследоваться от базовых классов фреймворка).
Одним из первых коммерческих фреймворков приложения был MacApp, написанный Apple для Macintosh. Первоначально созданный с помощью расширенной (объектно-ориентированной) версии языка Object Pascal, впоследствии он был переписан на С++. Другие популярные каркасы для
Macintosh включали:
Metrowerks PowerPlant и MacZoop (все основаны на Carbon);
WebObjects от NeXT.

57
В различной степени фреймворки приложения представляют собой Cocoa для Mac OS X, а также свободные фреймворки, существующие как часть проектов Mozilla, OpenOffice.org, GNOME и KDE.
Реализация фреймворка. «Фреймворк» определяется как множество конкретных и абстрактных классов, а также определений способов их взаимоотношения. Конкретные классы обычно реализуют взаимные отношения между классами. Абстрактные классы представляют собой точки расширения, в которых каркасы могут быть использованы или адаптированы.
Точка расширения — это та «часть» фреймворка, для которой не приведена реализация. Соответственно, каркас концептуальной модели состоит из концептуальных классов, а каркас программной системы — из классов языка программирования общего назначения.
Процесс создания фреймворка заключается в выборе подмножества задач проблем и их реализаций. В ходе реализаций общие средства решения задач заключаются в конкретных классах, а изменяемые средства — выносятся в точки расширения.
Microsoft создала похожий продукт для Windows, который называется
Microsoft Foundation Classes (MFC). На данный момент основным продуктом
Microsoft для разработки ПО предлагается .NET Framework.
Кроссплатформенными каркасами приложений (для операционных систем Linux, Macintosh и Windows) являются, например, widget toolkit, wxWidgets, Qt, MyCoRe[de] или FOX toolkit.
Фреймворки и паттерны имеют много общего и, в первую очередь, — это подходы к повторному использованию кода. Различие между паттернами и фреймворками состоит в следующем. Фреймворк можно рассматривать как реализацию системы паттернов проектирования (поведенческих паттернов). В то время как фреймворк — это исполняемая программа, а паттерн — это знание и опыт как решать конкретную задачу.
Еще одно отличие фреймворка от паттерна состоит в том, что фреймворк представляет собой скелетное решение достаточно крупной задачи и обычно

58 включает в себя большое количество как паттернов, так и компонентов. Кроме того, фреймворки могут использовать подклассы и другие механизмы.
Фреймворки можно классифицировать по месту применения в ИТ- системе, способу использования и масштабу применения [9].
По месту применения фреймворки можно разделить на три типа: инфраструктурные фреймворки (System Infrastructure Frameworks);
фреймворки уровня промежуточного ПО (Middleware Frameworks); фреймворки, ориентированные на приложения, относящиеся к конкретному предметному домену (Enterprise
Application
Frameworks), архитектурные фреймворки.
Использование
инфраструктурных фреймворков упрощает разработку инфрастуктурных элементов, таких как, например операционные системы. Обычно такие фреймворки используются внутри организации и не поступают в продажу.
Фреймворки уровня промежуточного ПО используются для интеграции распределенных приложений и компонентов.
Фреймворки, ориентированные на приложения, используются, в первую очередь, для поддержания процесса разработки систем, ориентированных на конечного пользователя и принадлежащих некоторому конкретному предметному домену.
Международный стандарт ISO/IEC 42010 определяет архитектурный
фреймворк как «совокупность соглашений, принципов и практик, используемых для описаний архитектур и принятых применительно к некоторому предметному домену и (или) в сообществе специалистов
(заинтересованных лиц)»[21].
Типовой архитектурный фреймворк включает в себя следующие основные элементы: типовые для домена заинтересованные лица; типовые для домена проблемы; архитектурные точки зрения; правила интеграции различных точек зрения.
Можно выделить два типовых подхода к использованию фреймворков:
 по принципу белого ящика;
 по принципу черного ящика.

59
Кроме того, возможно использование гибридных подходов, которые называют серым ящиком.
Фреймворки, используемые по принципу белого ящика, называют также архитектурными фреймворками (architecture-driving framework). Эти фреймворки применяют наследование и динамическое связывание для формирования скелета приложения. Фреймворк, работающий по принципу белого ящика, определяется через интерфейсы объектов, которые разработчик может добавлять в систему. Основным недостатком данного подхода является то, что для того чтобы работать с фреймворками, необходимо иметь подробную информацию о классах, которые будут расширяться.
Фреймворки, используемые по принципу черного ящика, называют также фреймворками, управляемыми данными. При использовании фреймворков данного типа в качестве основных механизмов формирования приложения выступают композиция компонентов и параметризация. При этом требуемая функциональность достигается посредством добавление в фреймворк дополнительных компонентов. В общем случае работать с фреймворками, использующими принцип черного ящика, проще, чем с фреймворками, реализующими принцип белого ящика, но их разработка является более сложной.
Большинство реальных фреймворков используют комбинацию рассмотренных выше подходов и их называют
фреймворками,
используемыми по принципу серого ящика (grey-box).
По масштабу применения фреймворки можно разделить на три группы: фреймворки уровня приложений, фреймворки уровня домена (организации), вспомогательные фреймворки.
Фреймворки
уровня
приложения
(application
frameworks) обеспечивают полный набор функций, которые реализуются типовыми приложениями. Обычно сюда входят GUI, базы данных, документация.
Примером таких фреймворков могут быть MFC (Microsoft Foundation Classes),

60 которые служат для создания приложений, ориентированных на работу в среде
MS Windows.
Фреймворки уровня домена (Domain frameworks) используются для создания приложений, относящихся к определенному предметному домену.
В качестве домена может выступать как информационная система, включающая несколько взаимодействующих между собой приложений, например, системы сбора и обработки телеметрической информации, поступающих от сложной технической системы, так и целой организации, в качестве которой могут выступать, например, промышленные корпорации, органы государственной власти, правительственные ведомства и т. п.
В последнем случае речь идет о фреймворках уровня организации
(enterprise). Термин «организация» понимается в самом широком смысле и включает коммерческие и некоммерческие организации, целые корпорации и их подразделения, различного рода ассоциации типа совместных предприятий и т.д. Следует особо отметить, что термин «организация» включает в себя такие элементы, как людей, собственно бизнес, информацию, технологии, а не только информационную систему.
Фреймворки уровня домена можно классифицировать по следующим признакам:
 назначению;
 принципам построения;
 гибкости при использовании;
 условиям распространения.
Возможны различные концептуальные подходы к построению фреймворков, в частности, ключевым элементом фреймворка может быть онтология. В основу фреймворка может быть положен тот или иной процесс разработки или ориентация на данные (данноцентри- ческий подход), фреймворк может быть ориентирован на эффективную поддержку сетевых взаимодействий.

61
Вспомогательные фреймворки (Support frameworks) ориентированы на решение частных задач, таких как управление памятью или файловой системой.
Фреймворки могут распространяться на коммерческой основе либо быть бесплатными для некоммерческого использования. Кроме того, фреймворк может быть ориентирован на использование внутри организации.
С точки зрения возможности реконфигурирования и возможности настройки на конкретное применение фреймворки можно разделить на
«жесткие» и «гибкие». Жесткие фреймворки не предусматривают возможности настройки, а гибкие — разрешают настраивать фреймворк для решения конкретной задачи. Жесткие фреймворки могут требовать использовать конкретный инструментарий и конкретную методологию проектированию.
7. СЕРВИСНО-ОРИЕНТИРОВАННЫЕ АРХИТЕКТУРЫ (СОА) И WEB-
СЕРВИСЫ ИНФОРМАЦИОННЫХ СИСТЕМ
Сервисно-ориентированные архитектуры. Сервисно-ориентированная архитектура СОА (service-oriented architecture, SOA) — это подход к созданию
ИС, основанный на использовании сервисов или служб (service). Сервис и службу можно рассматривать как синонимы. СОА — это, в первую очередь, интеграционная архитектура, использование которой позволяет обеспечить гибкую интеграцию
ИС.
При использовании
СОА приложения взаимодействуют, вызывая сервисы, входящие в состав других приложений.
Сервисы объединяются в более крупные последовательности, реализуя бизнес- процессы, которые могут быть доступны как сервисы.
СОА можно рассматривать так же как подход к построению слабосвязанных
(loosely coupled) систем, реализующих механизмы асинхронного взаимодействия. К слабосвязанным системам обычно относятся такие системы, как электронная почта и системы очередей сообщений.
Сервисы можно рассматривать как строительные блоки, которые могут использоваться для построения как сервисов более высокого уровня, так и

62 законченных распределенных ИТ-систем. Сервисы могут вызываться независимо внешними или внутренними потребителями для выполнения элементарных функций либо могут объединяться в цепочки для формирования более сложных функций и для быстрого создания новых функций.
При использовании СОА организации могут создавать гибкие КИС, которые позволяют оперативно реализовывать быстро изменяющиеся бизнес- процессы и многократно использовать одни и те же компоненты в рамках одной ИТ-системы, в рамках семейств продуктов и в независимых ИТ- системах.
Сервисом можно назвать любую дискретную функцию, которая может быть предложена внешнему потребителю. В качестве сервиса может выступать как отдельная бизнес-функция, так и набор функций, которые образуют бизнес- процесс.
СОА не принуждает пользователя использовать конкретный протокол для доступа к сервису. Идея заключается в том, что сервис не определяется используемым протоколом, напротив, описание сервиса составляется независимым от протокола способом, позволяющим использовать для доступа к сервису разные протоколы. В идеале служба определяется только один раз при помощи интерфейса службы и должна иметь несколько реализаций для работы с разными протоколами доступа. Такой подход позволяет максимально расширить возможности повторного использования сервиса [2, 3, 4].
Web-сервисы. В самом общем виде понятие Web-сервиса можно определить как сервис (услугу), которая предоставляется через WWW с использованием языка XML и протокола HTTP.
Практически все ведущие ИТ-компании положительно относятся к использованию Web-сервисов, поэтому Web-сервисы можно использовать в качестве механизма интеграции приложений, реализованных на любых платформах. Существует много разных определений понятия Web-сервиса.
В качестве «официального» определения можно рассматривать определение, которое дается консорциумом W3C: