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




Скачать 151.8 Kb.
НазваниеПрограмма запись алгоритма задачи на формальном языке, исключающая неоднозначность интерпретации. Программная система
Дата публикации24.03.2013
Размер151.8 Kb.
ТипПрограмма
odtdocs.ru > История > Программа
1. Введение. Основные понятия, классификации.
Основные определения, технология и методология программирования. Программная инженерия.
Программа – запись алгоритма задачи на формальном языке, исключающая неоднозначность интерпретации.
Программная система – совокупность логически связанных друг с другом программ, предназначенных для решения группы задач.
Программный продукт – программа или программная система, записанная на носителе данных, снабжённая программной документацией. Различают коробочные и заказные.
^ Программное обеспечение – программный продукт, рассматриваемый как составная часть автоматической информационной системы.
Технология программирования (англ. Programming technology) – совокупность производственных процессов, приводящих к созданию и развитию программного продукта и охватывающее все процессы его цикла.
^ Жизненный цикл (англ. Software life cycle) – весь цикл: от разработки до эксплуатации, начиная от выработки требований, завершая прекращением его (ПО) использования.
^ Этапы развития технологии программирования (принципы и методы):
Основной принцип:


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

  • Необходимость документирования

  • Два измерения


Методы:
Основными методами разработки программного продукта является модульное, структурное и объектно-ориентированное программирование. Разработка программного продукта имеет вертикальные и горизонтальные измерения.


  • Вертикальные: процессы, этапы (статистическое измерение)

  • Горизонтальные: стадии разработки (динамическое измерение)


^ Процесс – совокупность взаимосвязанных действий, преобразующих входные данные в выходные.
Стадия – часть процесса разработки программного обеспечения, включающая в себя не менее одного процесса, и ограниченная временными рамками. Её результатом является конкретный продукт, определяемый заданными для этой стадии требованиями. Стадии обычно делятся на этапы, имеющие итерационный характер. Они могут объединяться в более крупные временные отрезки – фазы.
Технологический подход определяется конкретным сочетанием стадий и процессов разработки, ориентированных на разные классы ПО и особенности коллектива разработчиков. Например, Windows Forms – технология разработки.
В традиционном варианте разработка представляет замкнутый процесс выполняемый собственными специалистами с использованием программных инструментальных средств, повышающих продуктивность разработчика.


Разработка современного сложного программного обеспечения требует участия нескольких разработчиков, в том числе географически удалённых друг от друга. Для современной технологии программирования характерно использование инструментальных средств (CASE-средств – Computer Aided Software Engineering), предназначенных для поддержки жизненного цикла. Например, Shellware – полочное программное обеспечение.
^ Методология программирования – (англ. Methodology programming) совокупность методов и средств, применяемых на различны стадия программного продукта и объединённые общим подходом. Технология программирования рассматривается с точки зрения организации технологических процессов.
Методология – основы построения (методы), определяющие какие инструментальные средства и языки программирования будут использоваться при разработке программных продуктов. Например, для функционального программирования, LISP.
^ Программная инженерия – (англ. Software Engineering) системный подход к разработке, эксплуатации, сопровождения и вывода из обращения. Программная инженерия занимается разработкой способов и приёмов инструментальных средств с точки зрения достижения определённых целей: критерии, срок, заявленные требования и.т.д.

^ Классификация технологий программирования


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

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

  • Классические технологии программирования. Применяются для средних и крупномасштабных проектов с фиксированным объёмом работ.

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


^ Классические технологии программирования
А) Каскадный технологический подход

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



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


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





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

  • нехватка специалистов

  • нарушение сроков и бюджет разработки

  • создание ПО с нессответствующей функциональностью

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

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



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






Каждый виток спирали соответствует созданию фрагмента или версии программного продукта. На нём уточняются цели и характеристики проекта, определяется его качество, планируется работа на следующем витке спирали. Анализ риска – «следует ли выполнять следующий процесс». Если риски слишком велики, то цикл прекращается. Использование спиральной модели позволяет осуществлять переход на следующую стадию выполнения проекта не дожидаясь полного завершения текущей. Основная задача: быстро создать продукт, который можно показать заказчику или пользователю. Таким образом упрощается процесс внесения изменений (дополнений) в проект.

Б) Каскадный технологический подход
Рациональный унифицированный процесс


  • IBM (Rational Software)

  • Rational Unified Process (RUP)

  • Computer Associates

  • Erwin Data Modeler, Process Modeler



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

  • итерационный подход

  • использование моделей вместо бумажных документов. (UML – Unified Modeller Language)

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

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

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


^ Разработка проекта при РУП предполагает прохождение четырёх фаз:


  1. Начало (inseption)

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

  2. Исследование (elaboration)

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

  3. ^ Построение (construction)

    Создание программного продукта.

  4. Внедрение (transition)

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



Каждая из фаз может делиться на итерации. На каждой итерации свои процессы. Характерны разные виды работ Требования можно просмотреть в таблице. Прохождение каждых фаз разработки называется циклом разработки. Первое прохождение – начальный цикл. Если после начального цикла проект не завершается, то программный продукт дорабатывается в ходе последующих циклов, которые называются эволюционными.
В) Генетические технологические подходы
^ Синтезирующее программирование

Предполагает синтез программы по её спецификации.

  1. Ручное (написание программного кода на языке программирования)

  2. Автоматическое (генерация программы на основе спецификации, составленной на формальном языке). Например, UML, IBM Rational Rose, IBM Rational XDE


Сборочное программирование

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




  1. Модульное

    Основано на методологиях модульного императивного программирования.

  2. Объектно-ориентированное сборочное программирование

    Основано на методологии объектно-ориентированного программирования, предполагает распределение библиотек классов в виде исходных текстов, либо в бинарном (DLL – Dynamic Link Library)

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

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

  4. ^ Аспектно-ориентированное программирование

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







^ Конкретизирующее программирование

Конкретизирующее программирование основано на системном использовании при построении программы созданных ранее параметрических заготовок и рациональных проектных решений с использованием паттернов. Наиболее известной разновидностью является подход с использованием паттернов программирования.
Паттерн-проектирование – (англ. Design Pattern) формальное оаписание задач проектирования, успешное решение данной задачи, рекомендации по применению различных решений. Например, паттерн «введение объекта параметров», который облегчает повторное использование проектных и архитектурных решений. Конкретной программой может трактоваться как адаптация некой универсальной программы к конкретному слою применения.
^ Г) Технологии на основе формальных преобразований
Технология стерильного цеха (cleanroom process model) предназначен для надёжного создания приложений, не содержащих ошибок, их недопущение. Технология основана на модульном принципе организации разработки.


Модули:

  1. Чёрный ящик (black box)

  2. Модуль описатель (state box)

  3. Прозрачный ящик (white box, clear box)


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

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

  • логический (дедуктивный)

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

  • аналитический

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


^ Формальное сборочное программирование

Это объединение ранее созданных фрагментов спецификации.
Г) Гибкие технологии программирования
Ранние технологические подходы быстрой разработки

Все эти подходы объединяют итеративный характер разработки (прототипы) и тесно взаимодействуют с заказчиком.
^ Эволюционное прототипирование (Evolution prototyping)

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






^ Итеративная разработка (Iterative development)

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

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

Возникли как поддерживающие изменения.
Экстремальное программирование

Не придерживается традиционных подходов, в особенности к отношению к каскадным. Вместо одномоментного планирования и проектирования, эти операции выполняются постепенно в ходе разработки, что позволяет максимально сократить стоимость изменений в проекте. (см. модульное тестирование, парное программирование, рефакторинг, режим труда и отдыха).
Цикл разработки. Разработка проекта начинается с того, что заказчик предлагает разработчикам часть функциональности (истории пользователя, user story). «История» представляет собой описание некоторых подзадач с точки зрения заказчика, которые описываются на естественном языке. После выполнения задания получаем ещё один кусок функциональности. Для каждой истории оцениваются ресурсы для реализации и необходимое время. Это позволяет точно выдерживать срок разработки.



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

  • программисты сами составляют тесты

  • это делается до начала разработки


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


  • Доверие

  • Коллективное владение кодом. Любой программист может в любой момент изменить код.

  • Парное программирование (pair programming). В случае возникновения вопросов, проводится короткое собрание.





Адаптивная разработка (Adaptive software development)
Фазы:

  • планирование

  • общение

  • обучение

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

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

  2. Отсутствует возможность заранее спланировать необходимые ресурсы.

  3. Процесс разработки максимально ориентирован на особенности личности разработчика.


Компьютерный дарвинизм

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

Добавить документ в свой блог или на сайт

Похожие:

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

Решение задачи анализа входного файла на языке spice описано в разделе 4 «Анализ входного файла»
Основная задача, решаемая в настоящей работе — это построение иерархии схемотехнических элементов и ее визуализация на основе данных,...

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

Тема урока: Исполнители и алгоритмы
Сформировать понятие алгоритма, познакомить с исполнителями алгоритмов, научить построению алгоритма

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

Оценка времени работы эволюционного алгоритма rmhc под управлением...
Буздалов М. В., ассистент кафедры компьютерных технологий ниу итмо

Оценка времени работы эволюционного алгоритма rmhc под управлением...
Буздалов М. В., ассистент кафедры компьютерных технологий ниу итмо

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

Название доклада на иностранном языке
Система гарантированного электроснабжения предприятий с непрерывным технологическим циклом. На примере ОАО «Севкабель»

Студенты факультета иностранных языков участники всероссийской школы-семинара...
Студенты факультета иностранных языков – участники всероссийской школы-семинара «современные направления анализа и интерпретации...

Вы можете разместить ссылку на наш сайт:
Школьные материалы


При копировании материала укажите ссылку © 2013
контакты
odtdocs.ru
Главная страница