Текст книги "Основы проектирования корпоративных систем"

Раздел II
Средства, платформы и технологии разработки корпоративных систем

Глава 7
Средства автоматизации разработки корпоративных систем

От методологической и модельной части перейдем к части, которая в большей мере касается практики.

Обсудим более подробно CASE-средства.

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

Речь пойдет о попытках классификации CASE-средств. Их существует великое множество, и их число непрерывно растет. В последнее время популярна тема DSL (Domain Specific Languages) – предметно-ориентированных языков, которые нацелены на какие-то конкретные, узкие предметные области. Для них существуют как большие CASE-средства, такие как Microsoft Visual Studio, в который можно встроить такого рода языки и поддержку диаграмм, так и специальные средства, которые появляются достаточно часто. В любом случае причина появления подобных средств понятна (они будут рассмотрены более подробно), но прежде следует подвести некоторые итоги того, что было рассмотрено в предыдущей части курса моделей и методологий, а также сделать краткие выводы, чтобы перейти к практической части более естественным образом.

По поводу моделей и методологий нужно заметить, что это наиболее абстрактная формализация всего жизненного цикла ПО. Как правило, методологии включают все этапы ЖЦ, за редким исключением. Правильный выбор модели и методологии (если речь идет о жизненном цикле, то лучше употреблять термин «модели», методологии – это просто набор практических приемов реализации этого ПО того или иного программного проекта или программного продукта). Выбор модели критическим образом сказывается в целом на успехе проекта, поскольку он определяет архитектуру проекта, архитектуру решения, из какого количества компонентов будет состоять решение, какие технологии будут использоваться, как эти компоненты будут взаимодействовать. Во многом определяется экономика проекта, поскольку существует глобальный документ – план проекта, тесно связанный с той моделью и методологией, которая принимается для разработки. И в этом плане, естественно, трудозатраты будут указываться в соответствии с выбранной моделью. Некоторые модели, скажем каскадная, поддерживают проектирование в один проход, являются документоориентированными, другие – неполный жизненный цикл, например модель Build-and-fix (модель проб и ошибок), либо итеративную или эволюционную разработку, когда на каждом этапе после завершения каждого частичного цикла появляется в общем готовый с точки зрения надежности продукт, пусть и не полнофункциональный. Здесь тоже во многом можно вести речь о раннем начале сопровождения, т. е. тоже об экономике проекта. Конечно, модель, также как и методология, должна учитывать опыт проектной команды. Естественно, если вести речь о больших системах, команда должна иметь опыт работы с той или иной моделью, с теми или иными стандартами. Конечно, серьезные модели требуют определенной дисциплины при проектировании и зрелости проектной команды, нужно соблюдать стандарты и знать в том числе CASE-средства, используемые командой для всех этапов проектирования и реализации системы. Поэтому стоит обсудить CASE-средства более подробно.

Универсальной модели не существует так же, как и универсального CASE-средства, несмотря на то, что есть линейка Rational, которая поддерживает практически все этапы жизненного цикла, Microsoft Visual Studio – достаточно серьезное средство, в том числе и для командной работы. Поэтому в ряде случаев хорошим подходом является комбинирование. Конечно, у всех моделей, также как и у всех CASE-средств, есть свои определенные преимущества и недостатки, они ранее упоминались. Так, спиральная модель требует оценки рисков, что, с одной стороны, является преимуществом, а с другой – влечет достаточно серьезные затраты, поэтому ее лучше применять для внутренних проектов, где разработчик может получить от заказчика полную информацию о рисках и сложностях, с которыми можно столкнуться в проекте с точки зрения представления предметной области. Преимущества и недостатки имеют смысл только в контексте проекта, исходя из этого следует выбирать не только модель жизненного цикла и методологию разработки, но и те технологические средства и архитектурные особенности, которые будут лежать в основе поддержки этого проекта.

По поводу проектирования и управления базами данных необходимо напомнить, что в основе корпоративных систем лежат базы данных достаточно большого объема, измеряемые тера-, а в ряде случаев – петабайтами (10¹⁵ байт). Размер, которого они могут достигать, достаточно быстро возрастает, примерно в 2 раза за пять лет. Это можно считать экспоненциальным ростом при достаточно больших базовых объемах, поэтому достаточно важно рассмотреть базы данных как элемент корпоративных систем.

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

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

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

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

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

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

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

Конечно, перспективны компонентные корпоративные приложения, как в архитектуре. NET или Java Bins, масштабируемые, мобильные, естественно, существуют и мобильные версии приложений. Компонентный подход. NET предполагает и мобильную версию. Например, мобильный смартфон на платформе Windows Mobile 5.0 также имеет. NET Framework, семейство классов. NET, и на том же самом языке C#, о котором пойдет речь, можно вести проектирование так же, как и на большой системе. Корпоративные клиенты могут получать доступ к данным с таких устройств. Как на платформе. NET, так и на платформе Java возможны подобные решения. Речь идет о клиент-серверных решениях, причем, как правило, трехзвенных, с явным выделением прикладной логики в отдельный слой. Перспективные направления развития корпоративных систем – это кроссплатформенность, т. е. возможность миграции с платформы на платформу (здесь под платформой можно понимать операционную систему и более высокий прикладной уровень), также интероперабельность и безопасность, это достаточно важные тенденции. Интероперабельность связана с компонентным проектированием, т. е. с возможностью гибкого наращивания функциональности или производительности за счет небольшой локальной доработки отдельных компонентов.

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

Как уже было отмечено, важные составляющие корпоративных систем – это база данных и СУБД. Перечислим основные стандарты, которым имеет смысл следовать, определившись со стратегией и тактикой реализации корпоративного приложения. В частности, большое значение имеют стандарты UML, Rational Unified Process и Microsoft Solution Framework. Существуют корпоративные стандарты, ряд объектных стандартов, например COM, DCOM, COM+, объектные модели Microsoft, модель Java Bins, компонентная модель Java, модель брокеров объектных запросов CORBA и целый ряд других. Здесь, может быть, нет строгой математической интерпретации, но тем не менее это некая формализация и во многом официальный стандарт, которого следует придерживаться.

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

Теперь уже предметно рассмотрим CASE-средства, которые помогают автоматизировать проектирование корпоративных приложений. Попробуем выделить несколько направлений классификации CASE-средств, принципы их упорядочивания, организации, поскольку их действительно достаточно много и многие из них реализуют целый ряд полезных идей, которые было бы целесообразно использовать при производстве корпоративных приложений. Рассмотрим классификации по масштабам применения, видам моделирования (здесь речь идет не совсем о математических моделях, хотя есть CASE-средства, которые используют раскрашенные сети Петри и другие интересные математические формализации, но их не так много) и функциональному назначению. Дадим определение CASE-средств, рассмотрим их основные функции и состав, а также достаточно большое количество примеров с описанием функций основных CASE-средств, которые популярны прежде всего в нашей стране. На Западе традиционно используется немного иной набор CASE-средств. Например, в России достаточно популярно CASE-средство Borland Delphi, а в США оно практически не используется, т. е. срез распространенности, или популярности, CASE-средств в нашей стране и за рубежом выглядит иначе.

Что такое CASE, или Computer Aided Software Engineering? Software Engineering – это программная инженерия, та самая дисциплина, которая и ведет к построению качественных, надежных, производительных, масштабируемых, больших программных систем и комплексов, в том числе в масштабах корпорации. А CASE – это инструментальные средства, которые поддерживают создание таких систем, т. е., по сути, весь жизненный цикл корпоративных приложений. Рассмотрим основные этапы жизненного цикла и задачи, которые пользователи CASE-средств или разработчики решают в ходе создания корпоративных приложений. Во-первых, это анализ и спецификация требований к функционалу и других проектных ограничений к программному обеспечению, которое будет создаваться, проектирование прикладного программного обеспечения и баз данных, т. е. речь идет о диаграммировании и архитектурном проектировании. CASE-средства позволяют в отношении баз данных строить схему базы данных по ER-модели, по ER-диаграмме. Кодогенерация в определенной мере производится также автоматически, например, по диаграмме классов можно строить сигнатуры классов автоматизированно, а также вести трассировку проектных спецификаций.

Когда речь идет о модели Microsoft, или модели синхронизации и стабилизации, следует заметить, что эта модель достаточно сложна, поскольку она требует автоматизации тестирования. Также стоит отметить, что средства тестирования, такие как Rational Robot, достаточно широко распространены в мире CASE-средств. Есть похожее средство и у Microsoft.

Рассмотрим средства документирования. Когда речь идет о большом количестве билдов, большом количестве релизов ПО, нужно поддерживать каждый релиз своей версией документации, которая также имеет версии. Вести контроль этих версий и изменений, которые были внесены, достаточно сложно, особенно если документирование ведется вручную и документация имеет большой объем, вполне сопоставимый, а иногда и превосходящий объем кода. Скажем, документация только для пользователей по одному модулю Oracle Applications – это книга объемом примерно 700 страниц с большим количеством иллюстраций, перекрестными ссылками, глоссарием и целым рядом других вещей для быстрого поиска информации. Конечно, создавать такие документы вручную и отслеживать их взаимосвязи, что очень важно в проекте, в случае корпоративных систем без CASE-средств невозможно.

Далее речь пойдет о системах обеспечения качества, в том числе тестирования и трассировки спецификации. Рассмотрим управление конфигурацией. Как было отмечено ранее, проекты сложны, в них большое количество файлов (тысячи, может быть, десятки тысяч) и каждая версия характеризуется их уникальным набором. Если некорректно учитывать состав этой версии и собирать ее, ПО будет ненадежным или вообще неработоспособным. Когда речь идет о корпоративной системе, это, конечно, недопустимо. Поэтому управление конфигурацией, полный учет модулей и проектной документации, которая их сопровождает, – это тоже важная функция CASE-средств. Еще одной важной функцией является управление проектом, организация взаимодействия на основе, скажем, программного инструментального CASE-средства Microsoft Visual Studio Team System, и целый ряд других процессов.

На самом деле CASE-средства поддерживают весь жизненный цикл и все процессы, сопровождающие ЖЦ, которые приводят к построению надежного, устойчивого, масштабируемого, сопровождаемого, эргономичного ПО. Ведь CASE-средства поддерживают и тестирование, и пользовательский интерфейс, а это достаточно сложная задача, если решать ее вручную. В качестве примера можно привести проект создания системы учета, планирования, управления людскими ресурсами. В проекте достаточно гибкая цепочка ввода данных – порядка 20 форм, которые можно настраивать в зависимости от типа пользователя. То есть когда человек устраивается на работу, он должен заполнить анкету, состоящую на самом деле из последовательного ввода данных в формы. При этом в каждой форме существуют обязательные и необязательные поля, а также поля, которые подразумевают только выбор из уже существующих вариантов, т. е. самостоятельно заполнять эти поля нельзя, и т. д. Настраиваются эти поля достаточно гибко. Понятно, что при создании такого количества форм проверить вручную нажатие всех кнопок и выбор всех вариантов не представляется возможным, поскольку сценарий ввода данных гибко настраивается в зависимости от типа пользователя. Такого рода сложные интерфейсы и позволяют тестировать специализированные CASE-средства.

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

CASE-средства включают также графические средства как для анализа и проектирования, так и для последующих шагов жизненного цикла. Это возможность создания и редактирования целого ряда диаграмм, например Microsoft Visual Studio, которая поддерживает большое количество диаграмм на основе интеграции со средством Visio. Линейка Rational поддерживает практически все виды UML-диаграмм, поскольку изначально ориентирована на этот язык и стандарт моделирования. Другой стандарт – это IDEF, диаграмма потоков данных, ER-диаграммы и ряд других диаграмм относятся к этому стандарту.

Другими компонентами CASE-средств являются средства, поддерживающие разработку прикладного ПО, т. е. создание программного кода. Здесь сразу следует отметить такие интересные возможности, как IntelliSense с цветовой подсветкой синтаксиса, выделением метаинформации, например, членов данных классов при вводе имени класса и т. д., которые существуют в Microsoft Visual Studio.NET.

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

Какого рода критерии классификации можно выделить, если вести речь о CASE-средствах? Их достаточно много. Первые CASE-средства появились в 1990-х гг. В журнале «Byte» от марта 1993 г., который был полностью посвящен CASE-средствам, были описаны методологии проектирования и поддерживающие их CASE-средства. Существовала методология Буч известного автора Гради Буча, сотрудничество которого с Якобсоном и Рамбо привело к созданию языка UML с целым рядом диаграмм. Ивар Якобсон тоже работал в те времена, когда происходило становление CASE-средств. Первые CASE-средства были основаны в том числе на диаграммах потоков данных, так как объектных моделей в полной мере тогда, наверное, не было или они были в начальном состоянии. Также широко использовались ER-диаграммы.

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

Естественно, хорошим критерием классификации может явиться стандарт. Скажем, поддерживают ли CASE-средства UML-диаграммирование, или IDEF-диаграммы, или XML как формат хранения и т. д. Методологии проектирования тоже очень важны. Поддерживает ли это средство MSF или Rational Unified Process и в каком объеме, в каких аспектах? Какие модели корпоративных информационных систем, в частности баз данных, поддерживаются? Поддерживаются ли ER-модели и вообще реляционные модели данных или, может быть, поддерживается сетевая иерархическая модель данных, объектная модель определенного рода?

С какого рода СУБД эти CASE-средства интегрированы – еще один критерий. Может быть, эти средства рассчитаны только на кодогенерации, ведь структуры данных могут быть снабжены также ограничением целостности и триггерами и хранимыми процедурами на определенных языках. Скажем, существует язык PL/SQL, который предназначен специально для СУБД Oracle, и какие-то CASE-средства поддерживают только базы данных Oracle или ориентированы преимущественно на Oracle, другие ориентированы преимущественно на Microsoft SQL Server. Эти базы данных и SQL-серверы более подробно будут рассмотрены в дальнейшем.

Начнем по порядку рассматривать CASE-средства и отмечать те их аспекты, которые полезны и укладываются в ту или иную классификацию. Одним из первых CASE-средств, достаточно серьезных и хорошо известных в нашей стране, является BPwin. Как правило, оно используется в комплексе с Erwin, которое генерирует ER-диаграммы и по ER-диаграммам – схемы базы данных. Автором является Computer Associates. Здесь поддерживается методология IDEF0, DFD-диаграмма потоков данных, и основным назначением является функциональное моделирование и анализ деятельности предприятия. То есть речь идет об анализе и спецификации требований. Эта часть жизненного цикла в основном и реализуется CASE-средством BPwin.

В качестве модели данных используется не объектная модель данных, а диаграмма процессов, это очень похоже на DFD и является некоторым развитием. Это более ранняя технология, структурный анализ и проектирование (Structured Analysis and Development Technology, SADT), современный подход называется объектно-ориентированным (Object Oriented Analysis and Development, OOAD). При этом учитываются этапность, стоимость, длительность и периодичность процессов, т. е. в основе лежат диаграммы процессов, и с помощью этого средства возможно проанализировать бизнес-процессы на предприятии, их формальное описание и построение определенных диаграмм, которые позволят оценить стоимость затрат на внедрение системы, узкие места технологических цепочек и затратные центры – другими словами, точки, которые потребуют наибольших затрат.

Полезна интеграция с Erwin, которая поддерживает ER-модель как направление, и генерация отчетов в достаточно распространенных форматах офисных приложений MS Word, MS Excel. Связанным с этим CASE-средством является CASE-средство Erwin той же компании изначально. Это CASE-средство для проектирования и реализации баз данных, т. е. работа идет с IDEF1X-диаграммами, с ER-диаграммами стандартного вида. Здесь достаточно полный набор возможностей: можно строить, настраивать, проектировать в графическом виде ER-диаграммы с атрибутами сущностей, связей, поддерживать индексы и ограничение целостности на основе бизнес-правил.

При этом поддерживается достаточно большое количество SQL-серверов или серверов баз данных – это и Oraсle, и Microsoft, и целый ряд других (Informix, Sybase, Progress, DB2 от IBM) СУБД корпоративного типа. И кроме того, поддерживаются достаточно легкие настольные системы, большинство из них, конечно, уже устарело, но Microsoft Access, например, достаточно современная система, Clipper до сих пор используется, также как и СУБД Paradox, в свое время созданная корпорацией Borland, и целый ряд других систем. При этом важно, что по ER-диаграммам автоматически производится генерация SQL-кода и триггеров, т. е. процедуры, которые поддерживают ограничение целостности. Возможен реинжиниринг базы данных, т. е. по SQL-коду можно восстановить структуру базы. Поддерживает кроме большого количества серверов баз данных достаточно большое количество CASE-средств, и осуществляется возможность коллективной разработки баз данных. Здесь поддерживаются форматы Oracle, Sybase, Microsoft SQL Server.

Что интересно, кроме BPwin, возможна интеграция и с другими CASE-средствами от сторонних производителей, в том числе Delphi – достаточно популярным и распространенным в России CASE-средством.