34. Повторное возбуждение исключительной ситуации. Вложенные блоки try
Может быть реализовано внутри функции catch и перехвачено другой catch вне этого блока. При этом значение выражения генерации исключения сохраняется.
Повторное возбуждение исключительной ситуации осуществляется инструкцией throw без параметров: throw;
Пример5:
#include <iostream>
using namespace std;
void f ()
{
try {throw “привет”;}
catch (char *) {cout << “перехват char * внутри функции f() \n”; throw;}
}
int main()
{
cout << “начало \n”;
try{ f();}
catch(char *) {cout << “перехват char * в main()\n”;}
cout << «конец»;
return 0;
}
Результат:
Начало
Перехват char *внутри функции()
Перехват char *в main()
Конец
Инструкцию throw целесообразно использовать при наличии вложенных контролирующих блоков:
try{…try{…try{…throw}}}
В случае вложенных блоков try поиск обработчика идет в следующей последовательности. Сначала отыскивается catch непосредственно за блоком try. Если обработчик не найден, поиск продолжается в охватывающем блоке и т.д. до тех пор, пока не будет найдена инструкция catch. Если же инструкция на найдена, генерируется стандартное исключение и выдается стандартное сообщение. Значение ВГИ продолжает существовать до выхода из самого внешнего блока try или по завершении catch, если он найден.
Значение выражения генерации исключения продолжает существовать до выхода из самого внешнего блока try.
Если создается иерархия классов исключительных ситуаций, то обработчики исключительных ситуаций должны стоять в порядке, обратном их определению, т.е.
сatch(C){}
catch(D){}
catch(B){}
catch(A){}
35. Организация проектировани и документирования разработки объектно-ориентированных программ
Организация проектирования программного обеспечения
В основе проектирования больших систем и в том числе программных систем лежит методология системного анализа. В основе системного анализа лежит принцип цели.
Цель – это ситуация или область ситуаций, которая достигается в ходе функционирования системы.
Ситуация – это значения характеристик системы и среды в данный момент времени.
Система – это целостная совокупность взаимосвязанных элементов.
Элемент – это неделимая при данном рассмотрении часть системы.
Система может быть описана на нескольких уровнях (стратах) – стратифицированное описание, например:
Страта 3 – уровень обеспечения процессов.
Страта 2 – уровень управления взаимодействием процессов.
Страта 1 – уровень взаимодействия процессов.
Уровень 0 – уровень физических процессов.
На каждом уровне описание может включать:
- структурную модель (статическое описание);
- функциональную модель (динамическое описание);
- информационную модель (динамическое описание).
Структурная модель отображает характер связей между элементами.
Функциональная модель отображает характер взаимодействия между объектами во времени.
Информационная модель отображает структуру, движение и преобразование информации в системе.
Правильное определение цели функционирования системы и выбор цели ее анализ в полной мере определяют моделирование системы на всех уровнях и этапах. Цели должны пронизывать все этапы системного анализа.
Цель и процесс – первичны, объекты вторичны.
Жизненный цикл программного обеспечения начинается с системного анализа предметной области (первый этап), в ходе которого создаются структура, функциональная и информационная модели.
Погружение системы в среду и анализ ситуации, которая сложилась на данный момент времени, позволяет сформулировать проблему.
Проблема – это несоответствие между существующими и требуемыми значениями показателей эффективности или критерия эффективности системы.
Показатель эффективности – это функционал, который аккумулирует в себе одну из частных целей и значения параметров системы и среды.
Критерий эффективности – это функционал, который аккумулирует в себе главную цель и значения показателей эффективности системы. Вместо показателей могут участвовать непосредственно параметры системы и среды.
Таким образом, в ходе системного анализа оценивают состояние системы на данный момент времени и формулируют требования к системе. Результаты оценки являются основой технического задания на проектируемую систему программного обеспечения.
Кроме описания проблемы в техническом задании могут приводиться следующие данные:
- описание исходной информации (структура, источники, время поступления, форма представления, гриф и т.д.);
- описание результирующей информации;
- описание процесса (статическая, функциональная и информационная модели).
На втором этапе создается объектно-ориентированная модель системы, которая включает:
- статическую и динамическую физические модели;
- статическую и динамическую физические модели.
Организация документирования разработки объектно-ориентированной модели
Акцентируем внимание на графической части объектно-ориентированной модели. Графическое отображение модели должно быть функционально полным, простым, выразительным, позволяющим абстрагироваться от деталей, способным отражать полноту и правильность принятых решений (адекватность) и общепризнанной.
Рассмотрим один из множества известных в мире вариантов графического отображения объектно-ориентрованной модели, автором которой является Гради Буч (главный исследователь корпорации Rational Software). Эта версия известна в мире как «Нотация Буча».
Она включает следующие графические модели:
1. Логическая модель:
а) статическая модель:
- диаграмма классов;
- диаграмма объектов;
б) динамическая модель:
- диаграмма состояний и переходов;
2. физическая модель:
а) статическая модель:
- диаграмма модулей;
- диаграмма процессов;
б) динамическая модель:
- диаграмма взаимодействия.
Диаграмма классов
Отражает классы и отношения между ними.
На стадии анализа выделяются общие роли и обязанности сущностей, обеспечивающих требуемое (целевое) поведение системы.
На стадии проектирования определяется структура классов и архитектура системы.
Графические примитивы: