Статьи

Автор: Дэвид Лоффредо
Об авторе: Д-р Дэвид Лоффредо (David Loffredo) является вице-президентом по разработке продуктов в компании STEP Tools, Inc. Он работает над программным обеспечением и стандартами для обмена данными САПР и систем автоматизированного производства/числового программного управления с 1987 года. Дэйв мастер на все руки, пьет много кофе и вообще довольно веселый человек.

Введение

Вспоминаю, как в начале 90-х годов мне довелось обсуждать моделирование информационных систем с сотрудником одной крупной компании. Я был молод, обуреваем идеями, однако мой собеседник быстро поставил меня на место:
«Однажды наша компания уже пыталась привлечь к работе специалистов по моделированию информационных систем. Через неделю после начала работы они принялись моделировать степлеры на рабочих столах сотрудников».
Я хорошо запомнил этот упрек специалистам по моделированию. Хотя архитектура информационной системы занимает центральное место во многих проектах, архитектор, если он отвлекается от основной задачи, никогда не достигнет успеха. В описанных ниже трех областях очень просто остаться без путеводной нити в лабиринте проблем.

Придерживайтесь рамок проекта

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

Помните, для чего разрабатывается модель

Архитектура информационных систем — это широкое понятие. Оно подразумевает несколько слоев моделей — совсем как в трехсхемной архитектуре, обычно используемой в учебных курсах по базам данных. И у каждого слоя свое назначение.
На верхнем уровне — информационная модель. В ней содержатся знания о прикладной области и документируется вся информация, которая должна обрабатываться в проекте. В то время как в задании по проекту документируется широта задачи, в информационной модели документируется ее «глубина». Некоторые могут считать ее лишь техническими требованиями к проекту, а не формальной моделью. Но каким бы образом ни документировалась информационная модель, она является неотъемлемой частью архитектуры информационной системы.
Независимо от того, что представляет собой конкретная прикладная область — систему автоматизированного проектирования (САПР) или отчеты о продажах, — источником знаний о ней являются эксперты в данной области, или люди, которые работают в этой сфере. Как правило, этот контингент отличается своими странностями, неточностями определений и профессиональным жаргоном. Такие специалисты не имеют представления, как формально описать информацию, с которой каждодневно имеют дело. Задача архитектора в том, чтобы вытянуть из них эти сведения, задокументировать и формализовать их.
Быстрейший из способов «заблудиться в трех соснах» — это собрать специалистов по прикладной тематике, объявить им текущую задачу разработки (скажем, «модель полного жизненного цикла степлеров») и предоставить самим себе. Во избежание последующего коллапса внимать им необходимо молча! Внимательно выслушайте все, что расскажут о предмете сами специалисты, прежде чем составить в уме целостную картину. Даже если вы не получите обобщенной характеристики происходящего, вы сможете лучше понять, что для них важно. Переработайте полученные знания в более формализованный вид. Стремитесь к полноте, точности и старайтесь избежать избыточности, но не заботьтесь пока о программном доступе и прочих деталях реализации.
Мои незадачливые коллеги, оконфузившиеся со степлерами, похоже, никогда не консультировались с настоящими специалистами по моделированию. У специалистов по моделированию есть несколько своеобразных идей о том, что является значимым, и эти идеи чужды специалистам из прикладной области. Насколько мне удалось выяснить подробности той самой истории, «приверженцы степлеров» ничуть не стремились донести до других, почему считают степлеры столь важными для компании, да и не особенно старались получить реальную информацию у ее сотрудников. Не повторяйте эту ошибку! Используйте информационную модель, чтобы прийти к согласию с заказчиком, и постарайтесь отразить в ней важнейшие компоненты прикладной области.
Как только все согласятся, что информационная модель соответствует постановке задачи, пора переходить на уровень ниже и приступать к разработке модели данных. Модель данных привязана к реализации, так что выбор инструментальных средств будет в значительной мере зависеть от используемых технологий.
Теперь, наконец, настало время перейти к подробностям реализации. Дальнейшее игнорирование их невозможно, так как это наверняка приведет к неправильному использованию базовой системы. Любой специалист, видевший достаточное количество различных реализаций, может рассказать свои излюбленные «страшилки» о неправильном применении технологий баз данных — такие как использование таблиц реляционной базы данных для реализации связанного списка, создание новых таблиц для каждого клиента и другие не менее удивительные истории.
Независимо от типа создаваемой модели следует избегать перегруженности деталями, которые не входят в задание по проекту. Не сосчитать, сколько раз умозрительно я добавлял к чему-либо детализацию лишь затем, чтобы впоследствии обнаружить, что выполнил задачу отчасти, и теперь это ограничивает дальнейшую доработку. Если, к примеру, вам для дела не требуется номер телефона, то и не нужно добавлять его в модель, каким бы естественным и простым это сейчас ни казалось!

Не позволяйте инструментальным средствам определять ваш взгляд на вещи

Как в случае с информационной моделью, так и при использовании модели данных главная задача архитектора — представить модель доступными средствами и с максимальной точностью. Например, в информационной модели проекта могут описываться всесторонние отношения наследования между различными объектами; но (по множеству причин) именно реляционная база данных является подходящей технологией реализации. SQL — это понятный выбор для модели данных, но, возможно, не самый лучший для описания наследования в информационной модели. Языки моделирования документируют результаты информационного моделирования; если один язык не позволяет охватить эти результаты, стоит перейти на какой-то другой, на котором это станет возможным.
Языков моделирования так же много, как и языков программирования, и у каждого имеются свои сторонники. Однако не всегда у архитектора есть возможность выбора, или в связи с обстоятельствами язык моделирования уже предопределен для проекта. В любом случае важно понимать, что у каждого языка есть как сильные стороны, так и ограничения. Я выбрал несколько языков, чтобы рассмотреть их подробнее.
• Простой текстовый документ — простейший способ документирования модели. Не являясь формальным описанием, на деле может быть вполне удобочитаем. Этот способ может оказаться полезным для информационных моделей. Для моделей данных он менее пригоден, поскольку нет соответствующих средств реализации, позволяющих что-либо сделать с этим описанием.
• Интегрированный язык описания (IDEF-0) — это более старая, основанная на схемах (диаграммах) методика, которая используется для документирования входов, выходов и средств управления. Он хорошо отражает поток данных через процессы на нескольких уровнях абстракции.
• IDEF1, IDEF1X и метод анализа информации на естественных языках (NIAM — Natural language Information Analysis Method) — это основанные на схемах (диаграммах) методики, очень популярные среди части разработчиков. Как и большинство схем, они удобны для документирования базовых объектов и связей, но практически не показывают ограничений. IDEF1 предназначен для информационных моделей, а IDEF1X лучше подходит для моделей данных (прежде всего, для реляционных баз данных).
• Язык моделирования EXPRESS (ISO 10303-11) мне гораздо ближе, хотя он не слишком распространен вне сообщества стандартов САПР. Он был разработан в 1980-х и 90-х годах для описания конструкций инженерных данных и хорошо подходит как для информационных моделей, так и для моделей данных. Он может охватить конструкции, связи и ограничения. В языке EXPRESS есть расширенная парадигма моделирования наследования, называемая наследованием «И/ИЛИ», которая выходит за пределы множественного наследования и позволяет совмещать типы с помощью логических операторов. Основанная на схемах (диаграммах) версия, называемая Graphical EXPRESS (EXPRESS-G), также полезна для информационных моделей, но она не способна отразить весь спектр ограничений, которые возможны в лексикографической версии.
• Универсальный язык моделирования (UML — Universal Modeling Language) и язык описания интерфейса (IDL — Interface Description Language) применяются широко, и чаще всего — для моделирования интерфейсов приложений, а также иногда для моделирования данных. Существуют превосходные наборы средств для создания полезного кода на основе модели. Но если использовать их для создания информационных моделей, могут возникнуть затруднения при описании ограничений.
• Язык SQL используется, конечно же, прежде всего для описания реляционных баз данных. Его поддерживает огромное число инструментальных средств. Пожалуй, это самый распространенный язык для описания моделей данных. Диаграммы сущностей и связей (ER-диаграммы) и расширенные ER-диаграммы также используются для документирования таблиц и ключевых связей между ними. Их полезность неоднозначна при описании информационных моделей, поскольку трудно описать такие понятия, как наследование, списки, множества и мультимножества, массивы или объединения, а также более сложные ограничения.
• Определение типа документа (DTD — Document Type Definition) на языке XML (eXtensible Markup Language — расширяемый язык разметки) и XML-схемы пришли к нам относительно недавно. Сначала были определения типа документа на языке XML. В них описываются модели базовых объектов и данных для XML-документов. В XML-схеме могут быть описаны более сложные модели данных, кроме наследования, хотя в ней есть форма уточнения, которая имитирует одинарное наследование.
• Язык описания онтологий (OWL — Web Ontology Language) берет свое начало от средств представления знаний и искусственного интеллекта. Включает богатый набор инструментов для описания связей, количества элементов и свойств. Потенциально с его помощью можно представить любую информационную модель. Однако в большинстве языков представления знаний заложена автоматизация формулирования логических выводов в определенной области. Иногда эти средства хорошо подходят для обмена информацией с людьми, а иногда — не очень.
Это лишь несколько примеров из большого числа возможных методов описания моделей. Какой бы язык или средство вы ни выбрали, помните, что у любого имеются свои сильные и слабые стороны. Отличное средство для документирования и демонстрации информационной модели может совершенно не подходить для составления и реализации модели данных.

Заключение

Каждый архитектор информационных систем должен учитывать три важные рекомендации.
• Контролируйте рамки проекта, иначе скоро вы заговорите о степлерах, сами того не замечая.
• Всегда помните, для чего нужна разрабатываемая модель. Модели данных предназначены для реализации, а информационные модели — для документации и обмена информацией с людьми.
• Не позволяйте инструментальным средствам определять ваш взгляд на вещи. Молоток всегда есть не больше чем молоток — удобен для забивания гвоздей и не годится для мытья окон. Точно так же трудно документировать обширные и нестрогие отношения наследования, используя только SQL или ER-диаграммы.
Усвоив и применив эти рекомендации, вы уже никогда не услышите упреков в «моделировании степлеров».

Вопросы для критического осмысления

• Что входит в объем моей работы? Что не входит в него?
• Я разрабатываю информационную модель или модель данных?
• Эта информация необходима для проекта или же ее просто приятно включить?
• Действительно ли я слушаю специалистов в прикладной области или пытаюсь их в чем-то убедить?
• Использую ли я преимущества сильных сторон выбранного языка моделирования? Или большую часть времени стараюсь обойти его ограничения?