Подходы к разработке программных средств Языки программирования

Зарегистрируйтесь, чтобы просмотреть полный документ!

Подходы к разработке программных средств

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

Ассемблер Были разработаны программы, названные ассемблерами и предназначенные для перевода записанных в мнемоническом виде программ на машинный язык. Название "ассемблер" [assembler - сборщик] эти программы получили потому, что их назначение заключалось в сборке машинных команд из кодов команд и операндов, полученных в результате перевода мнемонических обозначений и идентификаторов. Мнемонические системы записи программ стали, в свою очередь, рассматриваться как особые языки программирования, именуемые языками ассемблера. 3

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

Языки программирования третьего поколения Отличались от предыдущих поколений тем, что их языковые конструкции имели более высокий уровень и были машинно-независимыми. Наиболее известными примерами ранних языков третьего поколения являются FORTRAN [FORmula TRANslator переводчик формул], который был предназначен для научных и инженерных расчетов, и COBOL [COmmon Business-Oriented Language - язык общего назначения деловой ориентации], разработанный специалистами военно-морского флота США для решения экономических задач. 5

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

Компилятор Программы-переводчики часто называют компиляторами. Разработку первого компилятора приписывают Грейс Хоппер [Grace Hopper], которая играла ведущую роль в продвижении концепции языков программирования высокого уровня. 7

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

Парадигмы программирования Развитие языков программирования происходило по разным направлениям, связанным с альтернативными подходами к процессу программирования, называемыми парадигмами программирования. • • Императивная; Декларативная; Функциональная; Объектно-ориентированная парадигмы. 9

Императивная, или процедурная парадигма, представляет традиционный подход к процессу программирования. Действительно, именно в соответствии с этой парадигмой построен цикл обработки команды центрального процессора: "извлечь-декодироватьвыполнить". 10

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

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

Функциональная Например, функцию вычисления среднеарифметического нескольких чисел можно построить из трех более простых функций. Первая из них Sum - получает на вход список чисел и вычисляет их сумму; вторая Count - получает список чисел и подсчитывает их количество; третья Divide - получает на вход два числа и вычисляет их частное. 13

Объектно-ориентированная парадигма Предполагает применение методов объектноориентированного программирования [ООП], - это еще один подход к процессу разработки программного обеспечения. В рамках этого подхода элемент данных рассматривается как активный "объект", а не как пассивный элемент, как это принято в традиционной императивной парадигме. 14

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

Общие принципы и подходы к разработке ПО

Модели разработки ПО Водопадная Каскадная модель Спиральная Экстремальное программирование UI Prototyping Инкрементальная W-Model Testing Унифицированный процесс разработки программного обеспечения (USDP) Методология MSF 17

Водопадная модель Анализ требований Составляется спецификация продукта Проектирование Составляется архитектура продукта Реализация Разработка исходного кода Интеграция отдельных частей исходного кода Тестирование 18 Тестирование и устранение дефектов

Каскадная модель 19

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

Экстремальное программирование Анализ исходных требований Проектирование Интеграция Реализация Тестирование Новые требования Выпуск продукта Анализ/Утвержден ие/модификация плана разработки 21

UI Prototyping Выпуск продукта Разработка ПО с учетом изменений Уточнение требований и спецификации Изменение прототипа и доработка некоторой функциональности Базовая функциональность Прототип интерфейса Предварительная спецификация 22

Инкрементальная разработка Итерация 1 Итерация 2 …. Итерация N Анализ требований Проектирование Реализация Компонентное тестирование Интеграция Тестирование единого целого 23

Унифицированный процесс разработки программного обеспечения (USDP) Ø Модель вариантов использования, описывает случаи, в которых приложение будет использоваться. Ø Аналитическая модель описывает базовые классы для приложения. Ø Модель проектирования описывает связи и отношения между классами и выделенными объектами Ø Модель развертывания описывает распределение программного обеспечения по компьютерам. Ø Модель реализации описывает внутреннюю организацию программного кода. Ø Модель тестирования состоит из тестирующих компонентов, тестовых процедур и различных вариантов тестирования 24

Унифицированный процесс разработки программного обеспечения (USDP) Сбор требований Итер 1…. Итер N Проектирование Итер 1…. Итер N Реализация Конструирование Итер 1…. Итер N Тестирование Итер 1…. Итер N 25

W-Model Testing 26

Методология MSF Модель процесса MSF Каскадная модель Спиральная модель 27

Типичные компоненты архитектуры программного продукта и типичные требования к ПО Ø Ø Ø Ø Организация программы Основные классы системы Организация данных Бизнес–правила Пользовательский интерфейс Управление ресурсами Безопасность Производительность Масштабируемость Взаимодействие с другими системами (интеграция) Интернационализация, локализация Ввод-вывод данных Обработка ошибок 28

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

Типичные компоненты архитектуры программного продукта и типичные требования к ПО Ø Ø Возможности реализации разрабатываемой архитектуры. Избыточная функциональность. Принятие решение о приобретении готовых компонент ПО. Стратегия изменений. 30

Контрольный список вопросов, который позволяет сделать вывод о качестве архитектуры: Ø Ясно ли описана общая организация программы; включает ли спецификация обзор архитектуры и ее обоснование. Ø Адекватно ли определены основные компоненты программы, их области ответственности и взаимодействие с другими компонентами. Ø Все ли функции, указанные в спецификации требований, реализованы разумным количеством компонентов системы. Ø Приведено ли описание самых важных классов и их обоснование. Ø Приведено ли описание организации БД. Ø Определены ли все бизнес правила. Ø Описано ли их влияние на систему. 31

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

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

Скачать презентацию Подходы к разработке программных средств Языки программирования

Подходы к разработке программных средств.ppt

Количество слайдов: 33