- •Введение
- •Содержание
- •1.1 Анализ и характеристика областей знаний swebok
- •1.1.1. Требования к по (Software Requirements)
- •1.1.2. Проектирование по (Software design)
- •1.1.3. Конструирование по (Software Construction)
- •1.1.4. Тестирование по (Software Testing)
- •1.1.5. Сопровождение по (Software maintenance)
- •1.1.6. Управление конфигурацией по
- •1.1.7. Управление инженерией по
- •1.1.8. Процесс инженерии по (Software Engineering Process)
- •1.1.9. Методы и инструменты инженерии по
- •1.1.10. Качество по (Software Quality)
- •1.2. Жизненный цикл пс, связь с ядром знаний swebok
- •Контрольные вопросы и задания
- •Лекция 2: Модели жизненного цикла для разработки программных систем Содержание
- •2.1. Процессы жц стандарта iso/iec 12207
- •2.2. Типы моделей жц
- •2.2.1. Каскадная модель жц
- •2.2.2. Инкрементная модель жц
- •2.2.3. Спиральная модель
- •2.2.5. Стандартизация модели жц
- •2.3. Сопоставление жц стандарта iso/iec 12207 и областей swebok
- •2.3.1. Характеристика процессов стандарта iso/iec 12207
- •2.3.2. Характеристика областей знаний swebok
- •Контрольные вопросы и задания
- •Лекция 3: Методы определения требований в программной инженерии Содержание
- •3.1. Общие подходы к определению требований
- •3.1.1. Классификация требований
- •3.1.2. Анализ и сбор требований
- •3.1.3. Инженерия требований
- •3.1.4. Фиксация требований
- •3.1.5. Трассировка требований
- •Сложность программного обеспечения
- •1.8.1. Каскадная (водопадная) модель
- •1.8.2. Итеративная и инкрементальная модель
- •1.8.3. Спиральная модель Боэма
- •1.9.1. Методология Rational Unified Process (rup)
- •2. Проектирование (Elaboration)
- •3. Построение (Construction)
- •4. Внедрение (Transition)
- •1.9.2. Экстремальное программирование
- •Живое планирование (planning game)
- •Программирование парами (pair programming)
- •Включение заказчика в команду (on-site customer)
- •Использование кода как средства коммуникации
- •Открытое рабочее пространство (open workspace)
- •Изменение правил по необходимости (just rules)
1.1.2. Проектирование по (Software design)
Проектирование ПО - это процесс определения архитектуры, компонентов, интерфейсов, других характеристик системы и конечного состава программного продукта. Область знаний "Проектирование ПО (Software Design)" состоит из следующих разделов:
базовые концепции проектирования ПО (Software Design Basic Concepts),
ключевые вопросы проектирования ПО (Key Issue in Software Design),
структура и архитектура ПО (Software Structure and Architecture),
анализ и оценка качества проектирования ПО (Software Design Quality Analysis and Evaluation),
нотации проектирования ПО (Software Design Notations),
стратегия и методы проектирования ПО (Software Design Strategies and Methods).
Базовая концепция проектирования ПО - это методология проектирования архитектуры с помощью разных методов (объектного, компонентного и др.), процессы ЖЦ (стандарт ISO/IEC 12207) и техники - декомпозиция, абстракция, инкапсуляция и др. На начальных стадиях проектирования предметная область декомпозируется на отдельные объекты (при объектно-ориентированном проектировании) или на компоненты (при компонентном проектировании). Для представления архитектуры программного обеспечения выбираются соответствующие артефакты (нотации, диаграммы, блок-схемы и методы).
К ключевым вопросам проектирования ПО относятся: декомпозиция программ на функциональные компоненты для независимого и параллельного их выполнения, принципы распределения компонентов в среде выполнения и их взаимодействия между собой, механизмы обеспечения качества и живучести системы и др.
При проектировании архитектуры ПО используется архитектурный стиль проектирования, основанный на определении основных элементов структуры - подсистем, компонентов и связей между ними.
Архитектура проекта - высокоуровневое представление структуры системы и спецификация ее компонентов. Архитектура определяет логику отдельных компонентов системы настолько детально, насколько это необходимо для написания кода, а также определяет связи между компонентами. Существуют и другие виды представления структур, основанные на проектировании образцов, шаблонов, семейств программ и каркасов программных сред.
Одним из важнейших инструментов проектирования архитектуры является паттерн - типовой конструктивный элемент ПО, который задает взаимодействие объектов (компонентов) проектируемой системы, а также роли и ответственности исполнителей. Основным языком описания этого элемента является UML. Он может быть структурным, включающим типовые композиции структур из объектов и классов, объектов, связей и др.; поведенческим, определяющим схемы взаимодействия классов объектов и их поведение диаграммами активностей, взаимодействия, потоков управления и др.; порождающим, отображающим типовые схемы распределения ролей экземпляров объектов и способы динамической генерации структур объектов и классов.
Анализ и оценка качества проектирования ПО включает мероприятия по анализу сформулированных в требованиях атрибутов качества, оценки различных аспектов ПО - количества функций, структура ПО, качества проектирования с помощью формальных метрик (функционально-ориентированных, структурных и объектно-ориентированных), а также проведения качественного анализа результатов проектирования путем статического анализа, моделирования и прототипирования.
Нотации проектирования позволяют представить описание объекта (элемента) ПО и его структуру, а также поведение системы. Существует два типа нотаций: структурные, поведенческие и множество различных их представлений.
Структурные нотации - это структурное, блок-схемное или текстовое представление аспектов проектирования структуры ПО из объектов, компонентов, их интерфейсов и взаимосвязей. К нотациям относятся формальные языки спецификаций и проектирования: ADL (Architecture Description Language), UML (Unified Modeling Language), ERD (Entity-Relation Diagrams), IDL (Interface Description Language), Use Case Driven и др. Нотации включают языки описания архитектуры и интерфейса, диаграммы классов и объектов, диаграммы сущность-связь, конфигурации компонентов, схем развертывания, а также структурные диаграммы, задающие в наглядном виде операторы цикла, ветвления, выбора и последовательности.
Поведенческие нотации отражают динамический аспект поведения систем и их компонентов. Таким нотациям соответствуют диаграммы потоков данных (Data Flow), таблиц принятия решений (Decision Tables), деятельности (Activity), кооперации (Colloboration), последовательности (Sequence), пред- и постусловия (Pre-Post Conditions), формальные языки спецификации (Z, VDM, RAISE), языки проектирования PDL и др.
Стратегия и методы проектирования ПО.К стратегиям относятся: проектирование снизу-вверх, сверху-вниз, абстрагирование, использование паттернов и др. Методы - это функционально-ориентированные, структурные, которые базируются на структурном анализе, структурных картах, диаграммах потоков данных (Dataflow) и др. Они ориентированы на идентификацию функций и их уточнение сверху-вниз, после чего уточняются диаграммы потоков данных и проводится описание процессов.
В объектно-ориентированном проектировании ключевую роль играет наследование, полиморфизм и инкапсуляция, а также абстрактные структуры данных и отображение объектов. Подходы, ориентированные на структуры данных, базируются на методе Джексона [1.8] и используются для задания входных и выходных данных структурными диаграммами. Метод UML предназначен для сценарного моделирования проекта [1.19] в наглядном диаграммном виде. Компонентное проектирование ориентировано на использование готовых компонентов (reusing), их интерфейсов и интеграцию для формирования конфигурации, служащей основой развертывания компонентного ПО и взаимодействия компонентов в операционной среде.
Формальные методы описания программ основываются на спецификациях, аксиомах, описаниях некоторых условий, называемых предварительными (предусловиями), утверждениях и постусловиях, определяющих заключительное условие получения правильного результата программой. Спецификация является формальным описанием функций и данных программы, с которыми эти функции оперируют. Различают входные и выходные параметры функции, а также данные, которые не привязаны к реализации и определяют интерфейс с другими функциями. По формальным спецификациям, условиям и утверждениям выполняется доказательство правильности программы
