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

×


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

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


Сообщения - lnew

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 »
122
Я тоже живу в Питере.

Генерацию php базовый RSA не поддерживает. Плагины 3-их лиц мне неизвестны, хотя могут быть.

123
UML один, а инструменты разные.

Как я делаю:
- диаграммы деятельности рисую как альтернативу "ручному" текстовому описанию UC или BUC (например, по Коберну). Соответственно, под каждым UC или BUC (в том числе абстрактными: IUC и EUC) создаю activity, под которой - диаграмму деятельности. (я написал шаблончик отчета, который генерит красивое текстовое описание процесса по диаграмме).
- RSA, в котором я работаю, позволяет перетаскивать любую activity на поле диаграммы деятельности как "детализированное" действие (в RSA - call bechavior; думаю, в других инструментах должно быть что-то подобное, если они поддерживают стандарт преобразования форматов UML2).
- если описывается сложный UC, не использующий IUC и/или EUC, некоторые действия которого нужно (полезно) детализировать, я создаю новую activity в пространстве основной activity и перетаскиваю ее на поле основной диаграммы.
- если основной UC использует абстрактные UC (это показывается на диаграмме UC), то я также перетаскиваю их activity на поле основной диаграммы в нужное место.

Мой шаблончик отчета (Спецификация UC) разбирает каждый элемент диаграммы, и если это детализированное действие, помещает в раздел описания действия соответствующую поддиаграмму.

Думаю, в вашем инструменте можно делать что-то похожее. Нужно только поискать.

Если этот вопрос Вас интересует, и Вы в Москве, то сообщаю, что с 27 июня по 1-е июля я буду в Москве в УКЦ компании Интерфейс (ул. Бардина) читать курс. Вы можете приехать, и я покажу все эти приемы "вживую". Думаю, много времени это не займет.   

124
Любая диаграмма должна быть простой и понятной.

Если Вы решили часть деятельности выделить в поддиаграмму, ее обычно рисуют отдельно. Для этого вместо обычного действия (opaque action) на основную диаграмму устанавливают элемент структурного действия (например call bechavior action), который представляет поддеятельность.

Далее варианты:
- соответствующая "поддеятельность" с собственной диаграммой создается "под" основной деятельностью (если это просто детализация сложного процесса)
- в качестве детализации основной диаграммы используется деятельность абстрактного UC (расширения или включения).

В зависимости от инструмента. Например, в RSA на нужное место основной диаграммы перетаскивается мышкой нужная деятельность. На диаграмме создается call bechavior action. Двойной щелчок по значку открывает детализирующую диаграмму.

Рисование в виде поддиаграммы, показанной на основной диаграмме (как на рисунке) вообще не имеет смысла.

Условная компиляция показывается как любое другое условное поведение с использованием decision. 

125
Обсуждение статей / Re: Совещание
« : 12 Июня 2011, 16:38:34 »
Улыбнулись? С Праздником!
Троицы, надеюсь?

126
Наверное.

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

Конечно, нужно отслеживать новое. Но не бросаться "вступать", если другие "вступают". Можно промахнуться, и "вступить" не туда!

127
От себя про "серебрянные пули".
По мне, так они существуют. Более того их много.
Проблема в том, что либо оружие не то выбирают, либо стреляют не в ту сторону.
По закону сохранения, "если где-то прибыло, в другом месте убыло".
Чтобы сделать хороший продукт, нужна хорошая (адекватная) технология.
Чем сложнее продукт и/или выше требуемое качество, тем сложнее производство (технология).

Много технологий хороших и разных. И инструментов.
Но некоторые люди (и аналитики, как ни странно) не ищут и изучают адекватную технологию, а читают рекламу.

Денис! Пуль много, но "серебряной" (на все случаи жизни) я не знаю!

128
А почему "наболело"? Вы уже сталкивались с данной сертификацией? Если все так мрачно, то почему Украина плодит отделения IIBA?
Наболели метания из крайности в крайность.
"По какой методике можно все классно получить будучи не шибко грамотным ...?!"
Я оставляю за скобками истину, что "справедливее всего на Земле распределен ум: никто не жалуется на его недостаток"!

129
Ребята!

А не кажется ли вам, что это очередная "серебряная пуля"?

Кинулись на UML. Оказалось, успешное применение требует использование мозга! Само ничего не делается!

RUP. Все описано по шагам. Два недостатка:
- социальный (главный): саботаж (кто постарше - помнит, как сопротивлялись "автоматизации" работники бухгалтерий; а чем работники IT отличаются?)
- опять же: думать надо, описанные шаги к ситуации приспосабливать.

Архитектурные фреймворки: интерес пропал, не успев расцвести!

Классно, конечно, получить скидку $100! Как и купить шампунь от перхоти "по привлекательной цене".

Согласен, красивая иностранная бумажка может, иногда, помочь устроится на работу. Но ума уж точно не прибавит.

Извините за грубость. Наболело!

130
UML SysML и пр. / Re: Fork/Join&Actors
« : 07 Мая 2011, 23:43:20 »
Мне непонятны Ваши сомнения.

Основное назначение диаграммы деятельности - графическое описание UC.
Т.е. существует некая диаграмма UC, на ней нарисован UC с одним actor-ом. Тогда на диаграмме деятельности д.б. нарисовано 2 свимлайна: один представляет actor-а, а второй - систему.

Если Вы не хотите показывать, кто что делает, свимлайны можно не рисовать.

И система, и актор могут выполнять параллельные нити. Нить, выходящая из Fork, не обязательно должны заканчиваться в join.
 
Какие еще нужны объяснения?
Не перепечатывать же здесь тексты из книжек по UML.


А вот то, что Вы нарисовали астора и связали его с действиями - это, действительно, вызывает сомнение, мягко говоря!

131
UML SysML и пр. / Re: Fork/Join&Actors
« : 07 Мая 2011, 18:18:53 »
Ну, диаграммы деятельности так не рисуют. Акторы с действиями не связывают. Для этого есть свимлайны. Этому масса обоснований.

А что касается вопроса, то вот пример: завскладом формирует заказ. Одной рукой товары в ящик кладет, а другой - накладную заполняет.

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

132
Многие инструментальные средства UML могут использовать профиль UML Analysis. В модели анализа к классу можно присоединять стереотипы Entity, Controller и Boundary. Последний стереотип (Граничный класс) и представляет интерфейс.

Статическая диаграмма - это диаграмма граничных классов. Между классами устанавливаются отношения агрегации или композиции (чаще используют композицию, т.к. экземпляр граничного класса существует только во время выполнения).

Ну, а динамическое поведение моделируется, как и написал bas, с помощью диаграмм последовательности. Правда, я не рисую взаимодействие только граничных классов. Обычно, на диаграмме последовательности присутствуют объекты всех трех типов: граничный класс, контроллер, который обрабатывает управления граничных классов, и сущности, которые "работают" с информацией.

Но, если у Вас ограниченная задача проектирования интерфейса, а не функционирующего ПО, м.б., хватит и граничных классов.


134
Я выражаю все функциональные требования через UC.

А по количеству как скажешь? Где то много, где мало. Ну, в системе управления ремонтом для АЭС Tihange где-то, наверное, до 50 (основных) доходило (список на две с половиной страницы елочкой, почти три года проект был).
 
И детализация разная. От краткого описания до storyboard (с диаграммами граничных классов), в зависимости от сложности.

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

135
А кто говорит, что одних только функциональных требований достаточно.
Классификация требований FURS+. Но "F" здесь то, ради чего, собственно, делается система (молоток).

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