Файл: Применение объектно-ориентированного подхода при проектировании информационной системы (Основные принципы построения объектной модели).pdf

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

Детали, не учтенные в наборе ДПД, содержатся в словаре данных, который определяет потоки и хранилища данных, а также семантику различных имен.

Набор диаграмм состояния процессов играет ту же роль, что и динамическая модель в методологии ОМТ.

Диаграммы зависимостей объектов отражают зависимости между хранилищами данных. Эти диаграммы аналогичны объектной модели методологии ОМТ.

Так в методологии SA/SD организован этап структурного анализа (SA). После структурного анализа начинается этап структурного конструирования (SD), в процессе которого разрабатываются и уточняются более тонкие детали проектируемой системы.

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

В то же время методология SA/SD является одним из первых хорошо продуманных формальных подходов к разработке программных систем.

Методология JSD (Jackson Structured Development) предлагает свой стиль разработки программных систем; он отличается от стиля, принятого в методологиях SA/SD или ОМТ. Методология JSD, разработанная Майклом Джексоном в середине 80-х гг., особенно популярна в Европе. В методологии JSD не делается различий между этапом анализа требований к системе и этапом ее разработки; оба этапа объединяются в один общий этап разработки спецификаций проектируемой системы.

Как и другие методологии, методология JSD использует систему графических обозначений, хотя эта методология и менее ориентирована на графику, чем методологии SA/SD и ОМТ.

Разработка модели JSD начинается с изучения объектов реального мира. Целью системы является обеспечение требуемой функциональности. Модель JSD описывает реальный мир в терминах сущностей (объектов), действий и порядка выполнения действий. Разработка системы по методологии JSD включает следующие шесть фаз:

• разработка действий и объектов;

• разработка структуры объектов;

• разработка исходной модели;

• разработка функций;

• разработка временных ограничений;

• реализация системы.

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

На фазе разработки структуры объектов действия каждого объекта частично упорядочиваются во времени.

Фаза разработки исходной модели связывает реальный мир с абстрактной моделью, устанавливая соответствие между вектором состояния и потоком данных.

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

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

Наконец, на фазе реализации системы решаются проблемы управления процессами и распределения процессов по процессорам.

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

Тем не менее методология JSD может успешно применяться для проектирования и реализации следующих типов прикладных программных систем:

• параллельные асинхронные программные системы, в которых процессы могут взаимно синхронизировать друг друга;

• программные системы реального времени; методология JSD ориентирована именно на такие системы;

• программные системы для параллельных компьютеров; парадигма, принятая в методологии JSD, может здесь оказаться полезной. Методология JSD плохо приспособлена для решения следующих проблем:

• высокоуровневый анализ — методология JSD не обеспечивает широкого понимания проблемы, она неэффективна для абстракции и упрощения проблем;

• разработка баз данных — это слишком сложная проблема для методологии JSD.

Методология OSA (Object-Oriented System Analysis) обеспечивает объектно-ориентированный анализ программных систем и не содержит возможностей, связанных с поддержкой этапа разработки.

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

Методология OSA сосредоточена только на проблемах анализа, предлагая ряд интересных соображений, связанных с объектно-ориентированным анализом систем, специально исключая из рассмотрения особенности, характерные для разработки. Предлагая удобные и тонкие методы анализа систем, методология OSA обеспечивает интерпретацию моделей на компьютере на самых ранних этапах анализа системы: OSA реализована в системе программирования C++ на рабочей станции Hewlett-Packard 700 под управлением ОС HP-UX 9.01.

Методология OSA, как и другие методологии, поддерживает три взаимно-ортогональных представления (модели) проектируемой системы:

• модель зависимостей между объектами;

• модель поведения объектов;

• модель взаимодействия объектов.

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

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

Модель взаимодействия объектов — это набор представлений проектируемой системы, на которых показаны взаимодействия объектов между собой и с окружением системы.

Интерпретация и анализ представлений (моделей) проектируемой системы позволяют полностью формализовать описания объектов и получить строгую формальную спецификацию проектируемой системы до начала ее разработки.

Технология RUP (Rational Unified Process) представляет собой программный продукт, разработанный компанией Rational Software, которая в настоящее время входит в состав IBM.

RUP в значительной степени соответствует стандартам и нормативным документам, связанным с процессами ЖЦ ПО и оценкой технологической зрелости организаций-разработчиков (ISO 12207, ISO 9000, СММ и др.). Ее основными принципами являются:

• итерационный и инкрементный (наращиваемый) подход к созданию ПО;

• планирование и управление проектом на основе функциональных требований к системе — вариантов использования;

• построение системы на базе архитектуры ПО.

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

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

Методическую основу ТС ПО корпорации Oracle составляет метод Oracle (Oracle Method) — комплекс методов, охватывающий большинство процессов ЖЦ ПО. В состав комплекса входят:

• CDM (Custom Development Method) — разработка прикладного ПО;

• PJM (Project Management Method) — управление проектом;

• AIM (Application Implementation Method) — внедрение прикладного ПО;

• В PR (Business Process Reengineering) — реинжиниринг бизнес- процессов;

• OCM (Organizational Change Management) — управление изменениями и др.

Метод CDM оформлен в виде консалтингового продукта CDM Advantage — библиотеки стандартов и руководств (включающего также PJM). Он представляет собой развитие достаточно давно созданного Oracle CASE-Method. По существу, CDM является методическим руководством по разработке прикладного ПО с использованием инструментального комплекса Oracle Developer Suite, а сам процесс проектирования и разработки тесно связан с Oracle Designer и Oracle Forms.

В соответствии с CDM ЖЦ ПО формируется из определенных этапов (фаз) проекта и процессов, каждый из которых выполняется в течение нескольких этапов:

• стратегия (определение требований);

• анализ (формулирование детальных требований к системе);

• проектирование (преобразование требований в детальные спецификации системы);

• реализация (написание и тестирование приложений);

• внедрение (установка новой прикладной системы, подготовка к началу эксплуатации);

• эксплуатация.

Компания Borland в результате развития собственных разработок и приобретения целого ряда компаний представила интегрированный комплекс инструментальных средств, реализующих управление полным жизненным циклом приложений (Application Life Cycle

Management, ALM). В соответствии с технологией Borland процесс создания ПО включает в себя пять основных этапов:

• определение требований;

• анализ и проектирование;

• разработка;

• тестирование и профилирование;

• развертывание.

Выполнение всех этапов координируется процессом управления конфигурацией и изменениями. Определение требований реализуется с помощью системы управления требованиями CaliberRM, которая стала частью семейства продуктов Borland в результате покупки компании Starbase. CaliberRM сохраняет требования в базе данных, документы с их описанием создаются с помощью встроенного механизма генерации документов MS Word на базе заданных шаблонов. Система обеспечивает экспорт данных в таблицы MS Access и импорт из MS Word. CaliberRM поддерживает различные методы визуализации зависимостей между требованиями, с помощью которых пользователь может ограничить область анализа, необходимого в случае изменения того или иного требования. Имеется модуль, который использует данные требования для оценки трудозатрат, рисков и расходов, связанных с реализацией требований.

Средство анализа и проектирования Together ControlCenter разработано компанией TogetherSoft. В основе его применения лежит один из вариантов подхода «Быстрой разработки ПО» под названием Feature Driven Development (FDD).

Together ControlCenter — интегрированная среда проектирования и разработки, поддерживающая визуальное моделирование на UML с последующим написанием приложений для платформ J2EE (Java) и .Net (С#, C++ и Visual Basic). Кроме базовой версии имеется уменьшенный вариант системы для индивидуальных разработчиков и небольших групп (Together Solo), а также редакции для платформы IBM WebSphere и среды разработки Jbuilder.

В системе реализована технология LiveSource, которая обеспечивает синхронизацию между проектом приложения и изменениями — при внесении изменений в исходные тексты меняется модель программы, а при изменении модели надлежащим образом изменяется текст на языке программирования. Это исключает необходимость вручную модифицировать модель или переписывать код. Контроль версий осуществляется благодаря функциональной интеграции Together и системы StarTeam. Поддерживается также интеграция с системой управления конфигурацией Rational ClearCase.

Инструментальные средства тестирования появились в составе комплекса Borland в результате покупки компании Optimizeit. К ним относятся Optimizeit Suite 5, Optimizeit Profiler for .NET и Optimizeit ServerTrace.

Первые две системы позволяют выявить потенциальные проблемы использования аппаратных ресурсов — памяти и процессорных мощностей на платформах J2EE и .Net соответственно. Интеграция Optimizeit Suite 5 в среду разработки Jbuilder, a Optimizeit Profiler — в C#Builder и Visual Basic .Net позволяет проводить контрольные испытания приложений по мере разработки и ликвидировать узкие места производительности. Система Optimizeit ServerTrace предназначена для управления производительностью серверных J2EE-npH- ложений с точки зрения достижения заданного уровня обслуживания и сбора контрольных данных по виртуальным Java-машинам.