61

Sparx / Re: UC, UI, Req

« : 06 Июля 2011, 00:38:56 »

Иногда делают как во вложении.

Даже знаю, кто так делает
На страничках EA есть отдельные примеры касательно подобного случая.

62

Sparx / UC, UI, Req

« : 05 Июля 2011, 14:21:10 »

Добрый день.
У меня возник вопрос касательно того, как изобразить связь требований, юз кейсов и скринов на одной диаграмме
Т.е. предположим в ТЗ описаны требования к экранным формам.
Создаю диаграмму требований, GUI диаграмму, UC диаграмму. Набрасываю элементы.
После нужно показать связи. Пойдёт ли для этого дела отдельная Custom Diagram (EA) с дорожками Req, UC, UI и соответствующими связями (Req <- realize UC <- trace UI) ? Или просто декомпозировать Req и вложить UI? Что посоветуете?
Зараннее спасибо.

63

Термины и Определения / [Термин] Диаграмма Вариантов Использования

« : 14 Мая 2011, 16:50:50 »

дви = диаграмма вариантов использования = диаграмма прецедентов

Странный термин Откуда он родился вообще? И почему использования?

64

Примеры / Re: BUSINESS USE CASE MODEL

« : 14 Мая 2011, 12:17:08 »

А что по-русски Вы понимаете под английским термином Business Use-Case Model?

65

Термины и Определения / [Термин] Диаграмма Вариантов Использования

« : 14 Мая 2011, 11:51:47 »

Аналогичный вопрос и по трактовке требования и ВИ (см. приложение)
В чём разница?

66

Термины и Определения / [Термин] Диаграмма Вариантов Использования

« : 14 Мая 2011, 11:51:16 »

Возник вопрос. Вы часто употребляете термин "ДВИ" - диаграмма вариант использования.
Однако, в RUP'е такого понятия нет: есть следующая трактовка (см. приложение).
Мб у меня есть проблемы с англ. языком и я не правильно перевожу термин БП и БФ.
Что же такое ДВИ и БП и в чём, собственно, разница?
Заранее спасибо

67

UML SysML и пр. / Re: Fork/Join&Actors

« : 10 Мая 2011, 03:18:55 »

Ок. Наверняка вам знакомо вот это изображение, вытянутое из одной из статей. На изображении видно, что деятельность соединяется ненаправленной стрелкой с участником процесса. Возможно, это не эталон и всё совершенно не так. Хотелось бы почитать что-нибудь по этому поводу (желательно в оригинале и с соответствующими изображениями), ибо сам SparxEA и его мануал негуст и утверждает, что ролевые свимлэйны - отличное решение. Однако это принимает совершенно невообразимые формы при, опять же, одной роли на активити диаграмме (я имею в виду, когда мы имеем один ролевой свимлэйн). Неплохо было бы получить от вас немного конкретики.

68

UML SysML и пр. / Re: Fork/Join&Actors

« : 07 Мая 2011, 22:04:33 »

Ну, диаграммы деятельности так не рисуют. Акторы с действиями не связывают. Для этого есть свимлайны. Этому масса обоснований.

Да, свимлэйны не поставил:) Конечно, Sparx пишут, что бла-бла и правильно, когда свимлэйны вот такие. Но это жутко выглядит, когда роль одна и всё вперемешку.  

Параллельность не означает,...

Так я и не рассуждаю о сути параллельности. Меня смущают "однорукие" манипуляции одного актёра, стоящего перед параллельными потоками. Этому есть примеры, но нигде нет толкового объяснения.

69

UML SysML и пр. / Fork/Join&Actors

« : 07 Мая 2011, 16:46:37 »

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

70

Для всех / Re: Касательно ГОСТ 34.601-90

« : 06 Мая 2011, 17:49:30 »

Если у Вас Enterprise Architect (судя по рисунку в нотации "Золотухина" он самый) то просто на дереве объектов модели скопируйте диаграмму в буфер -  контекстное меню на диаграмме, пункт Copy Diagramm, а затем в нужном месте дерева моделей по контекстному меню выполняете Paste Diagram.

Это всё, конечно, здорово, но работает-то такой Paste только в другом пакете. А у меня несколько уровней декомпозиции. На последнем и нужно каждый раз кликать свимлэйны и заново их вбивать. На страничке EA в юзергайде что-то есть по этому поводу, но всё упирается в далёкие от меня JS, VB и всё такое Раньше, вроде бы, работала комбинация CTRL+B и свимлэйны копировались.

71

Для всех / Re: Касательно ГОСТ 34.601-90

« : 06 Мая 2011, 16:34:01 »

Возник ещё вопрос, правда немного из другого русла: могу ли я каким-нибудь образом дублировать/копировать swimlane из одной диаграммы в другую? Довольно много уходит времени на бесконечное создание одних и тех же колонок на разных диаграммах.

72

Для всех / Re: Касательно ГОСТ 34.601-90

« : 03 Мая 2011, 16:45:39 »

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

73

Для всех / Re: Касательно ГОСТ 34.601-90

« : 03 Мая 2011, 14:57:33 »

bas,
а что будет, если роль одна? На пересечение чего с чем будем ставить документ?

74

Для всех / Re: Касательно ГОСТ 34.601-90

« : 03 Мая 2011, 13:35:42 »

Золотухина рулит (

Е.Б. Золотухину узнают по Интерпрайзу?

И еще вопрос - А почему роль - это ответственный за формирование требований а АС?

Нет, роли чуть позже.

В общем, стало понятнее, наверное Буду тогда действительно вводить инфу по объекту, а выводить отчёт с соответствующим стэйтом.

75

Для всех / Re: Касательно ГОСТ 34.601-90

« : 03 Мая 2011, 02:30:20 »

Это-то понятно. Другое дело, что желательно бы детально порасписывать

Эскизно содержание этапа 1 (Обследование объекта и обоснование необходимости создания АС) по ГОСТу (3-й уровень) представлено на скрине в приложении. Прошу сильно не бить, если чего там не туда

Я так понимаю, что в реальной жизни происходит так: проходит процесс анкетирования/интервьюирования и т.д. посредством соответсвенно анкет и т.п. А может и не так. И вот не понятно, когда же в отчёт всё пакуют, т.е. после каждого действия я вставляю на диаграмму отчёт (см. рисунок), но уже с другим статусом или нет?

Или же просто формально обзывать объекты каким-нибудь, например, набором данных об объекте автоматизации да и всё???