ООП Лекция 15. Этапы разработки ПО с использованием объектно ориентированного подхода.
Перед нами стоит задача, как подходить к разработки объектно-ориентированной программы.
- Анализ
- Проектирование
- Кодирование
- Тестирование
- Анализ
- Проектирование
- Эволюция
- Модификация
В структурном программировании анализ - это формализация задач. В ООП на этап анализа приходится гораздо больше, это чуть ли не основной этап из всех этапов. Этап анализа - построение модели нашей задачи.
Этап анализа проходит вместе с заказчиком. Для нас, как программистов, это плюс - мы четко понимаем, что представляет из себя задача. Для заказчика это тоже плюс, так как на этом этапе он сам разбирается в модели той задачи, которую мы решаем.
Анализ строится на основе физического мира. Мы строим модель и как бы делаем "слепок" физического мира, то есть строить объектно-ориентированную модель, выделять сущности, выявлять взаимодействие сущностей.
Требования к модели:
- Модель должна быть полная.
- Модель должна быть понятная всем заинтересованным лицам.
Этап проектирования - очень важный этап, так как нам нужна документация к нашему ПП.
Проектирование - перевод из документов, которые нам помогали проводить анализ, в проектные документы, на основе которых мы уже непосредственно пишем код.
В структурном программировании было кодирование + тестирование.
В ООП эволюция включает в себя:
- кодирование
- тестирование
- рекурсивный дизайн.
Мы начинаем с простого, начального состояния модели нашей системы и потом её развиваем. Если у нас возникли какие-то проблемы, мы переходим или к анализу, либо перепроектируем какие-то части системы (рд-подход).
- Предоставляется обширная обратная связь.
- Появляются различные версии нашей системы. РД дает очень удобный механизм отката. Если мы понимаем, что текущая версия нам не подходит, мы можем вернуться на предыдущую. Возможна реализация нескольких версий нашей системы, мы можем разработать альтернативные версии (как правило, это связано с тем, когда мы делаем систему для нескольких пользователей - у них может быть разный функционал). Быстро и легко мы можем перейти от одного решения к другому.
- За счет большого количества версий системы появляется возможность плотно взаимодействовать с заказчиком.
- Как в структурном программировании, мы разворачиваем систему и уже на начальных этапах видны результаты.
- Интерфейс проектируется отдельно, заранее, до основного этапа разработки, так как на интерфейсе отрабатывается взаимодействие с заказчиком, как с пользователем системы.
- Добавление нового класса - вещь совершенно безболезненная, которая при нормальном анализе не приводит к изменению написанного кода.
- Изменения реализации класса. Это происходит на основе наследования, мы добавляем новый класс, подменяющий другой класс. Мы не переписываем существующий код.
- Добавление нового класса - имеется ввиду добавление своей ветви. Реализация класса - на основе наследования.
- Изменение представления класса. Мы можем с классом работать по другому и это не должно повлиять на переписывание кода.
- Реорганизация структуры классов - болезненная часть, затрагивающая минимальное переписывание (использование паттернов, например, появление компоновщика, адаптера для расширения функционала, прокси для добавления функционала или реализации доступа к объекту).
- Самое страшное - изменение интерфейса базового класса. До такой ситуации лучше не доводить, как правило, это переделывание большого кода.
Эволюция - непосредственно разработка ПП. Мы сдали заказчику готовый продукт, а следующие изменения, когда мы уже сдали, будет модификацией. Модификация затрагивает анализ и затрагивает проектирование
Разница между эволюцией и модификацией:
- До этапа сдачи - эволюция, после - модификация.
- Эти этапы выполняют совершенно разные люди.