Проектирование крупных ИС: от панацей к мастерской методов и моделей

Поиск универсальных средств

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

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

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

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

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

Типовые подходы и типичные проблемы

Методология построения информационных систем содержит три основных компонента:

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

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

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

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

Объектный подход. Он содержит набор моделей, связанных с понятием класса/объекта, объединяющего данные (состояние) и поведение. В настоящее время наиболее естественным является применение набора моделей, входящих в UML (универсальный язык моделирования), так как этот язык стандартизирован, широко используется и постоянно развивается. Распространенность языка UML можно объяснить тем, что он создан авторами трех самых известных в мире объектных методов (OMT, OOSE и Booch method). Прекращение "войны методов" и объединение ведущих специалистов привело к открытости и стандартной интерпретации моделей. Стандарт UML открыт для обсуждения и развивается при участии ведущих технологических фирм: Rational Software, Microsoft, Hewlett-Packard, Oracle, IBM, Platinum Technology и других. Использование единого языка моделирования позволяет специалистам разных стран "говорить" на одном языке. На таком языке удобно составлять технические спецификации на коммерческие программные продукты. А стандартизация моделей облегчит интеграцию средств моделирования с другими инструментами.

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

Сами по себе наборы моделей ни в коей мере не должны навязывать принципов построения систем. Тем не менее нередко такие принципы считаются неотъемлемой характеристикой самих моделей.

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

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

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

Основные модели - плюсы и минусы

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

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

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

Диаграмма "сущность - связь" подняла описание информации на качественно новый уровень - аналитики получили возможность говорить о данных в терминах сущностей предметной области, а не структур хранения компьютерных систем. В настоящее время имеется более богатая и выразительная модель описания данных - диаграмма классов. Однако диаграмму "сущность - связь" нельзя списывать со счетов. У нее есть одно большое достоинство: конструкции этой модели понятным образом соответствуют конструкциям реляционной модели данных. Наличие единого формализма для описания как сущностей предметной области, так и компонентов реляционной базы данных делает диаграмму "сущность - связь" удобным средством для описания хранимых в информационной системе данных. А простота преобразования модели в структуру базы данных (генерация SQL-кода) и обратно (реверс-инжиниринг базы данных) делает данную модель полезной в процессе сопровождения и развития базы данных на сервере реляционной СУБД.

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

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

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

Широко распространено заблуждение, что при создании программного обеспечения одна модель классов может быть использована для генерации кода на любом объектном языке программирования. Это неверно. Создавая модель классов, следует знать средство реализации. И для каждого языка программирования должны выполняться соответствующие требования. Например, в языке C++ множественное наследование имеется, а в языке Java - нет. И построить одну модель для эффективной реализации на языках C++ и Java нельзя. Здесь, как и в модели "сущность - связь", нет полной независимости от средств реализации.

Применение моделей

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

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

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

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

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

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

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

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

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

Мастерская методов

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

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

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

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