Технология разработки программного обеспечения

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

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

В UML это достигается с помощью диаграмм взаимодействий, которые описывают взаимодействия, состоящие из множества, объектов и отношений между ними, включая сообщения, которыми они обмениваются. Диаграммой последовательностей (Sequence diagram) начинается диаграмма взаимодействий, акцентирующая внимание на временной упорядоченности сообщений. Графически такая диаграмма представляет собой таблицу, объекты в которой располагаются вдоль оси X, а сообщения в порядке возрастания времени - вдоль оси Y. Диаграммой кооперации (Collaboration diagram) называется диаграмма взаимодействий, основное внимание в которой уделяется структурной организации объектов, принимающих и отправляющих сообщения. Графически такая диаграмма представляет собой граф из вершин и ребер.

Как правило, диаграммы взаимодействий содержат:

· объекты;

· связи:

· сообщения.

Диаграммы деятельности

Диаграммы деятельности - это один из пяти видов диаграмм, применяемых в UML для моделирования динамических аспектов поведения системы. Диаграмма деятельности - это, по существу, блок-схема, которая показывает, как поток управления переходит от одной деятельности к другой [2].

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

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

Диаграммы деятельности важны не только для моделирования динамических аспектов поведения системы, но и для построения выполняемых систем посредством прямого и обратного проектирования.

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

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

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

· из состояний деятельности и состояний действия;

· из переходов:

· из объектов.

Диаграммы состояний

Диаграммы состояний - это один из пяти видов диаграмм в языке UML, используемых для моделирования динамических аспектов. Ее частной разновидностью является диаграмма деятельности, в которой все или большая часть состояний - это состояния деятельности, а вес или большая часть переходов инициируются в результате завершения деятельности в исходном состоянии. Таким образом, при моделировании жизненного цикла объекта полезны как диаграммы деятельности, так и диаграммы состояний. Однако если диаграмма деятельности показывает поток управления от деятельности к деятельности, то на диаграмме состояний представлен поток управления от состояния к состоянию [2].

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

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

В UML для моделирования поведения объекта с точки зрения порядка возникновения событий используются диаграммы состояний.

Диаграмма состояний (Slatechart diagram) показывает автомат, фокусируя внимание на потоке управления от состояния к состоянию. Автомат (State machine) - это описание последовательности состояний, через которые проходит объект на протяжении своего жизненною цикла, реагируя на события, в том числе описание реакций на эти события. Состояние (State) - это ситуация в жизни объекта, на протяжении которой он удовлетворяет некоторому условию, осуществляет определенную деятельность или ожидает какое-то событие. Событие (Event) - это спецификация существенного факта, который происходит во времени и пространстве. В контексте автоматов событие - это стимул, способный вызвать срабатывание перехода.

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

Деятельность (Activity) - это продолжающееся неатомарное вычисление внутри автомата.

Действие (Action) - это атомарное вычисление, которое приводит к смене состояния или возврату значения. Диаграмма состояний изображается в виде графа с вершинами и ребрами.

Обычно диаграмма состояний включает в себя:

· простые и составные состояния;

· переходы вместе с ассоциированными событиями и действиями.

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

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

Архитектура

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

Архитектура - это совокупность существенных решений в отношении:

· организации программной системы;

· выбора структурных элементов, составляющих систему, и их интерфейсов;

· поведения этих элементов, специфицированного в кооперациях с другими элементами;

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

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

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

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

Вид с точки зрения прецедентов (Use case view) охватывает прецеденты, которые описывают поведение системы, наблюдаемое конечными пользователями, аналитиками и тестировшиками. Этот вид специфицирует не истинную организацию программной системы, а те движущие силы, от которых зависит формирование системной архитектуры. В языке UML статические аспекты этого вида передаются диаграммами прецедентов, а динамические диаграммами взаимодействия, состояний и действий.

Вид с точки зрения проектирования (Design view) охватывает классы, интерфейсы и кооперации, формирующие словарь задачи и ее решения. Этот вид поддерживает, прежде всего, функциональные требования, предъявляемые к системе, т.е. те услуги, которые она должна предоставлять конечным пользователям. С помощью языка UML статические аспекты этого вида можно передавать диаграммами классов и объектов, а динамические диаграммами взаимодействия, состояний и действий.

Вид с точки зрения процессов (Process view) охватывает нити и процессы, формирующие механизмы параллелизма и синхронизации в системе. Этот вид описывает главным образом производительность, масштабируемость и пропускную способность системы. В UML его статические и динамические аспекты визуализируются теми же диаграммами, что и для вида с точки зрения проектирования, но особое внимание при этом уделяется активным классам, которые представляют соответствующие нити и процессы.

Вид с точки зрения реализации (Implementation view) охватывает компоненты и файлы, используемые для сборки и выпуска конечного программного продукта. Этот вид предназначен в первую очередь для управления конфигурацией версий системы, составляемых из независимых (до некоторой степени) компонентов и файлов, которые могут по-разному объединяться между собой. В языке UML статические аспекты этого вида передают с помощью диаграмм компонентов, а динамические - с помощью диаграмм взаимодействия, состояний и действий.

Вид с точки зрения развертывания (Deployment view) охватывает узлы, формирующие топологию аппаратных средств системы, на которой она выполняется. В первую очередь он связан с распределением, поставкой и установкой частей, составляющих физическую систему. Его статические аспекты описываются диаграммами развертывания, а динамические - диаграммами взаимодействия, состояний и действий.

Каждый из перечисленных видов может считаться вполне самостоятельным, вследствие этого лица, имеющие отношение к разработке системы, могут сосредоточиться на изучении только тех аспектов архитектуры, которые непосредственно их касаются. UML позволяет отобразить каждый из пяти перечисленных видов и их взаимодействия [2].

Контрольные вопросы

1. Каковы задачи моделирования?

2. Перечислите задачи UML.

3. Из каких строительных блоков состоит UML?

4. Что такое сущность? Каковы типы сущностей в UML?

5. Перечислите и дайте определение основных структурных сущностей.

6. Какие сущности описывают поведение системы?

7. Как обозначаются классы в UML?

8. Что такое отношения в UML?

9. Дайте характеристику следующим отношениям: зависимость, обобщение, ассоциация.

10. Приведите примеры атрибутов ассоциаций.

11. Что такое кратность ассоциации?

12. Что определяют правила UML?

13. Перечислите виды диаграмм UML.

14. Перечислите принципы создания диаграмм.

15. Какие сущности обычно содержат диаграммы классов?

16. Какие диаграммы относятся к статическому виду, а какие - к динамическому?

17. Объясните назначение каждого вида диаграммы.

18. Какой вид диаграмм делится на диаграммы последовательностей и диаграммы коопераций?

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

20. Что такое архитектура систем?

21. Какие аспекты разработки ПО охватывает архитектура?

22. Что включает в себя вид с точки зрения развертывания и вид и точки зрения процессов?

4. Модульное программирование

Современные технологии программирования

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

Рассмотрим сначала, как появилось объектно-ориентированное программирование. Ключевое понятие, помогающее при программировании - это абстракция. Она позволяет лучше понять сущность программированного объекта или среду. Например, нужно совершить поездку в Мурманск. Возникают вопросы: «Каким образом это сделать? Какой транспорт использовать? Сколько это будет стоить?» и т.д. Нужно выделить главное и отбросить лишнее. Тут главным будет вид транспорта. Эту абстракцию при программировании можно назвать классом. У транспорта есть данные (скорость, количество двигателей и др.) и методы (взлет, посадка для самолета). Класс группирует данные и методы в единую сущность. Данные обычно закрыты и их изменение, как правило, производится посредством методов, т.е. они защищены корректной работой методов.

Впервые классы как объекты были использованы в 1967 г.: Бьерн Страуструп в своей диссертации использовал язык Simula для программы, моделирующей компьютерные системы. Это язык очень выразителен и позволяет работать с высоким уровнем абстракций. Однако при запуске программы оказалось, что у нее очень низкая производительность и выполнить работу в срок не удастся, поэтому пришлось переписать программу на языке Си. В Си классов нет. Страуструп их добавил и появился язык C++ [3].

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

В этот же период Microsoft создает Visual Basic. Главным нововведением в нем является возможность вставки управляющих элементов (кнопок, полей ввода) на форму. К каждому элементу можно добавить часть кода для описания его деятельности, что оказалось очень удобным, и вскоре были созданы тысячи новых элементов, в результате чего появилось расширение VBX (Visual Basic Extention). В журнале «BYTE» были описаны управляющие элементы VBX как наиболее успешная реализация мечты о повторном использовании кода.

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

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

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

Распределение памяти при использовании статических библиотек показано на рис. 4.1. Распределение памяти при использовании DLL отражено на рис. 4.2.

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

Рис. 4.2 Распределение памяти при использовании DLL

Архитектура открытых систем Windows (WOSA)

DLL - это первая попытка Microsoft реализовать компоненты. DLL лучше, чем статические библиотеки, но и у них есть ряд недостатков, к которым относятся следующие:

1. Несовместимость версий.

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

Явление полиморфизма крайне важно для работы с базами данных различного формата (ORACLE, ACCESS). Например, необходимо вызвать БД в EXCEL из ORACLE и т.д. Для этого был создан промежуточный программный слой Open Database Connectivity (ODBC), который определяет общий программный интерфейс (API) баз данных. Он использует синтаксис SQL и реализует взаимодействие с БД с помощью инсталлированных драйверов. Driver Manager загружает необходимые DLL драйверы [3].

Технология OLE

Следующим шагом эволюции разработки ПО стала технология OLE 1.0 в 1991 г. Это была попытка Microsoft создать объектно-ориентированный механизм интеграции приложений, в результате чего была введена концепция составного документа, который мог содержать объекты других приложений. Как появилась такая идея? Программисты трудились над созданием PowerPoint. Они могли создавать картинку и через буфер обмена вставлять ее в документ, но если ее необходимо потом еще раз редактировать, то нужно снова использовать буфер обмена и повторять все операции. Никакой связи с редактором не было. Вследствие этого стали применять технологию DDE (Dynamic DataExchange), позволяющую поддерживать связи с приложением, в котором был создан объект. В результате при щелчке на объекте в приложении, отдельно открывалось приложение для редактирования, в связи с чем стало возможным связывать объект. Однако технология OLE 1.0 имела ряд недостатков:

1. связи OLE 1.0 разбивались при перемещении файлов;

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

Все эти проблемы были успешно решены в OLE 2.0 в 1993 г. IDDE заменили на протокол облегченного удаленного вызова процедур (LRPC). Разделяемую память заменили механизмом передачи данных UDT (унифицированный механизм передачи данных).

Также можно было внедрять объект в свое приложение - программа редактирований встраивалась в приложение, а не открывалась отдельно.

Технология СОМ, созданная в качестве базиса OLE, может быть рассмотрена как третье поколение архитектуры компонентов Microsoft. Оно вводи понятие «компонентные объекты». Объектно-ориентированное программирование связывает понятие данных и методов. СОМ расширяет эти понятия - теперь объекты могут поддерживать еще и разные интерфейсы. Например, сервер составного приложения может как поддерживать активизацию на месте для редактирования объекта, так и не поддерживать. Это зависит от использования интерфейса и определяется при программировании параметрами функции QueryIntеrface. Еще один пример использования интерфейсов. На материнской плате имеются разъемы PCI, в которые можно вставить видеокарту, аудиокарту, сетевую плату, т.е. разъем один, а реализует разные возможности устройств с помощью интерфейсов [3].

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

Каждый объект СОМ поддерживает один или несколько интерфейсов. Однако существует один интерфейс, который должен поддерживаться любым объектом СОМ - это интерфейс unknown, имеющий три метода: QueryInterface, AddRef и Release. Все остальные интерфейсы - это потомки данного интерфейса.

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

HRESULT QueryInterface (REFIID iid, void** ppvObject)

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

1. Тождественность. Если указатели на интерфейс Iunknown совпадают, то интерфейсы принадлежат одному и тому же объекту.

2. Предсказуемость. Если вызов Querylnterface завершился удачно в первый раз, то он завершится удачно и при последующих вызовах.

3. Рефлективность. Запрос интерфейса самого себя всегда должен заканчиваться удачно.

4. Симметричность.

5. Транзитивность.

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

Вместе с Windows NT4 появляется технология DCOM (distributed), расширявшая возможности СОМ для использования в сети. Теперь СОМ использует механизм удаленного вызова процедур - RPC. Независимо от того, где находится объект - в другом процессе, на другой машине - клиентская программа обращается к нему одинаково.

СОМ не является промежуточным ПО, как, например, ODBC. Время выполнения СОМ включается в установку соединения между клиентом и сервером. Если СОМ запускается в тот же процесс, что и клиент, то накладные расходы отсутствуют (то же, что и вызов виртуальных функций). Если запускается отдельно или с другой машины, то это просто удаленный вызов процедуры.

Необходимо выделить следующие проблемы СОМ-технологии [7]:

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

2. Клиент и сервер СОМ взаимодействуют на расстоянии. Их взаимодействие основано на внешних интерфейсах, а не на сходстве внутренней реализации. Отличия интерфейсов СОМ коварны и трудно согласуемы. Например, строки в C++ реализованы иначе, чем в VB. При передаче строки от сервера СОМ, написанной на VB, необходимо сглаживать эти отличия. Обычно это делает C++. Однако на это программисты тратят время.

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

4. Дополнительная проблема - это нехватка памяти. Программист выделяет блок памяти в своей программе и затем забывает его освободить. В этом нет ничего страшного, если программа работает небольшой период времени, но если это сервер, работающий сутки? В итоге ОС выдаст ошибку о нехватке памяти.

В эпоху создания управляющих элементов для web-страниц их называли «управляющие элементы ActiveX». Название менеджерам понравилось, и весь OLE назвали ActiveX.

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

Первую задачу успешно решил сервер транзакций Microsoft (MTS - Microsoft Transaction Server). Транзакция - это одна атомарная операция. Программист может создать компонент СОМ как DLL для одного приложения и не заботиться о многопоточности и безопасности. MTS Explorer экспортирует компонент СОМ в пакет MTS, и затем программа будет обращаться не к компоненту СОМ непосредственно, а использовать процесс MTS, который и будет контролировать доступ к общим базам данных и вопросы безопасности. MTS обеспечивает прочную модель управления ресурсами.

Также со временем было разработано понятие очередности сообщений (Microsoft Message Query - MMQ), которая представляет собой концептуальную модель построения распределенных систем. Программа создает сообщение для другого приложения и пересылает его в очередь сообщений. Другое приложение может его считать и ответить. Очередь сообщений асинхронна. Приложение посылает сообщение и не ждет ответа, а продолжает работать. Сообщение может быть послано к незапущенному еще приложению - сразу после запуска оно выбирает сообщения из очереди и отвечает пославшим их программам. Microsoft Transaction Server Query - очень мощное средство. Его можно организовать как объект, который сохраняется в случае сбоя и может быть быстро восстановлен. Назовем три основных компонента MSTQ:

1. интерфейс API для отправки и получения сообщений;

2. сами сообщения;

3. очередь сообщений [3].

Принцип работы.NET

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

Ключевым понятием в.NET Framework является управляемый код (managed code), работающий в среде CLR (Common Language Runtime), которая поддерживает более богатый набор служб, чем обычная операционная система. Как происходит взаимодействие CLR с языком программирования? Создано специальное средство разработки ПО - Vstudio.NET. Эта среда компилирует текст программы в программы на стандартном языке Microsoft Intermediate Language (MSIL, или IL). Так как все средства разработки выдают код на IL, все различия в программах исчезают к моменту достижения CLR. Код на IL не может сразу работать ни на одном компьютере, поэтому требуется следующий шаг - компиляция по требованию. Утилита just-in-time-compiler (JIT) читает исходный код на IL и производит настоящий машинный код, способный работать на данной платформе. Сам JIT должен быть для каждой платформы своим. Следует отметить, что компилируется не весь код, а только тот, который выполняется в данный момент. Откомпилированный код хранится на диске (в кэше), поэтому при последующих обращениях к нему задержек не происходит [4]. Характеристики.NET Framework:

1. Поддержка сборки мусора.

2. Поддержка управления версиями.

3. Реализация безопасности доступа к коду. Программе можно разрешить чтение файлов, но запретить запись в них. CLR реализует заданные ограничения и блокирует любые попытки выйти за их пределы. Это значит, что к полученному из разных источников коду можно применять различные уровни доверия. Это, в частности, позволяет работать с кодом, взятым из Web, не опасаясь за ОС.

4. Поддержка бесшовного взаимодействия с СОМ-объектами. СОМ-объект помещается в объект-оболочку и воспринимается как часть.NET.

Перечислим технологии, поддерживаемые Microsoft.NET:

1. Реализация платформы.NET Runtime.

2. Все современные версии Windows (Windows 98/ Windows NT/ Windows 2000/ Windows Me/ Windows XP/ Windows NT4.0).

3. Solaris (исходный код реализации открыт).

4. Нет принципиальных проблем для реализации под Linux и карманные ПК и даже сотовые телефоны.

Следует отметить, что NET-приложения работают и будут работать медленнее.

Решения, предоставляемые NET

NET решает некоторые основные проблемы, возникающие при разработке современного программного обеспечения [4].

Microsoft.NET, платформа Microsoft XML Web-сервисов состоят из:

· программной платформы для создания.NET-модулей;

· программной модели и инструментов для создания и интеграции XML;

· набора программируемых XML Web-сервисов.

Microsoft.NET позволяет пользователям взаимодействовать с широким кругом «умных» устройств через Web, при этом контроль над взаимодействием будет в первую очередь у пользователя, а уже только потом - у самого приложения. Microsoft.NET предоставляет пользователям приложений, сервисов и устройств более персонализированный, простой, единообразный и защищенный доступ к ним. «Умные» устройства - это устройства, способные работать в среде Web. В их качестве могут выступать персональные и портативные компьютеры, «умные» телефоны в совокупности с программным обеспечением, позволяющим им осуществлять взаимодействие с пользователями, информационными средами, вычислительными сетями и другими устройствами или сервисами [2].

Основу.NET-среды составляет операционная система, под управлением которой работает среда исполнения (Common Language Runtime) и ее сервисы - библиотеки классов: базовой логики, манипуляции данными, обеспечения безопасности, отображения информации, электронной почты, Интернет и др.

Поверх них работают WebService, WеbForms, WinForms и др.

Общая структура.NFT-платформы выглядит следующим образом:

· операционная система, где исполняются приложения. Windows СЕ, ME или 2000 требует установки среды исполнения.NET Framework;

· платформа для разработки офисных приложений Office.NET;

· MSN.NET и bCentral.NET - сетевые сервисы платформы.NET для дома, а также малого и среднего бизнеса;

· Enterprise Servers - серверные продукты, такие как Exchange, SQL, BizTalk Server и т.д.;

· Visual Studio.NET - средства разработки приложений.

Серверные продукты.NET

Практически все основные продукты данной линейки подверглись основательной модернизации, а кое-где - и слиянию. В итоге имеется следующий набор [4]:

· сервер приложений - Microsoft Application Center;

· сервер интеграции приложений - Microsoft BizTalk Server;

· сервер для создания электронных торговых площадок (В2С) - Microsoft Commerce Server, который является дальнейшим развитием Microsoft Site Server. Тесно интегрирован с BizTalkServer;

· почтовый сервер - Microsoft Exchange;

· сервер для интеграции мэйнфреймов в рабочую среду - Microsoft Host Integration Server (бывший Microsoft SNA Server);

· сервер корпоративного доступа в Интернет - Microsoft InterNET Security and Acceleration Server (бывший Proxy Server);

· сервер трансляции услуг.NET для мобильных устройств - Microsoft Mobile Information Server;

· сервер корпоративных веб-порталов - Microsoft Tahoe Server;

· Microsoft SQL Server [2].

ASP.NET

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

В конце 1997 г. Microsoft реализовала для этих целей относительно простую среду выполнения для Web - Active Server Page (ASP), которая позволяет программистам создавать динамические страницы из статических страниц HTML и кода сценария. Однако потребовалось усовершенствовать два ключевых свойства ASP: простоту программирования и качество выполнения. Эти изменения были сделаны b ASP.NET. Эта среда полностью совместима с Microsoft.NET и использует все возможности.NET Framework.

Смесь HTML-элементов и сценарного кода логична, но неудобна в реализации. ASP.NET отделяет HTML от алгоритмов, создавая фоновый код. Теперь HTML не смешивается со сценариями, а пишется в отдельном файле. Благодаря этому можно создавать Web-приложения, используя Vstudio.NET.

ASP.NET поддерживает Web Forms - архитектуру Web-cтaнции, делающих их программирование похожим на программирование форм настольных приложений. Программист добавляет на формы элемент и пишет для него обработчик событий. Вследствие этого не нужно помнить синтаксис HTML для установки основного цвета или цвета фона строки.

ASP реализует также защиту соединения и сохранение информации.

Контрольные вопросы

1. В результате решения какой проблемы появилось объектно-ориентированное программирование?

2. В чем заключается нововведение VB?

3. Как загружаются в память DDL?

4. В чем недостатки динамических библиотек?

5. Что представляет собой архитектура WOSA?

6. В чем различие технологий OLE1.0 и OLE2.0? В чем идея этой технологии?

7. Что такое программный интерфейс?

8. Как реализован интерфейс unknown?

9. Отличие технологии СОМ от WOSA?

10. Расшифруйте понятия MTS и MSMQ. Как они связаны с технологией СОМ+?

11. В чем недостатки технологии СОМ?

12. Что такое.NET Framework?

13. Что дает программистам.NET Framework?

14. Опишите общую идею платформы Microsoft.NET.

15. Расшифруйте понятия CLR, JIT.

16. Каковы основные характеристики.NET Framework?

17. Какие решения предоставляются.NET?

18. Какова структура.NET?

19. Что такое ASP? Чем ASP.NET отличается от ASP?

20. Что дает технология.NET пользователям, разработчикам?

5. Тестирование и сопровождение программ

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

Выполнение программы с целью обнаружения ошибок (табл. 5.1) называется тестированием. Локализация и исправление ошибок называется отладкой [3].

Таблица 5.1

Виды программных ошибок и способы их обнаружения

Виды программных ошибок	Способы их обнаружения
Синтаксические	Статический контроль и диагностика компиляторами и компоновщиком
Ошибки выполняемые, выявляемые автоматически: а) переполнение, защита памяти; б) несоответствие типов; в) зацикливание	Динамический контроль; аппаратурой процессора; run-time системы программирования; операционной системой - по превышению лимита времени
Программа не соответствует спецификации	Целенаправленное тестирование
Спецификация не соответствует требованиям	Испытания, бета-тестирование

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

Тест - это набор контрольных входных данных совместно с ожидаемыми результатами. В число входных данных зависимых программ входят события и временные параметры. Ключевой вопрос - полнота тестирования: какое количество каких тестов гарантирует полную проверку программы? Исчерпывающая проверка на всем множестве входных данных недостижима. Пример: программа вычисляет функцию двух переменных: Y=f(X,Z). Если X,Y,Z - real, то полное число тестов (2³²)² = 2⁶⁴ = 10³¹. Если на каждый тест тратить 1мс, то 2⁶⁴мс = 800 млн лет. Следовательно:

• в любой нетривиальной программе на любой стадии ее готовности содержатся необнаруженные ошибки;

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

Детективность: тест должен с большой вероятностью обнаруживать возможные ошибки.

Покрывающая способность: один тест должен выявлять как можно больше ошибок.

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

Только на основании выбранного критерия можно определить тот момент времени, когда конечное множество тестов окажется достаточным для проверки программы с некоторой полнотой (степень полноты определяется экспериментально). Используются два вида критериев:

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

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

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

Классы, как правило, назначаются исходя из семантики решаемой задачи [6].

Порядок разработки тестов

1. По внешней спецификации разрабатываются тесты [3]:

• для каждого класса входных данных;

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

2. Разрабатываются тесты для тех функций, которые не проверяются в п.1.

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

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

5. Готовятся тесты, проверяющие исключительные ситуации,
недопустимые входные данные, аварийные ситуации.

Функциональное тестирование дополняется здесь структурным. Классы входных/выходных данных должны быть определены в плане тестирования уже во внешней спецификации.

Систематическое тестирование предполагает также ведение журнала отладки (Bug Book), в котором фиксируется ошибка (описание, дата обнаружения, автор модуля) и в дальнейшем - исправление (дата, автор).

Приведем так называемые аксиомы тестирования.

1. Тест должен быть направлен на обнаружение ошибки, а не на подтверждение правильности программы.

2. Автор теста - не автор программы.

3. Тесты разрабатываются одновременно или до разработки программы.

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

5. Предыдущее тестирование необходимо повторять после каждого внесения исправлений в программу.

6. Следует повторять полное тестирование после внесения изменений в программу или после переноса ее в другую среду.

7. Для тех программ, в которых обнаружено много ошибок, необходимо дополнить первоначальный набор тестов [7].

Автоматизация тестирования

А. Автоматизация прогона тестов актуальна для 5-й и 6-й аксиом Майерса. Пишутся командные файлы для запуска программы с каждым тестом из набора и сравнением реального результата с ожидаемым. Существуют специальные средства (например, система MIL-Smia PL/1 фирмы IBM). Разрабатывается стандарт IEEE скриптового языка для описания тестовых наборов [3].

Б. Средства автоматизации подготовки тестов и анализа их результатов.

1. Генераторы случайных тестов в заданных областях входных данных.

2. Отладчики (для локализации ошибок).

3. Анализаторы динамики (profilers). Обычно входят в состав отладчиков; применяются для проверки соответствия тестовых наборов структурным критериям тестирования.

4. Средства автоматической генерации структурных тестов методом «символического выполнения» Кинга.

Надежность программного обеспечения

Это комплексное свойство включает две составляющие [3]:

• безошибочность (correctness) - соответствие спецификации;

• устойчивость (robustness) или отказоустойчивость (fault-tolerance) - способность продолжать правильно работать после отказов.

Улучшение первого качества достигается хорошей технологией, предупреждающей ошибки (fault-avoidance). Однако 100%-ное отсутствие ошибок недостижимо. Устойчивость должна быть относительно любых видов отказов, для ее поддержания создаются специальные программно-аппаратные средства.

Отказ (failure) по ГОСТу - нарушение работоспособности изделия и его соответствия требованиям технической документации. Применительно к программам (стандарт IEEE/ANSI) отказ есть неспособность функциональной единицы системы, зависящей от программы, выполнять требуемую функцию в заданных пределах.

Классификация причин отказов:

1. Физические дефекты:

• внутренние (старение, износ);

• внешние воздействия (радиация, высокая температура).

2. Ошибки людей:

• ошибки эксплуатации или взаимодействия;

• проектные ошибки.

Повреждение (Fault) - неисправность уже появилась, но еще не проявилась вовне. Например, отказала ячейка памяти, но из неё еще не читали или в нее еще не писали. Отказ компонента - это повреждение системы. Время нахождения в неисправном, но работоспособном состоянии называется латентным (скрытым) периодом отказа.

Восстановление (Recovery) - возврат в исправное состояние путем:

· ручного ремонта, замены, исправления;

· автоматически - задействованием резервов;

· самопроизвольно, обычно быстро.

В 3-м случае отказ называется сбоем, т.е. сбой - это кратковременный самовосстанавливающийся отказ. Остальные отказы называются устойчивыми. В электронной аппаратуре сбои происходят на порядок чаще устойчивых отказов. Их причины - флюктуации питания, ситуации «гонок» сигналов, альфа-частицы и др. В программах аналогично сбоям ведут себя времязависимые ошибки - их иногда называют «мерцающими» (blinking bugs).

Типичный пример восстановления - с помощью резервной (backup) копии данных. Если выполнить восстановление в латентном периоде отказа, то он никогда не проявится вовне - в этом состоит идеальная отказоустойчивость.

Количественные характеристики надежности программ

Надежность нужно оценивать, измерять, предсказывать, т.е. обеспечивать заданные требования к надежности в проекте и проверять их выполнение в продукте [3].

«Внутренняя» характеристика надежности - количество оставшихся ошибок в программе - интересна больше разработчикам, чем потребителям. Для последних важны две характеристики, традиционные для теории надежности, основанные на предположении о стохастическом (случайном во времени) процессе возникновения отказов: среднее время безотказной работы (MTBF - Mean Time Between Failures) и коэффициент готовности. Третья характеристика, взаимосвязанная с первой - интенсивность отказов -- среднее их количество в единицу времени.

В предположении простейшего потока отказов (отказы независимы, редки, и их вероятность неизменна во времени) P(f) - вероятность безотказной работы за время t - подчиняется закону Пуассона (экспоненциальному распределению вероятностей):

P(t)=e-^xt,

где х - интенсивность отказов (обычно количество отказов за 1 час).

Таким образом, программы вносят наибольший вклад в надежность современных вычислительных систем. Между тем существуют столь ответственные (mission-critical) приложения, где требуется очень малая вероятность отказов. Например, для бортовой системы управления космическим зондом требуется х = 10⁹, чтобы вероятность устойчивого отказа в первые 10 лет работы была не более 10⁴ (или вероятность безотказной работы 0,9999), что означает MTBF - 100 тысяч лет.

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

Если отказ все же произошел, время восстановления должно быть минимальным. Это характеризуется показателем ремонтопригодности коэффициентов готовности (availability):

к=(Т- T_пр)/T,

где Т - общее время работы; Т_пр - время простоя из-за восстановления.

В ответственных системах требуется, чтобы значение к почти не отличалось от 1: для цифровых АТС - 2 часа простоя суммарно за 15 лет; для системы управления воздушным движением - 3 с. за год.

Методы оценки и измерения характеристик надежности

«Внутренняя» характеристика - абсолютное или относительное количество оставшихся ошибок - абсолютное или относительное. Принято считать, что в хорошо отлаженной программе должно быть не более одной ошибки на 1 тыс. строк исходного кода. Для ответственных применений требуется то же на 10 тыс. строк и больше.

Как проверить соответствие ПП таким требованиям?

1. Метод Миллса (IBM, 1972 г.) использует прием биологов,
метод «меченых рыб». Группа тестирования засоряет программу
искусственно ошибками и, продолжая тестирование, анализирует долю внесенных ошибок среди обнаруженных.

2. Пусть внесено s ошибок, обнаружено n собственных и v внесенных ошибок. В методе Руднера (1977 г.) тестирование осуществляется двумя независимыми группами тестеров параллельно. Используя гипергеометрическое распределение, методом максимального правдоподобия может быть найдена оценка числа первоначально содержавшихся в программе ошибок.

3. Фирма Motorola использует в качестве меры надежности своих ПП (управляющих программ реального времени) среднее число ошибок на 1000 арок исходного кода. Она разработала метод оценки времени тестирования без отказов (zero-failure method), подтверждающего заданную надежность. Метод основан на известной форме зависимости:

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

Если за время T ни одного отказа не произошло, считается, что в программе не более N ошибок и тестирование можно закончить. Если же отказ произошел через промежуток времени t_n < T, то испытание продолжается, причем функция T пересчитывается заново для п+1.

Функция Т получена на базе одной из моделей надежности программ на основе оценок функции (t), экстраполирующих динамику отладки (для этого и ведутся журналы отладки). Например, модель Джелинского-Моранды (1972 г.), использовавшаяся в ряде ответственных проектов, в том числе Apollo, основана на следующих допущениях:

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

Все ошибки равновероятны, и их проявление не зависит друг от друга.

Ошибки постоянно исправляются без внесения новых.

R(i) постоянна в промежутке между двумя смежными моментами обнаружения t_i, и t_i+1. Тогда R(t) - ступенчатая монотонно убывающая функция. Предполагается, что динамика проявления ошибок во время эксплуатации остается такой же, как при тестировании, т.е. постулируется тождество функций R(t) и Х(t) с тем отличием, что значение (t) «замораживается» в момент завершения тестирования - прекращается исправление ошибок.

Если t - число ошибок, обнаруженных к моменту времени 1, то до следующего обнаружения справедливо R(t) = K(B - i), где В - неизвестное число исходных ошибок; К - неизвестный коэффициент пропорциональности. Полагая X_i= t_i - t_i+1, (i=0,..., п-1), можно утверждать, что X имеет экспоненциальное распределение: Р(Х') = exp(-К(В-i)X_i). Имея набор X из журнала отладки, можно решать задачу нахождения значений К и В, отвечающих принципу максимального правдоподобия. Однако проще решение для модифицированной модели, где, поскольку dN(i)/dt=R(t) (число ошибок, обнаруженных в единицу времени), получаем дифференциальное уравнение с начальными условиями:

Здесь снято допущение 4, и функция R(t) перестает быть кусочно-постоянной: R(t) = K(B-N(i)).

Его решение: R(t) = КВе-^Kt. Обозначая а = Ln (KB), h = -К, получаем запись решения в виде: R(t) = ехр(а + bt). Логарифмируя обе части этого равенства и переходя к дискретному времени t, получим систему уравнений:

Решая эту систему относительно двух неизвестных К и В методом наименьших квадратов, можно найти оценки величин К и В в соответствии с критерием максимального правдоподобия. Этот метод был применен для ряда конкретных проектов IBM и показал хорошее соответствие реальности.

Экстремальное программирование. Предварительное и эволюционное проектирование

Методология Extreme Programming (ХР) бросила вызов многим устоявшимся представлениям о разработке программного обеспечения. Пожалуй, наиболее противоречивой идеей является отказ от предварительного проектирования в пользу более эволюционного подхода. Противники ЕР считают, что это возврат к разработкам типа «code and fix» («пишем и правим»). Для приверженцев новой методологии это отказ от техник проектирования (например, UML), их принципов. Существуют два стиля проектирования: эволюционное и предварительное[18].

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

...