Файл: Lektsii_TP.doc

На базе технологии COMиDCOMбыли разработаны компонентные технологии, решающие различные задачи разработки ПО:

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

- ActiveX– технология, построенная на базеOLE-automation, предназначенная для создания ПО, как сосредоточенного на одном компьютере, так и распределенного в сети. Предполагает использование визуального программирования для создания компонентов – элементов управленияActiveX. Полученные таким образом элементы управления могут устанавливать на компьютер дистанционно с удаленного сервера, причем устанавливаемый код зависит от используемой ОС. Это позволяет применять элементы управленияActiveXв клиентских частях приложенийInternet. Основные преимуществаActiveX:

• Быстрое написание программного кода, так как все действия, связанные с организацией взаимодействия сервера и клиента на программное обеспечение COM, программирование сетевых приложений становится похожим на программирование самого компьютера;

• Открытость и мобильность. Сертификация технологии передана в OpenGroup, как основа открытого стандарта;

• Возможность написания приложений с использованием знакомых приложений, таких как VisualC++,BorlandC++ и т.д. и любых средств разработкиJava;

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

• Стандартность. Технология ActiveXоснована на стандартахInternet(TCP/IP,Java,HTML) с одной стороны и стандартах, необходимых для сохранения совместимости (COM,OLE), с другой.

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

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

Все указанные технологии реализуют компонентный подход, заложенный в COM. С точки зренияCOM, элемент управленияActiveX– это внутренний сервер, поддерживающий технологиюOLE-automation. Для программиста элементActiveX– это «черный ящик», обладающий свойствами, методами и событиями, которые можно использовать, как строительный блок при создании приложений.

- Технология CORBA. Разработана группой компанийOMG(ObjectManagementGroup) (группа внедрения объектных технологий программирования). Она реализует подход аналогичныйCOMна базе объектов и интерфейсовCORBA. Программное ядроCORBAреализовано для всех основных аппаратных и программных платформ, поэтому эту технологию можно использовать для создания распределенного ПО в гетерогенной вычислительной среде. Организация взаимодействия между объектами клиента и сервер вCORBAосуществляется с помощью специального посредникаVisiBrokerи других специальных ПО.

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

1.2. Проблемы разработки сложных программных систем

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

Дополнительные факторы, увеличивающие сложность разработки программных систем:

1). Сложность форматного определения требований к программным системам.

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

3). Коллективная разработка.

4). Необходимость увеличения степени повторяемости кодов.

Сложность определения требований обуславливается двумя факторами:

1). При определении требований необходимо учитывать большое количество различных факторов.

2) Разработчики программных систем не являются специалистами в автоматизируемых предметных областях и наоборот.

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

1.3 Блочно-иерархический подход к созданию сложных систем

Большинство сложных систем в природе и технике имеет иерархическую внутреннюю структуру. Это связано с тем, что связи элементов сложных систем различны по типу и по силе, что позволяет рассматривать системы как совокупность взаимозависимых подсистем.Внутренние связи элементов таких подсистем сильнее, чем связи между подсистемами. Используя то же различие связей, каждую подсистему можно разделить на подсистемы и т.д. до самого нижнего «элементарного» уровня (выбор уровня, компоненты которого следует считать элементарными, остается за исследователем). На элементарном уровне система состоим из немногих типов подсистем, по-разному скомбинированных и организованных. Иерархии такого типа получили название «целое – часть».

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

В природе существует и иерархия «простое – сложное»или иерархия развития (усложнения) систем в процессе эволюции. Здесь любая функционирующая система является результатом развития более простой системы (данный вид иерархии реализуется механизмом наследования ООП).

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

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

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

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

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

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

Примечание. Понятие сложного объекта по мере совершенствования технологий меняется: то что было сложным вчера, не обязательно останется сложным завтра.

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

• непротиворечивость – контроль согласованности элементов между собой;

• полнота – контроль на присутствие лишних элементов;

• формализация – строгость методического подхода;

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

• локальная оптимизация – оптимизация в пределах уровня иерархии.

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

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

Использование блочно-иерархического подхода:

• делает возможным создание сложных систем;

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

• обеспечивает возможность модернизации систем, например, замены ненадежных блоков с сохранением их интерфейсов.

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

1.4. Жизненные циклы, этапы разработки ПО

Жизненный цикл – период от момента появления идеи ПО до завершения его поддержки. Состав процессов ЖЦ регламентируется международным стандартом ISO/IEC12207. Этот стандарт описывает структуру ЖЦ ПО и его процессы. Процесс ЖЦ – это совокупность взаимосвязанных действий, преобразующих входные данные в выходные. Каждый процесс характеризуется определенными задачами, методами их решения, исходными данными, результатами. Структура процессов:

1. основные процессы: приобретение, поставка, разработка, эксплуатация, сопровождение;

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

3. организационные процессы: управление, усовершенствование, создание инфраструктуры, обучение.

По стандарту процесс разработки включает действия:

1. подготовительную работу – выбор модели ЖЦ стандартов, методов, средств разработки, составление плана работ:

2. анализ требований к системе – определение её функциональных возможностей, пользовательских требований, требований надежности и безопасности к внешним интерфейсам и т.д.

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

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

5. проектирование архитектуры ПО – определение структуры ПО, документирование интерфейсов его компонентов, разработка предварительной версии пользовательской документации, требования к тестам и планы интеграции.

6. детальное проектирование ПО – подробное описание компонентов ПО и интерфейсов между ними, разработка требований к тестам и плана тестирования ПО.

7. кодирование и тестирование ПО.

8. интеграция ПО – сборка программных компонентов

9. квалификационное тестирование ПО

10. интеграция системы

11. квалификационное тестирование системы

12. установка и приемка ПО.