Объектно-ориентированное проектирование

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

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

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

В основе ОО подхода лежат понятия:

· Объект;

· Класс;

· Инкапсуляция;

· Наследование;

· Полиморфизм.

Объект — конкретный предмет, реальная или абстрактная сущность. Каждый объект является представителям («экземпляром») некоторого класса однотипных объектов. Класс определяет общие свойства для всех его объектов. К таким свойствам относятся:

· Состав и структура данных, описывающих атрибуты класса и соответствующих объектов;

· Совокупность методов — процедур, определяющих взаимодействие объектов этого класса с внешней средой (другими объектами).

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

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

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

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

Для ОО моделирования широко используется унифицированный язык моделирования Unified Modeling Language (UML), разработанный группой ведущих производителей ПО Object Management Group (OMG). UML фактически является стандартом по ОО технологиям. Язык UML реализован многими фирмами в рамках CASE-технологий, например: Rational Rose (фирма Rational), Natural Engineering Workbench (фирма Software AG) и т.д.

CASE-технология

В настоящее время не существует общепринятого определения CASE (C omputer- A ided S oftware/ S ystem E ngineering). Содержание этого понятия обычно определяется перечнем задач, решаемых с помощью CASE, а также совокупностью применяемых методов и средств. Очень грубо, CASE-технология представляет собой совокупность методологий анализа, проектирования, разработки и сопровождения сложных ИС, поддерживаемую комплексом взаимоувязанных средств автоматизации.

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

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

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

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

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

Появлению CASE способствовали:

· достижения в области методологии программирования, программирование приобрело черты формализованного процесса, а не искусства;

· подготовка аналитиков и программистов, восприимчивых к концепциям модульного, структурного и объектно-ориентированного программирования;

· широкое внедрение и постоянный рост производительности ПК, позволяющий эффективно использовать графические средства;

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

Преимущества CASE по сравнению с традиционной технологией оригинального проектирования:

· улучшение качества разрабатываемой ИС за счет средств автоматического контроля и генерации кода;

· возможность повторного использования компонентов разработки;

· поддержание адаптивности и сопровождения ИС;

· сокращение сроков создания системы, что позволяет на ранних стадиях проектирования получить прототип будущей системы и оценить его;

· освобождение разработчиков от рутинных операций документирования проекта за счет использования встроенного документатора;

· возможность коллективной разработки ИС в режиме реального времени.

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

Метод — процедура или техника создания описаний элементов ИС (например, потоков или структур данных).

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

Инструментальные средства CASE — специальные программы, которые поддерживают одну или несколько методологий анализа и проектирования ИС.

Архитектура CASE-средства:

 

Графический редактор диаграмм	Верификатор диаграмм	Генератор программного кода
	репозиторий
Документатор проекта	Сервисы	Администратор проекта

 

Ядром системы является база данных проекта — репозиторий. Репозиторий представляет собой специализированную базу данных, хранящую информацию о состоянии элементов проектируемой ИС и взаимосвязях между ними в каждый момент времени. Объекты всех диаграмм синхронизированы на основе общей информации словаря данных. В глобальном смысле:

Репозиторий (репозитарий) — разделяемая (инструментальными средствами и системами) корпоративная база данных, содержащая информацию об объектах проектирования, надмножество словарей метаданных.

В общем случае, в репозитории хранятся описания следующих объектов:

· проектировщиков и их прав доступа к различным компонентам системы;

· организационных структур;

· диаграмм;

· объектов диаграмм;

· структур диаграмм;

· связей между диаграммами;

· программных модулей;

· и т.д.

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

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

Верификатор диаграмм контролирует правильность построения диаграмм в заданной методологии проектирования.

Документатор проекта — построение различных отчетов.

Администратор предоставляет инструменты для выполнения следующих функций:

· инициализация проекта, задание начальных параметров;

· назначение и изменение прав доступа к элементам проекта;

· отслеживание графика выполнения проекта.

Сервисы — утилиты по обслуживанию репозитория (архивация, восстановление, создание, удаление).

Современные CASE-системы классифицируются по следующим признакам:

· по поддерживаемым методологиям проектирования: функционально(структурно)-ориентированные и объектно-ориентированные;

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

- с фиксированной нотацией;

- с отдельными нотациями;

- с наиболее распространенными нотациями;

· по степени интегрированности:

- отдельные локальные средства (tools),

- набор неинтегрированных средств, охватывающих большинство этапов разработки ИС (toolkit),

- полностью интегрированные средства (workbench), связанные общей базой проектных данных (репозиторием);

· по типу и архитектуре вычислительной техники:

- ориентированные на ПК,

- ЛВС,

- ГВС,

- смешанного типа;

· по режиму коллективной разработки проекта:

- не поддерживающие коллективную разработку;

- ориентированные на проектирование в режиме реального времени;

- ориентированные на режим объединения подпроектов;

· по типу операционной системы, под управлением которой может работать CASE.

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

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

· наличие базы проектных данных (репозитория), архива или словаря. СУБД и репозитории обеспечивают высокую степень интеграции данных и предоставляют широкие возможности для централизованного сбора, хранения и распределения проектной информации между различными этапами проекта и выполняемыми операциями;

· интерфейсы с другими CASE-системами. В процессе проектирования ИС могут использоваться различные методологии, поэтому важно, чтобы используемые CASE предоставляли возможности для использования нескольких методологий. При этом должна быть обеспечена терминологическая совместимость различных методологий;

· возможности импорта /экспорта, открытая архитектура. Спецификации, полученные на этапах анализа, проектирования и кодирования одной ИС, могут быть использованы при проектировании другой системы с использованием других CASE-систем;

· многопользовательский режим. Современные CASE должны обладать возможностями разделения полномочий персонала разработчиков и объединения отдельных работ в общий проект;

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

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

· автоматическая генерация отчетов о проектных решениях;

· генерация кодов программ. CASE-системы с жесткой ориентацией на конкретные СУБД должны обеспечивать возможность генерации программ в среде этих СУБД;

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

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

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

Технология RAD

Одним из возможных подходов к разработке ИС в рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ИС, характеризующийся тремя элементами:

• небольшая команда аналитиков и программистов (от 2 до 10 человек);
• короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);
• повторяющийся цикл, при котором разработчики, по мере того, как ИС начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком.

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

Жизненный цикл по методологии RAD состоит из четырех фаз:

• фаза анализа и планирования требований;
• фаза проектирования;
• фаза построения;
• фаза внедрения.

На фазе анализа и планирования требований:

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

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

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

Результатом данной фазы должны быть список и приоритетность функций будущей ИС, предварительные функциональные и информационные модели ИС.

На фазе проектирования:

- часть пользователей принимает участие в техническом проектировании системы под руководством специалистов-разработчиков.

- используются CASE-средства для быстрого получения работающих прототипов приложений.

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

- Более подробно рассматриваются процессы системы. Анализируется и, при необходимости, корректируется функциональная модель ИС.

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

- Определяются требования разграничения доступа к данным.

- Происходит определение набора необходимой документации.

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

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

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

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

На фазе построения:

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

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

- Тестирование системы осуществляется непосредственно в процессе разработки.

Репозиторий (репозитарий) — разделяемая (инструментальными средствами и системами) корпоративная база данных, содержащая информацию об объектах проектирования, надмножество словарей метаданных.

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

• определяется необходимость распределения данных;
• производится анализ использования данных;
• производится физическое проектирование базы данных;
• определяются требования к аппаратным ресурсам;
• определяются способы увеличения производительности;
• завершается разработка документации проекта.

Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.

На фазе внедрения:

- производится обучение пользователей;

- осуществляются организационные изменения;

- параллельно с внедрением новой системы ведется работа с существующей системой (до полного внедрения новой).

Так как фаза построения достаточно непродолжительна, планирование и подготовка к внедрению должны начинаться заранее, как правило, на этапе проектирования системы.

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

· разрабатывается совершенно новая система;

· уже было проведено обследование предприятия и существует модель его деятельности;

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

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

Методология RAD неприменима для построения сложных расчетных программ, операционных систем или программ управления сложными техническими объектами, т.е. программ, требующих написания большого объема (сотни тысяч строк) уникального кода.

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

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

< 1000 функциональных элементов	один человек
1000-4000 функциональных элементов	одна команда разработчиков
> 4000 функциональных элементов	4000 функциональных элементов на одну команду разработчиков

В качестве итога перечислим основные принципы методологии RAD:

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