ИГА. Понятие базы данных
 Скачать 0.77 Mb.
|
Обработка исключительных ситуаций.Основу обработки исключительных ситуаций в С# составляет пара ключевых слов try и catch. Эти ключевые слова действуют совместно и не могут быть использованы порознь. Ниже приведена общая форма определения блоков try/catch для обработки исключительных ситуаций: try { // Блок кода, проверяемый на наличие ошибок. } catch (ExcepType1 exOb) { // Обработчик исключения типа ExcepType1. } catch (ExcepType2 exOb) { // Обработчик исключения типа ExcepType2. } ... где ExcepType — это тип возникающей исключительной ситуации. Когда исключение генерируется оператором try, оно перехватывается составляющим ему пару оператором catch, который затем обрабатывает это исключение. В зависимости от типа исключения выполняется и соответствующий оператор catch. Так, если типы генерируемого исключения и того, что указывается в операторе catch, совпадают, то выполняется именно этот оператор, а все остальные пропускаются. Когда исключение перехватывается, переменная исключения exOb получает свое значение. На самом деле указывать переменную exOb необязательно. Так, ее необязательно указывать, если обработчику исключений не требуется доступ к объекту исключения, что бывает довольно часто. Для обработки исключения достаточно и его типа. Следует, однако, иметь в виду, что если исключение не генерируется, то блок оператора try завершается как обычно, и все его операторы catch пропускаются. Выполнение программы возобновляется с первого оператора, следующего после завершающего оператора catch. Таким образом, оператор catch выполняется лишь в том случае, если генерируется исключение. Технологии конструирования программ. Основные определения и понятия.Идея формализации процесса разработки ПО развивалась в течение десятилетий. Мы лишь кратко рассмотрим основные вехи истории. Процесс просиживания штанов На заре человечества никаких формальностей не было. Программист обсуждал программу с потенциальными пользователями и сразу же бросался писать код. Это было, впрочем, вполне приемлемо для небольших программ. Каскадный процесс Когда программисты стали более серьезными людьми, они стали разбивать процесс разработки на несколько этапов, выполняемых последовательно. Эта идея была на самом деле позаимствована из производственных процессов. Этапы были таковы: анализ, планирование, кодирование и внедрение. Такая последовательность часто называлась каскадной или водопадной моделью, так как процесс всегда шел в одном направлении — от анализа к внедрению, как показано на рис. 16.1. Для реализации каждого из этапов стали привлекаться отдельные группы программистов, и каждая из них передавала результаты своего труда следующей. Опыт показал, что водопадная модель имеет множество недостатков. Ведь подразумевалось, что каждый из этапов выполняется без ошибок или с минимальным их количеством. Так, конечно, почти не бывает в жизни. Каждая фаза вносила свои ошибки, их количество от этапа к этапу росло, как снежный ком, делая всю программу одной большой ошибкой. К тому же в процессе разработки заказчик мог изменить свои требования, а по окончании этапа планирования уже сложно было вновь вернуться к нему. Оказывалось в итоге, что к моменту написания программа уже просто устаревала.  Рис. 16.1. Водопадная модель разработки ПО Объектно-ориентированное программирование само по себе ООП создавалось для решения некоторых проблем, присущих процессу развития больших программ. Разумеется, процесс планирования при использовании ООП резко упрощается, так как объекты программы соответствуют объектам реального мира. Но само по себе ООП не скажет нам, что должна делать программа, оно применимо уже после того, как определены цели и задачи проекта. Начальной, как и всегда, является фаза «инициализации», когда мы выясняем требования заказчика и четко представляем себе нужды потенциальных пользователей. Только после этого можно начинать планирование объектно-ориентированной программы. Но как же нам сделать этот первый шаг? Современные подходы За последние годы появилось множество новых концепций разработки ПО. Они определяют последовательность действий и способы взаимодействия заказчиков, постановщиков задач, разработчиков и программистов. На сегодняшний день ни один язык моделирования не обладает той универсальностью, каковая присуща UML . Многие эксперты до сих пор не могут поверить, что один и тот же подход к разработке может быть применим к созданию проектов любых видов. Даже когда уже выбран какой-то процесс, может понадобиться, в зависимости от применения программы, довольно сильно его изменить. В качестве примера современного метода разработки ПО рассмотрим основные черты подхода, которому мы дадим название Унифицированный процесс. Унифицированный процесс был создан теми же людьми, которые создали UML : Грэди Бучем ( Grady Booch ), Айвором Джекобсоном ( Ivar Jacobson ) и Джеймсом Рэмбо ( James Rumbaugh ). Иногда эту концепцию называют Рациональным унифицированным процессом ( Rational Unified Process , по названию компании, в которой он был разработан) или Унифицированным процессом разработки ПО. Унифицированный процесс разбивается на четыре этапа: · начало; · развитие; · построение; · передача. На начальной стадии выявляются общие возможности будущей программы и ее осуществимость. Фаза оканчивается одобрением руководства проекта. На этапе развития планируется общая архитектура системы. Именно здесь определяются требования пользователей. На стадии построения осуществляется планирование отдельных деталей системы и пишется собственно код. В фазе внедрения система представляется конечным пользователям, тестируется и внедряется. Все четыре фазы могут быть разбиты на ряд так называемых итераций. В частности, этап построения состоит из нескольких итераций. Каждая из них является подмножеством всей системы и отвечает определенным задачам, поставленным заказчиком. (Как мы увидим далее, итерации обычно соответствуют вариантам использования.) На рис. 16.2 показан Унифицированный процесс.  Рис. 16.2. Унифицированный процесс Каждая итерация включает в себя свою собственную последовательность этапов анализа, планирования, реализации и тестирования. Итерации могут повторяться несколько раз. Целью итерации является создание работающей части системы. В отличие от водопадного, Унифицированный процесс дает возможность вернуться на более ранние стадии разработки. Например, замечания, сделанные пользователями на стадии передачи, должны быть учтены, что приводит к пересмотру фазы построения и, возможно, фазы развития. Следует отметить, что рассматриваемая концепция Унифицированного процесса может быть применена к любым типам программной архитектуры, а не только кпроектам, в которых используются объектно-ориентированные языки. На самом деле, наверное, как раз слабой стороной этого подхода является не очень-то активное использование ООП. Фаза развития обычно за основу берет технологию вариантов использования (use case). Это отправная точка детальной разработки системы. По этой причине Унифицированный процесс называют прецедентным. . азработка программных средств имеет ряд специфических особенностей. · Прежде всего, следует отметить некоторое противостояние: неформальный характер требований к ПС (постановки задачи) и понятия ошибки в нем, но формализованный основной объект разработки — программы ПС. Тем самым разработка ПС содержит определенные этапы формализации, а, как известно, переход от неформального к формальному существенно неформален. · Разработка ПС носит творческий характер (на каждом шаге приходится делать какой-либо выбор, принимать какое-либо решение), а не сводится к выполнению какой-либо последовательности регламентированных действий. Тем самым, эта разработка ближе к процессу проектирования каких-либо технических устройств, но никак не к их массовому производству. Этот творческий характер разработки ПС сохраняется до самого ее конца. · Следует отметить также особенность продукта разработки. Он представляет собой некоторую совокупность текстов (т. е. статических объектов), смысл же (семантика) этих текстов выражается процессами обработки данных и действиями пользователей, запускающих эти процессы (т. е. является динамическим). Это предопределяет выбор разработчиком ряда специфичных приемов, методов и средств. Продукт разработки имеет и другую специфическую особенность: ПС при своем использовании (эксплуатации) не расходуется и не расходует используемых ресурсов. Эти особенности превращают разработку программных средств в уникальный вид человеческой деятельности. Первая особенность означает, что разработка ПС является в значительной степени формализацией описаний требуемых процессов обработки данных, при этом сохраняется опасность, что полученное формальное описание будет недостаточно точно отражать неформальное описание требуемых процессов обработки данных. Вторая особенность позволяет заметить сходство разработки ПС с проектированием технического устройства, но это сходство продолжается до самого конца разработки ПС. Другими словами, можно сказать, что ПС является своим собственным проектом, а процесс его производства является вырожденным. В связи с этим весьма осторожно следует относиться к так называемому индустриальному подходу к разработке программных средств (точно так же, как бы мы относились к индустриальному подходу к проектированию). Третья особенность означает, что статическая форма представления программного продукта слишком мало говорит о его приемлемости для пользователя, ценности и надежности. Все это может быть выявлено только в результате его применения на компьютере. Четвертая особенность отражает уникальные свойства информации: ПС как информационный объект после каждого его применения сохраняется в неизменном состоянии (не уменьшается, не «устает», не «стареет»). Его надежность не связана со временем или интенсивностью его применения. Каждое его применение связано с работой компьютера, на котором ПС для выполнения своих функций использует память, каналы ввода и вывода и другие ресурсы компьютера. После применения этого ПС все эти ресурсы сохраняются в компьютере и могут использоваться при применении другого ПС. |