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

×


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

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


Сообщения - lnew

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 »
16
Sparx / Re: FAQ - Sparx Enterprise Architect
« : 20 Апреля 2012, 22:34:24 »
Добрый день!
Нужно сделать глоссарий проекта.
Термином может быть название или алиас любого модельного элемента. Определение термина - описание этого элемента.
Отчет должен печатать названия и описания элементов, помеченных как термины.

Испробовал два варианта.
  • Создал стереотип term с атрибутом domen (значения "Бизнес" и "Моделирование").
    Странно! Назначение элементу этого стереотипа отменяет уже установленный стереотип. В справке описан способ вводить нужные стереотипы вручную, через запятую. Тоже ничего не вышло. Временно бросил эту затею.
  • Для выбранных элементов определил помеченные значения term и value (название домена из предыдущего способа). "Нарисовал" два простейших шаблона с фильтрами по домену.
    Все хорошо, прекрасная маркиза! Один и тот же элемент печатается многократно. У меня сложилось впечатление, что столько раз, сколько упоминание об этом элементе встречается в дереве модели (например, на диаграммах)

Может быть кто-то с таким встречался? Помогите, ради бога!

Спасибо.

17
Мне кажется, это зависит от цели моделирования.

Если это уровень анализа, то, скорее всего, id за рамками модели: проектировщик разберется. Если это проектная модель, то вопрос, нужно ли выделять id как атрибут, зависит от принятой технологии (м.б., framework).

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

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

Если Вы студент, разъясните преподавателю, почему Вы приняли то или другое решениею

18
Добрый день!

Что-то все по-новому. Давно не был.

По поводу диаграммы UC.

Если читать книжку Коберна "за смысл", можно заметить, что он выделяет <<primary>> Actors.
Т.е., даже, если c UC взаимодействуют множество Actors, есть только один, цель которого выполняет UC. Actor не должность, а роль!

С другой стороны, любая диаграмма предназначена не для того, чтобы показать все, что мы знаем о той или иной предметной области, а для того, чтобы проиллюстрировать какую-то идею, мысль, явление. Эргономисты считают, что если на диаграмме более 9 сущностей, она нечитаема, а значит рисовать ее нет смысла.

Как я поступаю для разрешения сложности.
Рисую диаграмму, содержащую основные UC и их первичных Actors. Это то, для чего нужна система (хотелось написать "функции системы", но меня Юра в очередной раз "прихватит").
Рисую контекстную диаграмму, если требуется, для UCs. Она содержит всех Actors, а также Extend и Includ UCs.

Но это примерно то, о чем писал Эдуард.

Честно говоря, я представленную диаграмму даже читать не стал. Тем более, у меня с языками проблема. Знаю всего три: командный, матерный и русский (со словарем).

P.S. Я, наконец, нашел работу!

19
Sparx / Re: FAQ - Sparx Enterprise Architect
« : 21 Января 2012, 23:33:11 »
Предыдущие вопросы Bas вроде закрыты!?

Я хотел бы посоветоваться вот по какому вопросу:

На своем сайте сайте http://lnew.ucoz.ru я выложил несколько статей под общим заголовком "Повышение производительности аналитика".

К сожалению, этот цикл (по числу отзывов) не вызвал большой заинтересованности участников форума. Одна из причин - "заточенность" приведенных примеров на Rational Software Arhitect.

Мне захотелось показать, что идеи, заложенные в цикле статей, применимы к деятельности анализа (в разработке ПО) для других инструментов моделирования UML.

Может быть, я ошибаюсь, но мне показалось, что наиболее распространенным инструментом моделирования UML сегодня является EA.

Я попробовал применить приемы, описанные в цикле "Повышение производительности аналитика", на EA.

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

Мои выводы:
- стандартная конфигурация EA, даже с надстройками (Add-ins), это инструмент (для аналитиков) с весьма ограниченными возможностями. (Думаю, все понимают, что возможность рисования и возможность осмысления и документирования идей - это разные вещи)
- EA имеет огромные возможности расширения, о которых некогда задумываться в процессе выполнения "линейного" проекта (эти возможности или есть, и они описаны, или их нет).

Оказалось (практически проверено!), что:
- EA позволяет без особых трудозатрат создавать произвольные шаблоны отчетов моделей UML
- Отчеты могут быть представлены в форматах MS Word и MS Project (!)
- Последнее наталкивает на мысль об интегрированном моделировании разработки, включающем моделирование (и управление) как продукта (традиционный подход), так и процесса (то, что называют "моделированием (архитектуры) предприятия")
- Я , в частности, реализовал некоторые элементы профиля UPIA

Вопрос в следующем:
- А это кому нибудь надо?

Если надо, есть два пути:
- присоединяйтесь
- заявите о заинтересованности

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

Что скажете?
 

21
Собирательное, и, тем не менее, они разные и используются для разного.
Именно поэтому в данном случае я стал бы рисовать последовательность.
Уважаемый Галоген дал Вам правильный совет: нарисуйте сами так, чтобы Вам самому было понятно. Обсудим.
А рисовать за Вас "поди туда, не знаю куда; принеси то, не знаю что ...", скорее всего, никто не станет.

22
А правильно ли применять дорожки для отражения распределения работы по объектам-частям программы, или технического устройства?

Можно, конечно. Почему нельзя? (Тогда дорожки - устройства (классы), а действия - операции.)
Только нужно ли?
В такой ситуации гораздо лучше диаграммы последовательности.

23
Sparx / Re: FAQ - Sparx Enterprise Architect
« : 09 Декабря 2011, 14:10:04 »
Спасибо, достучался.

24
Sparx / Re: FAQ - Sparx Enterprise Architect
« : 09 Декабря 2011, 02:59:16 »
Дорогие друзья!

Опять вопрос об экземплярах классов и о переменных Run-time State.

Galogen рассказал как устанавливать значения этим переменным:

Ура! Я вспомнил

Правила работы:
1. Создать диаграмму объектов или не создавать:)
2. Переместить на диаграмму нужный классификатор (класс) из барузера проектов на диаграмму как инстанс
3. Правой кнопкой мыши по объекту вызвать контекстное меню
4. Advance -> Set Run State
Ну умному достаточно :)! Успехов и приятной работы

Спасибо Tryestes. Он рассказал, как вставить их в шаблон отчета:

А вот это не то ?
{ElemRunState.Variable} {ElemRunState.Operator} {ElemRunState.Value}

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

Сейчас я делаю AddIn, обеспечивающий, в частности, генерацию отчетов. Немножко трудоемко, но нет необходимости тупо повторять "дерево" проектного броузера. Фактически, появляется возможность представлять нужную информацию в нужной последовательности и в нужной форме.

А теперь все тот же вопрос:
Знает ли кто нибудь, как "достучаться" до значений переменных экземпляров классов в библиотеке Enterprise Architect Object Model 2.10?

Это потребуется не только для отчетов, но и для разработки преобразований "модель - модель", которые в EA вообще не представлены. В RSA я их делал и успешно пользовался. В ЕА тоже понятно, как это сделать.

25
Я приверженец UML.

DFD - это только один срез будущей системы. И если Вы захотите рисовать другие диаграммы для других "срезов", Вам придется все начинать сначала, м.б., на других инструментах.

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

26
Простите, а зачем?

Человеку надо отобразить бизнес-процесс, а не потоки данных.

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

27
Компания (морская логистика) ищет бизнес-аналитика для проведения следующих работ:

Требования: опыт работы бизнес-аналитиком от 2 лет, успешные проекты.

Нет Ваших контактных данных!?

А Вы думаете, бизнес-аналитик с двухлетним стажем может уже "накопить" успешные проекты?

28
Я немного не врубился, а как можно описывать действия пользователя в системе в отрыве от реакции? Можно-то можно, но какой смысл?

Описан бизнес-процесс. Сотрудник - business actor. Бухгалтер и кассир - business worker. Документы - business entity. Стиль описания - "прозрачный ящик (в терминах Коберна).

По моему, все путем! Мне диаграммы больше нравятся. Когда будет много процессов, да еще связанных, такой табличкой не обойдешся. Но это дело вкуса.

29
Вы знаете! Что-то я сомневаюсь, чтобы кто-то срочно схватился рисовать ваши диаграммы в разных нотациях. Своих дел полно. Еще рецензию на Ваши диаграммы - куда ни шло!

Плохих и хороших нотаций нет, мне кажется. Есть цели моделирования, привычки.

Сегодня такие задачки чаще всего моделируют на BPMN. Там все нужное есть.

Если цель описания - поддержка разработки ПО, то нужно подумать о преемственности моделей, чтобы потом разработчикам не пришлось начинать все сначала. В таком случае я бы использовал профиль бизнес-моделирования для UML.

Если Вы просто хотите формально задокументировать свои процессы, вообще думать не о чем: Ваша таблица вовсе не корявая, и если ее использовать только для изучения процесса, она вполне достаточна. Особенно, если у Вас нет навыков моделирования.
Я вот уже много лет в этой сфере работаю, у меня получается быстро. Трачу время не на моделирование, а на понимание проблем. А, если навыков нет и надобность зибзическая, лучше сэкономить время и деньги.

У меня на сайте (http://lnew.ucoz.ru) есть несколько статей под общим названием "Повышение производительности ..." Они, правда, для профессионалов. Но там есть пример моделирования бизнес-процесса и получения из него требований к системе.

Удачи!

30
Sparx / Re: FAQ - Sparx Enterprise Architect
« : 23 Ноября 2011, 00:34:43 »
Я долго работал с инструментами Rational. В частности - с RSA для моделирования и проектирования. Наработал множество приемов и шаблонов.
Одна из претензий к циклу статей "Повышение производительности аналитика" - опыт заточен на дорогие инструменты и для широкого круга аналитиков его использование невозможно.

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

Какие то возможности я попробовал: создание шаблона структуры проекта, библиотеки "строительных блоков", работа с профилями UML, создание т.н. "технологий" MDG. В этой части трудностей я не увидел (за исключением большого объема работы).
 
Но ...
Одна из ключевых идей цикла - документы не надо писать "ручками", даже для заказчика. Их можно генерировать из модели.
Для этого нужно "наплодить" некоторое количество шаблонов, поддерживающих общие или корпоративные стандарты.
Если невозможно создавать сложные автоматизированные документы, все остальное просто не имеет смысла!

Использование стиля "класс - атрибут" проблематично по многим причинам:
- для каждого типа отчета нужно явно определять все атрибуты классов. В сложном мастер-документе будет много MD, которые нужно грамотно выбрать. Написать инструкцию по каждому типу документа - не фокус. Но не будет же аналитик держать ее под руками для создания каждого документа. Какое уж тут увеличение производительности!
- есть и внутренние проблемы. Например спецификация UC. Описание рабочего потока должно выполнятся с использованием диаграммы деятельности. Самое большее, что можно допустить - это разметку элементов, которую должен понимать шаблон. И здесь без фильтров и сортировки не обойтись.

Короче, я поставил себе задачу отработать приемы создания сложных отчетов на примере двух документов: Обзор модели прецедентов и Спецификация прецедента <название>. Документы должны напоминать документы RUP.

Если это не удастся, бросаю это черное дело. Если получится - буду делать "технологию" под названием "Интегрированное моделирование" с профилем UPIA.

Если кто-то хочет поучаствовать - милости просим!
Если кто-то найдет коммерческое применение - тем более!

Вот почему не хочу использовать технологию "Класс - атрибут", хотя для простых документов она предпочтительнее.
Если бы я в проекте участвовал, я бы пользовался RSA (пока). А если бы пришлось использовать ЕА, то, скорее всего, плодил бы множество простых отчетов и собирал бы их в нужный документ в ворде!


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