Software Engineering IОбъектно-ориентированный анализ и проектирование

Раздел 1. Введение

(Advanced Introduction)

Пышкин Е.В.

Санкт-Петербургский политехнический университет

План курса

• Введение

▫ Дуализм ПО: инженерия и искусство

▫ Сложность, присущая программному

обеспечению

▫ Обеспечение качества в процессе разработки

▫ Модели жизненного цикла ПО

▫ Что такое ООАиП

▫ Объектная модель: основополагающие

концепции

План курса

• Концептуальное основание ООП

▫ Инструмент для рассмотрения: UML

Развитие и использование UML

Структура UML

▫ Моделирование пользовательских аспектов:

варианты использования (прецеденты)

▫ Моделирование предметной области

Классы и отношения

Диаграммы классов UML

Другие диаграммы UML

План курса

• Шаблоны проектирования (GoF и другие)

▫ Что такое «шаблон проектирования» (design

pattern). Оправданность применения

▫ Механизмы повторного использования

▫ Описание паттернов

Порождающие паттерны

Структурные паттерны

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

Другие паттерны

План курса

• Тестирование программного обеспечения

▫ Основные виды тестирования

▫ Особенности организации тестирования

объектно-ориентированных приложений

▫ Модульное тестирование

Основные концепции

Разработка, управляемая тестированием

Связь с процессом разработки

Инструменты тестирования

План курса

• Специальные лекции▫ Современные тенденции развития языков

программирования. Объектно-ориентированная парадигма, особенности ее реализации в С++

▫ Введение в Scientific Writing

▫ Конференция «Разработка ПО 2015»: обзор

▫ Введение в программную инженерию

▫ Проектирование на базе интерфейсов: практический подход

▫ Основы тестирования и быстрой разработки программного обеспечения

Ресурсы и организация курса

• Программа на сайте курса

• Рекомендуемые источники

• Две траектории практикума

▫ Проект + статья (4-5)

▫ Статья (3-4)

Введение

• Дуализм природы программного обеспечения

• Сложность, присущая программному

обеспечению

• Две основные фазы программирования

▫ Понять, что требуется

▫ Выразить в терминах имеющихся средств

проектирования

Software: Part Art, Part Engineering

“A programmer is rather not a

mathematician but a

philosopher and a linguist all

in one: ability to program is

not simply a kind of creative

ability but the best one”

(Richie O’Bower, 1977)

“Software development is a

kind of human activity which

is mistakenly attributed to

engineering”

(Sergey Arkhipenkov, 2012)

Image from eDX “Computing: Art, Magic, Science”Learn the principles and techniques behind modern Information Technology

Software Complexity

• Proving program correctness may be difficult, long or impossible

Logical complexity

• Details = Complexity• Complexity of interface

Structural complexity

• Associative human memory

Psychological complexity

Shneiderman

Software Complexity

Why is SOFTWARE complex?

• Software projects are not material

▫ Team leader can’t touch the project result

▫ You can hardly see the progress

• How to choose the “right” design process

▫ Difficult to recognize possible bottlenecks

• Most big projects are unique

▫ Technologies change

▫ Difficult planning

▫ Experience appears in process

Why is software COMPLEX?

• Real subject domain complexity

▫ Users and developers

▫ Requirements that change

▫ Implicit limitations

• How to evaluate quality?

• Very creative process with a lot

of different types of activity

▫ Human factors

▫ Even if we use CASE tools

• Interface vs implementation

▫ Easy to use ≠ easy to

implement

13

Software Complexity

▫ Efficiency▫ Reliability

▫ Portability

▫ Maintainability▫ Project time▫ Cost

A lot of mutually exclusive properties

• The cheapest, fastest, and most reliable components are those that aren’t there (Gordon Bell)

Cheap, fast, and reliable. Choose any two

Nice Quotes on Complexity

• The computing scientist’s main challenge is not to get confused by the complexities of his own making

(Edsger W. Dijkstra)

• Controlling complexity is the essence of computer programming

(Brian Kernighan)

• So much complexity in software comes from trying to make one thing do two things

(Ryan Singer)

• Давайте посмотрим клип

▫ EDS Plane

• Разработка программных систем: теория и практика▫ Элементы теории для отдельных направлений

проектирования появляются на основе использования удачных практических достижений и анализа результатов неудачных разработок Практика приходит первой и развивается вначале

очень быстро; теория появляется после того как уже накоплен определенный практический опыт, требующий формализации, и также развивается очень быстро, даже быстрее практики, затем линии развития пересекаются и далее теория начинает предшествовать практике (Роберт Гласс)

Красивая теория может быть разрушена под напором ужасной действительности (Роберт Гласс)

• Взаимодействие теории и практики

▫ Практика скорее предшествует теории:

Проектирование программного обеспечения

Сопровождение программного обеспечения

Разработка пользовательского интерфейса

Программирование больших систем

Метрики программного кода и процесса

проектирования

…

• Иерархичность сложных систем▫ Простой пример:

персональный компьютер Рассматриваем

части и их взаимодействие

Уровни иерархии представляют различные уровни абстракции

Чаще всего, система содержит несколько иерархий

• Иерархичность сложных систем

▫ Некоторые считают, что, скорее всего, мы

можем понять только те системы, которые

имеют иерархическую структуру

Мы создаем иерархии для лучшего понимания

структуры того, что мы проектируем

Мы создаем иерархии, чтобы другие лучше

понимали, что мы проектируем

▫ Основной путь к пониманию сложной системы–

обнаружение общих абстракций и механизмов

Способность к абстрагированию – одна из сторон

творческих способностей человека (Дмитрий

Лихачев)

• Иерархическая декомпозиция сложных

систем

▫ Функционально-иерархическая

(алгоритмическая)

Проектирование «сверху вниз»

Сфокусирована на процессах

main

OpenFile ProcessTextCloseFile

ScanLex

GelLit

GetSynterm LexFirst LexNext LexFinish

LexemaLitera

File

Main

LEXER

main

OpenFile ProcessTextCloseFile

ScanLexGelLit

GetSynterm LexFirst LexNext LexFinish

LexemaLitera

File

Main

• Иерархическая

декомпозиция

сложных систем

▫ Объектно-

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

Сфокусирована на

моделировании

данных

Опирается на

основные абстракции

предметной области

Основы инженерии программного

обеспечения: предисловие• Основные принципы инженерии ПО

(программной инженерии)

• Роль объектно-ориентированного дизайна и проектирования▫ ООП – доминирующий подход, но это не только

подход к проектированию

▫ Сначала – принципы, затем – методы, затем –мотивированный выбор

• Пример:▫ Сокрытие информации

▫ Реализация в ООП: инкапсуляция, наследование

Основы инженерии ПО

• История программной инженерии▫ От маленьких проектов к большим

▫ От систем для небольшого числа пользователей к требованиям масштабируемости

▫ От прикладных систем математического обеспечения к глобальным информационным системам

▫ От локальных систем к распределенным

▫ От исследования к инженерии

▫ От систем, проектируемых отдельными разработчиками, к управлению самим процессом проектирования

Разрывы в разработке ПО

• Кризис ПО [Парнас, Брукс, Ньюман]

▫ Методологический разрыв

Теория не дает ответов на запросы практики

▫ Семантический разрыв [Лекарев]

Изобразительные средства языков

программирования не полностью адекватны

сложности решаемых задач

▫ Ответственность программной инженерии

• Корректность, надежность и устойчивость

ПО. Обсуждение

Современные проблемы

проектирования ПО• Повторное использование кода

▫ Много такого кода

▫ Трудности сопровождения и модификации

• Гетерогенность программных систем▫ Распределенные системы

▫ Различные операционные системы и вычислительные архитектуры

• Временные ограничения▫ Потребности рынка и изменение требований

▫ Быстро, дешево, качественно – выберите два

ПО как продукт

инженерии

Управление разработкой

Организация команды

Улучшение языков и

технологий

Стандарты кодирования

Формальные методы(теория)

Основы инженерии ПО

Средства и технологии

Методологии

Методы и приемы

Принципы

Ин

жен

ери

я П

О

Основы инженерии ПО

• Фундаментальные принципы программной инженерии и связанные с ними методы и концепции▫ Строгость и формальность

▫ Декомпозиция задач

▫ Модульность

▫ Абстрагирование

▫ Ожидание изменений

▫ Общность

▫ Инкрементность

•Спецификация•Управление требованиями

•Алгоритмы•Корректность•Верификация•Теория компиляции

Строгость и формальность

•Функциональная декомпозиция

•Последовательные вычисления

•Параллелизм•Управление проектом•Парадигмы

Декомпозиция задач

•Стратегии проектирования

•Раздельная компиляция•Иерархическое проектирование

•Пространства имен•Пакеты•Компоненты

Модульность

•Уровни абстрагирования•Управление сложностью•Языки программирования

Абстрагирование

•Управление требованиями

•Управление версиями•Отслеживание ошибок•Управление модификациями

Изменяемость

•Обобщенные решения и их специализации

•Шаблоны и настраиваемые типы

•Библиотеки компонентов•Сервис-ориентированнаяархитектура

Общность

•Прототипирование•24/7•Эволюционный дизайн•Итерационная разработка

•Унифицированный процесс

Инкрементность

Пример: проектирование

компилятора• Задача компиляции

• Модульная структура компилятора

▫ Лексический анализ

▫ Синтаксический и семантический анализ

▫ Кодогенерирующий компонент

• Как это пример иллюстрирует применение

принципов программной инженерии?

•Корректность –критический фактор

•Теория компиляции, грамматики, языки, теория автоматов и др.

Строгость и формальность

•Собственные компоненты компилятора

•Интерфейс пользователя•Средства профилирования и отладки

Декомпозиция задач

•Лексический анализ•Синтаксический разбор•Генерация кода•Пользовательские сервисы, средства поддержки проектирования и др.

Модульность

•Абстрактный синтаксис•Абстрактные вычисления и виртуальные машины

•Языки программирования

Абстрагирование

•Изменение архитектур процессоров

•Изменение номенклатуры устройств ввода-вывода

•Изменение стандартов языка

Изменяемость

•Промежуточный код для межплатформенной совместимости

Общность

•Версии•Оптимизация•Изменения библиотек

Инкрементность

Сложность моделирования

• Моделирование как сужение проблемы

• Фазы моделирования▫ Модель

предметной области

▫ Модель прецедентов

▫ Модель проектирования

Объектно-ориентированный

подход к разработке ПО

• Анализ▫ Создание ОО

модели предметной области

• Проектирование▫ Разработка ОО

модели системы ПО (системной архитектуры) с учетом системных требований

• Программирование▫ Реализация на

языке (языках) программирования

ООАиП и UML

• Unified Modeling

Language▫ Визуальный язык для

определения,

конструирования и

документирования

артефактов систем

▫ ООАиП и UML

Нотация

Методология

Средства

ООАиП и шаблоны

проектирования

• Шаблон проектирования (pattern)▫ Типичное решение

проблемы в определенном контексте

• Описание паттерна▫ Имя▫ Проблема▫ Решение▫ Результаты

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

программного обеспечения

• Каскадная модель (Waterfall lifecycle)▫ Определение требований

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

▫ Реализация (кодирование)

▫ Интеграция

▫ Тестирование и отладка

▫ Инсталляция

▫ Поддержка

• Недостатки▫ Предположение о

стабильности спецификаций-идеализация

▫ Изменение требований очень дорого стоит

OOA&D and Design Process

Models

• Эволюционный дизайн▫ Спецификация,

проектирование и тестирование – в пределах одной итерации

▫ Риски Плохая

документация Плохая структура Множественность

технологий => несовместимость версий

Specification

Draft requirements

Development

Testing and Evaluation

Prototype

Versions

Release

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

программного обеспечения

• Спиральная модель▫ Эволюционная

разработка

▫ Итерация Определение целей

Оценка и разрешение рисков

Разработка и тестирование

Планирование

▫ Совместима с другими моделями

Closer view... What is strange?

(*) «Версия испр. и дополн.»

OOA&D and Design Process Models

• V-Model

▫ Сфокусирована на управлении процессом

проектирования

▫ Сфокусирована на управлении требованиями и

спецификациями

▫ Улучшенная каскадная модель

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

программного обеспечения

• Итеративная разработка▫ Основные черты

Раннее проектирование и тестирование частей системы в многократно повторяемых циклах

Прояснение требований в ходе разработки- обычное явление

Итеративная разработка допускает изменения

▫ Используйте итеративную разработку только в тех проектах, которые должны быть успешно завершены (Мартин Фаулер)

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

программного обеспечения

• Unified Process (UP)▫ Унифицированный

процесс – один из самых популярных итеративных методов разработки

▫ RUP

• Важные принципы▫ Оценка рисков на ранних

итерациях▫ Управление

требованиями▫ Применение

прецедентов▫ Раннее и частое

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

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

RU EN

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

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

• Итеративная разработка

▫ Rational Unified Process

• Гибкая методология

▫ SCRUM

▫ Экстремальное

программирование

• Быстрая разработка

• Microsoft Solutions Framework

• Waterfall

• Spiral Model

• Iterative Development

▫ RUP

• Agile Development

▫ SCRUM = Agile + Discipline

▫ XP = Agile + Test first

• RAD

• MSF

Software Engineering IОбъектно-ориентированный анализ и проектирование

Раздел 1. Введение

Q & A