3451
UML SysML и пр. / Re: Плюсы и минусы диаграмм вариантов использования
« : 09 Мая 2009, 19:49:31 »Он Ивар, швед.Ага ты прав, просто я что-то не обратил внимание когда сдирал библиографии книги

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
Он Ивар, швед.Ага ты прав, просто я что-то не обратил внимание когда сдирал библиографии книги
Конечно я ен совсем понимаю, скорее я совсем не понимаюМне в этом оношени нравится диаграма деятельности в UML, она в прочем сильно похожа не IDEF3 сценраий.![]()
Хотелось отобразить в функциональной модели работу бух отдела, дабы выявить необходимые для автоматизации участки, и хотелось выявить функциональную разницу между двумя ИС внедряемой и существующей.
1.
Цели
1. Описать на процессом уровне происходящее в бухгалтерии, для выявления участков либо ручной, либо часто повторяющейся и мало автоматизированной деятельности.IMHO, для этого лучше подходят другие нотации ARIS, BPMN к примеру
2. Выявить различие между текущей БД и внедряемой БД
Да в том правильно ли я "думаю", и не бью ли гвозди микроскопом, или может нужен совершенно иной "подход", скажем создание отдельной модели в IDEF0 для процессов, и отдельной для выполняемых действий в IDEF3. интересует мнение людей решавших поставленные мною в топике цели, и их подходы к решению.Цель то какова? Непременно нарисовать диаграммы? Или получить понимание проблемы?
А вообще любой инструмент окажется бесполезным в руках того, кто не умеет им пользоваться. ДВИ ничем не хуже и не лучше любого другого в этом отношении.Ida, простите, но это демагогия. Для того чтобы научиться пользоваться инструментом, нужно точно понимать его назначение и правила его применения. Мне кажется, как раз это мы и пытаемся выяснить, поскольку на форуме существуют две диаметральные точки зрения КОНКРЕТНО на ДВИ.
Each use case specifies some behavior, possibly including variants, that the subject can perform in collaboration with one or more actors...The subject of a use case could be a physical system or any other element that may have behavior, such as a component, subsystem, or class. ...Английский язык велик и могуч. И не всегда можно его понять буквально.
Use cases can be used both for specification of the (external) requirements on a subject and for the specification of the
functionality offered by a subject. Moreover, the use cases also state the requirements the specified subject poses on its environment by defining how they should interact with the subject so that it will be able to perform its services.
Поведение субъекта ВИ устанавливает требования, которые субъект накладывает на окружающую среду через определение взаимодействия среды с субъектом. Т.е. спецификация как раз определяет назначение ВИ для описание взаимодействия. ДВИ описывает множество взаимодействий, задаваемых ВИ.
Уфф. Прочитал мнения участников дискуссии...Типа, чем бы дитятки не тешились?
* П.ч. нельзя\сложно показать иерархию ролей, участие одной роли в нескольких задачах, и ВИ, как мы помним, - это цель Пользователя и не совсем задача или функция Системы.Демонстрация иерархии ролей может быть выполнена и без реализации диаграммы вариантов использования.
* Тебе сценарий написал СергейНаписал, однако участие ДВИ здесь может быть минимальным.
* Например, мы формируем сценарий из 5-9 шагов, а потом каждый Системный шаг детализируем уже с помощью ФТНапоминаю что мы обсуждаем диаграмму использования, а не целесообразность использования ВИ. О ней никто не дискутирует. Твоя фраза совершенно не в тему.
* Да можно, все можно. Можно сюда заместо одной идеологии ВИ вкрутить и Таблицы и Списки и Ментальные Карты и Контекстные Диаграммы и CRC и т.д. просто ВИ - это комплексный продуманный подход по выявлению, анализу и документированию ПТ.смотри выше. ВИ может и подход, но причем тут диаграмма?
* Выделение ВИ и выявление Требований немного разные вещиВИ - это функциональные ТРЕБОВАНИЯ. Нельзя говорить противопоставлять одно другому. Форма записи не означает различия смысла!
* Если нормально нарисовать и объяснить, то сложностей мало, если этого не делать, то ДВИ бесполезнаЕще раз спрошу. Можно ли постулировать такое утверждение.
* Если грамотно использовать, то это +, если нет, то это -Что такое грамотно использовать. Приведи примеры грамотного использования.
Кто не понял, что я написал? Задайте конкретные вопросы.Денис ты написал все очень корректно. Но на мой взгляд ты говоришь примерно так: Очем тут разговор - ДИ полезна - это аксиома, доказательства не требует. Тем неменее ты приводишь, где будет полезна ДИ. Это хорошо. Но хотелось бы наглядных примеров в пользу твоей точки зрения.
В качестве примера - ЛЮБАЯ ГРАМОТНО составленная ДИ.
ДВИ полезны для выявления назначения системы в диалоге с Заказчиком/Пользователем.Вот точка зрения Дениса. Полезна не сама ДИ, а процесс получения некой диаграммы в ходе взаимодействия З/П. При этом неважно будет ли это ДИ, или нечто иное.
Как понятно из его рассказа, это целиком и полностью зависит от умения аналитика вести эту работу в качестве Коммуникатора.
Рисует он там овальнички или прямоугольнички — Заказчику всё равно. Рисует он там мужиков с яйцами или мордочки-смайлики — всё равно.
Аналогичным образом я могу составить рассказ о том, как в взаимодействии с Заказчиком получить на доске Список ролей (например, с помощью Контекстной диаграммы), а потом пройдясь по каждой роли, получить Список задач, которые будут решать эти роли с помощью системы (Проходом по сценарию деятельности этой Роли вообще, в бизнесе, а не в системе).
ЛЮБАЯ ГРАМОТНО составленная ДИ.Что значает тогда грамотная?
многочисленные примеры в форуме показывают, что ДИ рисуется в отрыве от З/П, и когда последний получает готовый результат, он не понимает её пользу.Принимаем ли мы факт, что ДИ полезна только ходе взаимодействия З/П? А сама по себе даже с комментариями лишняя?
+ ДВИ:* а почему ты полагаешь, что таблица Участник/Задача не отвечает той же цели? А что делать, если система слишком велика, чтобы продемонстрировать ее функционал для охвата одним взглядом. ДВИ не подлежит декомпозиции
* Охватить одним взглядом функционал Системы, Пользовательские Требования
* Хорош при выявлении Требований
* Служит каркасом для дальнейшей детализации Требований и Архитектуры
* Служит для формирования первоначального набора Тестов, Ролей и Пользовательской Документации
- ДВИ:* нет ли противоречия этого пункта с * Хорош при выявлении Требований
* Сложность выявления ВИ и рисования ДВИ
* Сложность понимания
* Не применимость для ряда задач - Интеграционные решения, Один Пользователь и т.д.
* Много взглядов (вариантов) на одну и ту же ДВИ
Эдуард, как обычноЭх.... ничто не скроется от опытного взгляда, умудренного опытом Лодочникавыступает с провокационными предложениями в поисках бури
Можно сказать: "Над седой равниной моря гордо реет..."
Ну вы блин даете.Денис, никто не выплескивает. Аргументы прошу давать не абстрактные, а точно конкретные.
Надо просто учиться и учить других. Вот и все. А то что кто-то там (ссылка Эдуарда) вообще не понимает что рисует ... так идиотов хватает.
Давайте на эмоциях-то ребенка не выплескивать.