Как планировать код до его написания: ООАП

04.02.2025

Зачем анализировать перед программированием?

Если просто садиться и писать код, не продумывая структуру, получится каша. Представь, что ты строишь дом без чертежа – стены рухнут, проводка запутается, а двери будут выходить в никуда.

Вот почему появилась методология объектно-ориентированного анализа и проектирования (ООАП).

Она помогает:

• Разбить сложную задачу на понятные части

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

• Сделать код логичным, понятным и удобным в поддержке

Кто этим занимается?

В ООАП участвуют три типа людей:

1. Специалисты предметной области – те, кто понимает, какие задачи должна решать программа (например, бухгалтеры, если это софт для финансов).

2. Аналитики – переводят требования заказчика в понятную структуру.

3. Архитекторы – продумывают, как именно должна быть устроена программа.

Программисты не сразу пишут код – они работают с тем, что придумали аналитики и архитекторы.

Жизненный цикл программы (ЖЦ)

Любая программа проходит несколько этапов

1. Анализ – разбираемся, что вообще должно делать приложение. 2. Проектирование – создаём схему будущего кода: какие классы нужны, как они связаны. 3. Программирование – пишем код на основе схемы. 4. Тестирование – проверяем, работает ли всё как надо. 5. Внедрение – запускаем программу в реальной жизни. 6. Сопровождение – исправляем баги, улучшаем функционал. 7. Отказ от использования – программа больше не нужна (например, заменили на новую версию).

Важно! Код пишется на третьем этапе, а до этого – чистая логика и проектирование.

Как выглядят схемы?

Чтобы не объяснять на пальцах, придумали UML – унифицированный язык моделирования. Это графические схемы, показывающие:

• Какие классы есть в программе

• Как они взаимодействуют

• Какие у них методы и свойства

Пример UML-диаграммы для игры:

+--------------+      +---------------+
|   Player     | ---> |     Weapon    |
+--------------+      +---------------+
| health       |      | damage        |
| attack()     |      | shoot()       |
+--------------+      +---------------+

Здесь видно, что у игрока есть здоровье и метод атаки, а у оружия – урон и возможность стрелять.

Кейс — это просто конкретная ситуация или сценарий, в котором программа должна работать. В ООАП кейс помогает понять, какие действия программа должна выполнять в разных условиях.

Пример:

• Кейс 1: Игрок нажал кнопку "Атаковать". Программа должна уменьшить здоровье врага.

• Кейс 2: Игрок получил урон. Программа должна уменьшить здоровье игрока.

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

Что даёт ООАП?

• Программисты знают, что писать – не надо гадать, какие классы нужны.

• Программа развивается без боли – можно легко добавить новый функционал.

• Работа в команде проще – все видят, как устроен проект.

В итоге, ООАП – это как план перед стройкой: без него код превратится в хаос.