Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
ТРПП пособие Шишов.doc
Скачиваний:
132
Добавлен:
17.11.2018
Размер:
3.25 Mб
Скачать

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

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

  • стандарт проектирования;

  • стандарт оформления проектной документации;

  • стандарт пользовательского интерфейса.

Стандарт проектирования должен устанавливать:

  • набор необходимых моделей на каждой стадии проектирования и степень их детализации;

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

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

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

Стандарт оформления проектной документации должен устанавливать:

  • комплектность, состав и структуру документации на каждой стадии проектирования;

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

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

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

Стандарт интерфейса пользователя должен устанавливать:

  • правила оформления элементов отображения данных;

  • правила использования элементов управления (клавиатуры);

  • правила оформления сообщений и их перечень;

  • правила обработки реакции пользователя.

6.3. Основные этапы технологического процесса разработки программ

Технологический процесс разработки программ делится на отдельные технологические операции – этапы (рис. 6).

Р и с. 6. Этапы процесса разработки программы

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

Входные и выходные данные программы и их связи определяют ее спецификацию. Спецификацией называется полное описание требований к исходной программе для конкретного типа ЭВМ. В спецификации учитываются ограничения на представление данных и связи с другими программными модулями. Различают внешние и внутренние спецификации.

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

– имя программы и имена всех точек входа;

– функции, выполняемые программой;

– число и порядок параметров, передаваемых программе;

– определение формата, размеров, атрибутов всех входных и выходных параметров;

– описание всех внешних для программы событий, происходящих при ее работе.

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

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

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

Существуют два варианта неопределенности:

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

• неизвестна структура автоматизируемых информационных процессов – обычно встречается при построении автоматизированных систем управления предприятиями.

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

Во втором случае определяют:

• структуру и взаимосвязи автоматизируемых информационных процессов;

• распределение функций между человеком и системой, а также между аппаратурой и программным обеспечением;

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

• требования к программным и информационным компонентам, необходимые аппаратные ресурсы, требования к базам данных и физические характеристики программных компонент.

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

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

Факторами, определяющими характеристики разрабатываемого программного обеспечения, являются:

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

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

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

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

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

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

На техническое задание существует стандарт ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению». В соответствии с этим стандартом техническое задание должно содержать следующие разделы:

• введение;

• основания для разработки;

• назначение разработки;

• требования к программе или программному изделию;

• требования к программной документации;

• технико-экономические показатели;

• стадии и этапы разработки;

• порядок контроля и приемки.

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

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

• требования к результатам (допустимую погрешность);

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

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

• выбор архитектуры программного обеспечения;

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

• выбор метода разработки;

• выбор языка и среды программирования.

Другими словами, эти решения определяют, что проектируется, с какими потребительскими характеристиками, как и какими средствами.

Виды архитектур уже рассматривались выше.

Тип пользовательского интерфейса во многом определяет сложность и трудоемкость разработки. По последним данным до 80 % программного кода может реализовывать именно пользовательский интерфейс. Виды пользовательского интерфейса будут рассмотрены отдельно.

В большинстве случаев никакой проблемы выбора языка программирования реально не существует. Язык может быть определен:

• организацией, ведущей разработку; например, если фирма владеет лицензионным вариантом C++ Builder, то она будет вести разработки преимущественно в данной среде;

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

• устоявшимся мнением («все разработки подобного рода должны выполняться на C++ или на Java или на ...») и т. п,

Если же все-таки выбор языка реально возможен, то нужно иметь в виду, что все существующие языки программирования можно разделить на следующие группы:

• универсальные языки высокого уровня;

• специализированные языки разработчика программного обеспечения;

• специализированные языки пользователя;

• языки низкого уровня.

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

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

Наиболее часто используемыми являются визуальные среды Delphi, C++ Builder фирмы Borland (Inprise Corporation), Visual C++, Visual Basic фирмы Microsoft, Visual Ada фирмы IBM и др.

Реальное применение любой технологии проектирования требует формирования или выбора ряда стандартов, которые должны соблюдаться всеми участниками проекта:

• стандарт проектирования;

• стандарт оформления проектной документации;

• стандарт интерфейса пользователя.

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

Процесс построения математической такой модели включает:

• анализ условия задачи;

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

• формальную постановку задачи;

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

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

Основная проблема в подобных случаях – обоснование применимости той или иной математической модели для решения конкретной задачи.

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

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

Функциональная схема или схема данных (ГОСТ 19.701-90) – схема взаимодействия компонентов программного обеспечения с описанием информационных потоков, состава данных в потоках и указанием используемых файлов и устройств. Функциональные схемы, более информативны, чем структурные. Для изображения функциональных схем используют специальные обозначения, установленные стандартом. Основные обозначения схем данных по ГОСТ 19.701-90 приведены в табл. 5.1.

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

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

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

Алгоритмы большой сложности обычно представляются с помощью схем двух видов:

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

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

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

Создание любой программы всегда подчиняется известной формуле: ПРОГРАММА = АЛГОРИТМ + СТРУКТУРА ДАННЫХ. После того как обозначены структура и алгоритм программы, необходимо определить состав и формат переменных и констант, с которыми она будет работать.

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

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

• вид хранимой информации каждого элемента данных;

• связи элементов данных и вложенных структур;

• время хранения данных структуры («время жизни»);

• совокупность операции над элементами данных, вложенными структурами и структурами в целом.

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

• целые и вещественные числа различных форматов;

• символы;

• булевские значения: true и false;

а также некоторые структурные типы данных, например:

• строки;

• записи;

• специально объявленные классы.

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

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

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

Различают две базовые структуры организации данных в оперативной памяти: векторную и списковую.

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

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

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

Желательно размещать в динамической памяти временные структуры, хранящие промежуточные результаты, и структуры, размер которых сильно зависит от вводимых исходных данных.

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

Однако при использовании списковых структур следует помнить, что:

• для хранения указателей необходима дополнительная память;

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

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

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

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

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

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

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

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

Основной результат работ этого этапа – создание эксплуатационной документации на программный продукт.