Файл: Учебное пособие.doc

Каждый интерфейс имеет имя, начинающееся с символа «I» и глобальный уникальный идентификатор IID (Interface IDentifier). Любой объект СОМ обязательно реализует интерфейс (Unknown (на схемах этот интерфейс всегда располагают сверху). Использование этого интерфейса позволяет получить доступ к остальным интерфейсам объекта.

Рис. 1.8. Взаимодействие программных компонентов различных типов

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

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

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

• удаленный сервер: создается процессом, который работает на другом компьютере.

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

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

1.1.5.Пятый этап – разработка, ориентированная на архитектуру и CASE-технологии (с начала XXI в. до нашего времени)

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

В ноябре 1997 года после продолжительного процесса объединения различных методик, группа OMG (Object Management Group) приняла получившийся в результате унифицированный язык моделирования (Unified Model Language – UML) в качестве стандарта. В 2001 году члены OMG начали работу над новой версией UML, добавляя в неё недостающие элементы и устраняя недостатки, выявленные в UML1. Версия UML2 была принята в 2004 году. С официальной спецификацией UML можно ознакомится на веб-сайте OMG по адресу www.omg.org.

Идея создания языка UML включала в себя не только реализацию стандарта для документирования и общения разработчиков, но и реализацию возможности использования UML как язык программирования. Этот момент вызывал массу проблем для реализации, так как язык визуального моделирования по определению не мог содержать в себе всей выразительности объектно-ориентированных языков в плане проектирования (программирования) динамики и реализации алгоритмов. Нужен был язык, который на более высоком (абстрактном) уровне смог бы обеспечить разработку на UML. Такой язык был создан – это объектный язык ограничений OCL (object constraint language).

Тенденции развития средств разработки программных систем заключаются в создании таких средств, которые обеспечили бы не только автоматизацию всех этапов и процессов разработки программных систем, но и обеспечили бы связь между результатами этапов. Одним из ключевых соединительных узлов является связь между проектными моделями и программным кодом. Когда разработка программных систем начинается от проектирования её структуры до последующего кодирования и все изменения в функциях, разрабатываемой системы, реализуются начиная с перепроектирования архитектуры, то такая технология называется ориентированной на архитектуру (Model Driven Architecture – MDA).

Компания Borland начиная с седьмой версии своей среды разработки (Delphi) уже использует набор компонент, реализующий подход, ориентированный на архитектуру, но в этой версии присутствует ещё масса недостатков и недоработок. В последней своей версии (Delphi 2006) компания Borland модернизировала технологию, ориентированную на архитектуру, что позволило использовать её для разработки промышленных приложений, в том числе и для платформы Microsoft Framework .Net.

1.2.Эволюция моделей жизненного цикла программного обеспечения

1.2.1.Каскадная модель

Первоначально (1970-1985 годы) была предложена и использовалась каскадная схема разработки программного обеспечения (Рис. 1 .9), которая предполагала, что переход на следующую стадию осуществляется после того, как полностью будут завершены проектные операции предыдущей стадии и получены все исходные данные для следующей стадии.

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

Рис. 1.9. Каскадная модель разработки программного обеспечения

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

Рис. 1.10. Каскадная модель разработки ПО с промежуточным контролем

Охарактеризуем содержание основных этапов.

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

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

Анализ требований относится к программному элементу – программному обеспечению. Уточняются и детализируются его функции, характеристики и интерфейс.

Все определения документируется в спецификации анализа. Здесь же завершается решение задачи планирования проекта.

Проектирование состоит в создании представлений:

• архитектуры ПО;

• модульной структуры ПО;

• алгоритмической структуры ПО;

• структуры данных;

• входного и выходного интерфейса (входных и выходных форм данных).

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

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

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

Сопровождение – это внесение изменений в эксплуатируемое ПО. Цели изменений:

• исправление ошибок;

• адаптация к изменениям внешней для ПО среды;

• усовершенствование ПО по требованиям заказчика.

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

Как и любая инженерная схема, классический жизненный цикл имеет достоинства и недостатки.

Достоинства классического жизненного цикла:

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

2. простота планирования процесса разработки.

Недостатки классического жизненного цикла:

1. реальные проекты часто требуют отклонения от стандартной последовательности шагов;

2. цикл основан на точной формулировке исходных требований к ПО (реально в начале проекта требования заказчика определены лишь частично);

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

1.2.2.Спиральная модель

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

Как показано на рисунке 2.11, модель определяет четыре действия, представляемые четырьмя квадрантами спирали.

1. Планирование – определение целей, вариантов и ограничений.

2. Анализ риска – анализ вариантов и распознавание/выбор риска.

3. Конструирование – разработка продукта следующего уровня.

4. Оценивание – оценка заказчиком текущих результатов конструирования.

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

Рис. 1.11. Спиральная модель: 1 – начальный сбор требований и планирование проекта; 2 – та же работа, но на основе рекомендаций заказчика; 3 – анализ риска на основе начальных требований; 4 – анализ риска на основе реакции заказчика; 5 – переход к комплексной системе; 6 – начальный макет системы; 7 – следующий уровень макета; 8 – сконструированная система; 9 – оценивание заказчиком

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

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

Достоинства спиральной модели:

1. наиболее реально (в виде эволюции) отображает разработку программного обеспечения;

2. позволяет явно учитывать риск на каждом витке эволюции разработки;

3. включает шаг системного подхода в итерационную структуру разработки;

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

5. Недостатки спиральной модели:

6. повышенные требования к заказчику;

7. трудности контроля и управления временем разработки.

1.2.3.Макетирование

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

Основная цель макетирования – снять неопределенности в требованиях заказчика.

Макетирование (прототипирование) – это процесс создания модели требуемого программного продукта.

Модель может принимать одну из трех форм:

1. бумажный макет или макет на основе ПК (изображает или рисует человеко-машинныый диалог);

2. работающий макет (выполняет некоторую часть требуемых функций);

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

Макетирование основывается на многократном повторении итераций, в которых участвуют заказчик и разработчик (Рис. 1 .12).

Рис. 1.12. Макетирование

Последовательность действий при макетировании представлена на рисунке 2.13.

Рис. 1.13. Последовательность действий при макетировании

Макетирование начинается со сбора и уточнения требований к создаваемому ПО. Разработчик и заказчик встречаются и определяют все цели ПО, устанавливают, какие требования известны, а какие предстоит доопределить.

Затем выполняется быстрое проектирование. В нем внимание сосредоточивается на тех характеристиках ПО, которые должны быть видимы пользователю.

Быстрое проектирование приводит к построению макета.

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

Достоинство макетирования: обеспечивает определение полных требований к ПО.

Недостатки макетирования:

1. заказчик может принять макет за продукт;

2. разработчик может принять макет за продукт.

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

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

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

1.2.4.Быстрая разработка приложений

Модель быстрой разработки приложений (Rapid Application Development) обеспечивает экстремально короткий цикл разработки. RAD – высокоскоростная адаптация линейной последовательной модели, в которой быстрая разработка достигается за счет использования компонентно-ориентированного конструирования. Если требования полностью определены, а проектная область ограничена, RAD-процесс позволяет группе создать полностью функциональную систему за очень короткое время (60-90 дней).

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