Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - lnew

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 »
1
Sparx / Re: Re: FAQ - Sparx Enterprise Architect
« : 30 Марта 2017, 15:20:20 »
Здравствуйте!

Вы можете написать мне
- в почту - lnew@yandex.ru
- на скайп - Leonid.Novikov2

Если смогу - помогу.

2
С Новым годом, flekder!

Напишите мне lnew@yandex.ru. Может быть, помогу.
Предварительно можно посмотреть http://lnew.ucoz.ru.

3
Да, не позавидуешь!

Предполагаю, что Вы неправильно поняли задачу. Состояние в принципе может относится только к одному объекту.

Другое дело, что полная система, как объект, может иметь собственные состояния, которые определяют, что система может делать в каждом состоянии. Может быть, это имелось ввиду?

Рисовать на одной диаграмме состояний множество объектов - элементов системы - нонсенс.

4
UML SysML и пр. / Re: Нюансы разработки модели UC
« : 13 Сентября 2012, 15:03:32 »
Из моего опыта, заказ имеет состояния, например, "зарегистрирован", "принят", "назначен" и т.д.
Номенклатура параметров, которые можно редактировать, зависит не только от эктора, но и от состояния.

Я стараюсь делать более простые UC, чтобы я мог указать все предусловия, а не рассыпать условия в тексте или на диаграмме деятельности!

5
UML SysML и пр. / Re: Нюансы разработки модели UC
« : 13 Сентября 2012, 14:56:18 »
На диаграммах полезно делать примечания.

6
UML SysML и пр. / Re: Нюансы разработки модели UC
« : 13 Сентября 2012, 14:32:03 »
Вот смотрите ребята, реальный пример
Собственно тут возникает следующая сложность:
В системе 4 эктора. Есть UC которые выполняют только определенные экторы, скажем
"Разморозить заказ" может Заказчик и Администратор.
"Заморозить заказ" может Заказчик и Исполнитель
"Отменить заказ" может Администратор и Исполнитель
"Передать заказ другому исполнителю" может Администратор, Заказчик, Исполнитель
"Просмотреть заказ "/"Посмотреть список заказов" может Интересант, Исполнитель, Администратор, Заказчик
и так далее..

Но, по крайней мере, здесь все равно пять UC!

7
UML SysML и пр. / Re: Нюансы разработки модели UC
« : 13 Сентября 2012, 14:28:50 »
Великий Коберн и некоторые другие считают, что UC может иметь только одного первичного эктора.
Если не нравятся "виртуальные" экторы, назначьте этора "Пользователь" (обычно, предок всех остальных) и права доступа опишите в предусловиях.

8
UML SysML и пр. / Re: Нюансы разработки модели UC
« : 13 Сентября 2012, 13:26:34 »
Здравствуйте.

Насколько я помню (читал в одной из статей блога Александра Шамрай, потом сделал краткую выжимку: http://it-analysis.blogspot.com/2011/03/blog-post_24.html), операции с данными (СЧОУ -- создание, чтение, обновление, удаление -- сюда можно и отнести редактирование) не рекомендуется выносить в виде отдельных UC.

Я бы порекомендовал выделять в виде UC только действительно важные цели пользователя, которые принесут ему ощутимую пользу. Все остальное опишите в виде текстовых требований, привязанных к конкретному варианту использования.

Насколько я понял из примера (уточнения adelante не изменили моего мнения), речь идет не о типовой ситуации СЧОУ. Фактически, каждый эктор имеет свою цель  (и свои права!).

Но спор здесь не продуктивен. adelante просит варианты. Все предложенные варианты правильные. Я предложил тот, которым пользуюсь (как правило, но не всегда).

9
UML SysML и пр. / Re: Нюансы разработки модели UC
« : 13 Сентября 2012, 11:51:21 »
Добрый день!

Я где-то вычитал, что "хороший UC - это простой UC".

При рассмотрении Вашего примера мне показалось, что Вы в плену слова "редактирование". На самом деле, экторы в вашем примере имеют разные цели: "создать заказ", "детализировать информацию заказа", "назначить заказ исполнителю", "создать проект выполнения заказа", "закрыть заказ" и т.п. Различные цели - различные (достаточно простые) UC.
Конечно, эти UC имеют одинаковые фрагменты, например, "выбор заказа". Выделите его в UCI, и никакого дублирования не будет!

Дополнительно:
Название "Редактировать заказ исполнителем", мне кажется, неудачное:
1) Вы указываете эктора в названии UC (дублируете информацию диаграммы, на которой, наверное, Вы нарисуете этого эктора).
2) Слово "Редактировать" в названии UC какое-то аморфное; оно мало что говорит о действительной цели.

10
Правильно!

Если знаешь, для чего и что сказать, и есть дизайнерские навыки, инструмент может помочь. А если нет, то отказ от РР делу не поможет!
И первоисточник (Лебедев) я воспринял именно в этом смысле: нельзя абсолютизировать инструмент.

Не РР плохой! Докладчики пустые или неумелые!

11
Sparx / Re: FAQ - Sparx Enterprise Architect
« : 22 Апреля 2012, 18:48:03 »
Эдуард!
Большое спасибо!
Ты поддержал во мне веру в себя!
Действительно, в 9.3 мое решение работает корректно!

12
Sparx / Re: FAQ - Sparx Enterprise Architect
« : 22 Апреля 2012, 12:26:17 »
Вполне рабочий проект.
Увидеть можно, наверное, только в модели целиком. И выложить ее на форум просто нельзя!

Могу прислать текущее состояние модельного файла ЕА по указанному адресу (на условиях конфиденциальности).

Пришли адрес.

13
Sparx / Re: FAQ - Sparx Enterprise Architect
« : 21 Апреля 2012, 23:45:44 »
Постановка задачи:
1. Необходимо составить и поддерживать в актуальном состоянии проектный глоссарий.
2. Все понятия, используемые в проекте, представлены в модели как модельные элементы (или могут быть представлены)
3. ЕА позволяет вводить термины (вручную) и печатать глоссарий. Но эти термины не синхронизированы с соответствующими модельными элементами.
4. Необходимо реализовать способ формировать глоссарий из модели средствами ЕА.

В RSA я такую технологию реализовал и использовал. Очень удобно.

При воплощении в ЕА столкнулся с такой трудностью (остальные, о которых писал, "обойдены"):
- шаблон (см. рис. 01) перебирает дерево модели (пакеты и элементы) и печатает имена и описания обрабатываемых объектов. Фильтр отсеивает объекты, не имеющие признака термина глоссария, и сортирует результат по лексикографии.

Ошибка (скорее всего, моя) состоит в том, что в модели многие элементы встречаются многократно (один раз находит элемент и много раз - ссылки на него). Редактор отчетов обрабатывает их одинаково и все помещает в отчет (см. Глоссарий.doc).

Можно после генерации отчета удалить лишние разделы вручную, тем более, повторяющиеся разделы печатаются подряд.
Но это не то, о чем мечтали большевики. Должна же где-то быть какая-то опция, которую я не заметил!!!

14
Sparx / Re: FAQ - Sparx Enterprise Architect
« : 21 Апреля 2012, 18:30:34 »
Результаты исследования таковы:

Складывается впечатление, что применение множества стереотипов к одному элементу в ЕА реализовано не очень корректно. Применить то можно, но в поиске, отображемых картинках и т.д. можно использовать только первый!??

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

Если считать, что я просто не нашел какую-то опцию, отменяющую повторение, или делал чт-то не так (а это самое разумное объяснение. Не дураки же ЕА делали, хороший инструмент), то второй испробованный метод (без стереотипа) экономичнее.

Во вложении один из примененных шаблонов, окна, показывающие опции и результат тестирования.

Специалисты! Будьте добры, посмотрите, что я сделал не так!
Моя благодарность будет безгранична (в пределах разумного).

15
Sparx / Re: FAQ - Sparx Enterprise Architect
« : 21 Апреля 2012, 11:35:27 »
Спасибо. Я еще сегодня поэкспериментирую.
Со множеством стереотипов для элемента вроде разобрался:
  • В поле Sereotype всегда виден только один, который ввели первым. И значок соответствующий.
  • При вводе другого стереотипа через запятую, этот другой стереотип применяется, но после OK его не видно
  • Устанавливать множество стереотипов и увидеть все примененные стереотипы можно, если нажать (...) и поставить (увидеть) галочки в списках доступных профилей
Сейчас продолжу изыскания.

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 »