Архитектура программного обеспечения для кубинского модуля инвентаризации ERP

Резюме

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

э.и.м.-сервис-ориентированная архитектура

Для достижения поставленной цели определения и описания архитектуры программного обеспечения было проведено исследование его элементов и современных тенденций в соответствии с наиболее престижными авторами по данному вопросу, а также опыт разработки системы управления запасами и Склады (СИГИЯ).

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

Ключевые слова

Архитектура программного обеспечения, стиль, шаблон, компонент, инфраструктура, сервис-ориентированная архитектура (SOA), веб-сервис, интеграция, планирование ресурсов предприятия (ERP), XML, SOAP, UDDI, WSDL.

Введение

С исчезновением социализма в Союзе Советских Социалистических Республик и усилением блокады США против Кубы в 1990-х годах кубинская экономика была парализована. В связи с этим страна нуждалась в процессе перестройки экономической политики. С тех пор начала осуществляться постепенная программа экономических мер с целью преодоления положения нации при минимальных социальных затратах.

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

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

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

Одним из наиболее важных процессов в планировании ресурсов компании являются системы инвентаризации, и поэтому он составляет прочную основу для разработки ERP-систем.

В современной экономике управление запасами достигло вершины проблем управления бизнесом, потому что это фундаментальный компонент производительности. Если запасы будут слишком высокими, это может привести к проблемам с финансовой ликвидностью. С другой стороны, если поддерживается недостаточный уровень запасов, клиенты могут не обслуживаться удовлетворительно, что приведет к снижению прибыли и убыткам на рынке (Sanchez, 2006). Таким образом, можно видеть, что поддержание здоровых запасов гарантирует любой компании и отрасли большую надежность при перемещении товаров на складе.

На Кубе существуют Системы управления запасами, среди которых: Система инвентаризации культурного и природного наследия (SIP), как следует из ее названия, была создана для целей наследия, таких как: регистрация, контроль и сохранение, Компьютеризированная система обработки инвентаризации леса (INVENFOR 1.0), созданная для регистрации и обработки данных, полученных из инвентаризации леса, для оценки дазометрических параметров древостоев таким образом, чтобы способствовать более эффективному планированию лесопользования эффективный. Другими примерами систем являются: DRIM, FONDUS, SI и IHMM 2000 от компании GET (Группа Электроники для Туризма), последняя с целью использования в гостиничных объектах.

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

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

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

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

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

Все вышеперечисленное привело к определению следующей проблемы:

Как принимать решения по проектированию на высоком уровне в процессе разработки системы управления запасами, которая позволяет ей быть масштабируемой, безопасной, переносимой и интегрируемой с другими системами управления бизнесом?

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

Определение как поле деятельности: Архитектура программного обеспечения для Системы управления запасами.

Исследование было выполнено с использованием следующих задач для достижения поставленной цели :

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

Для выполнения задач были использованы следующие методы:

Теоретические Методы

Историко-логическое: определить современные тенденции развития архитектурных моделей и подходов. Аналитический - Синтетический: для получения выводов в ходе исследования на основе информации, которая обрабатывается, и для определения характеристик предлагаемой архитектурной модели. Системный метод: определить элементы системы и их отношения.

Эмпирические методы

Измерение: для оценки времени отклика в критических ситуациях тематического исследования.

Возможные результаты

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

Настоящая работа состоит из трех глав

Глава 1: Теоретическое обоснование

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

Эпизод 2:

В этой главе предложено решение проблемы, поставленной в теоретическом плане исследования, оно дается в документе «Описание артефакта архитектуры», предложенном Университетом информатики для использования в продуктивных проектах.

Глава 3:

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

Глава 1: теоретическое обоснование

Введение

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

Состояние искусства архитектуры программного обеспечения

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

Точно так же Басс определяет это следующим образом: «Архитектура программного обеспечения компьютера или программной системы - это структура структур системы, которая включает компоненты программного обеспечения, свойства этих видимых извне компонентов и взаимосвязи среди них." (Pressman, 2002).

С другой стороны, определение, наиболее признанное многими архитекторами на международном уровне, облагается налогом промышленностью и относится к IEEE 1471, который цитирует таким образом: «Архитектура программного обеспечения - это фундаментальная организация системы, воплощенная в ее компонентах, отношениях между ними и окружающая среда и принципы, которые определяют ее дизайн и развитие ». (Рейносо, 2006).

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

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

1.2.1.2. Стиль

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

Эти классификации назывались различными способами, такими как: классы архитектуры, архитектурные типы, повторяющиеся архетипы, виды, топологические парадигмы, общие структуры и несколько десятков других. Уже более десяти лет эти архитектурные квалификации называются: стили или, альтернативно, архитектурные образцы. Стили проявляются только в описательной теоретической архитектуре с высоким уровнем абстракции; узоры везде. (Рейносо и др., 2004)

Первые явные определения стиля, по-видимому, были предложены Дьюэйном Перри и Александром Вольфом в октябре 1992 года. Они устанавливают рассуждения об архитектурных стилях как один из фундаментальных аспектов дисциплины. «Стиль - это описательная концепция, которая определяет форму артикуляции или архитектурной организации. Набор стилей каталогизирует возможные базовые формы программных структур, в то время как сложные формы формулируются посредством композиции фундаментальных стилей »(Perry, et al., 1992).

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

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

Можно сделать вывод, что:

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

1.2.1.3. Шаблон

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

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

Итак, в итоге, каркас - это скелет приложения, который должен быть адаптирован программистом в соответствии с его конкретными потребностями при разработке приложения.

1.2.2. тенденции

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

Предлагаемое разделение школ архитектуры ПО выглядит следующим образом:

Архитектура как этап инженерного и объектно-ориентированного проектирования. Очевидно, это будет Грэди Буч; Для него Архитектура программного обеспечения - это «логическая и физическая структура системы, созданная всеми стратегическими и тактическими решениями, которые применяются в процессе разработки». Другие определения показывают, что архитектура программного обеспечения, с этой точки зрения, касается решений об организации, выборе структурных элементов, поведении, композиции и архитектурном стиле, которые можно описать с помощью пяти классических представлений модели Крухтена 4 + 1. (Reynoso, 2006) Структурная архитектура, основанная на статической модели стилей, ADL и представлений, Представителями этой тенденции являются все ученые, в основном из Университета Карнеги, а также видение доминирующей архитектуры программного обеспечения в академии, и хотя именно оно предприняло наиболее важные усилия для признания архитектуры программного обеспечения дисциплина, ее категории и инструменты до сих пор плохо изучены в производственной практике. Внутри движения вы можете увидеть различные подразделения. Существует неформальный вариант «боксологии» и более формалистическая сторона, представленная группой Марка Морикони в НИИ в Менло-Парке. В принципе, три условия могут быть признаны с точки зрения формализации; более неформальные используют словесные описания или рамочные диаграммы,для тех, кто использует промежуточные символы, используются ADL, а наиболее требовательные используют формальные языки спецификации, такие как CHAM и Z. На всем протяжении нынешнего архитектурное проектирование не только является высшим уровнем абстракции, но и не должно совпадать с явная настройка приложений; ссылки на языки программирования или фрагменты кода встречаются редко, и вообще никто не говорит о классах или объектах. Хотя некоторые участники исключают модель данных из соображений архитектуры программного обеспечения (Шоу, Гарлан и т. Д.), Другие настаивают на ее актуальности (Медвидович, Тейлор). (Рейносо, 2006)ссылки на языки программирования или фрагменты кода встречаются редко, и вообще никто не говорит о классах или объектах. Хотя некоторые участники исключают модель данных из соображений архитектуры программного обеспечения (Шоу, Гарлан и т. Д.), Другие настаивают на ее актуальности (Медвидович, Тейлор). (Рейносо, 2006)ссылки на языки программирования или фрагменты кода встречаются редко, и вообще никто не говорит о классах или объектах. Хотя некоторые участники исключают модель данных из соображений архитектуры программного обеспечения (Шоу, Гарлан и т. Д.), Другие настаивают на ее актуальности (Медвидович, Тейлор). (Рейносо, 2006)Радикальный архитектурный структурализм. Это отрыв от предыдущего тренда, в основном европейского, который предполагает более конфронтационное отношение к миру UML. В рамках этого движения есть, по крайней мере, две тенденции: одна категорически исключает актуальность объектно-ориентированного моделирования для архитектуры программного обеспечения, а другая стремится определить новые метамодели и стереотипы UML как корректирующие ситуацию. (Reynoso, 2006) Архитектура, основанная на шаблонах, Признавая важность модели, исходящей из объектно-ориентированного проектирования, она не так тесно связана с UML в моделировании, как с CMM в методологии. Текст паттернов, который этот вариант распознает как ссылку, представляет собой серию POSA Бушмана и др., А во-вторых, текст Band of Four. Дизайн состоит из идентификации и формулирования уже существующих шаблонов, которые определяются аналогично архитектурным стилям. (Reynoso, 2006) Архитектура процесса, С начала 21-го века, в центре SEI и при участии некоторых архитекторов Карнеги-Меллона первого поколения и многих новых имен второго: Рик Казман, Лен Басс, Пол Клементс и другие. Он пытается установить модели жизненного цикла и методы выявления требований, мозгового штурма, проектирования, анализа, альтернативного выбора, проверки, сравнения, оценки качества и экономического обоснования, характерных для архитектуры программного обеспечения. (Reynoso, 2006) Архитектура на основе сценариев, Это новейший поток. Это преимущественно европейское движение с центром в Нидерландах. Он восстанавливает связь архитектуры программного обеспечения с требованиями и функциональными возможностями системы, иногда размытыми в классической структурной архитектуре. Диаграммы прецедентов UML часто используются в этом потоке в качестве неформального или случайного инструмента, поскольку прецеденты использования являются одним из возможных сценариев. Варианты использования не являются объектно-ориентированными. Авторами, связанными с этой модальностью, были, помимо кодировщиков ATAM, CBAM, QASAR и других методов SEI, голландские архитекторы Технического университета Эйндховена, Университета Брие, Университета Гронингена и Philips Research. (Рейносо, 2006)

1.2.3. Разница между архитектурой программного обеспечения и дизайном

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

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

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

Архитектура относится к более высокому уровню абстракции; имеет дело с компонентами, а не с процедурами; о взаимодействиях между этими компонентами, а не об интерфейсах; ограничений на компоненты и взаимодействия, а не алгоритмов, процедур и типов. Что касается композиции, то архитектура грубая, а дизайна - тонкая процедурная композиция; Взаимодействия между компонентами в архитектуре связаны с протоколом высокого уровня (в нетехническом смысле этого слова), в то время как в разработке рассматриваются взаимодействия процедурного типа (сообщения, обычные вызовы) (Perry, 1997).

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

Уровни абстракции архитектуры программного обеспечения

1.3.1. Архитектурные стили

1.3.1.1. Классификация стилей

Сколько и какие стили?

В исследовании, проведенном Мэри Шоу и Дэвидом Гарланом (Garlan et al., 1994), они предлагают следующую таксономию, в которой то, что ранее называлось «архитектурами», смешивалось с «моделями проектирования»:

Трубные фильтры Абстракция данных и организация объектно-ориентированного управления Неявный, основанный на событиях вызов Многоуровневые системы Репозитории Таблично-ориентированные интерпретаторы Распределенные процессы. Конкретной формой распределенного процесса является, например, архитектура клиент-сервер. Основные организации программы / подпрограммы. Архитектуры программного обеспечения для конкретных областей. Системы перехода между состояниями. Системы процессов управления. Гетерогенные стили.

В «Архитектуре программного обеспечения на практике», фундаментальном тексте Басса, Клементса и Казмана (Bass, et al., 1998), приведена систематизация классов стилей в пяти группах:

Поток данных (перемещение данных, без контроля получателем того, что происходит «вверх по течению»)
- Сетевые конвейерные фильтры последовательного потока данных
Вызов и возврат (стиль, в котором преобладают вычисления, обычно с одним потоком управления)
- Основная программа / подпрограммы Абстрактные типы данных Объекты Многоуровневые системы клиент-сервер на основе вызовов
Независимые компоненты (преобладают шаблоны связи между независимыми процессами, почти всегда параллельные)
- Событийно-ориентированные системы Коммуникационные процессы
Ориентированный на данные (доминирует сложное центральное хранилище, управляемое независимыми вычислениями)
- Доска хранилища
Виртуальная машина (характеризуется переводом инструкции в какую-то другую)
- переводчик

Стили, в отличие от шаблонов, немногочисленны, и они сгруппированы в классы стилей; наиболее актуальная и краткая классификация, принятая в ходе исследования, следующая (Reynoso, 2005):

Стили потока данных
- Труба и фильтры
Центрированные стили данных
- Архитектура сланца или хранилища
Стили звонка и возврата
- Многоуровневые архитектуры модель-представление-контроллер (MVC)Объектно-ориентированные архитектурыКомпонентные архитектуры
Стили мобильного кода
- Архитектура виртуальной машины
Гетерогенные стили
- Системы управления процессами Архитектура на основе атрибутов
Одноранговые стили
- Архитектуры на основе событийСервисно-ориентированные архитектуры (SOA) Ресурсные архитектуры

1.3.1.2. Самые популярные стили

В 1960-х и 1970-х годах было естественно структурировать приложение с точки зрения функциональных услуг, которые оно должно было предоставлять. Фактически, такие методологии, как анализ и структурированное проектирование, начинались с иерархической функциональной декомпозиции, которая позднее была преобразована в процедуры внутри приложения. С ростом сложности приложений и необходимости их развития, такого подхода было недостаточно. В 80-х и 90-х годах разработка объектно-ориентированного программного обеспечения стала популярной, стремясь, среди прочего, к созданию более обслуживаемых приложений. (Casallas и др., 2005)

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

Объектно-ориентированная архитектура

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

Компонентами этого стиля являются объекты, точнее, экземпляры абстрактных типов данных. В классической характеристике Дэвида Гарлана и Мэри Шоу объекты представляют класс компонентов, которые они называют менеджерами, потому что они несут ответственность за сохранение целостности своего собственного представления. Важной особенностью этого аспекта является то, что внутреннее представление объекта не доступно из других объектов. (Гарлан и др., 1994)

Согласно Билли Рейносо (Reynoso, et al., 2004), если обобщить характеристики объектно-ориентированных архитектур, можно сказать, что:

Компоненты стиля основаны на принципах ОО: инкапсуляция, наследование и полиморфизм. Они также являются единицами моделирования, проектирования и реализации, а объекты и их взаимодействия находятся в центре внимания при разработке архитектуры и структуры приложения.Интерфейсы отделены от реализаций. В общем, распределение объектов прозрачно, и в современном уровне техники не имеет значения, являются ли объекты локальными или удаленными. Наилучшим примером объектной ориентации для распределенных систем является архитектура Common Object Request Broker (CORBA), в которой интерфейсы определяются с использованием языка описания интерфейсов (IDL); Посредник запросов объектов обеспечивает взаимодействие между объектами клиента и объектами сервера в распределенных средах.Можно допустить, что интерфейс может быть реализован несколькими классами. Есть много вариантов стиля; например, некоторые системы позволяют объектам выполнять параллельные задачи; другие позволяют объектам иметь несколько интерфейсов.

Преимущество:

Вы можете изменить реализацию объекта, не затрагивая его клиентов. Объект является объектом многократного использования в среде разработки

Недостатки:

Чтобы взаимодействовать с другим объектом посредством процедурного вызова, его идентичность должна быть известна. Это создает проблемы каскадных побочных эффектов: если A использует B и C тоже использует его, влияние C на B может повлиять на A. Гранулярность очень хорошо для больших систем. Многоуровневая архитектура

Гарлан и Шоу определяют многоуровневый стиль как иерархическую организацию, так что каждый уровень предоставляет услуги непосредственно вышестоящему уровню и использует преимущества, предоставляемые непосредственно нижним уровнем (Reynoso, et al., 2004). (См. Приложение 2)

В многоуровневом стиле соединители определяются протоколами, которые определяют формы взаимодействия. Ограничения топологического стиля могут включать в себя более или менее строгое ограничение, которое требует, чтобы каждый уровень работал только со смежными уровнями, а элементы уровня понимались только с другими его элементами; если этот спрос ослаблен, стиль должен перестать быть чистым и потерять часть своих эвристических возможностей (MSDN, 2004); Естественно, возможность замены слоя без ущерба для остальных также естественным образом теряется, что снижает гибкость сборки и усложняет ее обслуживание.

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

преимущество

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

Недостатки

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

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

Есть несколько определений этого термина (программный компонент):

Согласно Крутчену, компонент является нетривиальной, почти независимой и заменяемой частью системы, которая выполняет функцию в контексте четко определенной архитектуры. Компонент соответствует набору интерфейсов и обеспечивает их физическую реализацию. (Браун и др., 1998 г.) Институт разработки программного обеспечения (SEI) Университета Карнеги-Меллона сформулировал определение с целью объединения различных мнений о том, каким должен быть программный компонент: «компонент - это реализация непрозрачный в функциональности, подчиненный сторонней компоновке и совместимый с компонентной моделью »(Bachmann, et al., 2000). Согласно Szyperski, программный компонент представляет собой составную единицу с контрактно заданными интерфейсами и только явными контекстными зависимостями,Программный компонент может быть развернут независимо и может быть составлен третьими лицами. (Шиперски, 2002).

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

Характеристики:

Одна из наиболее важных характеристик компонентов - их многократное использование. Для этого компоненты должны удовлетворять как минимум следующему набору характеристик:

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

Доминирующая оценка стиля компонента подчеркивает его большую универсальность по отношению к объектной модели, но также и его более низкую адаптивность по сравнению с сервис-ориентированным стилем (Reynoso, et al., 2004).

Преимущество:

Повторное использование программного обеспечения. Это приводит к более высокому уровню повторного использования программного обеспечения. Упростите тесты. Это позволяет выполнять тесты, тестируя каждый из компонентов перед тестированием полного набора собранных компонентов. Упростите обслуживание системы. В случае слабой связи между компонентами разработчик может обновлять и / или добавлять компоненты по мере необходимости, не затрагивая другие части системы. Более высокое качество. Поскольку компонент может быть создан, а затем постоянно совершенствоваться экспертом или организацией, качество приложения на основе компонентов со временем улучшится.

Недостатки:

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

Сервис-ориентированная архитектура (SOA) состоит из слабосвязанных и высоко совместимых сервисов приложений. Для связи друг с другом эти службы используют формальное определение, которое не зависит от платформы и языка программирования (например, WSDL: язык описания веб-служб). Определение интерфейса заключает в себе особенности реализации, делая ее независимой от производителя, языка программирования или технологии разработки (например, Java или.NET).

Предполагается, что с этой архитектурой разработанные программные компоненты можно многократно использовать, поскольку интерфейс определяется в соответствии со стандартом; таким образом, служба, разработанная в CSharp, может использоваться приложением Java.

Одна из наиболее выдающихся характеристик SOA заключается в том, что она основана на контрактах, в которых поставщик устанавливает правила связи, транспортировки и данные отправления и отправления, которыми будут обмениваться обе стороны. Чтобы увидеть больше характеристик SOA, см. (Приложение 3).

Что такое SOA?

SOA - это концептуальная архитектура, которая организует бизнес-функции в виде функционально совместимых сервисов, позволяет повторно использовать сервисы для удовлетворения потребностей бизнеса. SOA основывается на стандартах. Независимость от производителя. SOA - ИТ-стратегия уровня предприятия.

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

Что не является SOA

SOA как таковой не является:

Методология разработки проектов. Методология архитектуры бизнеса.

SOA как архитектурный стиль

Компонент: ServiceConnectors: раньше, RPC - сейчас, передача сообщений. Конфигурация: Распределенные ограничения (ограничение): низкая связь, независимость модели программирования, независимость от платформы, транспорт и протокол по отраслевому соглашению.

преимущество

Улучшить принятие решений.
- Единый панорамный. Больше информации с лучшим качеством.
Повысить производительность труда сотрудников.
- Оптимальный доступ к системам. Нет ограничений ИКТ
Укрепление отношений с клиентами и поставщиками.
- Большая отзывчивость к клиентам.
Более производительные и гибкие приложения. Более безопасные и более управляемые приложения.

Недостатки

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

1.3.2. Архитектурные Узоры

Существует широко используемая категоризация, разделенная на две наиболее распространенные системы шаблонных архитектур, которые являются одинаковыми: модель Pattern-Oriented Software Architecure (POSA) (Buschmann и др., 1996) и модель Pattern of Enterprise Application Architecture (PEAA).) (Фаулер и др., 2002).

POSA категории

В справочнике шаблонов архитектуры POSA шаблоны разделены следующим образом:

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

В (Приложение 4) показано распределение моделей POSA в перечисленных категориях, а затем в (Приложение 5) приведено краткое объяснение некоторых из них.

PEAA Категории

В PEAA (Fowler, et al., 2002) они описывают большое количество шаблонов, ориентированных на архитектуру бизнес-приложений.

Следующие категории шаблонов определены в PEAA:

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

В приложении 6 показано распределение образцов, определенных в PEAA, по категориям, указанным выше.

Термины «архитектурный паттерн» и «архитектурный стиль» часто путают, и многие из студентов дисциплины, кажется, не совсем понимают это. В целях четкого сравнения архитектурного стиля и архитектурного шаблона (Приложение 7) представлены некоторые различия между этими концепциями, построенными на основе этого подхода (Buschmann et al., 1996).

1.3.3. Отношения между уровнями абстракции

В (Приложение 8) показана взаимосвязь абстракции между понятиями архитектурного стиля, архитектурного шаблона и шаблона проектирования.

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

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

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

1.3.4. Каркасы

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

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

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

Каковы преимущества использования фреймворка?

Те, полученные из использования стандарта; среди прочего:

Программисту не нужно учитывать глобальную структуру приложения, но среда предоставляет каркас, который необходимо «заполнить». Это облегчает сотрудничество. Любой, кому приходилось бороться с исходным кодом другого программиста или даже со своим собственным, будет знать, насколько сложно его понять и изменить; следовательно, все, что определено и стандартизировано, сэкономит время и работу для совместных разработок. Легче найти инструменты (утилиты, библиотеки), адаптированные к конкретной среде для облегчения разработки.

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

Согласно одному из принципов безопасного программирования, почему бы не использовать уже определенные рамки и воспользоваться преимуществами работы других разработчиков? Другими словами, зачем изобретать велосипед? Если у вас есть что-то, что доказано, работает и работает, нет необходимости делать что-то, что делает то же самое, это не очень полезно и может привести только к осложнениям, таким как трата времени.

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

SOA: вызов современности

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

SOA стал наилучшим способом решения задачи увеличения объема работы с меньшими ресурсами. Это обещает значительно упростить повторное использование и интеграцию, помогая сократить время разработки и повысить гибкость организации. Неудивительно, что 80% ИТ-организаций внедряют приложения с использованием SOA с базовыми веб-сервисами. SOA обеспечивает большую гибкость, чтобы противостоять изменениям как в бизнес-среде, так и в технологической инфраструктуре »(Reynoso, 2005).

Gartner, ведущий поставщик исследований и анализа для мировой индустрии информационных технологий (IT), в 2003 году заявляет: «К 2008 году SOA станет преобладающей практикой разработки программного обеспечения, положив конец 40-летнему доминированию монолитных архитектур. (вероятность 0,7) »(Natis, 2003).

1.4.1. Причины использовать SOA

Есть несколько причин для принятия компанией SOA-подхода, в частности SOA-подхода, основанного на веб-сервисах:

Повторное использование: фундаментальным фактором при переходе на SOA является повторное использование бизнес-сервисов. Бизнес-функции внутри компании и с деловыми партнерами могут быть представлены в виде веб-сервисов и использованы повторно для удовлетворения новых потребностей бизнеса. Функциональная совместимость. Цель слабосвязанной архитектуры - взаимодействие клиентов и служб независимо от платформы, на которой они находятся. Протоколы связи с веб-сервисами не зависят от платформы, языка кодирования и операционной системы, что облегчает общение с деловыми партнерами. Масштабируемость: Поскольку службы SOA слабо связаны, приложения, использующие эти службы, легко масштабируются. Это связано с тем, что существует очень небольшая зависимость между клиентскими приложениями и службами, которые они используют. Гибкость: это еще одна особенность, которая обеспечивает слабую связь между сервисами. Любое изменение в реализации одного из них не повлияет на остальные, пока поддерживается интерфейс. Экономическая эффективность: архитектуры SOA основаны на возможности повторного использования существующих сервисов. Используя веб-сервисы для предоставления этих сервисов, существующая веб-инфраструктура используется повторно практически во всех организациях, что значительно ограничивает стоимость.

1.4.2. Элементы SOA

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

В Приложении 9 показаны элементы, которые можно наблюдать в сервис-ориентированной архитектуре. В нем можно выделить две области: одна охватывает функциональные аспекты архитектуры, а другая - аспекты качества обслуживания. Элементы кратко описаны ниже (Endrei, et al., 2004):

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

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

Приложение 10 иллюстрирует объекты (роли, операции и артефакты) в сервис-ориентированной архитектуре, где они сотрудничают.

Каждый субъект, показанный на диаграмме в (Приложение 10), может выполнять роль потребителя, поставщика и / или реестра:

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

Операции:

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

Наконец, артефакты в сервис-ориентированной архитектуре (Alvez, et al., 2006):

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

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

1.4.2.1. Типы услуг

Базовые сервисы: они могут быть ориентированы на данные или логику и включать такие функции, как сложные вычисления, доступ к данным и сложные бизнес-правила. Посреднические услуги: услуги адаптера, фасады и т. Д. Обычно это услуги без гражданства. Сервисы процессов: бизнес-сервисы, которые инкапсулируют логику процессов. Они имеют тенденцию сохранять состояние и могут находиться в инструментах BPM. Государственные услуги: услуги, доступные третьим лицам (вне организации).

Бизнес - услуг является компонентом повторного использования программного обеспечения, с полным функциональным смыслом, и который состоит из (Приложение 11):

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

1.4.3. Веб- сервисы

Сервисно-ориентированные архитектуры, в отличие от объектно-ориентированных архитектур, состоят из сильно взаимодействующих и слабо связанных сервисов приложений. Где эти сервисы можно рассматривать как эволюцию сложности распределенного компонента, отличающегося тем, чем они являются (Alvez, et al., 2006):

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

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

Веб-сервисы обмениваются приложениями, позволяя обмениваться информацией независимо от того, как они были созданы, на какой операционной системе или платформе они работают и какие устройства используются для доступа к ним. Связь характеризуется обменом сообщениями XML и независимостью от протокола связи. Для достижения этой независимости сообщение XML упаковывается соответствующим образом для каждого протокола благодаря созданию транспортного протокола SOAP (Simple Object Access Protocol: Simple Object Access Protocol). (Alvez, et al., 2006)

Язык описания веб-сервисов (WSDL), выраженный в XML, описывает, как получить доступ к сервису, какие у него функции, какие аргументы ему нужны и что возвращает каждый.

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

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

1.4.3.1. Ассоциированные технологии

WSDL

Язык описания веб-сервисов, родившийся в сентябре 2000 года Microsoft, IBM и Ariba, представляет собой стандарт для описания услуг Консорциума World Wide Web (W3C), организации, которая направляет разработку в Интернете. (Endrei и др., 2004)

По сути, WSDL - это контракт между поставщиком услуг и клиентом, в котором поставщик услуг указывает (Alvez, et al., 2006):

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

МЫЛО

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

Тот факт, что SOAP использует XML, имеет свои преимущества, такие как простота понимания людьми, но в то же время он имеет свои недостатки из-за того, что сообщения длиннее.

UDDI

Это центральный элемент группы стандартов, связанных с технологией веб-сервисов. Это посредник, через которого потенциальные клиенты знакомы с поставщиками услуг. Он определяет стандартный метод публикации и обнаружения сервисов в контексте SOA (Alvez, et al., 2006).

Спецификация UDDI родилась почти в то же время, что и спецификация WSDL, от тех же компаний. Текущая версия 3.0, спецификация, которая датируется августом 2003 года, находится под управлением Организации по развитию стандартов структурированной информации (OASIS). Реализация этих спецификаций называется «Регистрация UDDI», которая предоставляет набор веб-сервисов регистрации и консультаций через SOAP.

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

Структуры данных в UDDI

Информация, хранящаяся в записи UDDI, представляет собой набор так называемых «структур данных UDDI». Эти структуры в XML, определенные в спецификации, являются теми, которые клиент будет обмениваться с реестром UDDI. Каждый экземпляр этих структур уникально идентифицируется с помощью идентификатора, называемого универсальным уникальным идентификатором (UUID) (OASIS, 2004).

Основными структурами высокого уровня являются следующие (Alvez, et al., 2006):

BusinessEntity. Он содержит основную информацию о компании: контактное лицо, классификацию компании в соответствии с одной из определенных таксономий, а также описание деятельности компании на естественном языке. PublisherAssertion. Компания может заявить о своих отношениях с другими компаниями, например, в качестве партнеров или клиентов. Каждое из этих отношений моделируется как PublisherAssertion. БизнесСервис. Этот элемент показывает услуги, предлагаемые компанией. Эти сервисы могут быть или не быть веб-сервисами. BusinessEntity состоит из одного или нескольких элементов businessService, а элемент businessService может использоваться несколькими элементами BusinessService. BindingTemplate, Этот элемент содержит ссылки на технические описания (например, URL-адреса, указывающие на технические руководства) и URL-адреса доступа для веб-служб. Каждый элемент BusinessService может иметь один или несколько элементов BindingTemplate. TModel. Этот элемент описывает, как вы взаимодействуете с веб-сервисом и его поведение. Среди его данных - URL, где находится документ WSDL. Здесь также могут отображаться категории, в которые может быть включена служба (они могут отличаться от тех, которые могут отображаться в BusinessEntity).

1.4.4. Состав услуг

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

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

Состав услуг включает в себя поиск механизма, который позволяет двум или более из них сотрудничать друг с другом для решения требований, которые выходят за рамки их индивидуальных возможностей. Вот некоторые из основных требований, которые должны быть выполнены (Alvez, et al., 2006):

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

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

оркестровка

Процесс можно рассматривать как оркестровку службы, когда он полностью контролируется одним объектом. Этот процесс полностью определяет взаимодействия со службами компонентов и логику, необходимую для правильного проведения этих взаимодействий. Этот тип процесса можно понимать как частный и исполняемый, поскольку только объект, который управляет процессом, знает поток управления и информацию, которая следует за процессом, который организуется. Таким образом, создается процесс, который использует разные сервисы, манипулируя информацией, которая течет между ними, преобразуя, например, выходные данные одних сервисов во входные данные другого. Здесь каждая участвующая организация реализует и контролирует свой собственный процесс (Cubillos, et al., 2004).

Хореография

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

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

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

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

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

Веб-сервис SOA if (Reynoso, 2005):

Интерфейсы основаны на веб-протоколах (HTTP, SMTP, FTP). Сообщения основаны на XML.

1.4.6. Модель зрелости SOA

Что такое модель зрелости?

Это позволяет измерить текущее состояние бизнес-архитектуры с точки зрения использования SOA и позволяет определить путь эволюции.

Почему модель зрелости?

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

Модель зрелости, предложенная в этом разделе, состоит из пяти уровней: начальные сервисы, архитектурные сервисы, бизнес-сервисы, сотрудничество, бизнес-метрики и бизнес-оптимизация. Эти уровни позволят масштабировать прибыль от SOA, поскольку в архитектурах этого типа она снижается до большего (см. Приложение 12). Эта модель зрелости предложена Progress Software Corporation, известной компанией-разработчиком программного обеспечения, занимающейся предоставлением платформ для бизнес-приложений, включая SOA и интеграционные инфраструктуры. У него есть продукты на рынке программного обеспечения, признанные, среди прочего, как SONIC ESB.

ADL и UML

ADL

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

Они предоставляют конструкции для указания архитектурных абстракций и механизмов для разложения системы на компоненты и соединители, определяя, как эти элементы объединяются для формирования конфигураций и определяя семейства архитектур или стилей. (Рейносо и др., 2004)

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

Некоторые из преимуществ, которые предлагает ADL:

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

Несмотря на все вышесказанное, можно сказать, что ADL удобны, но они еще не доказали свою важность, особенно из-за постоянства UML, теперь с версией 2.0 (Reynoso, et al., 2004).

UML

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

Несмотря на то, что он вообще не квалифицировался как ADL, было доказано, что он может использоваться не столько как ADL сам по себе, сколько как метаязык для моделирования других ADL, в частности C2 и Wright (Reynoso, et al., 2004).

В UML они идентифицируют:

Элементы (абстракции, которые составляют основные строительные блоки) Отношения (Связать элементы) Диаграммы (Графическое представление набора элементов)

UML предоставляет нотацию для описания проекции компонентов программного обеспечения в аппаратном обеспечении, соответствующую физическому представлению модели Крухтена 4 + 1 для описания программных архитектур (Kruchten, 1999).

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

Качество в программной архитектуре

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

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

Следует отметить, что нефункциональные требования также называют качественными атрибутами. Атрибут качества - это характеристика качества, которая влияет на предмет. Где термин «характеристика» относится к нефункциональным аспектам, а термин «элемент к компоненту» (Gómez, 2007).

Методы оценки

Существует группа методов оценки, которые подразделяются на качественные и количественные (Брей и др., 2005) (см. Приложение 13):

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

В целом, методы качественной оценки используются, когда архитектура находится в стадии разработки, а методы количественной оценки используются, когда архитектура уже внедрена (Gómez, 2007).

За какие качества можно оценить архитектуру?

Вообще говоря, Басс устанавливает классификацию качественных признаков в двух категориях (Камачо и др., 2004):

Наблюдаемые через выполнение: те атрибуты, которые определяются поведением системы во время выполнения. Описание некоторых из этих атрибутов представлено в (Приложение 14). Не наблюдается через исполнение: те атрибуты, которые устанавливаются при разработке системы. Описание некоторых из этих атрибутов представлено в (Приложение 15).

Какие результаты дает оценка архитектуры?

После того, как оценка проведена, должен быть подготовлен отчет. Это должно быть представлено как предварительный документ, чтобы его могли исправить люди, которые участвовали в оценке. Содержание отчета отвечает на два типа вопросов (Гомес, 2007):

Была ли разработана наиболее подходящая архитектура для системы? Какая из предложенных архитектур наиболее подходит для построения системы?

Помимо ответов на эти вопросы, в отчете также говорится:

Степень соответствия атрибутов качества Приоритетный список атрибутов качества, необходимых для оцениваемой архитектуры Риски, а не риски

Сегодня существует несколько методов оценки архитектуры программного обеспечения, которые проверяют соответствие или нет определенных атрибутов качества, некоторые из которых являются более конкретными, чем другие, такие как: метод анализа компромисса архитектуры (ATAM), Bosch (2000), Active Design Review (ADR), Активные обзоры для промежуточного дизайна (ARID), Losavio (2003).

Существуют и другие методы оценки архитектуры, которые оценивают определенный атрибут качества, такие как: анализ изменчивости уровня архитектуры (ALMA), оценка производительности архитектуры программного обеспечения (PASA), анализ юзабилити на уровне архитектуры (SALUTA) и анализ выживаемости сети (SNA)., Независимо от того, насколько конкретным или нет может быть метод оценки, у подавляющего большинства есть что-то общее: метод сценария используется как способ проверки того, в какой степени архитектура реагирует на атрибуты качества, требуемые системой.

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

Взаимосвязь между архитектурой программного обеспечения и атрибутами качества

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

Каждое решение, включенное в архитектуру программного обеспечения, может потенциально влиять на атрибуты качества (Bass, et al., 2000). Таким образом, можно сказать, что принятие таких решений обычно имеет такие последствия, как:

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

Взаимосвязь, которая существует между атрибутами качества и архитектурой программного обеспечения, имеет несколько преимуществ (Camacho и др., 2004):

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

Частичные выводы

Из целей, предложенных для этой главы, можно сделать следующие выводы:

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

Деловые партнеры: лицо или компания, которая является совладельцем компании или компании, другими словами, является партнером компании, к которой принадлежит ее часть.

Скачать оригинальный файл