Технологии программирования

Размещено на http://www.allbest.ru/

Сущность и актуальность дисциплины «Технологии программирования», основные понятия и определения дисциплины

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

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

перечисление условий, при которых выполняется та или иная операция;

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

программный обеспечение тестовый проектирование

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

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

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

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

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

Спецификация в сфере проектной деятельности -- это какое-либо описание в точных терминах.

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

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

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

Методики проектирования излагаются в виде описаний проектных процедур и проектных операций.

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

Жизненный цикл программного средства.

Жизненный цикл программного средства - это совокупность процессов (software process), которая отражает его различные состояния, начиная с момента принятия решения о необходимости создания программного средства и заканчивая его полным изъятием из эксплуатации.

Состав процессов жизненного цикла регламентируется стандартами. Международными организациями, такими, как:

IEEE -- Институт инженеров по электротехнике и электронике;

* ISO --Международная организация по стандартизации;

* EIA --Ассоциация электронной промышленности;

* IEC --Международная комиссия по электротехнике;

а также некоторыми национальными и региональными институтами и организациями:

* ANSI --Американский национальный институт стандартов;

* SEI --Институт программной инженерии;

* ECMA --Европейская ассоциация производителей компьютерного оборудования;

Структура жизненного цикла базируется на трёх группах процессов:

Основные процессы.

Вспомогательные процессы.

Организационные процессы

Каждый процесс характеризуется определёнными задачами и методами их решения, исходными данными и результатами.

Основные процессы:

приобретение,

поставка,

разработка,

эксплуатация,

сопровождение.

Вспомогательные процессы (обеспечивающие выполнение основных процессов):

документирование,

обеспечение качества,

управление конфигурацией,

верификация,

аттестация.

Организационные процессы:

управление проектами,

создание инфраструктуры проекта,

определение,

оценка и улучшение самого жизненного цикла,

обучение.

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

подготовительную работу

анализ требований к системе

проектирование архитектуры

анализ требований к программному обеспечению

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

детальное проектирование программного обеспечения

кодирование и тестирование программного обеспечения

интеграцию программного обеспечения;

квалификационное тестирование программного обеспечения

интеграцию системы

квалификационное тестирование системы;

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

приемку программного обеспечения.

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

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

Модели жизненного цикла ПО.

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

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

Достоинствами такой схемы являются:

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

простота планирования процесса разработки.

Каскадная схема разработки программного обеспечения

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

неточные спецификации, уточнение которых в процессе разработки может привести к необходимости пересмотра уже принятых решений;

изменение требований заказчика непосредственно в процессе разработки;

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

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

Модель с промежуточным контролем

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

Схема разработки программного обеспечения с промежуточным контролем

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

Спиральная модель

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

Спиральная или итерационная схема разработки программного обеспечения

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

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

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

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

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

ускорить формирование и уточнение спецификаций за счет появления практики использования продукта;

уменьшить вероятность морального устаревания системы за время разработки.

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

Изменение жизненного цикла программного обеспечения при использовании CASE-технологий.

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

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

Метод определяет способ достижения той или иной цели - выполнение шага работы.

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

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

Автоматизируя трудоемкие операции, современные CASE-средства существенно повышают производительность труда программистов и улучшают качество создаваемого программного обеспечения. Они:

обеспечивают автоматизированный контроль совместимости спецификаций проекта;

уменьшают время создания прототипа системы;

ускоряют процесс проектирования и разработки;

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

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

поддерживают технологии повторного использования компонентов системы;

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

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

Качество программного обеспечения.

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

Стандарт ISO 9126-01 рассматривает внешние и внутренние характеристики качества.

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

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

функциональность,

надежность,

удобства использования,

эффективность,

сопровождаемость,

переносимость.

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

Деятельности и техники гарантии качества включают: инспекцию, верификацию и валидацию ПО.

Инспекция ПО - анализ и проверка различных представлений системы и ПО (спецификаций, архитектурных схем, диаграмм, исходного кода и др.) и выполняется на всех этапах ЖЦ разработки ПО.

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

Валидация - процесс проверки соответствия ПО функциональным и нефункциональным требованиям и ожидаемым потребностям заказчика.

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

Модели качества ПО

Качество ПО было предметом стандартизации, создан стандарт ГОСТ 28195-89, в котором дано определение качества ПО, как совокупность свойств (показателей качества) ПО, которые обеспечивают его способность удовлетворять потребности заказчика, в соответствии с назначением. Этот стандарт регламентирует базовую модель качества и его показатели, главным среди них является надежность.

На этапах ЖЦ проводится анализ качества ПО, ориентированный на:

достижение качества ПО в соответствии с требованиями и критериями;

верификацию и аттестацию (валидацию) промежуточных результатов ПО на этапах ЖЦ и измерение степени достижения отдельных его показателей;

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

Качество ПО характеризуется тремя главными аспектами: качество программного продукта, качество процессов ЖЦ и качество сопровождения или внедрения

Рис. 3.1 Основные аспекты качества ПО

Рис. 3.2. Модель характеристик качества

Модель качества ПО имеет следующие четыре уровня детализации.

Первый уровень соответствует определению характеристик (показателей) качества для ПО, каждая из них отражает отдельную точку зрения пользователя на качество. Согласно стандартов ISO/IEC 9126, ГОСТ 2895 - 89 определено шесть характеристик или шесть показателей качества в стандартной модели качества:

функциональность (functionality),

надежность (realibility),

удобство (usability),

эффективность (efficiency),

сопровождаемость (maitainnability),

переносимость (portability).

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

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

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

Метрики качества программного обеспечения.

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

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

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

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

метрики использования.

Метрики программного продукта включают:

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

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

Внутренние метрики позволяют определить производительность продукта и они являются релевантными по отношению к внешним метрикам.

Внешние и внутренние метрики задаются на этапе формирования требований к ПО и являются предметом планирования способов достижения качества конечного программного продукта.

Метрики процессов включают метрики:

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

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

ненадежности процесса - число не обнаруженных дефектов при проектировании;

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

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

общее время разработки и отдельно время для каждой стадии;

время модификации моделей;

время выполнения работ на процессе;

число найденных ошибок при инспектировании;

стоимость проверки качества;

стоимость процесса разработки.

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

Измерение и оценка качества ПО, стандартный метод оценки значений показателей качества.

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

По определению стандарта ISO/IES 9126-2 метрика качества ПО представляет собой “модель измерения атрибута, связываемого с показателем его качества”. Для пользования метриками при измерения показателей качества данный стандарт позволяет определять следующие типы мер:

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

меры времени - периоды реального, процессорного или календарного времени (время функционирования системы, время выполнения компонента, время использования и др.);

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

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

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

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

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

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

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

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

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

метрическая (1.1 - абсолютная, 1.2 - относительная, 1.3 - интегральная);

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

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

Управление качеством ПС.

Под управлением качества понимается совокупность организационной структуры и ответственных лиц, а также процедур, процессов и ресурсов для планирования и управления достижением качества ПС. Управление качеством - SQM (Software Quality Management) базируется на применении стандартных положений по гарантии качества - SQA (Software Quality Assurance).

Цель процесса SQA состоит в гарантировании того, что продукты и процессы согласуются с требованиями, соответствуют планам и включает следующие виды деятельности:

внедрение стандартов и соответствующих процедур разработки ПС на этапах ЖЦ;

оценка соблюдения положений этих стандартов и процедур.

Гарантия качества состоит в следующем:

проверка непротиворечивости и выполнимости планов;

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

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

анализ применяемых процессов на соответствие договору и планам;

среда и методы разработки согласуются с заказом на разработку;

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

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

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

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

Требования стандарта к организации системы качества

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

Планирование качества представляет собою деятельность, направленную на определение целей и требований к качеству.

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

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

Обеспечение качества заключается в выполнении и проверки того, что объект разработки выполняет указанные требования к качеству.

Диалоговые программы, типы диалога, формы диалога.

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

Различают тип диалога и его форму.

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

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

фразовую,

директивную,

табличную.

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

Основными недостатками фразовой формы при использовании подмножества естественного языка являются:

большие затраты ресурсов;

отсутствие гарантии однозначной интерпретации формулировок;

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

Основное достоинство фразовой формы состоит в относительно свободном общении с системой.

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

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

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

Рис 4.1. Соответствие типов диалогов и его форм

Спецификация ПС.

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

Внешнее описание ПС = спецификация качества ПС + функциональная спецификация ПС

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

Определение требований к программному средству.

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

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

Известны три способа определения требований к ПС:

управляемый пользователем,

контролируемый пользователем,

независимый от пользователя.

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

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

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

Спецификация качества программного средства.

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

Функциональность: завершенность.

Надежность: завершенность, точность, автономность, устойчивость, защищенность.

Эффективность: временнaя эффективность, эффективность по памяти, эффективность по устройствам.

Модифицируемость: расширяемость, структурированность, модульность.

Мобильность: независимость от устройств, автономность, структурированность, модульность.

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

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

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

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

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

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

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

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

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

Функциональная спецификация программного средства.

Функциональная спецификация состоит из трех частей:

описания внешней информационной среды, к которой должны применяться программы разрабатываемой ПС;

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

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

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

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

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

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

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

статический просмотр,

смежный контроль,

пользовательский контроль,

ручная имитация.

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

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

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

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

Способы записи алгоритмов.

Существует четыре способа записи алгоритмов:

Словесный;

Графический;

Псевдокод;

Программа.

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

Представление основных структур алгоритмов.

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

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

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

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

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

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



Псевдокоды.

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



Flow-формы.

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

На рис. 6.4 представлено описание рассмотренного ранее поискового цикла с использованием Flow-формы. Хорошо видны вложенность и следование конструкций, изображенных прямоугольниками.



Рис. 6.4. Алгоритм поискового цикла

Диаграммы Насси-Шнейдермана.

Диаграммы Насси-Шнейдермана являются развитием Flow-форм. Основное их отличие от Flow-форм заключается в том, что область обозначения условий и вариантов ветвления изображают в виде треугольников (рис. 6.5). Такое обозначение обеспечивает большую наглядность представления алгоритма.

Рис. 6.5. Условные обозначения диаграмм Насси-Шнейдермана для основных конструкций: а - следование, б- ветвление, в - выбор, г - цикл-пока, д- цикл-до

Классификация структур данных.

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

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

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

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

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

Простые -- это встроенные, стандартные, базовые, примитивные структуры данных, интегрированные -- структурированные, производные, композитные, сложные структуры данных. Интегрированные структуры данных обычно относят к типам данных, определяемых программистом.

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

Рис. 7.1. Примеры широко известных структур данных

Файловые структуры, физическая организация файлов.

Файл -- упорядоченный набор информации на внешнем носителе (наиболее часто на дисковом носителе).

Физическая информация файла на внешнем носителе соотносится с логической структурой данных оперативной памяти методами доступа операционных систем.

Обычно файловая система операционной системы компьютера содержит следующие средства:

управление файлами: хранение файлов, обращение к ним, их коллективное использование и защита;

обеспечение целостности файлов -- гарантирование того, что файл содержит только то, что требовалось;

средства управления внешней памятью (распределяют внешнюю память для размещения файлов).

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

строковое имя файла;

тип файла (расширение имени) -- информация для пользователя о предполагаемой информации в файле;

размещение файла во внешней памяти;

тип организации файла (прямой, последовательный, индексно-последовательный и т. д.);

тип устройства (несъемный, съемный, допускающий только чтение и т. д.);

данные (атрибуты) для контроля доступа (владелец, групповой пользователь, допущенный и общедоступный пользователи);

диспозицию (файл постоянный или временный);

дату и время создания;

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

Наиболее общими операциями работы с файлами являются следующие операции:

связывание полного имени файла с файловыми переменными;

открытие файла (например, для записи, только чтения, изменения длины);

закрытие файлов;

установление атрибутов файла.

Логическая организация файлов.

Программист имеет дело с логической организацией файла, представляя файл в виде определенным образом организованных логических записей. Логическая запись - это наименьший элемент данных, которым может оперировать программист при обмене с внешним устройством. Даже если физический обмен с устройством осуществляется большими единицами, операционная система обеспечивает программисту доступ к отдельной логической записи. На рисунке 2.33 показаны несколько схем логической организации файла. Записи могут быть фиксированной длины или переменной длины. Записи могут быть расположены в файле последовательно (последовательная организация) или в более сложном порядке, с использованием так называемых индексных таблиц, позволяющих обеспечить быстрый доступ к отдельной логической записи (индексно-последовательная организация). Для идентификации записи может быть использовано специальное поле записи, называемое ключом. В файловых системах ОС UNIX и MS-DOS файл имеет простейшую логическую структуру - последовательность однобайтовых записей.



Рис. 2.33. Способы логической организации файлов

Документирование файлов.

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

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

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

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

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

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

«Чтение/запись» файлов со сложной произвольной организацией, как правило, производится последовательными порциями. Первая порция считывается в статическую запись оперативной памяти. Эту запись называют заголовочной (header). Она содержит один или несколько байтов идентификации, которые необходимы для проверки подлинности файла (его принадлежности к конкретным программам). В заголовочной информации может быть указана версия файла. Считывание последующих порций осуществляется как в статические, так и в динамические связные переменные, причем их длина может определяться информацией, полученной как из заголовочной порции, так и из ряда предшествующих порций.

Модульные программы, модули и их свойства.

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

Данные модуль может получать и/или возвращать через общие области памяти или параметры.

Первоначально к модулям (еще понимаемым как подпрограммы) предъявлялись следующие требования:

отдельная компиляция;

одна точка входа;

одна точка выхода;

соответствие принципу вертикального управления;

возможность вызова других модулей;

небольшой размер (до 50-60 операторов языка);

независимость от истории вызовов;

выполнение одной функции.

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

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

легче разобраться в отдельном модуле и всей программе и, соответственно, тестировать, отлаживать и модифицировать ее;

меньше вероятность появления новых ошибок при исправлении старых или внесении изменений в программу, т. е. вероятность появления «волнового» эффекта;

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

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

Сцепление и связность модулей.

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

по данным;

по образцу;

по управлению;

по общей области данных;

по содержимому.

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

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

функциональную;

последовательную;

информационную (коммуникативную);

процедурою;

временную;

логическую;

случайную.

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