Успех любого приложения XML зависит от того, насколько хорошо спроектированы фактически используемые документы XML: они должны быть способны не только нести информацию, которую люди передают друг другу сегодня, но и обладать достаточной гибкостью, чтобы учитывать будущие требования. Для этого необходимо рассмотреть следующие аспекты процесса проектирования:
Информационная модель - это описание используемой организацией информации, не зависящее от какой бы то ни было информационной технологии.
Моделирование информации имеет такое значение, потому что без модели нет информации, есть только данные. Информационная модель описывает назначение данных.
Любое информационное моделирование преследует две цели, которые не всегда бывает легко сочетать:
Существуют два основных типа информационной модели: статическая и динамическая.
В
Динамические модели описывают, что происходит с информацией: примерами таких моделей являются диаграммы рабочих процессов, потоков данных и жизненных циклов объектов. Динамические модели состоят примерно из таких утверждений: "Отделение патологии отправит результаты теста консультанту, отвечающему за пациента". Динамические модели описывают процесс обмена информацией: данные отправляются из одного места в другое с конкретной целью.
Язык XML, разумеется, может использоваться для представления в системе данных обоих типов - документов и сообщений. Тем не менее, в любом проекте системы необходимо рассмотреть как статические, так и динамические модели, причем оба типа моделей одинаково важны. Лучше начинать работу со
На практике, конечно, граница между долговечной статической информацией и временными сообщениями часто бывает размытой: объекты из статической информационной модели представляют собой события (например, продажа продукта), а документы, которые начинаются как временные сообщения (например, жалобы покупателя), затем архивируются на длительное время. Моделировать такие объекты как статические или как динамические, зависит от личного выбора и обстоятельств.
Традиционно документы и данные относились к различным областям. Работа с коммерческими данными была связана с высоко структурированной и формализованной информацией. Публикация документа, напротив, представляет собой организацию процесса создания и выпуска текста, который может быть прочитан людьми.
Таким образом, с одной стороны, основные усилия в мире данных были связаны с автоматизацией, анализом, кодированием и унификацией систем; с другой стороны, в документах главное - обеспечить гибкость, позволяющую авторам информации общаться со своими читателями по возможности творчески.
Сеть Web объединила эти миры. Язык XML стал первым примером технологии, одинаково применимой в обоих случаях.
Традиционный подход, касающийся как обработки данных, так и проектирования документов, предполагает начать с уже имеющейся документации на бумаге. Найдите документы, адекватные стоящей перед вами задаче, определите их структуру с помощью процессов обобщения и абстракции, побеседуйте с пользователями, узнайте, откуда приходит информация в документы, как она передается от одного документа другому и как используется, а затем на основе всего этого составьте модель данных.
В наши дни этот подход бывает неприемлем, поскольку люди не хотят создавать системы, просто репродуцирующие существующий способ работы. Необходимо знать не только, какая информация должна быть получена, но и почему необходима именно она.
При построении статической информационной модели необходимо пройти следующие этапы:
Этап 1. Идентификация понятий, присвоение им имен и их определение
Этап 2. Организация понятий в иерархию классов
Этап 3. Определение связей, множественности и ограничений
Этап 4. Добавление свойств для конкретизации деталей значений, связанных с объектами
Для начала нужно составить список понятий, относящихся к системе. Иногда предлагают даже описать систему на бумаге и выделить все существительные. В любом случае этот этап, как правило, не представляет затруднений.
Далее, и это иногда требует больше времени, надо описать типы объектов. Описание термина должно быть точным, чтобы не возникало разногласий по существу определения. Ценность моделирования в том и заключается, что оно предотвращает появление потенциальных источников непонимания.
По завершении работы, вероятно, получится длинный список типов объектов, и у некоторых будут длинные имена. Следует выбирать такие имена, которые занятые в этом бизнесе люди смогут корректно понять и интерпретировать: дело в том, что они не всегда будут сверяться с написанными определениями.
Помимо именования типов объектов стоит определить также, каким образом можно идентифицировать индивидуальные экземпляры. Возможно, в этом виде бизнеса существует код, который следует знать, или написать его. Надо принимать во внимание, что в схемах кодирования в бизнесе часто обнаруживаются проблемы.
В конце этого этапа мы получим список типов объектов с именами и определениями, по поводу которых достигнуто соглашение.
Таксономия - это термин, используемый в биологии для обозначения
Ключевой здесь является фраза, определяющая принадлежность (в английском языке - is или is kind of). Написав предложение вида "А есть разновидность В" или "Каждое А есть В", вы определили отношения подтипов в вашей таксономии.
Иногда эти действия называются тестом "is а" ("есть", "представляет собой"). Однако будьте внимательны, поскольку эта конструкция используется также и для описания отношений между конкретным экземпляром и его типом, безопаснее писать этот тест в форме "is a kind of" ("представляет собой разновидность").
Идентификация подтипов бывает полезна при проектировании документа, что более важно, она помогает лучше понять определения типов объектов.
Если вы занимались объектно-ориентированным программированием, то понимаете, как определять
Итак, этап 2 сводится к организации типов объектов в иерархию типов.
После того как объекты названы, в статическом информационном моделировании надо определить связи, существующие между ними. Связи (на языке UML они называются ассоциациями) можно показать просто сформулировав их в виде обычных предложений или их можно показать графически в виде диаграммы. Для диаграмм, описывающих связи между объектами, существует большое количество нотаций, каждый может выбрать более предпочтительную для себя. Диаграммы следует делать предельно простыми и интуитивно понятными, сосредоточившись на ключевых сообщениях и оставив подробности текстовым документам, которые проще обслуживать.
Существует некая информация, которую надо знать о каждой связи:
Найти подходящие имена для связей иногда бывает нелегко. При записи связей полезно использовать полные фразы типа "отель расположен на курорте" или "человек - это автор книги". Нам не надо использовать эти имена в тегах разметки XML, они присутствуют только в документации на систему.
Итак, в конце этапа 3 мы определили связи существующие между типами объектов в нашей модели.
Типы объектов и связи формируют скелет статической информационной модели; свойства можно сравнить с плотью на костях. Свойства представляют собой простые значения, ассоциированные с объектами. У человека можно определить рост, вес, национальность и род занятий; отель имеет определенное количество комнат, этажность и ценовую категорию.
Не следует снова включать связи в список свойств объекта: расположение отеля не является его свойством, если мы уже промоделировали его как связь с курортом.
Главное, что нам надо знать о свойствах, - это тип их данных. Определен ли для них фиксированный диапазон значений, являются ли они числовыми, в каких единицах выражаются? Является ли свойство обязательным и есть ли у него значение по умолчанию?
В конце этапа 4 мы завершили формирование статической информационной модели: получили полное описание типов объектов в системе, их связей друг с другом и их свойств.
Динамические модели описывают, что происходит с информацией: примерами таких моделей являются диаграммы рабочих процессов, потоков данных и жизненных циклов объектов. Динамические модели состоят примерно из таких утверждений: "Отделение патологии отправит результаты теста консультанту, отвечающему за пациента". Динамические модели описывают процесс обмена информацией: данные отправляются из одного места в другое с конкретной целью.
Для построения динамической модели можно воспользоваться различными программными системами (например, диаграммы рабочих процессов и BPWin ).
Существует несколько подходов к динамическому моделированию:
Модели рабочих процессов заостряют внимание на роли людей и организаций в выполнении работы, хранение и обработка информации играют в них вторичную роль. Модель процесса описывает, например, что будет с путешественником, если на отдыхе с ним произойдет несчастный случай. Она определяет, за какие действия отвечает локальный представитель на курорте, агент в стране, где находится курорт и главный офис. В результате становится ясно, кто должен отвечать за организацию медицинской помощи, за перевозку туриста домой и за информирование родственников. Она может описывать различные формы, заполняемые и пересылаемые между участниками, и вообще не привлекать компьютерные системы. Модель процесса обычно фокусирует внимание на ролях, обязанностях и задачах каждого действующего лица системы ( workflow -модель имеет дело с документами, передаваемыми между действующими лицами.
Объектные модели содержат как динамический, так и статический компоненты. Динамическая или поведенческая часть определения объекта сосредоточена на том, что может делать или делал каждый объект, представляя для этого набор операций или методов, описывающих его действия.
Жизненные циклы объекта (на языке UML это называется линиями жизни объекта) также заостряют внимание на индивидуальных объектах, но придерживаются более целостного подхода. Они описывают, что происходит с объектом на протяжении его жизни: как он создается, какие события с ним происходят, как он реагирует на эти события и какие условия приводят в конце к его разрушению.
Жизненные циклы объекта очень полезны для тестирования завершенности модели. Часто наблюдается тенденция к акцентированию внимания только на некоторых событиях за счет остальных. Пока мы не определим, каким образом каждый объект попадает в систему и как он удаляется из нее, полного понимания не будет.
Варианты использования ( use cases ) анализируют выполнение специфических задач пользователя (например, человек, купивший туристическую поездку, отменяет свой заказ). Вариант использования напоминает модель процесса, но в общем случае заостряет внимание на деятельности одного конкретного пользователя.
Варианты использования могут быть полезны как на этапе моделирования деловой активности, так и при описании внутреннего поведения информационных систем. Одна из опасностей заключается в смешении двух уровней. Лучше этого не делать, поскольку они представляют интерес для различных аудиторий.
Представленный в виде варианта использования диалог пользовательского интерфейса описывает, какой информацией пользователи обмениваются с системой, а не то, как она представлена на экране. Это естественным образом приводит к реализации XML, в которой информационное содержание отделено от особенностей представления.
Модели нужны только как рабочие инструменты, дающие возможность при встрече с пользователями прийти к соглашению по вопросу о том, как она должна работать. Поэтому не нужно рассматривать все модели. Достаточно рассмотреть только те, которые действительно дадут необходимую информацию о разрабатываемой проблеме. Эти диаграммы самостоятельно появятся в проекте XML, когда начнется описание сообщения между подсистемами.
Существует два типа данных: информационные хранилища, предназначенные для долговременного хранения данных, и потоки сообщений, передающие временную информацию из одной подсистемы в другую.
Язык XML применим в обоих случаях, но подходы к проектированию различны.
Использование языка XML для работы с сообщениями системы представляет меньше связанных с проектированием проблем, чем использование его для постоянных данных. Это связано с тем, что каждое сообщение обычно бывает сравнительно автономным, и вопрос о том, что в него включить, естественным образом выпадает из модели обработки.
Разумеется, термин "сообщение" мы используем в широком смысле. Эти сообщения могут быть составлены в стиле электронного обмена данными. Или это могут быть данные, которыми обмениваются подсистемы в форме сообщения XML. Кроме того, сообщение может быть предназначено для отображения на экране. В таком случае, ответ на запрос вернется из базы данных в виде сообщения XML, но клиентская система (или браузер) преобразует его в видимую страницу с помощью соответствующей таблицы стилей.
Существуют некоторые общие принципы проектирования, применимые ко всем сообщениям XML, независимо от их роли:
BizTalk.Надо ли включать ненужную в настоящий момент информацию, которая может потребоваться в дальнейшем? На этот вопрос нет универсального ответа. С одной стороны, легче включить все свойства проекта, а не выбирать те, в которых заинтересован реципиент. Затем можно передать все эти свойства получателю и дать ему возможность проигнорировать ненужные. С другой стороны, глупо посылать лишние данные, учитывая еще проблемы безопасности или секретности. Принимаемое решение должно диктоваться прагматическими соображениями.
Имеет смысл включить в сообщение некоторую официальную информацию, даже если она дублирует доступную из других систем передачи сообщений. Очевидно, это дата и время, личность отправителя и получателя; с помощью серийного номера можно проконтролировать, что сообщение не было утеряно при передаче или отправлено дважды. Для включения всего этого в сообщения XML существуют две причины: реципиенту проще прочитать информацию из сообщения, а не извлекать ее откуда-то еще с помощью специального интерфейса API ; и что более важно при архивировании сообщений для последующего аудита, - всю информацию легче сохранять в одном месте.
Проекты сообщений определяются в основном динамическими информационными моделями. Но при использовании языка XML для хранения постоянной информации особенно важны
При использовании языка XML для хранения постоянной информации встает вопрос о размере одного XML документа. Существуют приложения, в которых имеет смысл поддерживать один документ XML, содержащий гигабайты информации, но это скорее исключения, чем правила. Язык XML не совсем подходит для организации прямого доступа к документу; чтобы обратиться к любой части такого большого документа с помощью современной технологии, его придется анализировать целиком, а это потребует много времени. С другой стороны, противоположная крайность также не является идеальным решением, поскольку наличие большого количества крошечных документов делает невозможным использование богатой структуры XML для представления связей в информационной модели.
Иногда существует естественное отображение одного документа XML на один
Основным методом определения правильного размера документа считается концепция "содержимого страницы экрана". Конечно, принимать ключевое решение по проекту на основе того, сколько информации мы хотим передать пользователю за раз, кажется неразумным. Однако на практике это оказывается хорошим тестом. Если сохраняемый документ XML содержит значительно больше информации, чем пользователь когда-либо захочет увидеть на экране, то придется анализировать много данных, на которые он никогда не взглянет; если же для заполнения одного экрана информацией нужно обратиться к сотням сохраняемых документов XML, это вызовет существенную дополнительную нагрузку.
Что делать, если пользователь хочет каждый раз видеть новый небольшой фрагмент информации? Одно из решений: сохранить весь документ DOM в памяти на сервере в области действия приложения. В ответ на запросы пользователей можно фильтровать его и создавать меньшие по размеру документы XML, более точно отвечающие его потребностям. Этот меньший документ можно затем направить клиенту для обработки.
В общем случае тип объекта в информационной модели будет транслирован в тип элемента в структуре XML.
В качестве имени элемента можно использовать название типа объекта или, если нужно сберечь место на диске, это имя можно сократить. Часто для тегов элементов применяются такие короткие имена. Это связано не с экономией дискового пространства, а с тем, что документ XML становится более читаемым: такие теги не слишком отвлекают внимание от содержания.
Если тип объекта входит в состав
Для представления некоторых связей модели используются вложенные элементы структуры документа XML. Очевидными кандидатами на подобное представление являются связи "содержания".
Элемент может содержаться непосредственно только в одном порождающем элементе, так что другие связи модели следует устанавливать иначе. На практике это означает использование какой-либо разновидности ссылок.
Обнаружив свойство в своей информационной модели, мы сталкиваемся с классической дилеммой: в документе XML представлять его с помощью атрибута или вложенного (порожденного) элемента. Приняв решение по этому поводу, можно приступать к остальным задачам.
Рассмотрим практические преимущества и недостатки каждого подхода.
| Преимущества | Недостатки | |
|---|---|---|
| Атрибуты XML | С помощью определений DTD можно ограничивать принимаемые значения; полезно, если имеется небольшое количество разрешенных значений, таких как "yes" и "nо" |
Принимает только простые строковые значения |
| В DTD можно определить значение по умолчанию | Отсутствует поддержка метаданных (или атрибутов у атрибутов) | |
| Использование атрибутов типа ID и |
Неупорядоченность | |
| Небольшие требования к месту на диске (существенно, когда по сети посылаются гигабайты информации) | ||
Для некоторых типов данных (например, NMTOKENS ) возможна нормализация пустых пространств, что избавляет приложение от этих действий |
||
| Легко обрабатывать с помощью интерфейсов DOM и |
||
| Порожденные элементы | Поддержка произвольно сложных и повторяющихся значений | Несколько более высокие требования к дисковому пространству |
| Упорядоченность | Более сложное программирование | |
| Поддержка "атрибутов у атрибутов" | ||
| Возможность расширения при изменении модели данных |
Баланс всех факторов зависит от конкретного приложения.
Формальная роль схем заключается в описании группы всех возможных допустимых документов, или, иначе выражаясь, в описании ограничений, помимо налагаемых самим языком XML, которым должен соответствовать документ, чтобы быть значимым.
Используя слово "допустимость" ( validity ) в этом контексте, следует быть очень осторожным. В соответствии со стандартом XML допустимость означает соответствие документа правилам, содержащимся в DTD. Но сейчас мы говорим о таких ограничениях, которые не могут быть выражены в DTD, а некоторые из них не могут также быть выражены и в схемах XML.
Одной из задач схем является определение различий между допустимыми и недопустимыми документами. Насколько это, возможно, правила следует выражать таким способом, чтобы программное обеспечение само могло решить, является ли документ допустимым; однако на практике всегда остаются такие правила, которые может интерпретировать только человек.
Конечно, не всегда правильно налагать ограничения. Существует огромное искушение бездумно воспользоваться правом устанавливать правила и сделать систему чрезмерно жесткой. Информационные системы пользуются плохой репутацией из-за их негибкости, и надо вдумчиво использовать ограничения, позволяя людям в процессе работы проявить свой интеллект. В противном случае ограничения могут негативно повлиять на качество информации.
Возможность определять недвусмысленные правила и проверять их программными средствами не означает, что мы должны делать это на каждом удобном этапе обработки. Например, нет необходимости проверять документ в момент его доставки с Web-сервера: прежде всего его допустимость должна быть проверена при поступлении туда. Однако некоторые программисты несмотря ни на что слепо используют во всех случаях проверяющий на допустимость анализатор. Аналогично при отправке документов XML из одной программной системы в другую в рамках той же организации имеет смысл проверять допустимость только на этапе тестирования, но если все работает нормально, одно приложение уже может доверять другому.
Вторая задача схем заключается в объяснениях - необходимо документировать интерпретацию и использование предоставляемых конструкций так, чтобы отправитель и получатель сообщения одинаково понимали его смысл.
В традициях работы с документами и базами данных роль схем вторична, хотя потенциально она более важна. Частично проблема связана с тем, что схемы как правило не доходят до людей, которым надо знать эту информацию, особенно до пользователей, вводящих данные на экране. В связи с этим большое количество систем страдает от так называемого семантического сдвига, тенденцией сообщества пользователей со временем изменять способ использования системы и значения, связываемого ими с полями данных, даже если программные структуры остаются неизменными.
Поскольку конечные пользователи не будут специально изучать схему, эти схемы должны стать доступными для чтения с помощью приложения: например, следует обеспечить возможность извлекать описание полей данных и показывать его в качестве совета на экранах ввода информации.
Успех любого приложения XML зависит от того, насколько хорошо спроектированы фактически используемые документы XML: они должны быть способны не только нести информацию, которую люди передают друг другу сегодня, но и обладать достаточной гибкостью, чтобы учитывать будущие требования. Для этого необходимо рассмотреть следующие аспекты процесса проектирования:
Информационная модель - это описание используемой организацией информации, не зависящее от какой бы то ни было информационной технологии.
Моделирование информации имеет такое значение, потому что без модели нет информации, есть только данные. Информационная модель описывает назначение данных.
Любое информационное моделирование преследует две цели, которые не всегда бывает легко сочетать:
Существуют два основных типа информационной модели: статическая и динамическая.
В
Динамические модели описывают, что происходит с информацией: примерами таких моделей являются диаграммы рабочих процессов, потоков данных и жизненных циклов объектов. Динамические модели состоят примерно из таких утверждений: "Отделение патологии отправит результаты теста консультанту, отвечающему за пациента". Динамические модели описывают процесс обмена информацией: данные отправляются из одного места в другое с конкретной целью.
Язык XML, разумеется, может использоваться для представления в системе данных обоих типов - документов и сообщений. Тем не менее, в любом проекте системы необходимо рассмотреть как статические, так и динамические модели, причем оба типа моделей одинаково важны. Лучше начинать работу со
На практике, конечно, граница между долговечной статической информацией и временными сообщениями часто бывает размытой: объекты из статической информационной модели представляют собой события (например, продажа продукта), а документы, которые начинаются как временные сообщения (например, жалобы покупателя), затем архивируются на длительное время. Моделировать такие объекты как статические или как динамические, зависит от личного выбора и обстоятельств.
Традиционно документы и данные относились к различным областям. Работа с коммерческими данными была связана с высоко структурированной и формализованной информацией. Публикация документа, напротив, представляет собой организацию процесса создания и выпуска текста, который может быть прочитан людьми.
Таким образом, с одной стороны, основные усилия в мире данных были связаны с автоматизацией, анализом, кодированием и унификацией систем; с другой стороны, в документах главное - обеспечить гибкость, позволяющую авторам информации общаться со своими читателями по возможности творчески.
Сеть Web объединила эти миры. Язык XML стал первым примером технологии, одинаково применимой в обоих случаях.
Традиционный подход, касающийся как обработки данных, так и проектирования документов, предполагает начать с уже имеющейся документации на бумаге. Найдите документы, адекватные стоящей перед вами задаче, определите их структуру с помощью процессов обобщения и абстракции, побеседуйте с пользователями, узнайте, откуда приходит информация в документы, как она передается от одного документа другому и как используется, а затем на основе всего этого составьте модель данных.
В наши дни этот подход бывает неприемлем, поскольку люди не хотят создавать системы, просто репродуцирующие существующий способ работы. Необходимо знать не только, какая информация должна быть получена, но и почему необходима именно она.
При построении статической информационной модели необходимо пройти следующие этапы:
Этап 1. Идентификация понятий, присвоение им имен и их определение
Этап 2. Организация понятий в иерархию классов
Этап 3. Определение связей, множественности и ограничений
Этап 4. Добавление свойств для конкретизации деталей значений, связанных с объектами
Для начала нужно составить список понятий, относящихся к системе. Иногда предлагают даже описать систему на бумаге и выделить все существительные. В любом случае этот этап, как правило, не представляет затруднений.
Далее, и это иногда требует больше времени, надо описать типы объектов. Описание термина должно быть точным, чтобы не возникало разногласий по существу определения. Ценность моделирования в том и заключается, что оно предотвращает появление потенциальных источников непонимания.
По завершении работы, вероятно, получится длинный список типов объектов, и у некоторых будут длинные имена. Следует выбирать такие имена, которые занятые в этом бизнесе люди смогут корректно понять и интерпретировать: дело в том, что они не всегда будут сверяться с написанными определениями.
Помимо именования типов объектов стоит определить также, каким образом можно идентифицировать индивидуальные экземпляры. Возможно, в этом виде бизнеса существует код, который следует знать, или написать его. Надо принимать во внимание, что в схемах кодирования в бизнесе часто обнаруживаются проблемы.
В конце этого этапа мы получим список типов объектов с именами и определениями, по поводу которых достигнуто соглашение.
Таксономия - это термин, используемый в биологии для обозначения
Ключевой здесь является фраза, определяющая принадлежность (в английском языке - is или is kind of). Написав предложение вида "А есть разновидность В" или "Каждое А есть В", вы определили отношения подтипов в вашей таксономии.
Иногда эти действия называются тестом "is а" ("есть", "представляет собой"). Однако будьте внимательны, поскольку эта конструкция используется также и для описания отношений между конкретным экземпляром и его типом, безопаснее писать этот тест в форме "is a kind of" ("представляет собой разновидность").
Идентификация подтипов бывает полезна при проектировании документа, что более важно, она помогает лучше понять определения типов объектов.
Если вы занимались объектно-ориентированным программированием, то понимаете, как определять
Итак, этап 2 сводится к организации типов объектов в иерархию типов.
После того как объекты названы, в статическом информационном моделировании надо определить связи, существующие между ними. Связи (на языке UML они называются ассоциациями) можно показать просто сформулировав их в виде обычных предложений или их можно показать графически в виде диаграммы. Для диаграмм, описывающих связи между объектами, существует большое количество нотаций, каждый может выбрать более предпочтительную для себя. Диаграммы следует делать предельно простыми и интуитивно понятными, сосредоточившись на ключевых сообщениях и оставив подробности текстовым документам, которые проще обслуживать.
Существует некая информация, которую надо знать о каждой связи:
Найти подходящие имена для связей иногда бывает нелегко. При записи связей полезно использовать полные фразы типа "отель расположен на курорте" или "человек - это автор книги". Нам не надо использовать эти имена в тегах разметки XML, они присутствуют только в документации на систему.
Итак, в конце этапа 3 мы определили связи существующие между типами объектов в нашей модели.
Типы объектов и связи формируют скелет статической информационной модели; свойства можно сравнить с плотью на костях. Свойства представляют собой простые значения, ассоциированные с объектами. У человека можно определить рост, вес, национальность и род занятий; отель имеет определенное количество комнат, этажность и ценовую категорию.
Не следует снова включать связи в список свойств объекта: расположение отеля не является его свойством, если мы уже промоделировали его как связь с курортом.
Главное, что нам надо знать о свойствах, - это тип их данных. Определен ли для них фиксированный диапазон значений, являются ли они числовыми, в каких единицах выражаются? Является ли свойство обязательным и есть ли у него значение по умолчанию?
В конце этапа 4 мы завершили формирование статической информационной модели: получили полное описание типов объектов в системе, их связей друг с другом и их свойств.
Динамические модели описывают, что происходит с информацией: примерами таких моделей являются диаграммы рабочих процессов, потоков данных и жизненных циклов объектов. Динамические модели состоят примерно из таких утверждений: "Отделение патологии отправит результаты теста консультанту, отвечающему за пациента". Динамические модели описывают процесс обмена информацией: данные отправляются из одного места в другое с конкретной целью.
Для построения динамической модели можно воспользоваться различными программными системами (например, диаграммы рабочих процессов и BPWin ).
Существует несколько подходов к динамическому моделированию:
Модели рабочих процессов заостряют внимание на роли людей и организаций в выполнении работы, хранение и обработка информации играют в них вторичную роль. Модель процесса описывает, например, что будет с путешественником, если на отдыхе с ним произойдет несчастный случай. Она определяет, за какие действия отвечает локальный представитель на курорте, агент в стране, где находится курорт и главный офис. В результате становится ясно, кто должен отвечать за организацию медицинской помощи, за перевозку туриста домой и за информирование родственников. Она может описывать различные формы, заполняемые и пересылаемые между участниками, и вообще не привлекать компьютерные системы. Модель процесса обычно фокусирует внимание на ролях, обязанностях и задачах каждого действующего лица системы ( workflow -модель имеет дело с документами, передаваемыми между действующими лицами.
Объектные модели содержат как динамический, так и статический компоненты. Динамическая или поведенческая часть определения объекта сосредоточена на том, что может делать или делал каждый объект, представляя для этого набор операций или методов, описывающих его действия.
Жизненные циклы объекта (на языке UML это называется линиями жизни объекта) также заостряют внимание на индивидуальных объектах, но придерживаются более целостного подхода. Они описывают, что происходит с объектом на протяжении его жизни: как он создается, какие события с ним происходят, как он реагирует на эти события и какие условия приводят в конце к его разрушению.
Жизненные циклы объекта очень полезны для тестирования завершенности модели. Часто наблюдается тенденция к акцентированию внимания только на некоторых событиях за счет остальных. Пока мы не определим, каким образом каждый объект попадает в систему и как он удаляется из нее, полного понимания не будет.
Варианты использования ( use cases ) анализируют выполнение специфических задач пользователя (например, человек, купивший туристическую поездку, отменяет свой заказ). Вариант использования напоминает модель процесса, но в общем случае заостряет внимание на деятельности одного конкретного пользователя.
Варианты использования могут быть полезны как на этапе моделирования деловой активности, так и при описании внутреннего поведения информационных систем. Одна из опасностей заключается в смешении двух уровней. Лучше этого не делать, поскольку они представляют интерес для различных аудиторий.
Представленный в виде варианта использования диалог пользовательского интерфейса описывает, какой информацией пользователи обмениваются с системой, а не то, как она представлена на экране. Это естественным образом приводит к реализации XML, в которой информационное содержание отделено от особенностей представления.
Модели нужны только как рабочие инструменты, дающие возможность при встрече с пользователями прийти к соглашению по вопросу о том, как она должна работать. Поэтому не нужно рассматривать все модели. Достаточно рассмотреть только те, которые действительно дадут необходимую информацию о разрабатываемой проблеме. Эти диаграммы самостоятельно появятся в проекте XML, когда начнется описание сообщения между подсистемами.
Существует два типа данных: информационные хранилища, предназначенные для долговременного хранения данных, и потоки сообщений, передающие временную информацию из одной подсистемы в другую.
Язык XML применим в обоих случаях, но подходы к проектированию различны.
Использование языка XML для работы с сообщениями системы представляет меньше связанных с проектированием проблем, чем использование его для постоянных данных. Это связано с тем, что каждое сообщение обычно бывает сравнительно автономным, и вопрос о том, что в него включить, естественным образом выпадает из модели обработки.
Разумеется, термин "сообщение" мы используем в широком смысле. Эти сообщения могут быть составлены в стиле электронного обмена данными. Или это могут быть данные, которыми обмениваются подсистемы в форме сообщения XML. Кроме того, сообщение может быть предназначено для отображения на экране. В таком случае, ответ на запрос вернется из базы данных в виде сообщения XML, но клиентская система (или браузер) преобразует его в видимую страницу с помощью соответствующей таблицы стилей.
Существуют некоторые общие принципы проектирования, применимые ко всем сообщениям XML, независимо от их роли:
BizTalk.Надо ли включать ненужную в настоящий момент информацию, которая может потребоваться в дальнейшем? На этот вопрос нет универсального ответа. С одной стороны, легче включить все свойства проекта, а не выбирать те, в которых заинтересован реципиент. Затем можно передать все эти свойства получателю и дать ему возможность проигнорировать ненужные. С другой стороны, глупо посылать лишние данные, учитывая еще проблемы безопасности или секретности. Принимаемое решение должно диктоваться прагматическими соображениями.
Имеет смысл включить в сообщение некоторую официальную информацию, даже если она дублирует доступную из других систем передачи сообщений. Очевидно, это дата и время, личность отправителя и получателя; с помощью серийного номера можно проконтролировать, что сообщение не было утеряно при передаче или отправлено дважды. Для включения всего этого в сообщения XML существуют две причины: реципиенту проще прочитать информацию из сообщения, а не извлекать ее откуда-то еще с помощью специального интерфейса API ; и что более важно при архивировании сообщений для последующего аудита, - всю информацию легче сохранять в одном месте.
Проекты сообщений определяются в основном динамическими информационными моделями. Но при использовании языка XML для хранения постоянной информации особенно важны
При использовании языка XML для хранения постоянной информации встает вопрос о размере одного XML документа. Существуют приложения, в которых имеет смысл поддерживать один документ XML, содержащий гигабайты информации, но это скорее исключения, чем правила. Язык XML не совсем подходит для организации прямого доступа к документу; чтобы обратиться к любой части такого большого документа с помощью современной технологии, его придется анализировать целиком, а это потребует много времени. С другой стороны, противоположная крайность также не является идеальным решением, поскольку наличие большого количества крошечных документов делает невозможным использование богатой структуры XML для представления связей в информационной модели.
Иногда существует естественное отображение одного документа XML на один
Основным методом определения правильного размера документа считается концепция "содержимого страницы экрана". Конечно, принимать ключевое решение по проекту на основе того, сколько информации мы хотим передать пользователю за раз, кажется неразумным. Однако на практике это оказывается хорошим тестом. Если сохраняемый документ XML содержит значительно больше информации, чем пользователь когда-либо захочет увидеть на экране, то придется анализировать много данных, на которые он никогда не взглянет; если же для заполнения одного экрана информацией нужно обратиться к сотням сохраняемых документов XML, это вызовет существенную дополнительную нагрузку.
Что делать, если пользователь хочет каждый раз видеть новый небольшой фрагмент информации? Одно из решений: сохранить весь документ DOM в памяти на сервере в области действия приложения. В ответ на запросы пользователей можно фильтровать его и создавать меньшие по размеру документы XML, более точно отвечающие его потребностям. Этот меньший документ можно затем направить клиенту для обработки.
В общем случае тип объекта в информационной модели будет транслирован в тип элемента в структуре XML.
В качестве имени элемента можно использовать название типа объекта или, если нужно сберечь место на диске, это имя можно сократить. Часто для тегов элементов применяются такие короткие имена. Это связано не с экономией дискового пространства, а с тем, что документ XML становится более читаемым: такие теги не слишком отвлекают внимание от содержания.
Если тип объекта входит в состав
Для представления некоторых связей модели используются вложенные элементы структуры документа XML. Очевидными кандидатами на подобное представление являются связи "содержания".
Элемент может содержаться непосредственно только в одном порождающем элементе, так что другие связи модели следует устанавливать иначе. На практике это означает использование какой-либо разновидности ссылок.
Обнаружив свойство в своей информационной модели, мы сталкиваемся с классической дилеммой: в документе XML представлять его с помощью атрибута или вложенного (порожденного) элемента. Приняв решение по этому поводу, можно приступать к остальным задачам.
Рассмотрим практические преимущества и недостатки каждого подхода.
| Преимущества | Недостатки | |
|---|---|---|
| Атрибуты XML | С помощью определений DTD можно ограничивать принимаемые значения; полезно, если имеется небольшое количество разрешенных значений, таких как "yes" и "nо" |
Принимает только простые строковые значения |
| В DTD можно определить значение по умолчанию | Отсутствует поддержка метаданных (или атрибутов у атрибутов) | |
| Использование атрибутов типа ID и |
Неупорядоченность | |
| Небольшие требования к месту на диске (существенно, когда по сети посылаются гигабайты информации) | ||
Для некоторых типов данных (например, NMTOKENS ) возможна нормализация пустых пространств, что избавляет приложение от этих действий |
||
| Легко обрабатывать с помощью интерфейсов DOM и |
||
| Порожденные элементы | Поддержка произвольно сложных и повторяющихся значений | Несколько более высокие требования к дисковому пространству |
| Упорядоченность | Более сложное программирование | |
| Поддержка "атрибутов у атрибутов" | ||
| Возможность расширения при изменении модели данных |
Баланс всех факторов зависит от конкретного приложения.
Формальная роль схем заключается в описании группы всех возможных допустимых документов, или, иначе выражаясь, в описании ограничений, помимо налагаемых самим языком XML, которым должен соответствовать документ, чтобы быть значимым.
Используя слово "допустимость" ( validity ) в этом контексте, следует быть очень осторожным. В соответствии со стандартом XML допустимость означает соответствие документа правилам, содержащимся в DTD. Но сейчас мы говорим о таких ограничениях, которые не могут быть выражены в DTD, а некоторые из них не могут также быть выражены и в схемах XML.
Одной из задач схем является определение различий между допустимыми и недопустимыми документами. Насколько это, возможно, правила следует выражать таким способом, чтобы программное обеспечение само могло решить, является ли документ допустимым; однако на практике всегда остаются такие правила, которые может интерпретировать только человек.
Конечно, не всегда правильно налагать ограничения. Существует огромное искушение бездумно воспользоваться правом устанавливать правила и сделать систему чрезмерно жесткой. Информационные системы пользуются плохой репутацией из-за их негибкости, и надо вдумчиво использовать ограничения, позволяя людям в процессе работы проявить свой интеллект. В противном случае ограничения могут негативно повлиять на качество информации.
Возможность определять недвусмысленные правила и проверять их программными средствами не означает, что мы должны делать это на каждом удобном этапе обработки. Например, нет необходимости проверять документ в момент его доставки с Web-сервера: прежде всего его допустимость должна быть проверена при поступлении туда. Однако некоторые программисты несмотря ни на что слепо используют во всех случаях проверяющий на допустимость анализатор. Аналогично при отправке документов XML из одной программной системы в другую в рамках той же организации имеет смысл проверять допустимость только на этапе тестирования, но если все работает нормально, одно приложение уже может доверять другому.
Вторая задача схем заключается в объяснениях - необходимо документировать интерпретацию и использование предоставляемых конструкций так, чтобы отправитель и получатель сообщения одинаково понимали его смысл.
В традициях работы с документами и базами данных роль схем вторична, хотя потенциально она более важна. Частично проблема связана с тем, что схемы как правило не доходят до людей, которым надо знать эту информацию, особенно до пользователей, вводящих данные на экране. В связи с этим большое количество систем страдает от так называемого семантического сдвига, тенденцией сообщества пользователей со временем изменять способ использования системы и значения, связываемого ими с полями данных, даже если программные структуры остаются неизменными.
Поскольку конечные пользователи не будут специально изучать схему, эти схемы должны стать доступными для чтения с помощью приложения: например, следует обеспечить возможность извлекать описание полей данных и показывать его в качестве совета на экранах ввода информации.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.