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

×


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

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


Сообщения - Irr

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 »
121
А вот и откликнулись знатоки нотаций, ура!
Теперь у Helg'и будет полный набор рекомендаций со всех точек зрения, а не только с точки зрения структуры модели, а значит, после устранения замечаний получится красивая и правильная модель :-)

122
По дальнейшему курсу есть предложение сделать диаграммы анализа, т.е. набор диаграмм с т.з. системного аналитика + диаграмму процесса.
Irr, нам такой вариант подходит?
Замечательные планы! Вполне подойдет!

123
Спасибо! Очень приятно! :-)

124
Согласная я, только желательно в конце апреля семинар. У меня ожидается большая запарка на работе на апрель :-(

125
Слава Панкратов: Бизнес в ИТ на примере паровоза. Серия первая: Заказчик, задача и бизнес анализ.
http://pankratov.org.ua/it/parovoz01

126
Примеры / Re: EA - описание среды с примером
« : 27 Февраля 2009, 12:18:27 »
Business Domain Model определена в РУПе и ОпенУПе.
Она строится из элементов Класс со стереотипом Actor и  Business Entity.
О! Предчувствия меня не обманули, я как раз смутно помню, что не все так просто с ними...
А Actor просто или таки businessActor с кривой палочкой в районе шарика-головы?
Все-таки интересно, как называется эта нотация, где их ввели. Я помню, что видела их в RUPе, но это ж не нотация, а методология...

127
Примеры / Re: EA - описание среды с примером
« : 27 Февраля 2009, 10:53:53 »
А что ты хотела конкретно спросить про Business Domain Model? Ты вроде сама написала ответы :)
Из каких элементов она строится. Когда-то давно мы такое строили из элементов (видимо, классов, но не помню) со стереотипом BusinessEntity. Используется ли такое в свежих вариантах нотации UML, я не знаю, хочу узнать у вас, знатоки. Просто в EA, например, с 7й версии в дефолтном списке стереотипов нет ни businessentity, ни businessworker'а, а вот если ручками прописать, он меняет графическое отображение.

А насчет проектирования кто-нибудь добрый нам поможет? А то я набросала шаманских терминов, но я их понимаю интуитивно, а наверняка, есть знатоки.

128
Примеры / Re: EA/UML - вопросы от новичка
« : 26 Февраля 2009, 20:59:44 »
как можно создать (если можно) в ЕА вложенный процесс (процесс в процессе) или создать ссылку из одного процесса на другой?
А чем не подошла возможность делать composit element? и какой элемент для отображения процесса используется?
для чего нужна relationship matrix (RM)? в ней только отображаются связанные элементы или она сама предназначена для создания связей?
В ней можно просмотреть, добавить или удалить связанные элементы, а также экспортировать ее в CSV-файл, распечатать и сохранить как шаблон параметры фильтрации матрицы. Использовать матрицу удобно в случае, когда мы хотим увидеть наличие связей между несколькоими элементами. В случае, когда нам интересны все связи одного элемента, удобней использовать окно Hierarchy.

129
Примеры / Re: EA - описание среды с примером
« : 26 Февраля 2009, 20:45:40 »
Смотрю на очередную версию модели: выглядит чисто и красиво. Теперь можно сосредоточиться над соответствием модели нотации UML, чтоб количество диаграмм было побольше, элементы по-разнообразней. На них можно будет с трассировкой поиграть. - но выбор дальнейшего направления для усилий оставляю за автором :-)
Теперь комментарии:
Смущает пока схожесть модели классов и словаря предметной области. По идее в словаре предметной области все должно быть на русском языке, и классы словаря не должны принадлежать какому-то языку (а в модели это Java). А вот модель классов приложения - она как раз наоборот может строиться под определенный язык реализации, для дальнейшей кодогенерации. В общем, по этому поводу хорошо спросить знатоков UML:
1. Как нарисовать правильно словарь предметной области? Она же BusinessDomainModel (если пользоваться терминами RUPа) или DomainModel  в примере к ЕА. Кстати, в примере классы словаря имеют стереотип Entity и Language None.  - я думаю, это неспроста!
2. Рисование классов проекта - это такой сложный момент, классы проекта могут быть сначала нарисованы в виде абстрактной модели, а потом трансформированы в конкретную реализацию Переход от абстрактной модели классов к конкретной  реализации в примере показан как MDA Transforms из AbstractClassModel  (PIM - платформонезависимая модель) в ImplementationModel (PSM - платформозависимая модель). Решение о том, какие модели классов строить, а какие нет, принимает архитектор/проектировщик - в общем, это густо замешано на конкретной разработке, и зависит от того, собираемся ли мы генерировать исходный код из модели или нет. Эти решения так же принимать автору модели.
...единственное, что вызвало вопросы: диаграмма использования - это какой вид диаграммы? (нашла только ДВИ, но она у меня есть)?
Диаграмма использования - это мой термин, не общеупотребительный. Я предложила нарисовать метамодель нашей модели. Т.е. описать структуру нашй модели в виде классов. Практически это будет выглядеть как диаграмма классов, где на текущий момент есть следующие классы: Словарь предметной области, Заинтересованные лица (ЗЛ), связанный с ним класс Цели заинтересованных лиц, связанный с ЗЛ класс Бизнес-требования. В общем, когда будет побольше исходная модель - могу нарисовать и объяснить подробней.

130
Лучше поздно, чем никогда ... и я присоединяюсь к поздравлениям!
И я, и я того же мнения!

131
Спасибо большое, дорогие друзья и коллеги! :-)

132
Примеры / Re: EA - описание среды с примером
« : 19 Февраля 2009, 10:02:42 »
Helga, я написала Вам в личные сообщения.

Galogen, что-нибудь обязательно получится законченное и готовое для использования. Мы оформим.

133
Саш, в первом посте этой ветки кроме профиля еще требовалось:
6. Добавить в эту ветку пост, в котором изложены:
* Цели, которые Вы преследуете в участии в данном сообществе.
* Чем Вы можете помочь сообществу

А что, это уже писать не надо?

134
Примеры / Re: EA - описание среды с примером
« : 17 Февраля 2009, 15:19:49 »
Замечательно! Подробно посмотрю как всегда, в четверг :-)

135
Примеры / Re: EA - описание среды с примером
« : 13 Февраля 2009, 17:38:00 »
это точно (особенно в файле-отчете rtf). Все названия я переведу. А путаница с двумя языками возникла по тривиальной причине:в качестве примеров смотрела на разные диаграммы (с разными языками), ну и сделала на автомате по аналогии)))))
Очень хорошо. Для этого мы и пересматриваем модель, чтоб она была смысловая, а не на автомате.
По идее жить он должен там, где мы объявляем о его существовании. Вся соль ситуации в том, что у меня есть вариант 2 и 3. Но нет объявления существования. В связи с этим можно рассмотреть такой вариант:
добавить элементы actors на Д "объекты предметной области" . На Д заинт.лиц, ДВИ сделать наследование. насколько это верно?
Имхо, он должен жить там, где его интуитивно легко найти и там, где мы его объявляем. По-моему, если бы моделирование осуществлялось в реальной, а не обучательной последовательности, Преподаватель был бы объявлен в пакете Заинтересованные лица. А его ДВИ появилась бы позже и уже его использовала. К тому же в таком случае мы можем быстро обнаружить (включить в документ) всех наших Заинтересованных лиц, а не искать их отдельно по всем требованиям.
спасибо, что напомнили, что у всех  зависимостей есть названия - я про них просто забыла((
Тут кстати, может быть название не UML-ное, а просто логически интуитивно понятное. Какое название выбрать, зависит от квалификации пользователей диаграммы. Если заказчик не знает УМЛ, то ему захочется видеть нормальное русское название.
иногда (когда проект внутренний, да и внешний) у инициатора проекта есть необходимость обоснования  проекта (с т.з. затрат особенно). поэтому я добавила эту диаграмму. она, конечно, куцая и поэтому (что логично) и возник вопрос: зачем?...в более сложном проекте я бы в нее добавила колич.характеристики - насколько например увеличится производительность и пр. может и здесть что-нибудь придумаю...
Моделирование по сути это визуальное описание, более удобное, чем текст, в случае, когда требуется показать взаимосвязи между элементами. В данном случае у нас нет связей этих элементов, так что ценность этой диаграммы очень маленькая, я бы ее рисовала только в том случае, если мы всю информацию о системе собираемся хранить в модели, а документы получать генерированием отчета по модели. Предлагаю пока оставить ее так, как есть, вдруг и правда что-нибудь придумается.
в документе rtf это смотрится откровенно не оч хорошо. Нужно что-то менять - подозреваю, что Объекты предм.области придется понижать хотя бы на 1 ур.
OpDef переместить в Требования (если рассматривать пакет Требования как бизнес-требования к системе)
Я согласна с Вами, поэтому предлагаю Вам подумать на тему переструктурирования иерархии пакетов и переименования пакетов. Если рассматривать пакет Требования - как бизнес-требования, почему бы так его и не назвать?
если говорить о читателях, могу предположить:
цели, ЗИ - это для заказчика или руководства +БА.
объекты предм.области - БА+СА
требования - БА
В принципе, в отдельном пакете можно построить модельку структуры и использования нашей модели: у нее есть читатели (пользователи), пакеты (составные части) и появятся документы (т.е. этот пакет пойдет в ТЗ, этот в концепцию и т.д. - этакий userguide по модели ;)

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 »