Pull to refresh

Comments 10

Согласен, в связи с принципом Agile (не делать дорожные карты) строить диаграммы UML не вариант. Весь процесс постановки требований и проектирования основан на пользовательских историях, которые не дают представлений о масштабах и сложности задачи. Так же они не дают понимания структуры проекта(если дополнительно ничего не уточнять). На мой взгляд, начинающему разработчику(особенно в pet-проектах) нужно иметь полную структуру проекта перед глазами. Лично мне это помогает видеть дальнейший шаги в разработке и составлять какие-либо планы.
altai2013 (Извиняюсь, что это не «ответ» к комментарию, случайно тыкнул не туда)
У вас не подписаны стрелки-отношения зависимостей(include/extend). А в целом, все отлично!
Ну, это-то дело поправимое. я в принципе, как пример. Ну и хранится это в git-friendly виде:
Заголовок спойлера
@startuml
:Зам директора: as ЗД
:Обучающийся: as О
:Преподаватель: as П
:Кл. Руководитель: as КР

(Составить расписание) as (Расписание)
ЗД -- (Расписание)

(Расписание) ..> (Составить\n расписание\n занятий) : "include"
(Расписание) ..> (Составить\n расписание\n мероприятий) : "include"
(Расписание) ..> (Составить\n расписание\n Каникул) : "include"

(Отправить\n сообщение) as Сообщение

ЗД -- Сообщение
О -up- Сообщение
П -- Сообщение
КР -- Сообщение

Сообщение <.. (Прикреп файл\n к сообщению) : "extend"

О -- (Узнать расписание)
О -- (Узнать свои оценки)

П --> (Разместить\n материалы\n для урока)
П --> (Выставить оценки в\n электронный журнал)

КР --|> П
КР --> (Составить\n расписание\n родительских\n собраний)
@enduml

Всё понятно и разжеванно, спасибо. Будет ли продолжение про другие диаграммы?

Здравствуйте, рад стараться! Да, продолжение будет, я планирую статью про диаграмму классов UML.

Sign up to leave a comment.

Articles