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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

26 W-Model Testing

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

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

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

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

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

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

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