Проектирование ПО — это процесс определения архитектуры, компонентов, интерфейсов, других характеристик системы и конечного состава программного продукта. Область знаний «Проектирование ПО ( Software Design )» состоит из следующих разделов:
- базовые концепции проектирования ПО ( Software Design Basic Concepts),
- ключевые вопросы проектирования ПО (Key Issue in Software Design ),
- структура и архитектура ПО (Software Structure and Architecture),
- анализ и оценка качества проектирования ПО ( Software Design Quality Analysis and Evaluation),
- нотации проектирования ПО ( Software Design Notations),
- стратегия и методы проектирования ПО (Software Design Strategies and Methods).
Базовая концепция проектирования ПО — это методология проектирования архитектуры с помощью разных методов (объектного, компонентного и др.), процессы ЖЦ (стандарт ISO/IEC 12207) и техники — декомпозиция, абстракция, инкапсуляция и др. На начальных стадиях проектирования предметная область декомпозируется на отдельные объекты (при объектно-ориентированном проектировании) или на компоненты (при компонентном проектировании). Для представления архитектуры программного обеспечения выбираются соответствующие артефакты (нотации, диаграммы, блок-схемы и методы).
SDLС — Жизненный цикл разработки программного обеспечения. Подробный разбор этапов разработки.
К ключевым вопросам проектирования ПО относятся: декомпозиция программ на функциональные компоненты для независимого и параллельного их выполнения, принципы распределения компонентов в среде выполнения и их взаимодействия между собой, механизмы обеспечения качества и живучести системы и др.
При проектировании архитектуры ПО используется архитектурный стиль проектирования, основанный на определении основных элементов структуры — подсистем, компонентов и связей между ними.
Архитектура проекта — высокоуровневое представление структуры системы и спецификация ее компонентов. Архитектура определяет логику отдельных компонентов системы настолько детально, насколько это необходимо для написания кода, а также определяет связи между компонентами. Существуют и другие виды представления структур, основанные на проектировании образцов, шаблонов, семейств программ и каркасов программных сред.
Одним из важнейших инструментов проектирования архитектуры является паттерн — типовой конструктивный элемент ПО, который задает взаимодействие объектов (компонентов) проектируемой системы, а также роли и ответственности исполнителей. Основным языком описания этого элемента является UML. Он может быть структурным, включающим типовые композиции структур из объектов и классов, объектов, связей и др.; поведенческим, определяющим схемы взаимодействия классов объектов и их поведение диаграммами активностей , взаимодействия, потоков управления и др.; порождающим, отображающим типовые схемы распределения ролей экземпляров объектов и способы динамической генерации структур объектов и классов.
Анализ и оценка качества проектирования ПО включает мероприятия по анализу сформулированных в требованиях атрибутов качества, оценки различных аспектов ПО — количества функций, структура ПО, качества проектирования с помощью формальных метрик (функционально-ориентированных, структурных и объектно-ориентированных), а также проведения качественного анализа результатов проектирования путем статического анализа, моделирования и прототипирования.
Классификация программного обеспечения
Нотации проектирования позволяют представить описание объекта (элемента) ПО и его структуру, а также поведение системы. Существует два типа нотаций: структурные, поведенческие и множество различных их представлений.
Структурные нотации — это структурное, блок-схемное или текстовое представление аспектов проектирования структуры ПО из объектов, компонентов, их интерфейсов и взаимосвязей. К нотациям относятся формальные языки спецификаций и проектирования: ADL (Architecture Description Language), UML (Unified Modeling Language), ERD (Entity-Relation Diagrams), IDL (Interface Description Language), Use Case Driven и др. Нотации включают языки описания
архитектуры и интерфейса, диаграммы классов и объектов, диаграммы сущность-связь , конфигурации компонентов, схем развертывания, а также структурные диаграммы, задающие в наглядном виде операторы цикла, ветвления, выбора и последовательности.
Поведенческие нотации отражают динамический аспект поведения систем и их компонентов. Таким нотациям соответствуют диаграммы потоков данных (Data Flow), таблиц принятия решений ( Decision Tables ), деятельности (Activity), кооперации (Collaboration), последовательности (Sequence), пред- и постусловия (Pre-Post Conditions), формальные языки спецификации (Z, VDM , RAISE), языки проектирования PDL и др.
Стратегия и методы проектирования ПО.К стратегиям относятся: проектирование снизу-вверх, сверху-вниз, абстрагирование, использование паттернов и др. методы — это функционально-ориентированные, структурные, которые базируются на структурном анализе, структурных картах, диаграммах потоков данных (Dataflow) и др. Они ориентированы на идентификацию функций и их уточнение сверху-вниз, после чего уточняются диаграммы потоков данных и проводится описание процессов.
В объектно-ориентированном проектировании ключевую роль играет наследование, полиморфизм и инкапсуляция, а также абстрактные структуры данных и отображение объектов. Подходы, ориентированные на структуры данных, базируются на методе Джексона [1.8] и используются для задания входных и выходных данных структурными диаграммами. Метод UML предназначен для сценарного моделирования проекта [1.19] в наглядном диаграммном виде. Компонентное проектирование ориентировано на использование готовых компонентов (reusing), их интерфейсов и интеграцию для формирования конфигурации, служащей основой развертывания компонентного ПО и взаимодействия компонентов в операционной среде.
Формальные методы описания программ основываются на спецификациях, аксиомах, описаниях некоторых условий, называемых предварительными (предусловиями), утверждениях и постусловиях, определяющих заключительное условие получения правильного результата программой. Спецификация является формальным описанием функций и данных программы, с которыми эти функции оперируют. Различают входные и выходные параметры функции, а также данные, которые не привязаны к реализации и определяют интерфейс с другими функциями. По формальным спецификациям,
условиям и утверждениям выполняется доказательство правильности программы
1.1.3. Конструирование ПО (Software Construction)
Конструирование ПО — создание работающего ПО с привлечением методов верификации, кодирования и тестирования компонентов. К инструментам конструирования ПО отнесены языки программирования и конструирования, а также программные методы и инструментальные системы (компиляторы, СУБД, генераторы отчетов, системы управления версиями, конфигурацией, тестированием и др.). К формальным средствам описания процесса конструирования ПО, взаимосвязей между человеком и компьютером и с учетом среды окружения отнесены, например, структурные диаграммы Джексона.
Область знаний «Конструирование ПО (Software Construction)» включает следующие разделы:
- снижение сложности ( Reduction in Complexity),
- предупреждение отклонений от стиля (Anticipation of Diversity ),
- структуризация проверок (Structuring for Validation),
- использование внешних стандартов (Use of External Standards)
Снижения сложности — это минимизация, уменьшение и локализация сложности конструирования.
Минимизация сложности определяется ограниченными возможностями исполнителей обрабатывать сложные структуры и большие объемы информации на протяжении длительного периода времени. Минимизация сложности достигается, в частности, использованием в процессе конструирования модулей и других более простых элементов а также рекомендациями стандартов.
Уменьшение сложности в конструировании ПО достигается при создании простого и легко читаемого кода для придания большей значимости этого кода, простоте тестирования, производительности и удовлетворению заданных критериев. Это влияет на функциональность, характеристики и ограничения проекта. Потребность в уменьшении сложности влияет на все аспекты конструирования и особенно критична для процессов верификации (проверки) и тестирования результатов конструирования элементов ПС.
Локализация сложности — это способ конструирования с применением объектно-ориентированного подхода, который лимитирует интерфейс объектов, упрощает их взаимодействие, также проверку правильности самих объектов и связей между ними. Локализация упрощает внесение изменений, связанных с обнаруженными ошибками в коде, либо источником ошибок является среда, в которой выполняется код.
Предупреждение отклонений от стиля.Для решения различных задач конструирования применяются разные стили конструирования (лингвистический, формальный, визуальный).
Лингвистический стиль основан на использовании словесных инструкций и выражений для представлений отдельных элементов (конструкций) программ. Он используется при конструировании несложных конструкций и приводится к виду традиционных функций и процедур, логическому и функциональному их программированию и др.
Формальный стиль используется для точного, однозначного и формального определения компонентов системы. В результате его применения обеспечивается конструирование сложных систем с минимальным количеством ошибок, которые могут возникнуть в связи с неоднозначностью определений или обобщений при конструировании ПО неформальными методами.
Визуальный стиль является наиболее универсальным стилем конструирования ПО, он позволяет разработчикам проекта представлять конструируемый элемент в наглядном виде. Визуальный язык проектирования UML представляет разработчику набор удобных диаграмм для задания статической и динамической структуры ПО [1.17]. При применении визуального стиля конструирования создается текстовое и диаграммное описание конструктивных элементов ПО, которое выводится на экран дисплея не только для их наглядного представления, но и корректировки.
Структуризация проверок предполагает, что построение ПС должно проводиться таким образом, чтобы сама система помогала вести поиск ошибок, дефектов и причин сбоев при применении различных методов проверки, как на стадии независимого тестирования (например, инженерами-тестировщиками), так и в процессе эксплуатации, когда особенно важно быстрое обнаружение и исправление возникающих ошибок. Структуризации проверок способствуют обзор, инспектирование, просмотр, модульное тестирование, применение автоматизированных средств тестирования и др.
Использование внешних стандартов. Конструирование ПО зависит от применения внешних стандартов, связанных с языками программирования, инструментальными средствами и интерфейсами. При конструировании должен быть определен достаточный и полный набор стандартов для руководства и обеспечения координации между определенными видами деятельности, группами операций, минимизации сложности, внесения изменений, анализа рисков и др.
Иными словами, внешние и внутренние стандарты должны определить общие правила работы членов проектной команды с учетом процессов ЖЦ. Такими стандартами являются: языки программирования (например, Java Language Specification, С++), интерфейсы ЯП и прикладные интерфейсы платформ Windows и др. При конструировании используются стандарты: ЯП (Ада 95, С++ и др.), языков описания данных (XML, SQL и др.), средств коммуникации (COM, CORBA и др.), интерфейсных языков (POSIX, IDL, APL ) [1.18], сценарии UML [1.17] и др.
Данная область пополнилась новым разделом (SWEBOK, 2004 г.), описываемым ниже.
Управление конструированием — это управление процессом конструирования ПО, которое базируется на моделях конструирования, планировании и внесении изменений.
Модели конструирования включают набор операций, последовательность действий и результатов. Виды моделей определяются стандартом ЖЦ, методологиями и практиками. Некоторые стандарты ЖЦ по своей природе ориентированы на конструирование, например, экстремальное программирование (XP — eXtreme Programming ). Конструирование с помощью моделирования осуществляется в рациональном унифицированном процессе — RUP (Rational Unified Process) [1.19].
Планирование состоит в определении порядка операций и уровня выполнения заданных условий в процессе конструкторской деятельности. Определяется модель ЖЦ, включающая задачи и действия по созданию компонентов, а также по их проверке, включая достижение показателей качества на этапах ЖЦ. Исполнители распределяются по процессам ЖЦ и выполняют соответствующие задачи по реализации промежуточного продукта. Затем проводится измерение разных аспектов конструирования, например, количественная оценка объема кода, оценка степени использования reuse, вычисление вероятности появления дефектов и оценка количественных показателей качества ПО.
Внесение изменений связано с ошибками, выявленными путем разного рода проверок и тестирований, оно проводится с целью сохранения функциональной целостности системы. В случае обнаружения ошибок на этапе сопровождения принимается решение об изменении кода путем исправления обнаруженных ошибок или внесения изменений в требования к ПО.
1.1.4. Тестирование ПО (Software Testing)
Тестирование ПО — это процесс проверки готовой программы в статике (просмотры, инспекции, отладки исходного кода) и в динамике путем прогона конечного набора тестовых данных, проверяющих разные пути выполнения программы и сравнении полученных результатов с заранее запланированными.
Существует две формы проверки кода — модульное и интеграционное. При этом используются стандарты (IEEE 829-1996 и IEEE 1008-1987) проверки и тестирования модулей ПО. Затем проводится интеграционное тестирование модулей системы и их интерфейсов в динамике выполнения. В процессе разных видов проверок собираются данные об ошибках, дефектах, отказах и т.п. и оформляется соответствующая документация (таблицы типов ошибок, частота и время появления отказов и др.). Данные, собранные при отладке, просмотрах, инспекции и тестировании, используются для оценки характеристик качества готового ПО, например, атрибутов показателя надежности — интенсивность отказов , количество ошибок и др.
Область знаний «Тестирование ПО (Software Testing)» включает следующие разделы:
- основные концепции и определение тестирования (Testing Basic Concepts and definitions),
- уровни тестирования ( Test Levels ),
- техники тестирования (Test Techniques),
- метрики тестирования (Test Related Measures),
- управление процессом тестирования (Managing the Test Process ).
Данная область знаний SWEBOK представляет разработчику методы проверки правильности ПО: верификация, валидация, тестирование. Определяются типы, уровни и техники тестирования ПО, методы планирования процесса тестирования и разработки тестовых наборов данных для прогонки ПО в режиме испытания конкретного модуля или системы в целом, с последующим измерением результатов тестирования.
Основная концепция тестирования описывает базовые термины, ключевые проблемы и их связь с другими областями знаний. Тестирование — это процесс проверки правильности программы в динамике ее выполнения на тестовых данных.
При тестировании выявляются недостатки: отказы (faults) и дефекты ( defects ) как причины нарушения работы программы, сбои (failures) как нежелательные ситуации, ошибки (errors), как последствия сбоев и др. Базовым понятием тестирования является тест, который выполняется в заданных условиях и на заданных наборах данных. Тестирование считается успешным, если найден дефект или ошибка, и они сразу устраняются. Степень тестируемости определяется критерием покрытия системы тестами, проверки всех возможных путей выполнения алгоритмов программ и вероятности статического предположения того, что при тестировании может появиться сбой или ошибочная ситуация в системе.
Уровни тестирования:
- тестирование отдельных элементов,которое заключается в проверке отдельных, изолированных и независимых частей ПО;
- интеграционное тестирование,которое ориентировано на проверку связей и способов взаимодействия (интерфейсов) компонентов друг с другом, включая компоненты, расположенные на разных архитектурных платформах распределенной среды;
- тестирование системы предназначено для проверки правильности функционирования системы в целом, с обнаружением отказов и дефектов в системе и их устранение. При этом контролируется выполнение сформулированных нефункциональных требований (безопасность, надежность и др.) в системе, правильность задания и выполнения внешних интерфейсов системы со средой окружения и др.
Источник: intuit.ru
1.4. Проектирование и реализация программы
Проектирование – это процесс разработки структурной схемы программного обеспечения с проектированием компонентов и их взаимосвязей. Тип модели программного обеспечения определяется выбранной технологией — методом программирования (процедурный, объектно-ориентированный, компонентный).
При процедурном подходе модель построения программного обеспечения – иерархия функций, т.е. декомпозиция программы по функциональному принципу.
Методы декомпозиции используют простые пользовательские интерфейсы: простое меню без иерархии команд, меню с иерархической структурой команд, и рассчитаны на проектирование структур данных и программ. Проектирование заключается в декомпозиции программного обеспечения методом пошаговой детализации. В результате декомпозиции получается структурная схема программы, представляющая собой многоуровневую, иерархическую схему взаимодействия подпрограмм по управлению.
Метод пошаговой детализации применяет нисходящую пошаговую разработку алгоритма, когда на каждом шаге происходит разложение функции на подфункции.
При объектно-ориентированном подходе модель построения программы – это иерархия классов, объектная декомпозиция. В результате декомпозиции получается структурная схема программы, представляющая собой многоуровневую, иерархическую схему взаимодействия классов. Следующий этап проектирования программного обеспечения заключается в разработке классов и их интерфейсов с описанием элементов-данных и элементов-функций каждого класса. Для проектирования пользовательских интерфейсов используются сложные интерфейсы: меню с иерархической структурой команд, свободная навигация, не привязанная к уровням иерархии (используется в Windows-приложениях).
Этапы проектирования программного обеспечения при объектно-ориентированном подходе принципиально отличаются от процедурного подхода, так как проектирование программы ведется в терминах (понятиях) прикладной области и отражает ее иерархию.
Реализация – это процесс программирования компонентов программного обеспечения на выбранном языке программирования, их тестирования и отладки.
При процедурном подходе реализация заключается в программировании функций и файлов (модулей) с использованием методов структурного программирования функций и программирования «сверху-вниз» («top-down»).
Этап программирования задачи выполняется в следующей последовательности:
- — программирование функций верхнего уровня схемы;
- — программирование функций нижнего уровня схемы и т.д.
При программировании и отладке функций верхнего уровня функции нижнего уровня, текста которых еще нет, имитируются «заглушками», т.е. выводом сообщений о вызове этих функций.
При объектно-ориентированном подходе этап реализации заключается в программировании элементов-функций целых взаимосвязанных классов, начиная с базовых классов.
Тестирование и отладка являются завершающими этапами процесса реализации программного обеспечения. Тестирование позволяет обнаружить ошибки, а отладка – их исправить.
В соответствии с этапами обработки программы (компиляция, компоновка, выполнение) различают следующие группы ошибок:
- синтаксические ошибки, обнаруживаемые компилятором при синтаксическом и семантическом анализе программы;
- ошибки компоновки, фиксируемые компоновщиком (редактором связей) при объединении модулей программы;
- ошибки выполнения, обнаруживаемые операционной системой или пользователем при выполнении программы.
Из всех групп ошибок самыми сложными для тестирования и отладки являются ошибки выполнения программы, а среди них — логические ошибки, имеющие непредсказуемые причины. Так причинами могут быть ошибки при проектировании программы, разработке алгоритмов, определении структуры данных.
Тестирование – это процесс выполнения программы на тестовых наборах с целью обнаружения ошибок, допущенных при реализации программы. Согласно рекомендациям Microsoft, различают следующие стадии тестирования:
- модульное тестирование, проверяющее небольшие, отдельные части программы – циклы, блоки, подпрограммы;
- компоновочное тестирование, проверяющее следующий уровень – программные файлы (модули), объединение, взаимодействие отдельных частей программы;
- системное тестирование, проверяющее полную версию программы, взаимодействие с операционной системой;
- стресс-тестирование, изучающее работу программы при ограниченных системных ресурсах;
- бета-тестирование, позволяющее узнать мнение специалистов-пользователей;
- тестирование-приемка пользователями в реальных условиях.
Тестовый набор должен содержать для каждого теста: описание тестируемого элемента, цель и инструкция проведения теста, исходные данные и ожидаемые результаты, описание среды тестирования и др.
Отладка – это процесс поиска и исправления ошибок, обнаруженных при тестировании программы. Имеются методы отладки программного обеспечения, основанные на анализе текста программы и результатов тестирования без дополнительной информации. Например, метод индукции включает следующие процессы отладки: выявление симптомов ошибки, изучение фрагмента программы, выдвижение гипотезы об ошибке, проверка гипотезы и при необходимости выдвижение новой гипотезы, нахождение ошибки.
Имеются методы отладки, позволяющие получать дополнительную информацию об ошибке и облегчающие процесс поиска и исправления ошибки. К ним относятся метод отладочного вывода и интегрированные средства отладки. Метод отладочного вывода заключается в добавлении в программу дополнительного отладочного вывода в узловых точках. Но безусловно наиболее эффективными методами являются интегрированные средства отладки, имеющиеся в современных средах программирования (Visual C++, Visual Basic фирмы Microsoft, Delphi, Turbo C++, C++ Builder фирмы Borland). Например, отладчик Visual C++ встроен в среду Visual Studio, имеет свои меню и панели инструментов, позволяют выполнять следующие действия:
- установка различных точек прерывания, связанных с кодом, с данными, с сообщением, условных точек прерывания;
- выполнение программы до точки прерывания;
- просмотр в 6 окнах отладчика информации о текущем состоянии программы при остановке программы в точке прерывания и при пошаговом выполнении;
- пошаговое выполнение программы с заходом в функции и без захода;
- выполнение программы до строки с курсором.
Контрольные вопросы
- Перечислите этапы эволюции программного обеспечения
- Какие языки и методы программирования Вы знаете?
- Охарактеризуйте технологию процедурного программирования.
- Охарактеризуйте технологию объектно – ориентированного программирования.
- Чем достигается высокий уровень создания Windows- приложений на объектно-ориентированном языке Visual C++?
- Что такое компонентные технологии и CASE-технологии
- Что такое жизненный цикл программного обеспечения?
- Объясните эволюцию моделей жизненного цикла программного обеспечения.
- Каковы основные результаты постановки задачи и спецификации программы?
- Каковы основные результаты проектирования и реализации программы?
Тема 2 Базовый язык С++
Будем использовать термин базовый язык (kernel language) для обозначения подмножества С++, которое эквивалентно ANSI C, с не значительными расширениями. Он будет включать в себя не объектно-ориентированные расширения языка.
Источник: studfile.net
ПРОЕКТИРОВАНИЕ ПРОГРАММ
В предыдущем разделе, посвященномязыку Паскаль, приведено немало примеров программ. Однако, при анализе готовой программы чаще всего не ясно, как разработчики к ней пришли. В этом разделе рассказывается об общих моментах в технологии программирования. Конечно, при разработке небольших учебных программ не все элементы этой технологии следует отрабатывать (да это и не всегда возможно по-существу), однако само ее существование должно быть осознано.
Современный подход к проектированию программ основан на декомпозиции задачи, которая в свою очередь основана на использовании абстракций. Целью при декомпозиции является создание модулей, которые представляют собой небольшие, относительно самостоятельные программы, взаимодействующие друг с другом по хорошо определенным и простым правилам. Если эта цель достигнута, то разработка отдельных модулей может осуществляться различными людьми независимо друг от друга, при этом объединенная программа будет функционировать правильно.
Различают абстракцию через параметризацию и через спецификацию. Смысл абстракции через параметризацию в том, что одним алгоритмом можно решать задачи, отличающихся различными исходными данными, задаваемыми как параметры. Смысл абстракции через спецификацию в том, что разными алгоритмами можно получить один и тот же искомый результат. При этом описываются результаты работы программы, смысл обращения к программе становится ясным через анализ ее спецификации, а не самого текста программы.
Разработка любой программы или программной системы начинается с определения требований к ней для конкретного набора пользователей и заканчиваете,» эксплуатацией системы этими пользователями.
Существуют различные подходы и технологии разработки алгоритмов и программ. Хотя программирование в значительной степени искусство, тем не менее. можно систематизировать и обобщить накопленный профессиональный опыт. По современным взглядам проектирование и разработку программ целесообразнс разбить на ряд последовательных этапов:
2) проектирование программы;
3) построение модели;
4) разработка алгоритма;
5) реализация алгоритма;
6) анализ алгоритма и его сложности;
7) тестирование программы;
Кратко остановимся на каждом из этих этапов.
При постановке задачи для крупных компьютерных программ необходимо провести следующие работы:
• выработать требования (свойства, качества и возможности), необходимые для решения проблемы или достижения цели (как правило, эта деятельность носит экспертный характер);
• описание функций системы;
• спецификации входных и выходных данных;
• верификационные требования (установление тестовых случаев);
• тип и количество документов.
В ходе этой работы выявляются свойства, которыми должна обладать система в конечном виде (замысел), описываются функции системы, характеристики интерфейса.
Чтобы приступить к решению задачи необходимо точно ее сформулировать. В первую очередь, это означает определение исходных и выходных данных, т.е. ответы на вопросы: а) что дано; б) что нужно найти. Дальнейшая детализация постановки задачи представляет собой ответы на серию вопросов такого рода:
• как определить решение;
• каких данных не хватает и все ли они нужны;
• какие сделаны допущения и т.п.
Проектирование программы. Сначала производится проектирование архитектуры программной системы. Это предполагает первичную (общую) стадию проектирования и заканчивается декомпозицией спецификаций в структуру системы. Обычно на модульном уровне по каждому модулю разрабатывается спецификация модуля:
• имя/цель — даетсяимя модулю и предложение о функции модуля с формальными параметрами;
• неформальное описание — обзор действий модуля;
• ссылки — какие модули ссылаются на него и на какие модули ссылается данный модуль;
• вход/выход — формальные и фактические параметры, глобальные, локальные и связанные (общие для ряда модулей) переменные;
• примечания — полезные комментарии общего характера по модулю.
Следующим шагом является детальное проектирование. На этом этапе происходит процедурное описание программы, выбор и оценка алгоритма для реализации каждого модуля. Входной информацией для проектирования являются требования и спецификации системы.
Для проектирования программ существуют различные подходы и методы. Современный подход к проектированию основан на декомпозиции, которая, в свою очередь, основана на использовании абстракции. Целью при декомпозиции является создание модулей, которые взаимодействуют друг с другом по определенным и простым правилам. Декомпозиция используется для разбиения программы на компоненты, которые затем могут быть объединены.
Методы проектирования архитектуры делятся на две группы:
1) ориентированные на обработку и
2) ориентированные на данные.
Методы, ориентированные на обработку, включают следующие общие идеи.
а) Модульное программирование. Основные концепции:
• каждый модуль реализует единственную независимую функцию;
• имеет единственную точку входа/выхода;
• размер модуля минимизируется;
• каждый модуль разрабатывается независимо от других модулей;
• система в целом построена из модулей. Исходя из этих принципов каждый модуль тестируется отдельно, затем после кодирования и тестирования происходит их интеграция и тестируется вся система.
б) Функциональная декомпозиция.
Подобна стратегии «разделяй и управляй». Практически является декомпозицией в форме пошаговой детализации и концепции скрытия информации. Каждый модуль характеризуется субъективным решением проектировщика, связь осуществляется с помощью хорошо организованных интерфейсов.
в) Проектирование с использованием потока данных.
Использует поток данных как генеральную линию проектирования программы. Содержит элементы структурного проектирования сверху-вниз с пошаговой детализацией:
• экспертиза потоков данных и отображение графа потока данных;
• анализ входных, центральных и выходных преобразующих поток данных элементов;
• формирование иерархической структуры программы;
• детализация и оптимизация структуры программы.
г) Технология структурного анализа проекта.
Основана на структурном анализе с использованием специальных графических средств построения иерархических функциональных связей между объектами системы. Эффективна на ранних стадиях создания системы, когда диаграммы просты и читаемы.
Методы проектирования, основанные на использовании структур данных, описаны ниже.
а) Методология Джексона.
Здесь структура данных — ключевой элемент в построении проекта. Структура программы определяется структурой данных, подлежащих обработке. Программа представляется как механизм, с помощью которого входные данные преобразуются в выходные. В методе предусматривается:
• разработка и изображение структуры входных и выходных данных;
• изображение структуры программы путем соединения изображений этих структурных элементов:
• определение дискретных операций над структурами данных;
• построение алгоритмов обработки структур данных.
б) Методология Уорнера.
Подобна предыдущей, но процедура проектирования более детализирована. Используются следующие виды представления проекта:
• диаграммы организации данных (описывают входные и выходные данные);
• диаграммы логического следования (логический поток этих данных);
• список инструкций (команды, используемые в проекте);
• псевдокод (описание проекта);
• определение входных данных системы;
• организация входных данных в иерархическую структуру;
• детальное определение формата элементов входного файла;
• то же самое для выходных данных;
•спецификация программы: чтение, ветвление, вычисление, выходы, вызови подпрограмм;
• составление диаграммы (по типу блок-схем) указывающие логическую последовательность инструкций.
в) Метод иерархических диаграмм.
В этом методе определяется связь между входными, выходными данными и процессом обработки с помощью иерархической декомпозиции системы (без детализации). По сути используются три элемента: вход, обработка, выход.
Алгоритм проектирования по этому методу заключается в следующих шагах:
• начать с наивысшего уровня абстракции, определив вход, выход, обработку;
• соединить каждый элемент входа и выхода с соответствующей обработкой;
• документировать каждый элемент системы, используя диаграммы;
• детализировать диаграммы, используя шаги 1 — 3.
г) Объектно-ориентированная методология проектирования.
Основана на концепции упрятывания информации и абстрактных типов данных. Рассматриваются данные, модули и системы в качестве объектов. Каждый объект содержит некоторую структуру данных с набором процедур, знающих как работать с этими данными. По этой методологии создаются абстракции по заданной проблемной области:
· развитие неформальной стратегии, удовлетворяющей требованиям к системе;
· создание объектов и их атрибутов;
· определение операций над объектами;
Построение модели в большинстве случаев является непростой задачей. Чтобы приобрести опыт в моделировании, необходимо изучить как можно больше известных и удачных моделей.
При построении моделей,как правило, используют два принципа: дедуктивный (от общего к частному) и индуктивный (от частного к общему).
Рис. 3.3. Схема построения модели при дедуктивном способе
При дедуктивном подходе (рис.3.3) рассматривается частный случай общеизвестной фундаментальной модели. Здесь при заданных предположениях известная модель приспосабливается к условиям моделируемого объекта. Например, можно построить модель свободно падающего тела на основе известного закона Ньютона та = mg — Fcoпp и в качестве допустимого приближения принять модель равноускоренного движения для малого промежутка времени.
Рис. 3.4. Схема построения модели при индуктивном способе
Индуктивный способ (рис.3.4) предполагает выдвижение гипотез, декомпозицию сложного объекта, анализ, затем синтез. Здесь широко используется подобие, аналогичное моделирование, умозаключение с целью формирования каких-либо закономерностей в виде предположений о поведении системы.
Технология построения модели при индуктивном способе:
1) эмпирический этап
2) постановка задачи длямоделирования;
3) оценки; количественное и качественное описание;
4) построение модели.
Разработка алгоритма — самый сложный и трудоемкий процесс,но и самый интересный в творческом отношении. Выбор метода разработки зависит от постановки задачи, ее модели. (О некоторых приемах и методах разработки алгоритмов говорилось ранее в гл.
1 и будет сказано в следующих разделах данной главы.) На этом этапе необходимо провести анализ правильности алгоритма, что очень непросто и трудоемко. Наиболее распространенная процедура доказательства правильности алгоритма — это прогон его на множестве различных тестов. Однако, это не гарантирует того. что не может существовать случая, в котором программа «не сработает».
В общей методике доказательства правильности алгоритма предполагают, что алгоритм описан в виде последовательности шагов. Для каждого шага предлагается некое обоснование его правильности для всех подходящих входных (условиях до данного шага) и выходных данных (условиях после этого шага). Затем предлагается доказательство конечности алгоритма с окончательными исходными входными и выходными данными.
На этапе реализации алгоритма происходит конструирование и реализация алгоритма, включая:
По сути проводится перевод проекта в форму программы для конкретного компьютера, сборка системы и ее прогон при тестовых и нормальных условиях для подтверждения ее работы в соответствии со спецификациями системы. Этот этап зависит от того, какой язык программирования выбран, на каком компьютере алгоритм будет реализован. С этим связаны выбор типов данных, вводимых структур данных, связь с окружающей средой и т.п. Важно осознавать интерактивность, вид транслятора (компилятор или интерпретатор), наличие библиотек подпрограмм, модулей и объектов.
Анализ алгоритма и его сложности необходим для оценки ресурсов компьютеров, на которых он будет работать, времени обработки конкретных данных, приспособления в работе в локальных сетях и телекоммуникациях. Хотелось бы также иметь для данной задачи количественный критерий для сравнения нескольких алгоритмов с целью выбора более простого и эффективного среди них.
Перед началом эксплуатации программы необходим этап ее отладки и тестирования.
Тестирование — это процесс исполнения программ с целью выявления (обнаружения) ошибок. Тестирование — процесс деструктивный, поэтому считается, чти тест удачный, если обнаружена ошибка. Хорошим считается тест, который имеет большую вероятность обнаружения еще не выявленной ошибки. Удачным считается тест, который обнаруживает еще не выявленную ошибку.
Существуют различные способы тестирования программ.
Тестирование программы как «черного ящика» (стратегия «черного ящика» определяет тестирование с анализом входных данных и результатов работы программы). Критерием исчерпывающего входного тестирования является использование всех возможных наборов входных данных.
Тестирование программы как «белого ящика» заключается в стратегии управления логикой программы, позволяет использовать ее внутреннюю структуру. Критерием выступает исчерпывающее тестирование всех маршрутов и управляющих структур программы.
Разумная и реальная стратегия тестирования — сочетание моделей «черного» и «белого ящиков».
• описание предполагаемых значении выходных данных или результатов должно быть необходимой частью тестового набора;
• тесты для неправильных и непредусмотренных входных данных следует разрабатывать так же тщательно, как для правильных и предусмотренных;
• необходимо проверять не только делает ли программа то, длячего она предназначена, но и не делает ли она то, что не должна делать;
• нельзя планировать тестирование в предположении, что ошибки не будут обнаружены;
• вероятность наличия необнаруженных ошибок в части программы пропорциональна числу ошибок, уже обнаруженных в этой части;
• тестирование — процесс творческий.
При разработке программ очень полезным бывает метод «ручного тестирования» без компьютера на основе инспекции и сквозного просмотра (тестирование «всухую»).
Инспекция и сквозной просмотр — это набор процедур и приемов обнаружения ошибок при чтении текста.
Основные типы ошибок, встречающихся при программировании:
• обращения к переменным, значения которым не присвоены или не инициализированы;
• выход индексов за границы массивов;
• несоответствие типов или атрибутов переменных величин;
• явные или неявные проблемы адресации памяти;
• ошибочные передачи управления;
При проектировании процедуры тестирования предусматривают серии тестов, имеющих наивысшую вероятность обнаружения большинства ошибок. Для целей исчерпывающего тестирования создают эквивалентные разбиения входных параметров. причем предусмативают два класса: правильные входные данные и неправильные (ошибочные входные значения). Для каждого класса эквивалентности строят свой тест. Классом эквивалентности тестов можно назвать такое множество тестов, что выполнение алгоритма на одном из них гарантирует аналогичный результат прогона для других.
Особое внимание необходимо уделять тестам на граничных условиях. Граничные условия — это ситуации, возникающие непосредственно на, выше или ниже границ входных и выходных классов эквивалентности (т.е. вблизи границ эквивалентных разбиений). В частности, примерами классов эквивалентных тестов для алгоритма решения квадратного уравнения могут служить следующие классы: множество действительных, отличных от нуля, чисел а, b, с, таких, что b∙b — 4 ∙ а ∙ с < 0; множество чисел а = 0, b и с не равны нулю; b = 0, а и с не равны нулю, и т.п.
Сам процесс тестирования может быть пошаговым и/или монолитным. В том и в другом случае используют стратегии нисходящего тестирования, — начиная с верхнего, головного модуля, и затем подключая последовательно другие модули (аппарат заглушек), и восходящего тестирования, начиная с тестирования отдельных модулей.
В процессе отладки программы используют метод грубой силы — использование выводов промежуточных данных по всей программе (трассировка) или использование автоматических средств. Например, в Турбо-Паскале имеется в наличии мощный аппарат автоматической отладки программ (режим DEBUG).
Есть золотое правило программистов — оформляй свои программы в том виде, в каком бы ты хотел видеть программы, написанные другими. К каждому конечному программному продукту необходимо документированное сопровождение в виде помощи (help), файлового текста (readme.txt).
Контрольные вопросы и задания
1. Каковы основные этапы проектирования и разработки программы?
2. Что означает хорошо сформулированная постановка задачи?
3. Назовите методологии проектирования и разработки программ.
4. Как выбрать модель задачи?
5. Что такое тестирование программы?
6. Постройте группу тестов для алгоритма решения системы линейных уравнений.
Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:
Источник: studopedia.ru