Logo GenDocs.ru

Поиск по сайту:  

Загрузка...

Шпоры по ТП - файл ответы_all.doc


Шпоры по ТП
скачать (5040 kb.)

Доступные файлы (1):

ответы_all.doc7653kb.20.06.2010 21:43скачать

содержание

ответы_all.doc

  1   2   3   4   5

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  2. • ISO —Международная организация по стандартизации;

  3. • EIA —Ассоциация электронной промышленности;

  4. • IEC —Международная комиссия по электротехнике;

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

  6. • ANSI —Американский национальный институт стандартов;

  7. • SEI —Институт программной инженерии;

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

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

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

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

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

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

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

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

  • поставка,

  • разработка,

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

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

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

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

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

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

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

  • аттестация.

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

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

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

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

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

  • обучение.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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




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

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

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

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

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

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

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

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


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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • надежность,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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




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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

  • фразовую,

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

  • табличную.

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. Словесный;

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

  3. Псевдокод;

  4. Программа.

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

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

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

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

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

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

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

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



  1. Псевдокоды.

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



  1. Flow-формы.

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

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



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

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

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



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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • по данным;

  • по образцу;

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

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

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

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

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

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

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

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

  • процедурою;

  • временную;

  • логическую;

  • случайную.

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

  1. ^ Нисходящая и восходящая разработка программного обеспечения.

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

  • восходящий;

  • нисходящий.

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

Для тестирования и отладки компонентов проектируют и реализуют специальные тестирующие программы. Подход имеет следующие недостатки:

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

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

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

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

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

  1. ^ Программирование «с защитой от ошибок».

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



Рис. 8.2. Способы проявления ошибок

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

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

  • правильность выполнения операций ввода-вывода;

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

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

ошибки передачи – аппаратные средства, например, вследствие неисправности, искажают данные;

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

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

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

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

  1. ^ Основные подходы программирования, «стихийное» программирование.

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

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

  1. ^ Основные подходы программирования, структурный подход к программированию.

Второй этап – структурный подход к программированию (60-70-с годы XX в.). Структурный подход к программированию представляет собой совокупность рекомендуемых технологических приемов, охватывающих выполнение всех этапов разработки программного обеспечения. В основе структурного подхода лежит декомпозиция (разбиение на части) сложных систем с целью последующей реализации в виде отдельных небольших (до 40-50 операторов) подпрограмм. С появлением других принципов декомпозиции (объектного, логического и т. д.) данный способ получил название процедурной декомпозиции.

Поддержка принципов структурного программирования была заложена в основу так называемых процедурных языков программирования. Среди наиболее известных языков этой группы стоит назвать PL/1, ALGOL-68, Pascal, С.

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

  1. ^ Основные подходы программирования, объектный подход к программированию.

Третий этап – объектный подход к программированию (с середины 80-х до конца 90-х годов XX в.). ^ Объектно-ориентированное программирование определяется как технология создания сложного программного обеспечения, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного типа (класса), а классы образуют иерархию с наследованием свойств. Взаимодействие программных объектов в такой системе осуществляется путем передачи сообщений.

Основным достоинством объектно-ориентированного программирования по сравнению с модульным программированием является «более естественная» декомпозиция программного обеспечения, которая существенно облегчает его разработку. Бурное развитие технологий программирования, основанных на объектном подходе, позволило решить многие проблемы. Так были созданы среды, поддерживающие визуальное программирование, например, Delphi, C++ Builder, Visual C++ и т. д.

  1. ^ Основные подходы программирования, компонентный подход и CASE-технологии.

Компонентный подход предполагает построение программного обеспечения из отдельных компонентов физически отдельно существующих частей программного обеспечения, которые взаимодействуют между собой через стандартизованные двоичные интерфейсы. В отличие от обычных объектов объекты-компоненты можно собрать в динамически вызываемые библиотеки или исполняемые файлы, распространять в двоичном виде (без исходных текстов) и использовать в любом языке программирования, поддерживающем соответствующую технологию. Компонентный подход лежит в основе технологий, разработанных на базе COM (Component Object Model – компонентная модель объектов), и технологии создания распределенных приложений CORBA (Common Object Request Broker Architecture – общая архитектура с посредником обработки запросов объектов). Эти технологии используют сходные принципы и различаются лишь особенностями их реализации.

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

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

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

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

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


^ 36. Процедурное (императивное) программирование

Процедурное (императивное) программирование является отражением архитектуры традиционных ЭВМ, которая была предложена фон Нейманом в 40-х годах. Теоретической моделью процедурного программирования служит алгоритмическая система под названием «машина Тьюринга».

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

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

Процедурные языки характеризуются следующими особенностями:

  • необходимостью явного управления памятью, в частности, описанием переменных;

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

  • отсутствием строгой математической основы;

  • высокой эффективностью реализации на традиционных ЭВМ.


^ 37.Функциональное программирование.

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

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

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

Наиболее общие принципы функционального программирования:

1) ^ Унификация понятий <функция> и <значение>. 2)Кроме функций-констант, вполне допустимы функции-переменные.3)Самоприменимость.4)Интегральность ограничений на пространственно-временные характеристики.5)Уточняемость решений.6) Множественность определений.

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

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

3) ^ Подобие машинным языкам

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

^ 38. Декларативное программирование

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

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

Наиболее существенными классами декларативных языков являются функциональные (functional) или аппликативные, и логические (logic) языки. К категории функциональных языков относятся, например, Lisp и Haskell. Самым известным языком логического программирования является Prolog (Пролог).
^ 39. Объектно-ориентированное программирование

Объе́ктно-ориенти́рованное программи́рование (ООП) — парадигма программирования, в которой основными концепциями являются понятия объектов и классов (либо, в менее известном варианте языков с прототипированием, — прототипов).

Класс — это тип, описывающий устройство объектов. Понятие «класс» подразумевает некоторое поведение и способ представления. Понятие «объект» подразумевает нечто, что обладает определённым поведением и способом представления. Говорят, что объект — это экземпляр класса. Класс можно сравнить с чертежом, согласно которому создаются объекты. Обычно классы разрабатывают таким образом, чтобы их объекты соответствовали объектам предметной области.

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

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

Прототип — это объект-образец, по образу и подобию которого создаются другие объекты.

^ Абстракция данных 

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

Инкапсуляция 

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

Сокрытие данных — неотделимая часть ООП, управляющая областями видимости. Является логическим продолжением инкапсуляции. Целью сокрытия является невозможность для пользователя узнать или испортить внутреннее состояние объекта.

Наследование 

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

Полиморфизм 

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

^ 40.Объектно-ориентированные языки программирования.

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

  • Объявление классов с полями (данными — членами класса) и методами (функциями — членами класса).

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

  • Средства защиты внутренней структуры классов от несанкционированного использования извне. Обычно это модификаторы доступа к полям и методам, типа public, private, обычно также protected, иногда некоторые другие.

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

  • Полиморфное поведение экземпляров классов за счёт использования виртуальных методов. В некоторых ООП-языках все методы классов являются виртуальными.

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

  • Конструкторы, деструкторы, финализаторы.

  • Свойства (аксессоры).

  • Индексаторы.

  • Интерфейсы (например, в Java используются также как альтернатива множественному наследованию — любой класс может реализовать сколько угодно интерфейсов).

  • Переопределение операторов для классов.

  1   2   3   4   5



Скачать файл (5040 kb.)

Поиск по сайту:  

© gendocs.ru
При копировании укажите ссылку.
обратиться к администрации