 |
СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ #05-06/96
| |
С начала 90-х годов на Западе началось массовое внедрение в повседневную практику объектно-ориентированных (ОО) методов и CASE-средств, применяемых на всех этапах жизненного цикла прикладных программных систем. Причины, по которым многие разработчики программных систем отдают предпочтение ОО технологиям, заключаются в ряде преимуществ ОО методов и средств перед традиционными структурными. Главными из них являются возможность сборки программной системы из готовых повторно используемых компонентов; возможность накапливать опыт проектных решений в виде библиотек классов на основе механизма наследования; простота внесения изменений в проекты за счет инкапсуляции данных в объектах, использования свойств наследования и полиморфизма, что позволяет быстрее адаптировать приложения к изменяющимся требованиям бизнеса; возможность организации параллельной работы аналитиков, проектировщиков и программистов и сокращения тем самым времени, затрачиваемого на разработку.
В классической постановке решение задачи разработки программной системы (инжиниринг) представляет собой спиральный цикл, основанный на итеративном чередовании этапов ОО анализа, проектирования и программирования (реализации). Инжиниринг предполагает построение различных моделей программной системы, которые отражают различные взгляды на нее и служат основой для программирования. Система создается как последовательность исполняемых релизов, каждый из которых все более полно отвечает предъявляемым к системе требованиям.
Однако в реальной жизни разработка программной системы редко начинается "с нуля". Обычно программная система имеет некоторую предысторию в виде совокупности программ, реализующих - частично или полностью - требования к системе. Разработка таких систем базируется на процессе реинжиниринга программных кодов, при котором путем анализа текстов программ восстанавливается исходная модель программной системы, которая затем развивается теми же методами, что и при инжиниринге. Современные CASE-средства поддерживают как процесс инжиниринга, так и процесс автоматизированного реинжиниринга на основе кругового принципа, согласно которому не только изменения в модели отражаются в программной реализации, но и наоборот.
Следует особо подчеркнуть, что большинство ОО CASE-средств, первоначально задуманных как инструмент разработчика, могут использоваться не только при анализе и проектировании, но и весьма эффективны на других этапах жизненного цикла - при тестировании, сопровождении и развитии программных систем.
Исторически сложилось так, что ОО CASE начали создаваться в условиях, когда доминировала структурная методология разработки программных систем, а в рамках ОО подхода было предложено достаточно много различных методов разработки [2], которые отличаются как базовой нотацией, так и типами создаваемых моделей.
В настоящее время рынок ОО CASE включает средства, которые поддерживают несколько различных методов, и средства, ориентированные только на один метод. Средства первой группы предоставляют пользователю возможность выбора удобной для него нотации и преобразования из одной нотации в другую (хотя обычно с рядом ограничений). Некоторые из них позволяют создавать собственные нотации, представляя собой мета-CASE. Средства второй группы предоставляют более широкие возможности, предусмотренные в том или ином методе. Зачастую такие CASE-средства создавались под руководством авторов ОО методов (например семейство ОО CASE Rational Rose разработано под руководством Гради Буча - автора, пожалуй, наиболее ортодоксального ОО метода).
В настоящее время наблюдается сближение ОО методов, основой чему является достаточно большое число теоретических исследований в области ОО технологий. По существу различия между методами сводятся к разной форме представления моделей. В связи с этим стала актуальной задача создания унифицированной нотации, которая могла бы использоваться в различных методах. Авторы наиболее распространенных методов - Г. Буч [3], Д. Рамбо [4] и И. Джекобсон [5], - собравшись "под крылом" Rational Software Corporation, начали работу над унифицированным методом второго поколения. В настоящее время ими выпущена версия 0.9 унифицированного метода, которую они назвали Unified Modeling Language (Унифицированный язык моделирования - UML).
К концу 1996 года Rational обещает выпустить версию 1.0 UML и представить ее на рассмотрение OMG. Hewlett-Packard и Microsoft согласились поддержать это представление, и следует ожидать поддержку многих других компаний. Можно с большой вероятностью предсказать, что UML, возможно, с небольшими изменениями, будет утвержден OMG и к концу 1997 г. будет поддерживаться CASE-средствами всех фирм, желающими выжить на рынке ОО CASE. Остальные или исчезнут, или будут занимать весьма специализированные ниши.
Следует отметить еще одну тенденцию, состоящую в переориентации инструментальных средств, первоначально созданных для поддержки структурных методов разработки, на ОО методы. Комбинированные CASE поддерживают как ОО, так и структурные методологии. В принципе это упрощает переход на ОО технологии разработчикам, которые использовали такое средство в структурных разработках.
Существенным моментом является переход от простых клиент-серверных систем к распределенным (CORBA, DCOM). Это вынуждает поставщиков улучшать свои продукты. Сюда входят вопросы повторного использования, стандартных библиотек, Internet, языков типа Java, форматов типа HTML.
Немаловажное значение для распространения ОО CASE-средств имеют вычислительные платформы, на которых они реализуются. Сегодня это, как правило, Unix и Windows NT/95. Возможно, в дальнейшем ассортимент платформ расширится, но не раньше, чем через 2-3 года.
Таким образом, новый CASE конца 1997 г. должен качественно отличаться от сегодняшних средств. Поставщики должны будут многое добавить в свои продукты в ближайшие 6-12 месяцев. Не все компании выдержат эти требования и к 1998 г. сойдут с рынка. Для того чтобы представить, какие возможности должен предоставлять разработчикам современный ОО CASE, воспользуемся предложенной в [1] характеристикой идеального CASE-средства.
В любом ОО CASE-средстве можно выделить четыре основных блока: анализ, проектирование, разработка и инфраструктура.
Основой любого ОО CASE-средства является среда, в которой разработчики могут создавать диаграммы для различных моделей. Конечно, та или иная нотация диктует и модели, которые могут быть построены. Например, методы Г. Буча и Д. Рамбо (ОМТ) предусматривают возможность построения диаграмм классов, сценариев, состояний и переходов, которые описывают соответственно логические, функциональные и динамические аспекты модели программной системы.
Средство должно позволять разработчику возможность отбора выводимой на экран информации из всей совокупности данных, описывающих модели. Это особенно важно при разработке больших систем, когда число деталей становится ошеломляющим. Аналитик должен иметь возможность формировать представления разных уровней и уметь погасить ненужную информацию, оставив только то, что ему нужно для работы на данном уровне анализа.
При хранении диаграмм в репозитории CASE-система должна обеспечивать их согласованность. Внесенные изменения в одну из диаграмм должны гарантированно отразиться и в остальных. Разработчик должен иметь возможность распечатывать диаграммы в процессе анализа.
CASE-средство должно позволять вносить комментарии в диаграммы и соответствующую документацию, чтобы иметь возможность фиксировать проектные решения, возникшие в процессе анализа.
Идеальный CASE обязан предоставлять разработчику возможность динамического моделирования в терминах событий. В большинстве современных средств такая возможность отсутствует, хотя она имеется в высококлассных ОО системах искусственного интеллекта, которые целесообразно интегрировать с CASE-средствами разработчика.
И наконец, идеальное инструментальное средство должно поддерживать несколько нотаций. Данное требование имело бы больший смысл в прошлом, когда шло соревнование нотаций. При движении фирм к объединенному языку моделирования значимость этого требования снижается. Однако сегодня желательно, чтобы современный CASE поддерживал хотя бы три нотации: Г. Буча, И. Джекобсона и OMT.
Приложение состоит не только из базовой бизнес-модели (которую в большинстве CASE-средств называют объектной моделью) и бизнес-правил, но также из интерфейса, управления, базы данных. Лишь немногие CASE-средства обеспечивают современную поддержку данных элементов. В большинстве случаев это произошло потому, что фирмы уже работали с такими инструментами, как PowerBuilder или Visual Basic, реализующими разработку интерфейса и обеспечивающими организацию базы данных, оставляя на CASE-средства разработчика моделирование основных бизнес-процессов.
Современные ОО CASE-средства должны поддерживать весь процесс проектирования приложения. Дополнительно должны быть возможности работы с библиотеками, средства поиска и выбора.
Идеальный ОО CASE должен обеспечивать разработчику возможность разрабатывать пользовательский интерфейс, поддерживать стандарты OLE, ActiveX, OpenDoc и доступ к библиотекам HTML/Java. Он также должен поддерживать разработку распределенных или двух- и трехзвенных клиент-серверных систем, что включает в себя работу с CORBA, DCOM, Internet (через IIOP и HTML).
После того как завершено проектирование приложения, следует генерировать его код. Учитывая, что основным принципом ОО подхода является итеративное прототипирование, разработчику приходится постоянно проектировать, генерировать код, модифицировать, развивать прототип, снова генерировать, модифицировать и развивать, каждый раз реализуя все большее количество требований. Более того, т. к. изменения вносятся в коды программы, то инструмент должен обеспечивать реинжиниринг, чтобы восстановить по коду диаграммы моделей и сравнить их с предыдущим вариантом.
Современные ОО CASE-средства обычно генерируют код на С++ или Smalltalk. В ближайшем будущем добавится Java.
Идеальное ОО CASE-средство должно генерировать код полностью из диаграмм. Большинство современных средств этого не делает, ограничиваясь скелетными заготовками под классы, атрибуты, методы, оставляя разработчику этап их заполнения реальным содержанием. Некоторые CASE-средства генерируют программный код для языков программирования третьего поколения, другие используют ОО 4GL, что дает возможность дорабатывать приложения в клиент-серверных CASE-средствах типа Power Builder. При этом важно, чтобы инструмент обеспечивал реинжиниринг кодов и внесение соответствующих изменений в модель системы.
CASE-средство должно содержать средства контроля, которые позволяют выявлять несоответствие между диаграммами и генерируемыми кодами и обнаруживать ошибки как на стадии проектирования, так и на стадии реализации.
Центральное место в инфраструктуре ОО CASE-средства занимает репозиторий, построенный на базе данных. Хорошо организованный репозиторий гарантирует, что изменения в одной из диаграмм отразятся во всех остальных. Репозиторий отвечает за генерацию кода, реинжиниринг, отображение кода на диаграммах, а также обеспечивает соответствие между моделями и программными кодами.
В прошлом репозитории основывались на реляционных базах данных и были медленными и трудными в использовании. Для ОО CASE-средств более подходят ОО базы данных. Однако эффективность репозитория в той или иной степени зависит от того, кто разрабатывает систему управления им. Есть попытки создания стандартного репозитория (например Unisys, IBM, Texas Instruments, Microsoft), но практического результата пока нет. Если такой общий репозиторий будет создан, то, несомненно, CASE-средства им воспользуются, так как это шаг к сближению библиотек, проектных решений, программных кодов и т. п. Но пока это еще дело будущего.
В дополнение к репозиторию, инфраструктура включает обеспечение командной работы и реинжиниринга. Средства командной работы обычно обеспечивают многопользовательскую работу и управление версиями. Это позволяет разбивать проект на модули, которые разрабатываются независимо разными участниками проекта. Так как ОО CASE-средства, как правило, применяются для крупных проектов, обеспечение удобной коллективной работы жизненно важно для хорошего инструментального средства.
Если в стандартизации нотации достигнут значительный прогресс, то этого нельзя сказать о стандартизации методик. В принципе все соглашаются, что ОО методики включают в себя итерации и прототипирование. Также все согласны, что предложенные И. Джекобсоном "варианты использования" (use cases) [5] - удобное средство для начальной стадии разработки. Все остальное пока весьма туманно.
Rational предлагает неформальный подход к разработке проектов, названный "Управляемая итеративная разработка" (CID-Controlled Iterative Development). Согласно концепции Rational, ОО методика требует "итеративного побудительнного мотива" ("iteration" driver"). Это некоторое предположение, направляющее разработчиков по пути выбора объектов, создания первого варианта приложения и дальнейшего развития проекта. Таким побудительным мотивом может быть максимально скорое достижение осязаемого результата, откладывание в сторону дорогостоящих задач, более быстрое получение обратной связи от пользователя и тому подобное.
По методике CID после того, как разработчики завершат анализ требований, следует сконцентрироваться на критических частях проекта, наиболее рискованных с точки зрения успешного завершения проекта. Далее следует разработать прототип, доказывающий возможность справиться с этой ситуацией. По результату прототипирования разрабатывается проект, а в это время выбирается очередная рискованная область проекта и строится ее прототип и т. д. Такой подход является разновидностью минимаксной стратегии и гарантирует минимум потерь в виде затрат на проекты, которые не могут быть успешно завершены.
В то время как Rational разрабатывает идеи CID, Platinum предлагает свой подход, называемый "Моделирование элементов предприятия" (ECM-Enterprise Component Modeling). Здесь также подразумевается прототипирование, но больше внимание уделяется выявлению элементов, которые можно будет повторно использовать в последующих проектах.
И Rational, и Platinum являются сторонниками возвратного проектирования (Round TRip Engineering - RTE), предусматривающего восстановление модели по программному коду. Реинжиниринг существенен в методологиях, основанных на прототипировании. Вы генерируете код для прототипа и тестируете его. По результатам тестирования код модифицируется, и надо проанализировать измененную модель перед тем, как перейти к следующей итерации. В этом состоит суть RTE.
IBM исследует семантические модели и потоки деятельностей (BPR workflow models), другие фирмы изучают, каким образом можно применять аппарат шаблонов (patterns) при создании ОО приложений. Никто не знает, что предпочтительнее для объединения с ОО разработками: CORBA, DCOM, OpenDOC, ActiveX или Internet.
Таким образом, если время стандартизации нотации уже наступило, то различных подходов к ОО разработке все еще очень много и хочется надеяться, что через пару лет такой ОО метод появится.
В таблице 1 приведен обзор популярных инструментальных средств, продаваемых в Северной Америке. Указаны платформа, цена, поддерживаемая нотация, генерируемый код и некоторые замечания. Более полные данные приводятся в [2].
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Таблица 1.
Сравнительный анализ CASE-систем [1, 2] показывает, что на сегодняшний день одним из наиболее приближенных к идеальному варианту CASE-средств является семейство Rational Rose фирмы Rational Software Corporation. Следует полагать, что лидерство этой фирмы сохранится и в будущем, поскольку именно здесь работают авторы унифицированного языка моделирования - Г. Буч, Д. Рамбо и И. Джекобсон, под руководством которых ведется разработка нового CASE-средства, поддерживающего UML.
В настоящее время фирма Rational предлагает на рынке семейство Rational Rose версии 3.2. Системы, входящие в его состав, поддерживают методы Г. Буча и Д. Рамбо (ОМТ). Они отличаются языками, для которых генерируются программные коды. Среди них - С++, Ada, Smalltalk, Java, а также языки четвертого поколения - PowerBuilder, SQLWindows, Visual-Basic и другие.
Подводя итог, следует заметить, что, хотя CASE-средства поставляются с полной документацией и имеются теоретические разработки ОО методов, изложенные в литературе [3-5], решающее значение для судьбы проектов сложных программных систем имеет знание методик их разработки на основе конкретных CASE-средств, в которых отражается опыт разработки таких систем и которые не приводятся в документации.
1. Harmon P. Object-Oriented CASE. Object-Oriented Strategies V. 1, # 8, August 1996.
2. Новоженов Ю.В. Объектно-ориентированные технологии разработки сложных программных систем. - Аргуссофт компани, М. 1996, - 115 с.
3. Booch G. Object-Oriented Analysis and Design with Applications. - Bengamin/Cummings, Redword City, CA, USA, 1994.
4. Rumbaugh J., Blaha M. Object-Oriented Modeling and Design. - Prentis Hall Englewood Cliffs, NJ, 1991, - 500p.
5. Jacobson I. et al. Object-Oriented Software Engineering. - Addison-Wesley Reading, MA, 1992.
.gif) |