Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: О технологиях проектирования и введении в RUP и UML.  (Прочитано 21282 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« : 17-11-2004 12:24 » 

Хорошо написано. Возражений или замечаний нет.

Вопрос ко всем: чисто практически как на форуме оперировать диаграммами при обсуждении? Аттачить картинки пользователи не могут. Выдержит ли БД текущего форума, если это разрешить? И т.п.

О своей статье на эту тему я всё же подумаю. Теперь тема разложилась на 2 направления: 1) практическое - UML и использование методик в разработке, 2) идеологическое - то, в связи с чем выражено удивление - нежелание программистов перед написанием кода проводить анализ задачи, разрабатывать спецификации и т.п.

Если Alf сконцентриуется на первом направлении, то я тогда возьмусь за второе (рассмотрев, в частности, XP и сопоставив с более традиционными методами, изложив достоинства и недостатки).

По поводу преподавания: в том вузе, где я учился, упор на кодировании как раз не делали, делали упор на спецификациях. Возможно потому, что преподаватель как программирование для 1-го курса ведёт, так и метрологию для 4-го.

По поводу программистов: действительно, очень многие не уделяют внимания анализу задач, однако, к счастью, не все. У меня на работе в начале составляется документ, специфицирующий разрабатываемую систему (Software Specification Document), а затем (для сложных систем) документ детального проектирования (Detailed Design Document) вплоть до примеров кода. И пока не созданы первые версии этих документов, собственно кодированием никто не занимается.
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
x77
Команда клуба

ro
Offline Offline
Пол: Мужской
меняю стакан шмали на обратный билет с Марса.


« Ответ #1 : 17-11-2004 14:26 » 

на "почему..." касательно этого форума ты сам ответил: он не предназначен для проектного моделирования, тем более, корпоративного. и невозможность аплоада картинок - не самое непреодолимое препятсвие.
Записан

Never
Команда клуба

ua
Offline Offline
Пол: Женский

« Ответ #2 : 17-11-2004 19:59 » 

Фигня это все! Для желающих увидеть картинку ее можно разместить вне форума, как помнится делал Гром, рисуя свое видение задачи для прошлой, благополучно провалившейся разработки.
Было бы желание...
Записан

не умеете летать- не мучайте метлу!
x77
Команда клуба

ro
Offline Offline
Пол: Мужской
меняю стакан шмали на обратный билет с Марса.


« Ответ #3 : 17-11-2004 20:46 » 

Never, "а был ли мальчик?" Улыбаюсь
Записан

Alf
Гость
« Ответ #4 : 17-11-2004 20:49 » 

По-моему, проблема создана на пустом месте...

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

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

Однако оффтопим, господа. Давайте тут о статье говорить, а в технологических темах - о рабочих вопросах.
Записан
x77
Команда клуба

ro
Offline Offline
Пол: Мужской
меняю стакан шмали на обратный билет с Марса.


« Ответ #5 : 17-11-2004 20:58 » 

Alf, принято.

я никогда не пользовался UML. почитал - всё понятно. по статье. на практике - увы. разница между UML в твоём изложении, и, например, обычной ER-моделью  только в обобщённости UML, что с точки зрения разработки, скорее, минус.

ну нарисовал я красивых диаграмм с красивыми названиями на пол-стены, и дальше что? всё равно ведь придётся прорабатывать сущности, связи, строить нормальую модель. как это всё реализуется на практике?
Записан

x77
Команда клуба

ro
Offline Offline
Пол: Мужской
меняю стакан шмали на обратный билет с Марса.


« Ответ #6 : 17-11-2004 21:00 » 

постараюсь конкретизировать своё сумбурное изложение....  я не вижу связи между диаграммой UML и скриптом на генерацию базы данных. если этой связи нет как таковой - то нахрен весь этот UML, imho Улыбаюсь
Записан

Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #7 : 17-11-2004 21:33 » 

x77, для понимания Улыбаюсь Диаграмма классов/объектов по сути своей есть расширение ERD, где дополнительно можно вводить шаблоны, наследования (в ER того же Power Designer тоже можно наследовать), указать методы. Полагаю, ERD ты для базы данных строишь перед написанием скрипта генерации (если в БД не 2 таблички, а хотя бы 20 и более)? Но до диаграммы классов Alf ещё не дошёл - не спеши с выводами Улыбаюсь.

А вообще, думается, в конце концов будут созданы (и широко распространены) средства эффективной генерации кода по UML-модели. Они уже есть, но распространены пока слабо и дорого стоят.

Собственно, в этом и есть "идеологическая" составляющая - разработчики не понимают, зачем им эти UMLи нужы - жили без них и дальше жить будем. Но тут вопрос даже не в UML, а шире. На эту тему у Alf'а были переводы Дейкстры, об этом и я намечаю статью писать.

А про картинки сказать пойду в другой форум Улыбаюсь
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Alf
Гость
« Ответ #8 : 17-11-2004 23:07 » 

Цитата: x77
постараюсь конкретизировать своё сумбурное изложение....  я не вижу связи между диаграммой UML и скриптом на генерацию базы данных.

Если ты не видишь этой связи, значит, достаточно внимательно читал статью. Ибо этой связи и в самом деле нет  Улыбаюсь

Конечно, ее нет лишь в явном виде. Сейчас (в смысле - на первом этапе проектирования) эта связь существует в весьма косвенном виде и будет постепенно проявляться по мере детализации проекта. Именно это я имел в виду, когда говорил, что на ранней стадии проекта определять структуры данных преждевременно.
Цитата: x77
если этой связи нет как таковой - то нахрен весь этот UML, imho Улыбаюсь

Если в двух словах - причина кроется в том, что не юзеры существуют, чтобы набивать базы данных, а базы данных созданы для того, чтобы обслуживать потребности юзеров в информации. Как бы ни была горька эта истина, программерам приходится ее принимать  Улыбаюсь

Если серьезно, то RUP в общих чертах выглядит так. Сначала производится анализ бизнес-процессов задачи (в нашем случае опущен, поскольку процессы проще пареной репы и их моделирование - пустая трата времени).

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

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

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

Собственно, в этой точке имеет смысл согласовать проект с заказчиком, утвердив его в виде техзадания. Поскольку потребителя интересует функциональность программы и интерфейс, которым он будет пользоваться для работы с ним. Все остальное - это уже по усмотрению разработчика, и дальнейшая документация является внутренней для проекта. Собственно, ER-диаграммы и не фигурировали до сих пор именно потому, что заказчику совершенно безразлично, будешь ли ты использовать базу данных или же разместишь данные в массивах, и какими именно данными будет набита база. База - лишь один из технологических моментов, которые извне не видны и в ТЗ поэтому присутствовать не должны как особенность реализации.

Вкратце о составе дальнейшей документации проекта. Будут разработаны:
- диаграмма классов, которая показывает иерархию и статические связи между классами, реализующими основные сущности проекта;
- диаграммы последовательностей и кооперации, которые показывают динамику взаимодействия между объектами, обмен сообщениями между ними, а также создание и удаление динамических объектов;
- диаграммы видов деятельности, моделирующие основные алгоритмы;
- диаграммы состояний для объектов, которые лучше всего моделировать в виде конечных автоматов;
- диаграммы компонентов, отражающие физическое размещение классов, библиотек, данных и т.п.

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

Кстати, когда дело дойдет до диаграмм классов, выяснится, что некоторые классы должны долгосрочно хранить данные (это указывается атрибутом persistent). Такие классы - кандидаты на работу с базой данных (опять же - лишь кандидаты, в таких вопросах рубить сплеча не принято; иной раз может оказаться уместнее, например, обычная сериализация объекта в файл). Вот тут-то и появится долгожданная ER-диаграмма, а если понадобится, то и тяжелая артиллерия в виде IDEF1X. Именно тут и ни минутой раньше, если нет желание переделывать по многу раз.

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

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

ro
Offline Offline
Пол: Мужской
меняю стакан шмали на обратный билет с Марса.


« Ответ #9 : 17-11-2004 23:56 » 

эх, Alf....   ненавижу я буржуев, и чем дальше, тем больше начинаю ненавидеть их происки....   лет эдак пять назад припахали меня писать доку (как пользовательскую, так и техническую сопроводиловку для будущих прогов) по собственноручно писанной АСУ-шке (нач. отдела решил перестраховаться на тот случай, если мне вздумается забить на проект и уволиться). неделю я просто протупил перед экраном. хрен его знает, кк чего писать и т.д. а потом полез в инет и нарыл госты 79 года на составление проектной документации к АСУ. и знаешь что? там было 80-90%% того, что ты написал про умл. а гостам этим - 25 лет.

ну как тут не материться, блин...
Записан

Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #10 : 18-11-2004 08:12 » 

Я читал ГОСТы по АСУ - это страшно, куча времени уйдёт на оформление в бумажном виде мелочей, которые по сути можно (и проще) комментариями в коде выразить. UML - не столько стандарт, сколько средство. И модель делается на нём с той степенью подробности, которая нужна для однозначного понимания задачи всей командой разработки (и заказчиком, если он понимает UML). Детальная модель на UML нужна лишь для средств автоматизированной генерации кода (если такими пользуешься).

Я уже где-то в этом форуме говорил: основная сложность в изложении UML та, что практическая его польза видна лишь на нетривиальных или больших системах, а в учебниках и в качестве примера всегда фигурируют простые и тривиальные системы. Отсюда разработчики делают ошибочный вывод о ненужности UML, так как "проще и быстрее" написать сразу код, чем тратить время на рисование. Это опять "идеологическая" составляющая темы, отвечающая на вопрос "зачем оно нам?".
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Alf
Гость
« Ответ #11 : 18-11-2004 08:39 » 

x77, лукавишь  Ага

В бытность мою сотрудником военного НИИ у меня был доступ к библиотеке стандартов и время на работу с ними, так что перечитал я и ЕСПД, и прочие околокомпьютерные стандарты конца 80-х годов...

Во-первых, основное внимание в них уделяется формальностям: какой ширины поля оставлять, как заполнять рамку по ГОСТ и сколько интервалов делать между строками при печати на пишущей машинке. Никакой методической поддержки разработчику эти стандарты не предлагали.

Во-вторых, RUP - это не просто одна из многочисленных технологий программирования. Это технология, базирующаяся на объектно-ориентированном подходе, причем не только на словах. Сомневаюсь, что в стандартах 25-летней давности 90% было ориентировано на поддержку объектной парадигмы.

Кстати, даже 25 лет назад рекомендации ГОСТов уже были безнадежно устаревшими. Например, они на полном серьезе предлагали в качестве документирования алгоритма использовать блок-схемы, причем в их нотациях отсутствовало даже обозначения для цикла, все моделировалось через условный переход по результатам проверки условия. То есть даже программируя структурно, у тебя не было никакой возможности обойтись в документации без GOTO.

Так что приукрасил ты ситуацию, либо маловато поработал со старыми стандартами...
Записан
x77
Команда клуба

ro
Offline Offline
Пол: Мужской
меняю стакан шмали на обратный билет с Марса.


« Ответ #12 : 18-11-2004 09:31 » 

Alf, госты я, конечно, не вычерчивал. просто взял голое оглавление, выкинул всё, что мне показалось ненужным, и забил в эту рыбу то, что надо было мне Улыбаюсь

просто умл мне напомнило про эти грешные госты очень резко. оно также построено по принципу "описание описания", как мне кажется.
Записан

Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines