В этой серии статей я буду реализовывать приложение для управления задачами на Python. Эта серия будет охватывать весь путь, начиная от сбора требований к приложению и заканчивая реализацией серверной (Python, PostgreSQL) и внешней (Flask) частей приложения.

В первой статье проект будет следовать простому 5-этапному подходу к проектированию ООП-систем. Шаги:

  1. Соберите требования.
  2. Создавайте варианты использования и пользовательские истории.
  3. Определите наиболее важные объекты.
  4. Взаимодействия и отношения между объектами.
  5. Создайте диаграмму классов.

В последующих статьях я буду реализовывать ООП-систему по результатам этапов проектирования.

Шаг № 1 — Соберите требования

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

На этом этапе мы должны разделить требования на два типа:

  1. Функциональные требования.
  2. Нефункциональные требования.

Функциональные требования

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

Функциональные требования к системе управления задачами могут включать:

  1. Создание задачи: возможность для пользователей создавать новые задачи с именем, описанием, сроком выполнения, уровнем приоритета и любыми другими соответствующими деталями.
  2. Редактирование задач. Возможность для пользователей редактировать существующие задачи, включая изменение имени, описания, срока выполнения, уровня приоритета и других деталей.
  3. Удаление задачи. Возможность для пользователей удалять задачи, которые больше не нужны.
  4. Категоризация задач: возможность пользователей классифицировать задачи, назначая их одной или нескольким категориям, например «работа», «личные» или «поручения».
  5. Приоритизация задач. Возможность для пользователей приоритизировать задачи в зависимости от их важности и срочности, а также просматривать задачи в порядке приоритета.
  6. Фильтрация задач. Возможность для пользователей фильтровать задачи по различным критериям, таким как категория, срок выполнения, приоритет или статус.

Нефункциональные требования

Затем мы должны собрать нефункциональные требования. Эти требования описывают характеристики приложения, такие как ремонтопригодность, надежность, удобство использования, доступность и многое другое.

Допустим, нашему приложению требуется:

  1. Удобство использования. Система должна быть проста в использовании и навигации, а ее интерфейс должен быть интуитивно понятным и визуально привлекательным.
  2. Производительность. Система должна быть быстрой и отзывчивой; максимальная задержка не должна превышать нескольких секунд.
  3. Доступность. Система должна быть доступна круглосуточно и без выходных.

Этого достаточно, чтобы начать; мы всегда можем придумать дополнительные требования, если это необходимо.

Шаг № 2 — Генерация вариантов использования и пользовательских историй

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

Случаи использования

Отличный способ сделать это — создать варианты использования. Варианты использования имеют три вещи:

  1. заголовок, описывающий цель.
  2. актер/пользователь/объект, который будет взаимодействовать с приложением для достижения какой-либо цели.
  3. шаги, необходимые для достижения цели.

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

Сценарий 1. Создание новой задачи

  • Пользователь хочет добавить новую задачу в проект.
  • Пользователь переходит к экрану «Добавить задачу».
  • Пользователь вводит имя, описание, срок выполнения, уровень приоритета и любые другие важные сведения для новой задачи.
  • Пользователь нажимает кнопку «Сохранить», чтобы сохранить новую задачу в системе.
  • Система проверяет ввод и создает новую задачу.

Случай использования 2: редактирование существующей задачи

  • Пользователь хочет отредактировать существующую задачу в системе.
  • Пользователь переходит к экрану «Сведения о задаче» для задачи.
  • Пользователь нажимает кнопку «Редактировать».
  • Пользователь вносит изменения в имя, описание, дату выполнения, уровень приоритета или другие сведения о задаче.
  • Пользователь нажимает кнопку «Сохранить», чтобы сохранить изменения в задаче.
  • Система проверяет ввод и обновляет задачу новой информацией.

Сценарий 3. Удаление задачи

  • Пользователь хочет удалить задачу, которая больше не нужна.
  • Пользователь переходит к экрану «Сведения о задаче» для задачи.
  • Пользователь нажимает кнопку «Удалить».
  • Система предлагает пользователю подтвердить удаление.
  • Пользователь подтверждает удаление.
  • Система удаляет задачу из системы.

и т. д…

Истории пользователей

Затем мы должны создавать истории с точки зрения пользователей (желательно после обсуждения с ними), чтобы гарантировать, что команда разработчиков создает программное обеспечение, отвечающее потребностям пользователей. Это простой и эффективный способ зафиксировать требования и ожидания пользователей таким образом, чтобы он был легко понятен и практичен для команды разработчиков.

Некоторые примеры в нашем случае:

  1. История пользователя 1. Как пользователь я хочу иметь возможность фильтровать задачи по категориям, чтобы легко находить задачи, связанные с конкретным проектом или областью ответственности. .
  2. История пользователя 2. Как пользователь, я хочу получать уведомления по электронной почте, когда задачи приближаются к сроку выполнения, чтобы я мог оставаться в курсе своей работы и не нарушать важные сроки. .
  3. История пользователя 3. Как пользователь я хочу иметь возможность назначать задачи для конкретных проектов и отслеживать ход выполнения этих проектов, чтобы более эффективно управлять своей рабочей нагрузкой и расставлять приоритеты. соответственно мои задачи.
  4. История пользователя 4. Как пользователь, я хочу иметь возможность просматривать список выполненных задач, чтобы отслеживать свой прогресс и испытывать чувство выполненного долга, когда закончу важная работа.

и т. д…

Шаг № 3 — Определите наиболее важные объекты

После этих первых этапов мы можем приступить к проектированию системы. Общая идея на этом шаге состоит в том, чтобы приблизительно идентифицировать потенциальные объекты, которые могут превратиться в реальные объекты ООП в нашем коде. Мы хотим выделить то, о чем нам нужно знать в приложении.

Не каждый объект, который мы идентифицируем, со временем станет классом в системе.

Чтобы определить потенциальные объекты, нам нужно выделить существительные пользовательских историй и вариантов использования. Например, давайте определим потенциальные объекты в первом варианте использования:

Сценарий 1. Создание новой задачи

  • Пользователь хочет добавить новую задачу в проект.
  • Пользователь переходит к экрану «Добавить задачу».
  • Пользователь вводит имя, описание, срок выполнения, уровень приоритета и любые другие важные сведения для новой задачи.
  • Пользователь нажимает кнопку «Сохранить», чтобы сохранить новую задачу в системе.
  • Система проверяет ввод и создает новую задачу.

Теперь я выделю существительные:

  • Пользователь хочет добавить новую задачу в систему.
  • Пользователь переходит к экрану "Добавить задачу".
  • Пользователь вводит имя, описание, дату выполнения, уровень приоритета и любые другие важные сведения для новой задачи.
  • Пользователь нажимает кнопку "Сохранить", чтобы сохранить новую задачу в системе.
  • Система проверяет входные данные и создает новую задачу.

Теперь идея состоит в том, чтобы попытаться исключить существительные, которые, вероятно, не станут настоящими классами в нашей системе. Однако мы не должны планировать заранее слишком методично, если есть сомнения относительно существительного, мы должны оставить его.

В нашем случае следующие существительные имеют наибольшую вероятность быть полезными классами в нашем приложении:

User
Task
System

После расширения этой логики на остальные варианты использования и пользовательские истории, это лучшие кандидаты для классов в приложении:

User
Task
System
Project
Comment
Attachment
Notification

Шаг № 4 — Отношения и обязанности

Отношения

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

В нашем случае схема может выглядеть так:

Таким образом, мы можем перевести это так:

  • Одна система аутентифицирует многих пользователей.
  • Пользователь может создавать множество Проектов, каждый из которых может иметь множество Задач.
  • Каждая задача может иметь множество комментариев и уведомлений.

Обязанности

Далее, чтобы определить, какие из этих объектов нам нужно превратить в классы, мы должны определить обязанности и поведение этих объектов. Эта часть поможет нам понять, в каком классе мы должны кодировать методы, которые позволят нам выполнять пользовательские сценарии использования и истории. Другими словами, какой класс «отвечает» за поведение.

На мой взгляд, между этими объектами существует четкая иерархия. Поэтому:

  • Пользователь должен нести ответственность за создание и управление проектами.
  • Project должен отвечать за создание и обработку задач.
  • Task должен отвечать за создание и обработку комментариев и уведомлений.
  • Комментарий и Уведомление не должны нести никакой ответственности, поскольку они являются самыми низкими в иерархии.
  • Система будет общим классом, который будет передавать информацию между классами и базой данных приложения.

Шаг № 5 — Диаграмма классов

После всей тяжелой работы мы можем увидеть общую картину того, как должна функционировать система, какие классы в ней есть, их отношения, обязанности и т. д.

Теперь мы готовы создать диаграмму классов, она будет служить руководством для того, когда мы на самом деле будем кодировать приложение. Узел на диаграмме классов выглядит так:

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

Например, вот как я буду реализовывать класс User:

Я продолжил создание полной диаграммы классов для системы. Схема выглядит так:

Обратите внимание, как всегда, это не «высечено на камне» и, вероятно, будет несколько изменено на этапе кодирования, но тем не менее это отличное руководство, на которое можно положиться, когда мы кодируем приложение.

На этом вторая статья цикла завершена, в следующей я буду реализовывать серверную часть приложения с использованием Python и PostgreSQL.