ПаттернIterator (итератор). Cursor (курсор)
Предоставляет способ последовательного доступа ко всем элементам составного объекта, не раскрывая его внутреннего представления.
Структура паттерна представлена.
Iterator - итератор; определяет интерфейс для доступа и обхода элементов;
Concretelterator - конкретный итератор; - реализует интерфейс класса Iterator; - следит за текущей позицией при обходе агрегата;
Aggregate - агрегат:- определяет интерфейс для создания объекта-итератора;
ConcreteAggregate - конкретный агрегат:- реализует интерфейс создания итератора и возвращает экземпляр подходящего класса Concretelterator.
У паттерна итератор есть следующие важные особенности:
поддерживает различные виды обхода агрегата. Сложные агрегаты можно обходить по-разному. Например, для генерации кода и семантических проверок нужно обходить деревья синтаксического разбора. Генератор кода может обходить дерево во внутреннем или прямом порядке. Итераторы упрощают изменение алгоритма обхода - достаточно просто заменить один экземпляр итератора другим. Для поддержки новых видов обхода можно определить и подклассы класса Iterator;
итераторы упрощают интерфейс класса Aggregate. Наличие интерфейса для обхода в классе Iterator делает излишним дублирование этого интерфейса в классе Aggregate. Тем самым интерфейс агрегата упрощается;
одновременно для данного агрегата может быть активно несколько обходов. Итератор следит за инкапсулированным в нем самом состоянием обхода. Поэтому одновременно разрешается осуществлять несколько обходов агрегата.
ПаттернMediator (посредник)
Определяет объект, инкапсулирующий способ взаимодействия множества объектов. Посредник обеспечивает слабую связанность системы, избавляя объекты от необходимости явно ссылаться друг на друга и позволяя тем самым независимо изменять взаимодействия между ними.
Структура
Mediator посредник:- определяет интерфейс для обмена информацией с объектами С;
ConcreteMediator конкретный посредник: - реализует кооперативное поведение, координируя действия объектов C;
Классы C, A, B. Каждый из таких классов "знает" о своем объекте Mediator; - все объекты этих классов обмениваются информацией только с посредником, так как при его отсутствии им пришлось бы общаться между собой напрямую
У паттерна посредник есть следующие достоинства и недостатки:
устраняет связанность между подклассами С. Изменять классы C и Mediator можно независимо друг от друга;
упрощает протоколы взаимодействия объектов. Посредник заменяет дисциплину взаимодействия «все со всеми» дисциплиной «один со всеми», то есть один посредник взаимодействует со всеми подклассами С. Отношения вида «один ко многим» проще для понимания, сопровождения и расширения;
абстрагирует способ кооперирования объектов. Выделение механизма посредничества в отдельную концепцию и инкапсуляция ее в одном объекте позволяет сосредоточиться именно на взаимодействии объектов, а не на их индивидуальном поведении. Это дает возможность прояснить имеющиеся в системе взаимодействия;
централизует управление. Паттерн посредник переносит сложность взаимодействия в класс-посредник. Поскольку посредник инкапсулирует протоколы, то он может быть сложнее отдельных С. В результате сам посредник становится монолитом, который трудно сопровождать.
ПаттернObserver (наблюдатель).Dependents (подчиненные), Publish-Subscribe (издатель-подписчик).
Определяет зависимость типа один ко многим между объектами таким образом, что при изменении состояния одного объекта все зависящие от него оповещаются об этом и автоматически обновляются.
Структура и участники
Subject - субъект: располагает информацией о своих наблюдателях. За субъектом может «следить» любое число наблюдателей; так же субъект предоставляет интерфейс для присоединения и отделения наблюдателей;
Observer- наблюдатель: определяет интерфейс обновления для объектов, которые должны быть уведомлены об изменении субъекта;
ConcreteSubject - конкретный субъект: сохраняет состояние, представляющее интерес для конкретного наблюдателя ConcreteObserver; посылает информацию своим наблюдателям, когда происходит изменение;
ConcreteObserver - конкретный наблюдатель; Хранит ссылку на конкретного субъекта для получения доступа к состоянию последнего.
ПаттернState (состояние)
Позволяет объекту варьировать свое поведение в зависимости от внутреннего состояния. Извне создается впечатление, что изменился класс объекта.
ПаттернStrategy (стратегия). Policy (политика) .
Определяет семейство алгоритмов, инкапсулирует каждый из них и делает их взаимозаменяемыми. Стратегия позволяет изменять алгоритмы независимо от клиентов, которые ими пользуются.
ПаттернTemplateMethod (шаблонный метод).
Шаблонный метод определяет основу алгоритма и позволяет подклассам переопределить некоторые шага алгоритма, не изменяя его структуру в целом.
39. Разработка программной архитектуры и кодирование приложений на основе лучших типовых решений.Методы качественной разработки и усовершенствования программного кода. Понятия эффективности и качества программного обеспечения (ПО).
Чтобы понять, как проектировать конкретное программное решение, очень важно знать, как связаны между собой каркасы и шаблоны. Стандартное определение каркасов — наборы взаимосвязанных классов для многократно используемого проектирования определенного класса программного обеспечения [Гамма и др., 1995 г.]. Рабочий термин в определении — «класс программного обеспечения». Под этим подразумевается, что он выполняет определенную функцию в рамках программного решения. Каркасы часто основываются на шаблонах — универсальных решениях задачи с программной реализацией в определенном контексте. Основное различие между каркасами и шаблонами заключается в том, что каркасы являются реализацией программных конструкций, а шаблоны задают определение того, как решить ту или иную задачу с программной реализацией.
Смысл применения основанных на шаблонах каркасов в том, что они обеспечивают согласованность всего решения и могут повысить продуктивность. В динамичной среде с их помощью можно сделать решение более расширяемым. Кроме того, каркасы позволяют свести к минимуму объем кода, необходимого для реализации решения, благодаря чему решение легче сопровождать. Что еще важнее, используемые для создания каркасов шаблоны создают общий лексикон в организации разработчиков, в силу чего намного легче донести до других суть проекта.
Тем, у кого меньше опыта работы с программными шаблонами, может быть непонятно, как их применение поможет ускорить выпуск продукта. Но те, кто на своем опыте видел повышение продуктивности за счет использования каркасов в течение жизненного цикла решения, обычно являются приверженцами такого подхода. Правда, некоторые уважаемые профессионалы в области программного обеспечения предпочитают не создавать каркасы на ранней стадии цикла разработки продукта, а реструктурировать решение, после того как некоторая часть первоначального функционала уже реализована. Другие отраслевые специалисты считают, что если архитектор хорошо знаком со сферой применения, то можно выполнить предварительную структуризацию (prefactoring) приложения и создать каркасы в рамках первоначального выпуска. Зная, что схема продукта не должна измениться в обозримом будущем, я решил заранее структурировать решение и построить каркасы на базе основных абстракций решения.
План исполнения
Понимание направления разработки архитектуры лишь отчасти помогало в решении задачи. Главное, что я должен был сделать, — это довести архитектуру до момента, когда ее сможет утвердить руководство и по ней может быть начата разработка программного обеспечения. Для этого требовалась способность формулировать и четко излагать архитектуру. Зная, что разработка должна быть выполнена в кратчайшие сроки, я предпринял следующие шаги:
1. Определил границы системы
2. Определил структуру решения
3. Определил каркасы
4. Сопоставил функциональные требования с каркасами
Чтобы максимально использовать преимущества шаблонов архитектуры и проектирования программного обеспечения, архитектор всегда должен стараться найти ответ на следующие вопросы.
· Какую задачу мне нужно решить?
Поймите концепцию задачи, для которой предназначено проектируемое решение. Архитектура программного обеспечения начинается на концептуальном уровне, и архитектор обязательно должен охватывать картину в целом. Способность лаконично изложить решение в нетехнических терминах является хорошим показателем понимания области решения задачи.
· Как такая задача была решена в прошлом?
Для любого программного решения велика вероятность того, что похожая задача уже была решена в прошлом. Узнайте, как решалась эта задача, и по возможности примените тот же проект для решения новой задачи.
· Как может это решение расширяться в будущем?
Многие шаблоны задуманы так, чтобы обеспечить определенный уровень расширяемости для решения. Если требования к расширяемости решения понятны, может быть полезным применить такие шаблоны на ранней стадии проектирования.
40. Методы и средства конструирования высококачественного кода. Качественное использование переменных и данных.
Рефакторинг — процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы. В основе рефакторинга лежит последовательность небольших эквивалентных (то есть сохраняющих поведение) преобразований. Рефакторинг позволяет разрабатывать архитектуру программы постепенно, откладывая проектные решения до тех пор, пока не станет более ясной их необходимость.
Цель рефакторинга — сделать код программы более легким для понимания.
Рефакторинг нужно применять постоянно при разработке кода.
Можно выделить наиболее очевидные причины, когда код нужно подвергнуть рефакторингу:
· Дублирование кода
· Длинный метод
· Большой класс
· Длинный список параметров и др.
В программировании термин рефакторинг означает изменение исходного кода программы без изменения его внешнего поведения.
Наиболее употребимые методы рефакторинга:
· Инкапсуляция поля (EncapsulateField)
· Выделение класса (ExtractClass)
· Выделение интерфейса (ExtractInterface)
· Выделение локальной переменной (ExtractLocalVariable)
· Выделение метода (ExtractMethod)
· Встраивание (Inline)
Ка́чествопрогра́ммного обеспечения — характеристика программного обеспечения (ПО) как степени его соответствия требованиям.
Качество кода может определяться различными критериями. Многие из имеющихся стандартов оформления кода, определяющих специфичные для используемого языка соглашения и задающие ряд правил, улучшающих читаемость кода, имеют своей целью облегчить будущее сопровождение ПО, включающее отладку и обновление. Структурированность — степень логического разбиения кода на ряд управляемых блоков.
Фактор качества ПО — это нефункциональное требование к программе, которое обычно не описывается в договоре с заказчиком, но, тем не менее, является желательным требованием, повышающим качество программы.
Некоторые из факторов качества:
· Понятность
· Краткость
· Портируемость
· согласованность
· Сопровождаемость
· Тестируемость
· Структурированность
· Эффективность
· Безопасность и др.
Эффективность программного обеспечения - отношение уровня услуг, предоставляемых программным продуктом пользователю при заданных условиях, к объему используемых ресурсов.
Эффективность ПС обеспечивается принятием подходящих решений на разных этапах его разработки, начиная с разработки его архитектуры. Особенно сильно на эффективность ПС (особенно по памяти) влияет выбор структуры и представления данных.
41. Совместная разработка: методы и средства.
42. Методы и средства тестирования и отладки программных приложений.
Тестирование программного кода - процесс выполнения программного кода, направленный на выявление существующих в нем дефектов. Задача тестирования при таком подходе - определение условий, при которых проявляются дефекты системы, и протоколирование этих условий. Цель применения процедуры тестирования программного кода - минимизация количества дефектов (в особенности существенных) в конечном продукте.
Методы тестирования
a) Черный ящик
Основная идея в тестировании системы как черного ящика состоит в том, что все материалы, которые доступны тестировщику, - требования на систему, описывающие ее поведение, и сама система, работать с которой он может, только подавая на ее входы некоторые внешние воздействия и наблюдая на выходах некоторый результат. Все внутренние особенности реализации системы скрыты от тестировщика, - таким образом, система представляет собой "черный ящик", правильность поведения которого по отношению к требованиям и предстоит проверить.
b) Стеклянный (белый) ящик
При тестировании системы как стеклянного ящика тестировщик имеет доступ не только к требованиям к системе, ее входам и выходам, но и к ее внутренней структуре - видит ее программный код.
c) Тестирование моделей
Тестирование моделей находится несколько в стороне от классических методов верификации программного обеспечения. Причина прежде всего в том, что объект тестирования - не сама система, а ее модель, спроектированная формальными средствами. Если оставить в стороне вопросы проверки корректности и применимости самой модели, то тестировщик получает в свое распоряжение достаточно мощный инструмент анализа общей целостности системы. На модели можно создать такие ситуации, которые невозможно создать в тестовой лаборатории для реальной системы. Работая с моделью программного кода системы, можно анализировать его свойства и такие параметры системы, как оптимальность алгоритмов или ее устойчивость.
d) Анализ программного кода (инспекции)
Во многих ситуациях тестирование поведения системы в целом невозможно - отдельные участки программного кода могут никогда не выполняться, при этом они будут покрыты требованиями. Примером таких участков кода могут служить обработчики исключительных ситуаций. Если, например, два модуля передают друг другу числовые значения и функции проверки корректности значений работают в обоих модулях, то функция проверки модуля-приемника никогда не будет активизирована, т.к. все ошибочные значения будут отсечены еще в передатчике.
В этом случае выполняется ручной анализ программного кода на корректность, называемый также просмотрами или инспекциями кода. Если в результате инспекции выявляются проблемные участки, то информация об этом передается разработчикам для исправления наравне с результатами обычных тестов.
Отладка – это комплексный процесс по выявлению и исправлению дефектов в программном обеспечении. Сами же дефекты, обычно, обнаруживается в процессе тестирования ПО.
Отладка состоит из следующих этапов:
- воспроизведение дефекта (любым из доступных способов);
- анализ дефекта (поиск причины возникновения дефекта – root-cause);
- дизайн исправления дефекта (и возможно ревью, если есть альтернативы);
- кодирование исправления дефекта (и какие-либо активности связанные с кодированием);
- валидация исправления;
- интеграция исправления в кодовую базу или целевую систему;
- дополнительные валидации после интеграции (если необходимости).
Методы отладки ПО, используемые на данный момент в индустрии перечислены ниже.
1) Запуск программы изпод отладчика с пошаговой отладкой, просмотром состояний в требуемых точках исполнения программы.
2) Логирования кода – вывод в файл (или консоль и т.п.) входных, выходных аргументов функций, промежуточных состояний в процессе исполнения программы.
3) Анализ кода без исполнения программы – поиск причин возникновения дефекта с помощью анализа исходного кода программы, проблемного контента, конфигурации, состояния базы данных и т.п.
4) Анализ поведения системы или её части (в т.ч. в более простыхuse-case-ах) – изолирование проблемы, путём упрощения сценария (используя ручное или автоматическое тестирование).
5) Unit тестирование – выполнение автоматических unittest-ов в основном изолировано для функций, и таким образом автоматическое выявление проблемных участков кода.
6) Прототипирование – проверка функций (модулей, библиотек, и т.п.) в изоляции с помощью небольших примеров кода (прототипов).
7) Отладка с помощью memory-dump-ов или crash-дампов (применимо в основном для анализа паник) – разновидность логирования кода, только здесь логируется не просто некая структура памяти, а целиком вся память процесса и состояния регистров, когда возникает exception.
8) Отладка с помощью перехватов (hook-ов, spy-ев) – в основном используется в случаях утечки ресурсов, разновидность логирования кода.
9) Профилирование кода (если необходима оптимизация производительности) – разновидность логирования кода, хотя часто выполняется с использованием специализированных инструментальных средств (профилировщиков).
10) Выполнения программы (или её части) в другой среде (операционной системе, эмуляторе, симуляторе) – основная идея в том, что если нет инструментальных средств на целевой платформе, то можно спортировать код на другую платформу, где они есть.
11) Отладка методом RPC (remoteprocedurecall) – применимо в основном для встроенного программирования.
12) Отладка путём анализа документации, дизайна, требований или ограничений модулей (программных или аппаратных) – применимо в основном для сложных и крупных проектов.
13) Отладка трансляцией кода – сложный алгоритм пишется или прототипируется на одном языке программирования
14) Отладка разработкой интерпретатора - это не только метод отладки, но и паттерн проектирования.
43. Рефакторинг и оптимизация программного кода.
Рефакторинг - это переписывания программного кода, с целью исправления ошибок, улучшения быстродействия.
Рефакторинг — процесс изменения программного кода, при котором не меняется его внешнее поведение, но улучшается внутренняя структура. Рефакторинг может проводиться в самых разных целях — для улучшения читабельности кода, устранения ошибок и улучшения дизайна программной архитектуры приложений. Однако вне зависимости от первоначальных целей рефакторинга, в результате вы получаете максимально понятный, читабельный, масштабируемый и стабильный программный код.
Рефакторинг или рефакторирование (англ. refactoring) — процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы[1]. В основе рефакторинга лежит последовательность небольших эквивалентных (то есть сохраняющих поведение) преобразований. Поскольку каждое преобразование маленькое, программисту легче проследить за его правильностью, и в то же время вся последовательность может привести к существенной перестройке программы и улучшению её согласованности и четкости.
Цель рефакторинга — сделать код программы легче для понимания; без этого рефакторинг нельзя считать успешным.
Рефакторинг следует отличать от оптимизации производительности. Как и рефакторинг, оптимизация обычно не изменяет поведение программы, а только ускоряет её работу. Но оптимизация часто затрудняет понимание кода, что противоположно рефакторингу
С другой стороны, нужно отличать рефакторинг от реинжиниринга, который осуществляется для расширения функциональности программного обеспечения. Как правило, крупныерефакторинги предваряют реинжиниринг.
Рефакторинг нужно применять постоянно при разработке кода. Основными стимулами его проведения являются следующие задачи:
необходимо добавить новую функцию, которая недостаточно укладывается в принятое архитектурное решение;
необходимо исправить ошибку, причины возникновения которой сразу не ясны;
преодоление трудностей в командной разработке, которые обусловлены сложной логикой программы.
В программировании термин рефакторинг означает изменение исходного кода программы без изменения его внешнего поведения. В экстремальном программировании и других гибких методологиях рефакторинг является неотъемлемой частью цикла разработки ПО: разработчики попеременно то создают новые тесты и функциональность, то выполняют рефакторинг кода для улучшения его логичности и прозрачности. Автоматическое юнит-тестирование позволяет убедиться, что рефакторинг не разрушил существующую функциональность.
Иногда под рефакторингом неправильно подразумевают коррекцию кода с заранее оговоренными правилами отступа, перевода строк, внесения комментариев и прочими визуально значимыми изменениями, которые никак не отражаются на процессе компиляции, с целью обеспечения лучшей читаемости кода (см. codeformatting).
Рефакторинг изначально не предназначен для исправления ошибок и добавления новой функциональности, он вообще не меняет поведение программного обеспечения[2] и это помогает избежать ошибок и облегчить добавление функциональности. Он выполняется для улучшения понятности кода или изменения его структуры, для удаления «мёртвого кода» — всё это для того, чтобы в будущем код было легче поддерживать и развивать. В частности, добавление в программу нового поведения может оказаться сложным с существующей структурой — в этом случае разработчик может выполнить необходимый рефакторинг, а уже затем добавить новую функциональность.
Это может быть перемещение поля из одного класса в другой, вынесение фрагмента кода из метода и превращение его в самостоятельный метод или даже перемещение кода по иерархии классов. Каждый отдельный шаг может показаться элементарным, но совокупный эффект таких малых изменений в состоянии радикально улучшить проект или даже предотвратить распад плохо спроектированной программы.
44. Сборка, внедрение и поставка ПО.
45. Технологии и средства развертывания, наладки и обслуживания проектов.
Внедрение ПО
После приобретения, установки и начального ознакомления с программным продуктом необходимо выполнить внедрение программы, то есть запустить в эксплуатацию. Перечень работ по внедрению, их объем и стоимость всегда определяется индивидуально с каждым клиентом. Этот выбор зависит от масштабов внедрения, сроков, уровня подготовки пользователей и бюджета проекта.
Можно выделить три основные технологии внедрения ПОот которых мы отталкиваемся при составлении индивидуального плана работ для Вашей компании: экспресс-внедрение, стандартное внедрение, проектное внедрение.
Экспресс-внедрение
Экспресс-внедрение направлено на максимально "быстрый старт" информационной системы, что возможно на небольших предприятиях при использовании типового функционала наших программных продуктов. В данном случае бизнес-процессы Вашей компании полностью подстраиваются под процессы, реализованные в типовом прикладном решении.
Экспресс-внедрение проходит в 3 этапа:
1. Поставка программного продукта (платформа и типовое ПО).
2. Обучение пользователей.
3. Запуск ПО в эксплуатацию.
Стандартное внедрение
Стандартное внедрение — наиболее востребованная технология внедрения. Это объясняется использованием типового прикладного решения, возможно с небольшими доработками, с поэтапным внедрением необходимого функционала и, как следствие, предельно возможной скоростью внедрения и минимальными затратами для предприятия.
При таком варианте внедрения адаптируется функционал программного продукта в части наиболее уникальных для компании Заказчика бизнес-процессов, в остальном бизнес-процессы компании подстраиваются под процессы, реализованные в типовом прикладном решении.
Стандартное внедрение проходит в 7 этапов:
1. Поставка программного продукта (платформа и типовое ПО).
2. Обучение пользователей.
3. Составление технического задания на доработку типового ПО.
4. Доработка типового решения.
5. Передача ПО в опытную эксплуатацию.
6. Отладка системы.
7. Запуск ПО в промышленную эксплуатацию.
Проектное внедрение
Использование Проектной технологии позволяет создать комплексную автоматизированную систему управления (АСУ) организацией для максимально эффективной поддержки бизнес-процессов Заказчика.
Результатом применения Проектной технологии является соответствие реализуемых задач Проекта ожиданиям Заказчика, когда Заказчик получает действенный инструментарий для ведения, планирования, управления и развития бизнеса в соответствии со своими целями.
Проектное внедрение проходит в 8 этапов:
1. Разработка технического задания на создание.
2. Поставка программного продукта (платформа и типовое ПО).
3. Разработка и тестирование.
4. Обучение пользователей.
5. Перенос данных из предыдущих систем.
6. Передача в опытную эксплуатацию.
7. Отладка системы.
8. Запуск в промышленную эксплуатацию.
9. Сборка проекта
Данная работа состоит из следующих задач применительно к каждому программному объекту архитектуры (или объекту программной конфигурации, если он определен):
Разработчик должен разработать план сборки для объединения программных модулей и компонентов в программный объект. План должен включать требования к испытаниям (тестированию), процедуры тестирования, контрольные данные, обязанности исполнителя и программу испытаний. План должен быть документально оформлен.
Разработчик должен собрать программные модули и компоненты и протестировать их как продукты, разработанные в соответствии с планом сборки. Должно быть обеспечено, чтобы каждая сборка удовлетворяла требованиям к программному объекту и чтобы программный объект был полностью собран в результате данной работы. Результаты сборки и тестирования должны быть документально оформлены.
Разработчик, при необходимости, должен уточнить документацию пользователя.
Разработчик должен разработать и документально оформить для каждого квалификационного требования к программному объекту - набор тестов, контрольных примеров (исходные и выходные данные, критерии тестирования), процедуры испытаний для проведения квалификационных испытаний программных средств. Разработчик должен обеспечить, чтобы собранный программный объект был готов к квалификационным испытаниям.
Разработчик должен оценить план сборки, проект, запрограммированный программный объект, проведенные испытания, результаты тестирования и документацию пользователя по следующим критериям (при этом результаты оценок должны быть документально оформлены):
a) учет требований к системе;
b) внешнее соответствие требованиям к системе;
c) внутренняя согласованность между программными объектами;
d) тестовое покрытие требований к программному объекту;
e) соответствие используемых испытательных стандартов и методов испытаний;
f) соответствие ожидаемым результатам;
g) выполнимость квалификационного испытания программного объекта;
h) возможность эксплуатации и сопровождения.
Разработчик должен проводить совместный анализ(ы).
Поставка проекта.
Процесс поставки состоит из работ и задач, выполняемых поставщиком. Процесс может быть начат с решения о подготовке предложения в ответ на заявку на подряд, присланную заказчиком, или с подписания договора и вступления с заказчиком в договорные отношения по поставке системы, программного продукта или программной услуги. Процесс продолжается определением процедур и ресурсов, необходимых для управления и обеспечения проекта, включая разработку проектных планов и их выполнение посредством поставки системы, программного продукта или программной услуги заказчику.
Поставщик управляет процессом поставки на проектном уровне в соответствии с процессом управления, который конкретизируется в данном процессе; определяет инфраструктуру для данного процесса в соответствии с процессом создания инфраструктуры; адаптирует данный процесс к условиям проекта в соответствии с процессом адаптации и управляет процессом поставки на организационном уровне в соответствии с процессами усовершенствования и обучения .
Список работ. Данный процесс состоит из следующих работ:
1) подготовка;
2) подготовка ответа;
3) подготовка договора;
4) планирование;
5) выполнение и контроль;
6) проверка и оценка;
7) поставка и закрытие договора.
46. Язык XML: средства, назначения и особенности использования. XML и DTD.
XML (расширяемый язык разметки) — это мета-язык разметки, широко используемый в настоящее время. XML разработан консорциумом WorldWideWeb в комитете, возглавляемом Джоном Босаком (JonBosak). Основное предназначение XML — быть более простым, чем SGML и сфокусироваться на специфичной проблеме — документах в интернете. XML — мета-язык как SGML, пользователям разрешается создавать любые теги, какие необходимы (отсюда «расширяемый»). Становлению XML помогли, так как каждый XML-документ мог быть написан таким же способом, как и SGML-документ, а программы и пользователи, использующие SGML, могли перейти на XML достаточно легко.
Тем не менее, XML лишился многих ориентированных на людей особенностей языка SGML, упрощавших его использование (пока не расширилось количество разметки и не восстановилась читаемость и редактируемость на прежнем уровне). Другие улучшения исправляли некоторые проблемы SGML на международном уровне и делали возможным разбор документа иерархически, даже если не был доступен DTD.
XML был спроектирован, в основном, для не полностью структурированной среды, например для документов и публикаций. Тем не менее, это привело к золотой середине между гибкостью и простотой, и он был быстро принят многими пользователями. В настоящее время XML широко используется для передачи данных между программами. Как HTML, он может быть охарактеризован как «контейнерный» язык.
Основное назначение языка XML — облегчить работу с документами в Web.
DTD (англ. DocumentTypeDefinition определение типа документа) — включает в себя два понятия:
Термин, который используется для описания схемы документа или его части языком схем DTD.
Язык схем DTD (DTD schemalanguage) — искусственный язык, который используется для записи фактических синтаксических правил метаязыков разметки текста SGML и XML. С момента его внедрения другие языки схем для спецификаций, такие как XML Schema и RELAX NG, выпускаются с дополнительной функциональностью.
Из-за определённых отличий между XML и SGML, применение DTD также имеет некоторые особенности в зависимости от целевого документа
Сейчас идёт отказ от использования DTD в XML-технологии по ряду причин:
Используется отличный от XML синтаксис.
Отсутствует типизация узлов.
Отсутствует поддержка пространств имён.
DTD описывает схему документа для конкретного языка разметки посредством набора объявлений (объектов-параметров, элементов и атрибутов), которые описывают его класс (или тип) с точки зрения синтаксических ограничений этого документа. Также DTD может объявлять конструкции, которые всегда необходимы для определения структуры документа, но, зато, могут влиять на интерпретацию определённых документов.
47. Язык XML и схемы данных.
XML — текстовый формат, предназначенный для хранения структурированных данных (взамен существующих файлов баз данных), для обмена информацией между программами, а также для создания на его основе более специализированных языков разметки (например, XHTML), иногда называемых словарями. XML является упрощённым подмножеством языка SGML.
Целью создания XML было обеспечение совместимости при передаче структурированных данных между разными системами обработки информации, особенно при передаче таких данных через Интернет. Словари, основанные на XML (например, RDF, RSS, MathML, XHTML, SVG), сами по себе формально описаны, что позволяет программно изменять и проверять документы на основе этих словарей, не зная их семантики, то есть не зная смыслового значения элементов. Важной особенностью XML также является применение так называемых пространств имён.
XML не содержит никаких тэгов, предназначенных для разметки, он просто определяет порядок их создания.
XML позволяет также осуществлять контроль за корректностью данных, хранящихся в документах, производить проверки иерархических соотношений внутри документа и устанавливать единый стандарт на структуру документов, содержимым которых могут быть самые различные данные. Это означает, что его можно использовать при построении сложных информационных систем, в которых очень важным является вопрос обмена информацией между различными приложениями, работающими в одной системе. Создавая структуру механизма обмена информации в самом начале работы над проектом, менеджер может избавить себя в будущем от многих проблем, связанных с несовместимостью используемых различными компонентами системы форматов данных.
Схемы данных (Schemas) являются альтернативным способом создания правил построения XML-документов. По сравнению с DTD, схемы обладают более мощными средствами для определения сложных структур данных, обеспечивают более понятный способ описания грамматики языка, способны легко модернизироваться и расширяться. Безусловным достоинством схем является также то, что они позволяют описывать правила для XML- документа средствами самого же XML.
Однако это не означает, что схемы могут полностью заменить DTD- описания - этот способ определения грамматики языка используется сейчас практическими всеми верифицирующими анализаторами XML и, более того, сами схемы, как обычные XML- элементы, тоже описываются DTD. Но серьезные возможности нового языка и его относительная простота, безусловно, дают основания утверждать, что будущий стандарт найдет широкое применение в качестве удобного и эффективного средства проверки корректности составления документов.
В настоящее время в W3 консорциуме идет работа над первой спецификацией схем данных. В этом разделе мы рассмотрим основные возможности схем данных, попытаемся использовать их для проверки корректности ранее описываемых XML- документов.
Область схемы данных
Создавая схемы данных, мы определяем в документе специальный элемент, <schema>;, внутри которого содержатся описания правил:
<schemaid="OurSchema">
<!-- последовательность инструкций -->
</schema>
Если использовать отдельное пространство имен, то полный XML-документ, содержащий в себе схему данных, будет выглядеть следующим образом:
<?XML version='1.0' ?>
<?xml:namespacehref="http://www.mrcpk.nstu.ru/schemas/" as="s"/?>
<s:schemaid="OurSchema">
<!-- последовательность инструкций -->
</s:schema>
Описание элементов
Для определения класса элемента, к которому в дальнейшем будут применяться инструкции, описывающие его содержимое и структуру, предназначен специальный элемент схемы elementType,
<elementTypeid="issue">
<descript>Элемент содержит информацию об очередном выпуске журнала</descript>
</elementType>
Название элемента задается атрибутом id . Все дальнейшие инструкции, которые относятся к описываемому классу, определяют его внутреннюю структуру и набор допустимых данных, содержатся внутри блока, заданного тэгами <elementType> и </elementType>. Мы рассмотрим эти инструкции чуть позже.
Как видно из примера, при определении класса элемента, можно также использовать комментарии к нему, которые заключаются в тэги <descript></descript>
Атрибуты элемента
Для того, чтобы в описании элем