ТЕХНОЛОГИЯ ПРОГРАММИРОВАНИЯ

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

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

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

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

Типичная архитектура программы первого этапа Основная программа Глобальные данные Подпрограмма 1 Подпрограмма 2 Подпрограмма n При увеличении количества подпрограмм возрастала вероятность искажения части глобальных данных какой- либо подпрограммой. Здесь затруднена возможность параллельной разработки программы несколькими программистами

Усовершенствованная архитектура программ первого этапа Основная программа Глобальные данные Подпрограмма 1 Локальные данные В это время получила распространение технология программирования «снизу-вверх», не совершенство которой привело к кризису программирования (60-е годы). Подпрограмма 2 Локальные данные Подпрограмма n Локальные данные

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

Второй этап - структурный подход к программированию Структурный подход (60-70-е годы) охватывает все этапы разработки ПО. Он требует представления задачи в виде иерархии ( «часть-целое» ) подзадач более простой структуры вплоть до небольших подпрограмм (40-50 операторов). Разработка осуществляется «сверху-вниз», подразумевая детализацию общей идеи. Поддержка принципов структурного программирования была заложена в основу процедурных языков программирования PL/1, ALGOL-68, Pascal, С, включающих «структурные» операторы, подпрограммы, локализацию данных.

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

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

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

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

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

Четвертый этап – компонентный подход и CASE- технологии (с середины 90-х годов до нашего времени). Компонентный подход предполагает построение ПО из отдельных компонентов, которые взаимодействуют между собой через стандартизованные двоичные интерфейсы. В отличие от обычных объектов объекты- компоненты можно собрать в динамически вызываемые библиотеки или исполняемые файлы (*.dll *.exe), распространять в двоичном виде (без исходных текстов) и использовать в любом языке, поддерживающем соответствующую технологию.

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

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

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

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

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

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

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

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

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

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

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

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

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

Анализ требований и определение спецификаций Спецификациями называют точное формализованное описание функций и ограничений разрабатываемого ПО. Для получения спецификаций: - выполняют анализ требований ТЗ; - формулируют содержательную постановку задачи; - выбирают математический аппарат формализации; - строят модель предметной области; - определяют подзадачи и выбирают или разрабатывают методы их решения. Часть спецификаций может быть определена в процессе предпроектных исследований и, соответственно, зафиксирована в техническом задании. На этом этапе также целесообразно сформировать тесты для поиска ошибок в ПО, указав ожидаемые результаты.

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

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

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

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

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

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

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

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

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

Жизненный цикл ПО при использовании CASE-технологий. Computer-Aided Software/System Engineering - разработка программного обеспечения/программных систем с использованием компьютерной поддержки. CASE-технологии представляют собой совокупность методологий анализа, проектирования, разработки и сопровождения сложных программных систем, основанных как на структурном, так и на объектном подходах, которые поддерживаются комплексом взаимосвязанных средств автоматизации.

В основе любой CASE-технологии лежит парадигма методология/метод/нотация/средство. Методология – подход, шаги работы, их последователь- ность. Метод - способ достижения цели одного шага работы. Нотация - система обозначений, используемых для описания некоторого класса моделей. Используются для описания структуры проектируемой системы, элементов данных, этапов обработки и т.п. Средства инструментарий для поддержки методов.

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

Традиционная разработка Разработка с использованием CASE-средств Основные усилия на кодирование и тестирование Основные усилия на анализ и проектирование «Бумажные» спецификации Быстрое итерационное прототипирование Ручное кодирование Автоматическая генерация кодов Ручное документирование Автоматическая генерация документации Тестирование кодов Автоматический контроль проекта Сопровождение кодов Сопровождение спецификаций проектирования

Технология RAD Rapid Application Development – быстрая разработка приложений Спиральная модель ЖЦ ПО и CASE-технологий позволили сформулировать условия, выполнение которых сокращает сроки создания программного обеспечения: поддержка комплексом CASE-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ (спирального, итерационного); гарантированное достижение целей разработки с заданным качеством и в установленное время (3-6 месяцев); работа группами 3-7 человек.

Процесс разбивается на следующие этапы: Анализ и планирование требований - формулируют наиболее приоритетные требования. Проектирование - детально описывают подсистемы и процессы, используя CASE-средства. Определяют количество функциональных точек (ФТ - процедура, документ, форма, отчет, запрос) и создают команды разработчиков. менее 1 тыс. функциональных точек – 1 человек; от 1 до 4 тыс. функциональных точек – одна команда разработчиков; более 4 тыс. функциональных точек – одна команда на каждые 4 тыс. точек.

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

Оценка качества процессов создания ПО Существует несколько стандартов оценки качества процессов, которое обеспечивает организация-разработчик: ISO ISO сформулированы необходимые условия для достижения некоторого минимального уровня организации процесса, но не дается никаких рекомендаций по дальнейшему совершенствованию процессов. СММ – Capability Maturity Model – модель зрелости (совершенствования) процессов создания программного обеспечения, представляет собой совокупность критериев оценки зрелости организации-разработчика и рецептов улучшения существующих процессов. SPICE – Software Process Improvement and Capability dEtermination – определение возможностей и улучшение процесса создания программного обеспечения.

СММ определяет пять уровней зрелости организаций- разработчиков. 1. Начальный уровень (initial level) – на предприятии такого уровня организации не существует стабильных условий для создания качественного ПО. Результат зависит от личных качеств менеджера и опыта программистов. 2. Повторяемый уровень (repeatable level) – на предприятии внедрены технологии управления проектами. Существуют стандарты процессов разработки ПО. В критических условиях процесс может скатываться на начальный уровень.

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

4. Управляемый уровень (managed level) В организации устанавливаются количественные показатели качества ПО и процессов разработки. Управляющая роль числа. 5. Оптимизирующий уровень (optimizing level) Постоянно улучшаются существующие процессы. Мероприятия по улучшению качества применяются и к существующим процессам и к новым. Улучшение процессов помогает предупреждать возможные ошибки. Ведутся работы по уменьшению стоимости разработки ПО, (например повторное использование компонентов).