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

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

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

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

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

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

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

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

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

Типичные компоненты архитектуры программного продукта и типичные требования к ПО Кривая надежности N t 1 t Чем дальше, тем тяжелее будет найти ошибку. Чем сложнее система, тем больше вероятность отказов и сбоев.

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

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

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

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

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

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

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

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

1. Каскадная (англ. waterfall) - стандартная модель разработки

Каскадная модель разработки - модель, при которой все этапы разработки ведутся последовательно - последующий этап начинается после полного завершения предыдущего.

Такая модель включает следующие этапы процесса разработки ПО:

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

После полного завершения проектирования программистами выполняется реализация (конструирование) проекта. На стадии воплощения происходит интеграция всех компонентов проекта. Только после полного завершения этих стадий производится тестирование и отладка готового продукта. Далее программный продукт можно внедрять и после внедрения осуществлять поддержку - вносить новый функционал и устранять ошибки.

Основные плюсы каскадной разработки:

2. Гибкая методология разработки программного обеспечения (Agile software development)

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

Результатом каждого такого этапа, включающего цикл итерраций, является некий миниатюрный программный проект,

Методов гибкой разработки несколько, из наиболее известных - Scrum, экстремальное программирование, DSDM.

Основные плюсы гибкой разработки:

Принципы гибкой разработки:

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

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

Базовыми принципами структурного подхода являются:

o принцип "разделяй и властвуй";

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

Основными из этих принципов являются:

o абстрагирование - выделение существенных аспектов системы;

o непротиворечивости - обоснованность и согласованность элементов системы;

o структурирование данных - данные должны быть структуро-ване и иерархически организованы.

Методические основы технологий создания программного обеспечения

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

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

o трудностей проектируемой системы;

o необходимой полноты ее описания;

o знаний и навыков участников проекта;

o времени, отведенного на проектирование.

Визуальное моделирование очень повлияло на развитие CASE-средств в частности. Понятие CASE (Computer Aided Software Engineering) используется в широком смысле. Первоначальное значение этого понятия, ограничено только задачами автоматизации разработки ПО, в настоящее время приобрело новый смысл, охватывающий большинство процессов жизненного цикла ПО.

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

Информатика, кибернетика и программирование

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

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

Модели разработки ПО

1. Водопадная
2. Каскадная модель
3. Спиральная
4. Экстремальное программирование
5. Инкрементальная
6. Методология MSF

Водопадная модель

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

Инкрементальная разработка

Анализ требований

Проектирование

Реализация

Компонентное

тестирование

Интеграция

Тестирование

единого целого

Итерация 1 Итерация 2 …. Итерация N

Унифицированный процесс разработки программного обеспечения (USDP)

1. Модель вариантов использования, описывает случаи, в которых приложение будет использоваться.
2. Аналитическая модель описывает базовые классы для приложения.
3. Модель проектирования описывает связи и отношения между классами и выделенными объектами
4. Модель развертывания описывает распределение программного обеспечения по компьютерам.
5. Модель реализации описывает внутреннюю организацию программного кода.
6. Модель тестирования состоит из тестирующих компонентов, тестовых процедур и различных вариантов тестирования

Методология MSF

Типичные компоненты архитектуры программного продукта и типичные требования к ПО

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

Надежность – способность системы противостоять различным отказам и сбоям.

Отказ – это переход системы в результате ошибки в полностью неработоспособное состояние.

Сбой – ошибка в работе системы, которая не приводит к выходу системы из строя.

Чем меньше отказов и сбоев за какой-то определенный интервал времени, тем система считается надежнее.