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

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

Пышкин Е.В.

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

План курса

• Введение

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

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

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

План курса

• Язык UML: основы

▫ Введение

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

Структура UML

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

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

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

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

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

План курса

• Шаблоны проектирования GoF

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

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

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

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

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

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

Перспективы

• …

• Information Systems

▫ Базы данных (4-й курс)

• Software Engineering II

▫ Промышленные технологии разработки программного обеспечения (5-й курс)

План курса: литература

ВведениеСложность, присущая программному

обеспечению

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

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

Язык UML: основыВведение

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

Структура UML

Описание прецедентов

Моделирование предметной областиКлассы и отношения

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

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

Шаблоны проектирования GoFЧто такое «шаблон проектирования»

(design pattern)

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

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

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

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

1. Брукс Ф.П. Мифический человеко-месяц , или как создаются программные системы / Пер. с англ. – СПб.: Символ, 2000. – 304 с.: ил.

2. Соммервилл И. Инженерия программного обеспечения. 6-е издание / Пер. с англ. – М.: Издательский дом «Вильямс», 2002. – 624 с.: ил.

3. Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на C++. 2-е изд. / Пер. с англ. – М.: «Издательство Бином», СПб.: «Невский диалект», 2000. – 560 с.: ил.

4. Бадд Т. Объектно-ориентированное программирование в действии / Пер. с англ. – СПб.: Питер, 1997. – 464 с.: ил. (Серия «В действии»)

5. Буч Г., Рамбо Дж., Якобсон А. Язык UML. Руководство пользователя / Пер. с англ. – М.: ДМК Пресс, 2000. – 432 с.: ил. (Серия «Для программистов»)

6. Леоненков А.В. Самоучитель UML 2. – СПб.: БХВ-Петербург, 2007. –576 с.: ил.

7. Ларман К. Применение UML 2.0 и шаблонов проектирования, 3-е издание / Пер. с англ. – М.: «И.Д. Вильямс», 2007. – 736с.: ил.

8. Pender T.A. UML Weekend Crash Course. Wiley Publishing Inc., 2002. 358 p.

9. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентрованного программирования. Паттерны проектирования. / Пер. с англ. – СПб.: Питер, 2001. – 368 с.: ил. (Серия «Библиотека программиста»)

10. Гранд М. Шаблоны проектирования в Java / Пер. с англ. – М.: Новое знание, 2004. – 559 с.: ил.

11. Александреску А. Современное проектирование на C++. Серия C++ in Depth, т.3 / Пер. с англ. – М.: Издательский дом «Вильямс», 2002. – 336с.: ил.

12. Пышкин Е.В. Основные концепции и механизмы объектно-ориентированного программирования. – СПб.: БХВ-Петербург, 2005. –640 с.: ил.

Введение

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

Упражнение 1: сосчитайте точки

Упражнение 2: сосчитайте точки

• Не все программные проекты сложны

▫ Чем отличается программа в 50 строк от проекта в 5 000 000 строк?

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

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

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

• Сложность программного обеспечения (Шнейдерман)▫ Логическая трудность, длина или невозможность

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

▫ Структурная детализация = сложность модули и отношения между модулями сложность интерфейса

▫ Психологическая трудность для понимания человека ассоциативный характер человеческой памяти

• Почему программному обеспечению присуща сложность?

▫ Сложность реальной предметной области

Пользователи и разработчики

Изменение требований

Можно ли изменить фундамент уже построенного здания?

Неявные ограничения

▫ Творческий процесс, различные виды активностей

Человеческий фактор

CASE-tools и их ограничения

• Почему программному обеспечению присуща сложность?

▫ Трудность управления процессом разработки

▫ Гибкость программного обеспечения

▫ Сложность описания поведения больших систем

• Повышение производительности и улучшение функциональности

• Расширения областей применения информационных технологий

• Появляются новые возможности и сервисы

• Сложность задач Ю стоящих перед разработчиками, увеличивается

ЗадачиСистемы

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

Аппаратное обеспечения

Приложения

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

▫ 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

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

▫ Объектно-ориентированная

Сфокусирована на моделировании данных

Опирается на основные абстракции предметной области

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

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

(программной инженерии)• Роль объектно-ориентированного дизайна и

проектирования▫ ООП – доминирующий подход, но это не только

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

мотивированный выбор

• Пример:▫ Сокрытие информации▫ Реализация в ООП: инкапсуляция, наследование

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

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

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

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

▫ От локальных систем к распределенным▫ От исследования к инженерии▫ От систем, проектируемых отдельными

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

1950 1960 1970 1980 1990 2000

Кодирование

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

Команды разработчиков

Кризис ПО

Проектные коллективы

Вычислительная математика

Физика

Механика…

Системные утилиты

Операционные системы

Компиляторы

Бизнес-ориентированные системы

Проблемы крупных систем

Квалиф. пользователей

Глобальные

Кризис ПО: аспекты

Разрывы

1-й (семантический)2-й

(методологический)

Проблемы масштабируемости

Масштаб самого проекта

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

Формализация задач

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

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

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

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

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

Изобразительные средства языков программирования не полностью адекватны сложности решаемых задач

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

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

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

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

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

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

вычислительные архитектуры

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

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

инженерии

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

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

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

технологий

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

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

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

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

Методологии

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

Принципы

Ин

жен

ери

я П

О

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

• Фундаментальные принципы программной инженерии и связанные с ними методы и концепции▫ Строгость и формальность▫ Декомпозиция задач▫ Модульность▫ Абстрагирование▫ Ожидание изменений▫ Общность▫ Инкрементность

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

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

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

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

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

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

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

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

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

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

Модульность

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

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

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

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

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

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

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

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

Общность

•Прототипирование•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

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

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

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

разработка▫ Итерация Определение целей Оценка и

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

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

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

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

▫ XP

• RAD

• MSF

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

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

Q & A