постараюсь конкретизировать своё сумбурное изложение.... я не вижу связи между диаграммой UML и скриптом на генерацию базы данных.
Если ты не видишь этой связи, значит, достаточно внимательно читал статью. Ибо этой связи и в самом деле нет
Конечно, ее нет лишь в явном виде. Сейчас (в смысле - на первом этапе проектирования) эта связь существует в весьма косвенном виде и будет постепенно проявляться по мере детализации проекта. Именно это я имел в виду, когда говорил, что на ранней стадии проекта определять структуры данных преждевременно.
если этой связи нет как таковой - то нахрен весь этот UML, imho
Если в двух словах - причина кроется в том, что не юзеры существуют, чтобы набивать базы данных, а базы данных созданы для того, чтобы обслуживать потребности юзеров в информации. Как бы ни была горька эта истина, программерам приходится ее принимать
Если серьезно, то RUP в общих чертах выглядит так. Сначала производится анализ бизнес-процессов задачи (в нашем случае опущен, поскольку процессы проще пареной репы и их моделирование - пустая трата времени).
Затем выясняется, что система должна уметь делать, чтобы осчастливить юзера (тот самый анализ прецедентов, о котором я писал в статье). Перечисляются основные действия, ради которых она и создается.
После этого как логическое продолжение разрабатывается модель устойчивости, которая фактически представляет собой графическое отображение сценариев прецедентов. Эти сценарии в черновом виде набрасываются на предыдущем этапе, но неформально, только чтобы разъяснить назначение того или иного прецедента. Теперь же они прорабатываются на детальном уровне - что и в каком порядке нужно нажать и ввести, чтобы получить результат. Причем прорабатываются не только основные варианты развития сценария, но и альтернативные (например, клиент передумал доводить операцию до конца и решил откатиться обратно).
На этом же этапе уместно подготовить эскизы экранов и форм, которые представляют собой интерфейс пользователя, поскольку имено через них происходит диалог. Конечно, раскраску веб-страницы изображать рановато, но с основными контролами определиться самое время.
Собственно, в этой точке имеет смысл согласовать проект с заказчиком, утвердив его в виде техзадания. Поскольку потребителя интересует функциональность программы и интерфейс, которым он будет пользоваться для работы с ним. Все остальное - это уже по усмотрению разработчика, и дальнейшая документация является внутренней для проекта. Собственно, ER-диаграммы и не фигурировали до сих пор именно потому, что заказчику совершенно безразлично, будешь ли ты использовать базу данных или же разместишь данные в массивах, и какими именно данными будет набита база. База - лишь один из технологических моментов, которые извне не видны и в ТЗ поэтому присутствовать не должны как особенность реализации.
Вкратце о составе дальнейшей документации проекта. Будут разработаны:
- диаграмма классов, которая показывает иерархию и статические связи между классами, реализующими основные сущности проекта;
- диаграммы последовательностей и кооперации, которые показывают динамику взаимодействия между объектами, обмен сообщениями между ними, а также создание и удаление динамических объектов;
- диаграммы видов деятельности, моделирующие основные алгоритмы;
- диаграммы состояний для объектов, которые лучше всего моделировать в виде конечных автоматов;
- диаграммы компонентов, отражающие физическое размещение классов, библиотек, данных и т.п.
Диаграмма развертывания в нашем случае, пожалуй, будет избыточна, поскольку весь проект будет базироваться на одном сервере.
Кстати, когда дело дойдет до диаграмм классов, выяснится, что некоторые классы должны долгосрочно хранить данные (это указывается атрибутом persistent). Такие классы - кандидаты на работу с базой данных (опять же - лишь кандидаты, в таких вопросах рубить сплеча не принято; иной раз может оказаться уместнее, например, обычная сериализация объекта в файл). Вот тут-то и появится долгожданная ER-диаграмма, а если понадобится, то и тяжелая артиллерия в виде IDEF1X. Именно тут и ни минутой раньше, если нет желание переделывать по многу раз.
По заданным мне вопросам я так понял, что из моей статьи можно сделать вывод, будто UML сводится к единственной модели прецедентов. Поэтому прошу прощения у сбитых мною с толку читателей. Конечно же, по-хорошему нужно было начать с обзора RUP и UML, чтобы прояснилась картина в целом. Отчасти попытался загладить вину этим несколько сумбурным замечанием.
В качестве слабого оправдания могу лишь добавить, что задерживать публикацию еще дольше, чтобы внести необходимые обзорные сведения, не имело смысла, поскольку среди разработчиков и так появился некоторый разброс мнений, который в сочетании с отсутствием подходящей документации мог вообще загубить проект. Поэтому принимайте пока ее уж как есть, а все возможные недоразумения я постараюсь уладить в рабочем порядке.
