48278 (588533), страница 8

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

Текст из файла (страница 8)

2.3.2 Структурный анализ

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

2.3.3 Структурное проектирование

Логические связи, существующие между различными элементами данных, составляют основу всего процесса проектирования. Процесс проектирования должен быть структурирован. Проектирование становится более целенаправленным, если в его основе лежат зависимости между данными, присущие решаемой проблеме, а не условия, диктуемые вычислительной средой. Функциональные связи между программами могут быть определены еще до того, как начнется разработка соответствующих алгоритмов. На этапе проектирования вопросы реализации решаются на абстрактном уровне с использованием диаграмм, таблиц, структурных схем и псевдокодов. Эта информация обеспечивает возможность первоначальной проверки системы. Если проект системы или программы разработан на достаточно детальном уровне, допускающем моделирование основных процессов обработки данных, количество ошибок, возникающих на стадии реализации, резко снижается. Ошибки на этой стадии обходятся весьма дорого, поскольку к этому времени в проект вложено слишком много усилий. Гораздо проще вносить коррективы в проект на этапе разработки, чем вновь возвращаться к нему уже после его завершения.

2.3.4 Реализация и испытания

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

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

В конечном итоге вся система в целом будет испытана и готова к внедрению в промышленную эксплуатацию.

2.4 Вспомогательные средства проектирования

2.4.1 Графическая схема задания

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

Рис. 2.2. Графическая схема задания.

2.4.2 Развернутый план проекта системы

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

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

   2. Сфера применения. Характеризуется круг пользователей, на которых ориентирована разрабатываемая система.

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

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

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

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

   2. Программные средства. Указываются типы операционных систем, используемые библиотеки стандартных программ, системы управления базами данных.

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

3. Связь с внешней средой. Описывается взаимодействие пользователей с системой.

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

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

   3. Управляющие параметры. Перечисляются параметры, задаваемые при настройке системы на конкретную конфигурацию технических и программных средств.

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

4. Качество системы.

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

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

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

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

5. Документация по системе.

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

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

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

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

2.5 Организация процесса проектирования

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

• составление рабочих спецификаций

• составление перечня характеристик

• внешнее описание данных

• внешнее описание программ

• разработка архивов данных

• разработка программных модулей

• разработка тестовых задач

• кодирование программных модулей

• проверка программных модулей

• объединение программных модулей

• испытание системы в целом

• комплектация программной сопровождающей документации

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

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

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

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

2.6 Необходимость тестирования программных продуктов

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

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

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

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

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

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

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

Характеристики

Список файлов ВКР