Язык XPath и его применение для доступа к элементам XML

XPath -используется для произвольного выбора узлов из документов XML.

XPath (XML Path Language) — язык запросов к элементам XML-документа. Разработан для организации доступа к частям документа XML в файлах трансформации XSLT и является стандартом консорциума W3C. XPath призван реализовать навигацию по DOM в XML. В XPath используется компактный синтаксис, отличный от принятого в XML.

Для реализации этой первоочередной цели он также предоставляет основные средства оперирования строками, числами и логическими значениями. XPath обладает компактным, отличным от XML синтаксисом для облегчения его применения в идентификаторах URI и значениях атрибутов XML. XPath работает с абстрактной, логической структурой XML-документа, а не с его внешним синтаксисом. XPath получил свое имя благодаря тому, что для навигации по иерархической структуре XML-документа в нем используется нотация пути (path), как в идентификаторах URI».

XPath - это синтаксические правила для выделения различных частей XML-документа

XPath для выделения XML-элементов использует выражения в виде путей (path)

XPath имеет библиотеку стандартных функций

XPath - важная составляющая часть XSLT

XPath для своих выражений не использует формат XML

XPath является стандартом W3C

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

w3schools/xpath/default.asp

В XPath имеется библиотека стандартных функций для работы со строками, числами и булевскими выражениями.

Следующее выражение XPath выделяет все элементы cd, у которых дочерний элемент price имеет значение больше, чем 10.80:

/catalog/cd[price>10.80]

Фазы, итерации и циклы разработки. Рабочие процессы, модели и артефакты.

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

· Начало(inception) - определение бизнес-целей проекта.

· Исследование (elaboration) - разработка плана и архитектуры проекта.

· Построение (construction) - постепенное создание системы. В фазе построения постепенно и итеративно разрабатывается продукт, готовый к внедрению.

· Внедрение (transition) - поставка системы конечным пользователям.

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

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

Рабочие процессы

Рациональный Унифицированный Процесс состоит из девяти рабочих процессов:

· моделирование бизнес-процессов - описывается структура и динамика организации;

· разработка требований - описывается основанный на прецедентах метод постановки требований;

· анализ и проектирование - описываются различные виды архитектуры системы;

· реализация - собственно разработка программ, автономное тестирование и интеграция;

· тестирование - описываются тестовые сценарии, процедуры и метрики для измерения числа ошибок;

· развертывание - охватывает конфигурирование поставляемой системы;

· управление конфигурацией - управление изменениями и поддержание целостности артефактов проекта;

· управление проектом - описывает разные стратегии работы с итеративным процессом;

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

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

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

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

модель бизнес-процессов - формализует абстракцию организации;

модель предметной области - формализует контекст системы;

модель прецедентов - формализует функциональные требования к системе;

аналитическая модель (необязательная) - формализует идею проекта;

проектная модель - формализует словарь предметной области и области решения;

модель процессов (необязательная) - формализует механизмы параллелизма и синхронизации в системе;

модель развертывания - формализует топологию аппаратных средств, на которых выполняется система;

модель реализации - описывает части, из которых собирается физическая система;

модель тестирования - формализует способы проверки и приемки системы.

18. Совместная разработка: Методы и средства тестирования и отладки программных приложений

Тестирование программного обеспечения (Software Testing) - это одна из техник контроля качества, включающая в себя активности по планированию работ (Test Management), проектированию тестов (Test Design), выполнению тестирования (Test Execution) и анализу полученных результатов (Test Analysis).

— Ручное тестирование

— Автоматизированное тестирование

— Смешанное тестирование

Существует несколько методов тестирования:

Тестирование программ методом "чёрного ящика" (Black box testing)

Тестирование софта методом "белого ящика" (White box)

Тестирование ПО методом "серого ящика" (Grey box)

Тестирование не функциональных аспектов программы.

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

При тестировании белого ящика, разработчик теста имеет доступ к исходному коду программ и может писать код, который связан с библиотеками тестируемого ПО. Это типично для юнит-тестирования (англ. unit testing), при котором тестируются только отдельные части системы. Оно обеспечивает то, что компоненты конструкции — работоспособны и устойчивы, до определённой степени. При тестировании белого ящика используются метрики покрытия кода.

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

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

САТ бывают платными (Rational, Mercury, Segue, etc) и бесплатными (Winstress, Netbench, IOMeter, etc).

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

19. Особенности модель распределённых объектов. Модель RPC.

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

Особенности при использовании удаленных объектов, не встречавшихся в удаленном вызове процедур. 1. в системах, использующих удаленные объекты, сериализации подвержены как параметры метода и его результат, так и выбрасываемые при выполнении удаленного метода исключения. 2. в качестве параметра или результата методов могут тоже передаваться ссылки на удаленный объект, если вызывающий удаленный метод клиент также может являться сервером. При использовании удаленных объектов проблемными являются вопросы о времени их жизни: в какой момент времени создается экземпляр удаленного объекта и в течение какого промежутка времени он существует. Для описания жизненного цикла два дополнительных понятия: активация объекта: процесс перевода созданного объекта в состояние обслуживания удаленного вызова, то есть связывания его с каркасом и посредником. деактивация объекта: процесс перевода объекта в неиспользуемое состояние. Выделяют три модели использования удаленных объектов – модель единственного вызова (singlecall, для каждого вызова удаленного метода объекта клиентом на сервере создается и активируется новый экземпляр объекта, который деактивируется и затем удаляется сразу после завершения удаленного вызова метода объекта.Набор объектов, ожидающих своей активации, называется пулом объектов, достигается баланс между скоростью и ресурсами), модель единственного экземпляра (singleton удаленный объект существует не более чем в одном экземпляре. Он существует, пока есть хоть один использующий его клиент. Нет состояния, высокая производительность), а так же модель активации объектов по запросу клиента (client activation При каждом создании клиентом ссылки на удаленный объект на сервере создается новый объект, который существует, пока клиент не удалит ссылку на посредника. вызовы клиентов изолированы друг от друга, объект сохраняет свое состояние между вызовами, наименее рациональное использование памяти). Первых две модели так же иногда называют моделями серверной активации (server activation), хотя, строго говоря, активация всегда происходит на сервере после какого-либо запроса от клиента.

Идея вызова удаленных процедур (Remote Procedure Call - RPC) состоит в расширении известного механизма передачи управления и данных внутри программы, выполняющейся на одной машине, на передачу управления и данных через сеть.

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

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