В теме 21 ответ, и 7 участников, последнее обновление сделано пользователем 
Герман Шестеров 14 г, 5 мес. назад.
-
Сообщения
-
Уважаемая Belle Morte, не сочтите, пожалуйста, мой вопрос за невежливость или за нелояльность, просто очень захотелось узнать, к какому конкретно положению или фразе из классиков-родоначальников визуального моделирования, языка UML и его стандарта, а также и унифицированного процесса разработки (Г.Буч, Д. Рамбо, А.Якобсон, Ф.Кратчен) у Вас возникло критическое отношение и Вы засомневались в его правомерности? Где и в каком источнике Вы нашли это положение, дайте, пожалуйста, ссылку.
Уважаемый nousy123!
Вот просто интересно: когда вы писали свой вопрос, каким вы представляли мой ответ? Нет такой фразы, которую я могла бы сходу вам процитировать, предоставив в качестве примера.
Когда я писала свой пост, у меня перед глазами не было конкретного стандарта и, разумеется, я не имела в виду какое-то конкретное положение из "классиков-родоначальников визуального моделирования". Я всего лишь описывала общий подход к приобретению знаний и неважно, кто их источник — Гради Буч или Википедия.
Когда изучаешь практически любую литературу, по мере прочтения встречаются моменты, на одни из которых киваешь и думаешь "да-да, точно так оно и есть", на другие — "наверное я пока слишком плохо в этом разбираюсь, придется поверить", на третьи — "мда? а у меня другое мнение". Я не выписываю эти цитаты на бумажку, не делаю заметки на полях и не сохраняю ссылки на источники, потому что… а зачем?Когда я писала свой пост, у меня перед глазами не было конкретного стандарта и, разумеется, я не имела в виду какое-то конкретное положение из "классиков-родоначальников визуального моделирования". Я всего лишь описывала общий подход к приобретению знаний и неважно, кто их источник — Гради Буч или Википедия.
Когда изучаешь практически любую литературу, по мере прочтения встречаются моменты, на одни из которых киваешь и думаешь "да-да, точно так оно и есть", на другие — "наверное я пока слишком плохо в этом разбираюсь, придется поверить", на третьи — "мда? а у меня другое мнение".Вот, вот — именно этого ответа я от Вас и ожидал!!!
Я вначале моего курса всегда говорю своим слушателям (замечу, что у меня не студенты мальчишки и девчонки, а уже зрелые состоявшиеся люди, у которых уже есть одно высшее образование, а они второе получают, или на повышении квалификации, и на программерских фирмах я иногда тренинговые курсы для аналитиков провожу, на Эпаме, например, для пары групп проводил, АсконБел…) — читайте классику, именно они, и сам язык визуального моделирования разрабатывали, и все стереотипы, входящие в стандарт, и парадигму объектно-ориентированного подхода изложили, и процесс разработки программных продуктов, и инструметарий для него, и обязанности участников процесса, и какая диаграмма для чего и как их правильно строить написали, и все это в с точки зрения системного подхода к проекту. Это очень важно и об этом забывают остальные. Только у классиков-разработчиков метода визуального моделирования очень стройная система, которую легко оптимизировать под любой проект, любую предметную область и под любую команду. Все остальное — либо не очень удачный пересказ, или другое толкование их идей, часто искажение смысла и т.д. Я читаю много литературы, сейчас, например, буду переводить и готовить к изданию базовый курс по Requirements Engineering немецких авторов Chris Rupp и проф. Klaus Phol, но поверьте, к их методикам я тоже отношусь критически, потому, что нельзя рассматривать Requirements Engineering оторванно, а только в комплексе с другими категориями анализа. Так, что источник важен, а идеи классиков, если их внимательно читать и понимать о чем они говорят, не подвергаются сомнению, потому, что их правота очевидна.Так, что источник важен, а идеи классиков, если их внимательно читать и понимать о чем они говорят, не подвергаются сомнению, потому, что их правота очевидна.
А с какой радости их правота очевидна? Для меня вот очевидна моя личная правота, которая определяется моим собственным видением, что лучше, а что хуже. И я доверяю в некоторых моментах, связанных с ООП и UML (конкретно с аспектами их применения в той или иной ситуации) себе больше, чем им. И хоть убейте, но не заставите меня считать себя из-за этого ущербным.
Вот если я задамся вопросом, каково реальное значение, а точнее задумка той или иной концепции, то кроме них никто лучше не ответит ибо они это и придумали. Но вот насчет применимости этого всего дела на практике — слишком многое со временем меняется и слишком много других не менее блестящих умов поставили под сомнения этих абсолютных классиков, чтобы считать все сказанное ими истиной в последней инстанции. Возможно я так рассуждаю, потому что не обучал зрелых людей со вторым высшим и не проводил тренинг для Епама.А с какой радости их правота очевидна?
Потому, что все это проверено и подтверждено практикой.
И я доверяю в некоторых моментах, связанных с ООП и UML (конкретно с аспектами их применения в той или иной ситуации) себе больше, чем им.
Ну, наверное, Вы лучше их разбираетесь и в UML, и в ООП, и в процессах разработки ПО? И практики у Вас тоже больше, чем у них? Поэтому для улучшения восприятия тех же Use Case-диаграмм Вы туда все, что Вам нравится вносите, нарушая стандартную нотацию, хотя это все показывается элементарным образом и строго в стандарте UML. Давайте тогда каждый будет все со своей колокольни трактовать и рисовать как заблагорассудится, зато ущербными себя чувствовать не будем.
Потому, что все это проверено и подтверждено практикой.
Ну вот главная мысль, которуя я хочу донести (и судя по всему Belle Morte тоже), это то, что пока это не подтверждено собственной практикой, их истина будет ставится под сомнение. Поверьте, я не хотел постом выше выразить, что именно я знаток и гуру UML и ООП. Можно считать, что я разговаривал от некоего обобщенного лица, которое подвергает информацию критике, а не берет на веру.
Ну, наверное, Вы лучше их разбираетесь и в UML, и в ООП, и в процессах разработки ПО? И практики у Вас тоже больше, чем у них?
Разбираюсь хуже, очевидно. Практики? Ну, скажем так, она у меня своя, у них своя. И я сам буду искать то, как мне доносить инфу до заказчика и до команды. Конечно, я возьму их теорию за основу. Но я не буду стесняться менять ее в тех местах, где она мне не нравится.
Неужели вы просто берете ВСЮ их теорию на веру и даже не задумываетесь на тем, а полезно ли это, может ли быть лучше и что можно было бы изменить???И еще — сдалась вам эта моя юз кейс модель… Вы мне ее теперь в каждом посте будете в упрек ставить (это третий уже, кстати). Я еще раз повторю, что я признаю ее неправильность, о чем явно и выразил. Но: в своих аспектах применимости и в конкретно моей ситуации она подходит мне, как нельзя лучше. И ни вы, ни кто-либо другой в жизни меня не убедите, что я неправ. Вы моделируете четко корректно; я же позволяю себе отходить иногда от правил, но при этом признаю, что от них отхожу. Я Так что я так и не понял, кому вы хотели донести, что у меня неправильная диаграмма. Другим? Ну услышали уже все и свои выводы сделали. Да, я буду рисовать диаграммы со своей колокольни — и что их этого следует? Убедите меня в том, что я плохой аналитик
.Так, товарищи, сдается мне, мы отдалились от темы.И еще один вопрос (Ася, извини за оффтоп, но уж больно стройно идет логическая цепь дискуссии… я больше так не буду
)
Вы упомянули, что то, что я хотел изобразить, "показывается элементарным образом".
Не могли бы показать, как? Только не сочтите за подковырку или еще что-нибудь — я действительно не знаю четкого ответа, как это сделать. В UML вы хорошо разбираетесь, и мне будет интересно услышать ваше мнение. Я уже задавал этот вопрос в соответствующей группе в LinkedIn, но так и не получил внятного и удобного для использования ответа.
Исходные требования:
Нужно с рациональными эффортами отобразить варианты использования системы и последовательность их выполнения с точки зрения интерфейса. В моем варианте (его можно глянуть тут) рациональность достигается использованием только одной диаграммы (ну то есть можно было, конечно, построить диаграмму последовательностей или активностей, как дополнение, но это все же еще один рисунок). Я знаю, что есть вариант (если не ошибаюсь, расширение стандарта UML) использовать связь precedes, которая добавляет динамики в юз кейс модель. Что бы вы посоветовали?
Чтобы тут не флудить, предлагаю ответить в той теме, где изображена сама модель.
Вы должны авторизироваться для ответа в этой теме.
