Стратегия и модели конструирования по. Начальные этапы конструирования по.

Стратегия и модели конструирования ПО

Стратегия конструирования ПО – определяет общий характер конструирования ПО.

Три основные стратегии конструирования:

1. Каскадная – линейная последовательность этапов конструирования.

2. Инкрементная стратегия – итерационное повторение проходов, с целью наращивания функциональности ПО.

3. Эволюционное стратегия – это инкрементная стратегия с постепенным уточнениям требований.

Каскадная стратегия

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

Схема каскадной разработки ПО:

 

Преимущества:

1. После каждого этапа формируется законченный набор полной и согласованной документации.

2. Удобства планирования сроков и затрат

Недостатки:

1. Запаздывание с получением результатов.

2. Согласование результатов с пользователями возможно только после завершения какого-либо этапа работы.

3. Сложности с внесением изменений, при изменении требований.

Эволюционная стратегия

Эволюционная стратегия заключается в повторении процесса разработки ПО выпуском новой версии. К существующим этапам жизненного цикла разработки ПО добавляются этапы:

1. Планирования цикла

2. Анализ рисков.

Схема:

…

…

Преимущества:

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

2. Пользователи очень быстро могут увидеть работоспособную версию продукта.

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

Недостатки:

1. Более сложный механизм управления и документирования процессом разработки.

2. Структура разрабатываемого программного обеспечения не всегда несет целостную идею.

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

В инкрементной стратегии не происходит переопределение требований.

 

24.09.2012.

Модель формальной разработки систем

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

Формальная спецификация записывается с помощью специальной математической нотации (последовательные действия):

1. Определение требований

2. Формальная спецификация

3. Формальное преобразование

4. Сбор и тестирование системы

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

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

Недостатки:

1. Большинство систем трудно поддаются описаниям методам формальных спецификаций.

2. Большой объем сопроводительной документации.

Модель разработки ПО на основе ранее созданных компонентов

Этот подход предполагает повторное использование ранее созданных программных модулей.

1. Спецификация требований.

2. Анализ компонентов

3. Модификация требований (после возвращаемся в 1 нужное количество раз).

4. Проектирование системы

5. Реализация

6. Сборка

7. Тестирование системы.

Преимущества:

1. Сокращение стоимости и времени разработки программного продукта.

Недостатки:

1. Отход от требований заказчика.

2. Проблемы, связанные с модернизацией программного обеспечения.

Начальные этапы конструирования.

Разработка включает в себя:

1. Подготовительная работа.

2. Анализ требований к системе

3. Проектирование архитектуры системы.

4. Детальное проектирование.

5. Реализация.

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

Подготовительная работа

Подготовительная работа предполагает:

1. Написание экономического образования (бизнес план) проекта.

2. Определение границ проекта

3. Некоторый начальный анализ, для оценки его размера.

На этой фазе заказчик принимает на себя некоторые обязательства относительно дальнейшей работы.

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

Под собой подразумевает:

1. Определение ее функциональных возможностей.

2. Пользовательских требований.

3. Требований к надежности.

4. Требования к безопасности.

5. Требования к расширяемости.

6. Требования к масштабируемости.

7. И другим потребительским характеристикам.

 

Базис языка UML

В состав выразительных средств языка UML входят три разновидности строительных блоков:

1. Предметы – это абстракции, которые являются основными элементами в моделях.

2. Отношения – связывают предмет.

3. Диаграммы – группируют коллекции предметов.

Замечание:

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

Предметы

Есть 4 разновидности предметов:

1. Структурные предметы.

2. Предметы поведения.

3. Группирующие предметы.

4. Поясняющие предметы.

Структурные предметы

Структурные предметы являются существительными в UML моделях. Они представляют статические части моделей. К ним относятся:

1. Класс – описание множества объектов, которые разделяют одинаковые свойства, операции, отношения и семантика (смысл).

2. Интерфейс – набор операций, которые определяют услуги класса или компонента. Описывает поведение элемента видимое извне.

3. Кооперация (сотрудничество) – определяет взаимодействие объектов и является совокупностью их ролей и других элементов, совместно обеспечивающих коллективное поведение.

4. Актер – набор согласованных ролей, в которые могут играть пользователи, при взаимодействии с системой. Каждая роль требует от системы определенного поведения.

5. Вариант использований (прецедент – элемент «use case») – описание последовательности действий, выполняемых системой в интересах отдельного актера и производящий видимый для актера результат.

6. Активный класс – это класс, чьи объекты имеют один или несколько процессов и поэтому могут инициировать управляющую деятельность. Активный класс похож на обычный класс, но его объекты действуют одновременно с объектами других классов.

7. Компонент – это физическая и заменяемая часть системы, которая соответствует набору интерфейсов и обеспечивает реализацию этого набора интерфейсов (обычно это физическая упаковка различных логических компонентов). Компонентами выступают не только написанные, но и используемые извне.

8. Узел – это физический элемент, который существует в период работы системы и представляет ресурс (устройство).

Предметы поведения.

Предметы поведения – это динамические части UML моделей. Они являются глаголами моделей, представлением поведения во времени и пространстве. Разновидности:

1. Взаимодействие – поведение, заключающее в себе набор сообщений, которыми обменивается набор объектов в конкретном контексте для достижения определенной цели. Элементами взаимосвязи являются сообщения, последовательность действий и связи.

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

Группирующие предметы.

Группирующие предметы – организационные части UML моделей, по которым может быть «разложена» модель.

Пакет – это общий механизм для распределения элементов по группам. Он существует только в период разработки.

Поясняющие предметы.

Поясняющие предметы – разъясняющие части UML моделей, являются замечаниями, которые можно применить для описания объяснения и комментирования любого элемента модели.

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

 

 

Практика