Компоненты Delphi, их свойства

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

В стандартную поставку Delphi входят основные объекты, которые образуют удачно подобранную иерархию из 270 базовых классов. Delphi присуща открытая компонентная архитектура. Благодаря такой архитектуре приложения, изготовленные при помощи Delphi, работают надежно и устойчиво. Delphi поддерживает использование уже существующих объектов, включая DLL, написанные на С и С++, OLE сервера, VBX, объекты, созданные при помощи Delphi. Из готовых компонент работающие приложения собираются очень быстро. Кроме того, поскольку Delphi имеет полностью объектную ориентацию, разработчики могут создавать свои повторно используемые объекты для того, чтобы уменьшить затраты на разработку.

Delphi предлагает разработчикам - как в составе команды, так и индивидуальным - открытую архитектуру, позволяющую добавлять компоненты, где бы они ни были изготовлены, и оперировать этими вновь введенными компонентами в визуальном построителе. Разработчики могут добавлять CASE-инструменты, кодовые генераторы, а также авторские help’ы, доступные через меню Delphi.

Two-way tools - однозначное соответствие между визуальным проектированием и классическим написанием текста программы Это означает, что разработчик всегда может видеть код, соответствующий тому, что он построил при помощи визуальных инструментов и наоборот.

Визуальный построитель интерфейсов (Visual User-interface builder) дает возможность быстро создавать клиент-серверные приложения визуально, просто выбирая компоненты из соответствующей палитры.

Все объекты в Delphi являются производными от одного класса Tobject.У него нет явных полей, однако имеется скрытое поле для указания на VMT – Virtual Metod Table(таблица виртуальных методов). Именно в виде VMT представляется класс в Delphi. В этойы таблице содержаться указатели на методы класса и другая информацияо классе, доступная только для чтения. Объект в Delphi –это участок памяти, где delphi хранит значения всех полей объекта. Ссылка на объект – это уазатель на объект. В Delphi с объектом можно работать только через ссылку на него. Однако для краткости термин ссылка на объект часто сокращается до объект, хотя следует все-таки понимать настоящий смысл этих опредлений. Рассмотрим некоторые свойства класса Tobject:

Методы класса:

ClassInfo – возвращает указатель на таблицу TtypeInfo класса

ClassNameIs – Проверяет соответствует ли данная строка имени класса

ClassParent – Возвращает метакласс, непсредственного базового класса. Для Tobject вернется nil, т.к у него нет базового класса

Create – Конструктор. Не выполняет никаких действий! Существует для того, чтобы можно было вызвать унаследованный конструктор из конструктора при создании экземпляра любого другого класса.

GetInterfaceEntry – Выполняет поиск интерфейса в классе и его родительских классах по GUID.

InheritsFrom – проверяет класс, совпадает ли он с типом класса, переданным в качестве аргументаи является ли его потомком. Этот метод использую операторы As и Is.

InstanceSize – Возвращает количество байт, которые требуются экземпляру класса.

MethodAddress – Получает указатель на область памяти, выделенную для объекта и инициализирует ее.

MethodName, MethodAddress – позволяют получить имя метода по его адресу, и адрес метода по его имени.

NewInstance – создает новый экземпляр объекта и инициализирует объект.

Методы Объекта:

AfterConstruction – Delphi вызывает метод, после того как завершилось выполнение кода конструктора

BeforeDestruction– Delphi вызывает метод, перед тем как исполнять код деструктора

ClassType – возвращет ссылку на метакласс объекта, который является указателем на VMT

DefaultHandler – обработчик сообщений по умолчанию

Free – используется для уничтожения объекта.

GetInterface – выполняет поиск GUID и выбирает соответствующий интерфейс.

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

В стандартную поставку Delphi входят основные объекты, которые образуют удачно подобранную иерархию из 270 базовых классов. На рисунке приведена часть иерархии.

Рассмотрим основные классы этой иерархии:

Tobject – базовый класс для всех.

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

Exception – базовый класс для всех классов- исключений. Delphi естественно поддреживается структурная обработка исключений. И доступ к структуре исключения обеспечивается через этот класс и его наследники.

TinterfacedObject – служит базовым классом, для всех объектов поддерживающих интерфейс, так как в нем реализованы основные методы для поддрежки интерфейсов.

TcomObject – базовый класс для создания Com-объектов.

Tcomponent - Все компоненты Delphi – должны наследоваться от этого класса или его потомков. Компоненты Delphi – это те объекты, которыми можно манипулировать в режиме дизайна. В качестве примера можно привести все управляющие элементы(кнопки, radiobutton, Checkbox, memo, и т.д.)

tWinControl – большинстов визуальных компонентов наследованы от него. От него наследованы все классы – управляющие элементы Windows. Следует отметить, что существует и “ветка” классов реализующих кроссплатформенный код, т.е. в зависимости от платформы (ОС) –код классов, компилируется в код для этой ОС.

7. Концепция виртуальных машин Э. В. Дейкстры.

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

8. Лексический анализ.

Лексема (лексическая единица языка) — это структурная единица языка, кото­рая состоит из элементарных символов языка и не содержит в своем составе дру­гих структурных единиц языка.

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

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

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

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

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

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

Эти действия связаны с определенными проблемами. Далее рассмотрено, как эти проблемы решаются в лексических анализаторах.

Определение границ лексем

Выделение границ лексем является нетривиальной задачей. Ведь в тексте исход­ной программы лексемы не ограничены никакими специальными символами. Если говорить в терминах лексического анализатора, то определение границ лек­сем — это выделение тех строк в общем потоке входных символов, для которых надо выполнять распознавание.

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

• последовательный;
• параллельный.

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

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

Выполнение действий, связанных с лексемами

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

В конечном автомате, лежащем в основе лексического анализатора, эти действия можно отобразить довольно просто — достаточно иметь возможность с каждым переходом на графе автомата (или в функции переходов автомата) связать вы­полнение некоторой произвольной функции f(q, a), где q — текущее состояние автомата, a — текущий входной символ. Функция f(q, a) может выполнять любые действия, доступные лексическому анализатору:

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

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

9. Методика тестирования программных систем.

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

Спираль процесса тестирования

Охарактеризуем каждый шаг процесса тестирования.

1. Тестирование элементов. Цель - индивидуальная проверка каждого модуля. Используются способы тестирования «белого ящика».

2. Тестирование интеграции. Цель — тестирование сборки модулей в программ­ную систему. В основном применяют способы тестирования «черного ящика».

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

4. Системное тестирование. Цель — проверка правильности объединения и взаи­модействия всех элементов компьютерной системы, реализации всех систем­ных функций.

Тестирование элементов

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

Тестированию подвергаются:

· интерфейс модуля;

· внутренние структуры данных;

· независимые пути;

· пути обработки ошибок;

· граничные условия.

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

1) неправильный или непонятый приоритет арифметических операций;

2) смешанная форма операций;

3) некорректная инициализация;

4) несогласованность в представлении точности;

5) некорректное символическое представление выражений.

Источниками ошибок сравнения и неправильных потоков управления являются.

1) сравнение различных типов данных;

2) некорректные логические операции и приоритетность;

3) ожидание эквивалентности в условиях, когда ошибки точности делают эквива­лентность невозможной;

4) некорректное сравнение переменных;

5) неправильное прекращение цикла;

6) отказ в выходе при отклонении итерации;

7) неправильное изменение переменных цикла.

Обычно при проектировании модуля предвидят некоторые ошибочные условия Для защиты от ошибочных условий в модуль вводят пути обработки ошибок. Такие пути тоже должны тестироваться. Тестирование путей обработки ошибок мож­но ориентировать на следующие ситуации:

1) донесение об ошибке невразумительно;

2) текст донесения не соответствует обнаруженной ошибке;

3) вмешательство системных средств регистрации аварии произошло до обработ­ки ошибки в модуле;

4) обработка исключительного условия некорректна;

5) описание ошибки не позволяет определить ее причину.

И, наконец, перейдем к граничному тестированию. Модули часто отказывают на «границах». Это означает, что ошибки часто происходят:

1) при обработке n-го элемента n-элементного массива;

2) при выполнении т-й итерации цикла с т проходами;

3) при появлении минимального (максимального) значения.

Тестовые варианты, ориентированные на данные ситуации, имеют высокую веро­ятность обнаружения ошибок.

Тестирование интеграции

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

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

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

Существует два варианта тестирования, поддерживающих процесс интеграции: нисходящее тестирование и восходящее тестирование. Рассмотрим каждый из них.

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

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

Рассмотрим шаги методики восходящей интеграции.

1. Модули нижнего уровня объединяются в кластеры (группы, блоки), выполня­ющие определенную программную подфункцию.

2. Для координации вводов-выводов тестового варианта пишется драйвер, управ­ляющий тестированием кластеров.

3. Тестируется кластер.

1. Драйверы удаляются, а кластеры объединяются в структуру движением вверх.

Сравнение нисходящего и восходящего тестирования интеграции

Нисходящее тестирование:

1) основной недостаток - необходимость заглушек и связанные с ними трудно­сти тестирования;

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

Восходящее тестирование:

1) основной недостаток - система не существует как объект до тех пор, пока не будет добавлен последний модуль;

2) основное достоинство - упрощается разработка тестовых вариантов, отсутствуют заглушки.

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

Тестирование правильности

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

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

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

1. системную спецификацию;
2. план программного проекта;
3. спецификацию требований к ПС; работающий или бумажный макет;
4. предварительное руководство пользователя;
5. спецификацию проектирования;
6. листинги исходных текстов программ;
7. план и методику тестирования; тестовые варианты и полученные результаты;
8. Руководства по работе и инсталляции;
9. exe-код выполняемой программы;
10. описание базы данных;
11. руководство пользователя по настройке;

12. документы сопровождения; отчеты о проблемах ПС; запросы сопровождения; отчеты о конструкторских изменениях;

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

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

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

Альфа-тестирование проводится заказчиком в организации разработчика. Разра­ботчик фиксирует все выявленные заказчиком ошибки и проблемы использова­ния.

Бета-тестирование проводится конечным пользователем в организации заказ­чика. Разработчик в этом процессе участия не принимает. Фактически, бета-тестирование - это реальное применение ПС в среде, которая не управляется разработчиком. Заказчик сам записывает все обнаруженные проблемы и сооб­щает о них разработчику. Бета-тестирование проводится в течение фиксированного срока (около года). По результатам выявленных проблем разработчик изменяет ПС и тем самым подготавливает продукт полностью на базе заказ­чика.

Системное тестирование

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

1) предусмотреть средства обработки ошибки, которые тестируют все вводы ин­формации от других элементов системы;

2) провести тесты, моделирующие неудачные данные или другие потенциальные ошибки интерфейса ПС;

3) записать результаты тестов, чтобы использовать их как доказательство невиновности в случае «указания причины»;

4) принять участие в планировании и проектировании системных тестов, чтобы гарантировать адекватное тестирование ПС.

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

Тестирование восстановления

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

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

Тестирование безопасности

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

Тестирование безопасности проверяет фактическую реакцию защитных механиз­мов, встроенных в систему, на проникновение.

В ходе тестирования безопасности испытатель играет роль взломщика. Ему разре­шено все:

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

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

Стрессовое тестирование

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

Стрессовое тестирование производится при ненормальных запросах на ресурсы системы (по количеству, частоте, размеру-объему).

Примеры:

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

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

Тестирование производительности

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

10. Модели объектно-ориентированных программных систем.

Модели объектно-ориентированных программных систем делятся на статистические и динамические.

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

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

Обозначение класса показано на рисунке.

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

Общий синтаксис представления свойства имеет вид

Видимость Имя [Множественность]: Тип = НачальнЗначение {Характеристики}

В языке UML определены три уровня видимости.

public	Любой клиент класса может использовать свойство (операцию), обозначается символом +
protected	Любой наследник класса может использовать свойство (операцию), обозначается символом #
private	Свойство (операция) может использоваться только самим классом, обозначается символом -

Определены три характеристики свойств.

changeable	Нет ограничений на модификацию значения свойства
addOnly	Для свойств с множественностью, большей единицы; дополнительные значения могут быть добавлены, но после создания значение не может удаляться или изменяться
frozen	После инициализации объекта значение свойства не изменяется

Общий синтаксис представления операции имеет вид

Видимость Имя (Список Параметров): ВозвращаемыйТип {Характеристики}

Элемент Направление может принимать одно из следующих значений:

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

Допустимо применение следующих характеристик операций:

leaf	Конечная операция, операция не может быть полиморфной и не может переопределяться (в цепочке наследования)
isQuery	Выполнение операции не изменяет состояния объекта
sequential	В каждый момент времени в объект поступает только один вызов операций. Как следствие, в каждый момент времени выполняется только одна операция объекта. Другими словами, допустим только один поток вызовов (поток управления)
guarded	Допускается одновременное поступление в объект нескольких вызовов, но в каждый момент времени обрабатывается только один вызов охраняемой операции. Иначе говоря, параллельные потоки управления исполняются последовательно (за счет постановки вызовов в очередь)
concurrent	В объект поступает несколько потоков вызовов операций (из параллельных потоков управления). Разрешается параллельное (и множественное) выполнение операции. Подразумевается, что такие операции являются атомарными

Отношения в диаграммах классов

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

Ассоциации отображают структурные отношения между экземплярами классов, то есть соединения между объектами. Каждая ассоциация может иметь метку — имя, которое описывает природу отношения. Имени можно придать направление — достаточно добавить треугольник направления, который указывает направление, заданное для чтения имени.

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

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

Зависимость является отношением использования между клиентом (зависимым элементом) и поставщиком (независимым элементом). Обычно операции кли­ента:

• вызывают операции поставщика;
• имеют сигнатуры, в которых возвращаемое значение или аргументы принадле­жат классу поставщика.

Обобщение — отношение между общим предметом (суперклассом) и специализи­рованной разновидностью этого предмета (подклассом). Подкласс может иметь одного родителя (один суперкласс) или несколько родителей (несколько супер­классов). Во втором случае говорят о множественном наследовании.

Реализация — семантическое отношение между классами, в котором класс-приемник выполняет реализацию операций интерфейса класса-источника.

Динамические модели обеспечивают представление поведения систем. «Дина­мизм» этих моделей состоит в том, что в них отражается изменение состояний в про­цессе работы системы (в зависимости от времени). Средства языка UML для соз­дания динамических моделей многочисленны и разнообразны. Эти средства ориентированы не только на собственно программные системы, но и на отображение требований заказчика к поведению таких систем.

Для моделирования поведения системы используют:

• автоматы;
• взаимодействия.

Автомат (State machine) описывает поведение в терминах последовательности со­стояний, через которые проходит объект в течение своей жизни. Взаимодействие (Interaction) описывает поведение в терминах обмена сообщениями между объек­тами.

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

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

Автоматы отображают с помощью:

• Диаграмм схем состояний;
• Диаграмм деятельности.

Взаимодействия отображают с помощью:

• диаграмм сотрудничества (кооперации);
• диаграмм последовательности.

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

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

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

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

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

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

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

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

Переходы между вершинами — состояниями действий — изображаются в виде стре­лок. Переходы выполняются по окончании действий.

Кроме того, в диаграммах деятельности используются вспомогательные вер­шины:

• решение (ромбик с одной входящей и несколькими исходящими стрелками);
• объединение (ромбик с несколькими входящими и одной исходящей стрелкой);
• линейка синхронизации — разделение (жирная горизонтальная линия с одной входящей и несколькими исходящими стрелками);
• линейка синхронизации — слияние (жирная горизонтальная линия с несколь­кими входящими и одной исходящей стрелкой);
• начальное состояние (черный кружок);
• конечное состояние (незакрашенный кружок, в котором размещен черный кру­жок меньшего размера).

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

Вершина «объединение» отмечает точку слияния альтернативных потоков дей­ствий.

Линейки синхронизации позволяют показать параллельные потоки действий, отмечая точки их синхронизации при запуске (момент разделения) и при завершении (момент слияния).

Диаграммы взаимодействия

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

Диаграммы сотрудничества

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

Обозначение объекта показано на рисунке.

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

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

Сообщение — это спецификация передачи информации между объектами в ожи­дании того, что будет обеспечена требуемая деятельность. Прием сообщения рас­сматривается как событие.

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

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

Графически диаграмма последовательности — разновидность таблицы, которая показывает объекты, размещенные вдоль оси X, и сообщения, упорядоченные по времени вдоль оси Y.

От диаграмм сотрудничества диаграммы последовательности отличают две важ­ные характеристики.

Первая характеристика — линия жизни объекта.

Линия жизни объекта — это вертикальная пунктирная линия, которая обозначает период существования объекта. Большинство объектов существуют на протяже­нии всего взаимодействия, их линии жизни тянутся от вершины до основания диа­граммы. Впрочем, объекты могут создаваться в ходе взаимодействия. Их линии жизни начинаются с момента приема сообщения «create». Кроме того, объекты могут уничтожаться в ходе взаимодействия. Их линии жизни заканчиваются с момента приема сообщения «destroy».

Вторая характеристика — фокус управления.

Фокус управления — это высокий тонкий прямоугольник, отображающий период времени, в течение которого объект выполняет действие (свою или подчиненную процедуру). Вершина прямоугольника отмечает начало действия, а основание — его" завершение. Момент завершения может маркироваться сообщением возврата, которое показывается пунктирной стрелкой; Можно показать вложение фокуса управления (например, рекурсивный вызов собственной операции). Для этого вто­рой фокус управления рисуется немного правее первого.

Диаграммы Use Case

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

Вершинами в диаграмме Use Case являются актеры и элементы.

Актер — это роль объекта вне системы, который прямо взаимодействует с ее час­тью — конкретным элементом (элементом Use Case). Различают актеров и пользо­вателей. Пользователь — это физический объект, который использует систему. Он может играть несколько ролей и поэтому может моделироваться несколькими ак­терами. Справедливо и обратное — актером могут быть разные пользователи. Например, для коммерческого летательного аппарата можно выделить двух акте­ров: пилота и кассира.

Элемент Use Case — это описание последовательности действий (или нескольких последовательностей), которые выполняются системой и производят для отдель­ного актера видимый результат.

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

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

Между актерами допустимо отношение обобщения, означающее, что экземпляр потомка может взаимодействовать с такими же разновидностями эк­земпляров элементов Use Case, что и экземпляр родителя.

Между элементами Use Case определены отношение обобщения и две разновид­ности отношения зависимости — включения и расширения. Отношение обобщения фиксирует, что потомок наследует поведение родителя. Кроме того, потомок может дополнить или переопределить поведение родителя. Элемент Use Case, являющийся потомком, может замещать элемент Use Case, являющийся родителем, в любом месте диаграммы.

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

Отношение расширения между элементами Use Case означает, что базовый элемент Use Case неявно включает поведение другого элемента Use Case в точке, которая определяется косвенно расширяющим элементом Use Case. Базовый элемент Use Case может быть автономен, но при определенных условиях его поведение может расширяться поведением из другого элемента Use Case. Базовый элемент Use Case может расширяться только в определенных точках — точках расширения. Отношение расширения применяется для моделирования выбираемого поведения системы. Таким способом можно отделить обязательное поведение от необязатель­ного поведения.

???????????????????????????????????????????????????????????????????7???????????7