4306

Обучение / Re: Задачки для аналитиков?

« : 08 Февраля 2008, 23:16:26 »

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

4307

Варианты Использования (Use Case) / Re: Уйти от ВИ и перейти к иерархии Пользовательских Требований

« : 08 Февраля 2008, 23:04:20 »

Саша, немного сумбурно и не понятно.

Хотя в целом вопрос ясен. Итак, ты полагешь или констатируешь, что

1. есть некое не пустое множество функций в системе

2. есть некое непустое множество пользователей такой системе без четко выраженной роли

3. роль пользователя представляет собой абстракцию, определяемую текущим набором прав.

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

5. Одно из главных различий между вариантом использования и алгоритмом (функцией) заключается в том, что алгоритм (функция), который может содержать некоторую последовательность шагов, не будет (не должен) отображать диалог между пользователем и системой. Т.е. если функция системы (ERP-CRM) не отражает диалог пользователя с системой, то очевидно использовать ВИ не следует, в противном случае нужно писать вариант использования.

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

7. ВИ не единственный инструмент описания требований пользователя. Для этого можно испрользовать пользовательские истории.

8. Для более детального анализа сказанного Сашей, хотелось бы увидеть все-таки некоторые примеры, поскольку пункт 3 неясен и не новичку (какую технику? почему автор полагает что такая техника возможна, как понять не ошибается ли автор в своих суждениях по данной теме?)

4308

Сообщество Аналитиков / Re: Клуб любителей EA

« : 08 Февраля 2008, 20:05:29 »

2Irr: sorry за безграмотность, только что Galogen просветил
+1 добавил в Вашу копилку :-)

Gevorg, это была просто шутка, но приятно получать плюсики Хотя пока они ничего и не значат.

4309

Сообщество Аналитиков / Re: Клуб любителей EA

« : 08 Февраля 2008, 17:42:35 »

Irr, Вы просто кудесница!

а плюсик за кудесничество?

4310

Проектирование / Re: Проектирование по ICONIX

« : 08 Февраля 2008, 16:27:06 »

Странно. У меня было совсем другое представление данного процесса.
Мы создаем диаграммы деятельности для ВИ (черный ящик), далее анализируем и получаем классы анализа (диаграмма классов). Затем действия из ДД преносим на диаграмму последовательности в виде методов. В результате получаем ВИ->ДК+ДД->ДП
На примере RSA (не знаю как в EA) могу сказать, что из collaboration получается sequience одним шелчком мыши (и наоборот). Причем, если взять вашу картинку, то мне на сиквенсе RSA нарисовал бы актора, баундари, контрол и энтити и все сообщения, передаваемые от класса к классу.
По схеме Розенберга получается, что все операции (методы) будут принадлежать либо сущностям, либо граничным классам.
Тогда как же быть, например, с Session и Entity Bean из EJB (Java)? На сколько я понимаю, в данном случае JSP (servlets) / Session Bean / Entity Bean образуют самый настоящий MVC (вернее V/ C / M).

О чем я и толкую, у меня такое же было представление до этого момента. А вот ICONIX дает несколько иное представление. Все управляющие классы безусловно и в ICONIX, но уже на более поздних этапах, что крайне удивительно.
Про книгу я Вам написал по почте, но брал я с pdfchm.com

4311

Проектирование / Re: Проектирование по ICONIX

« : 08 Февраля 2008, 14:25:39 »

Это ты спроси у плагина, он их не проставил

Причем надо сказать что месаги на 2 диаграмме это моя вольность

Интенсивное чтение Розенберга привело меня к такой вот мысли:
1. берем описание варианта использование
2. строим человечк(ов)
3. рисуем граничный класс (или несколько)
4. рисуем сущностный класс (или несколько) - все согласно описанию
5. разбираем каждое предложение, извлекаем от туда глагольные фразы, смотрим на что и куда они направлены, каждую такую глагольную фразу(шаг, операцию, функцию) превращаем в управляющий класс
6. соединяем все это хозяйство по правилу noun-verb-noun или verb-verb
далее строим секвенцию
1. рисуем актера
2. рисуем формы(граничные объекты)
3. рисуем сущности
4. класс контроллер который мы определеи на диаграмме анализа превращается в сообщение в данном случае от одного класса к другому и соотвественно становится методом класса на который направлен

вот такую вещь я вычитал и книжки

4312

Проектирование / Re: Проектирование по ICONIX

« : 08 Февраля 2008, 12:28:28 »

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

За книгу спасибо, но прежде того, как начну скачивать - вопрос, у Вас это какая книга? Розенберг и Скотт(98) или Розенберг и Стевенс(07)?

Вот что написано в книге ООП с UML: Теория и практика. Часть 5
2. Objects on Your Robustness Diagram Will “Morph” into the Detailed Design
Boundary and entity classes on a robustness diagram will generally become object instances
on a sequence diagram, while controllers will become messages. It’s also advisable to create
test cases for the controllers.
Keep in mind that both boundary objects and entity objects are nouns, and that controllers
are verbs (i.e., an action performed on an object). As such, it makes sense that the
controllers (the actions) will become methods on the boundary and entity classes.

Не намного увеличился текст, но однозначно указывается что контролер - методы граничного и сущностного классов
Я попытался так бегло показать что получается автоматом в ЕА с использованием плагина от ICONIX

4313

Проектирование / Re: Проектирование по ICONIX

« : 08 Февраля 2008, 11:02:25 »

Саша, я понимаю назначение управляющего класса, но ты не внимательно читаешь текст.
Когда формируется диаграмма последовательности - управляющего класса там как раз и нет, ты говоришь что сообщениями управляет управляющий класс, как же это видно, если на ДП между граничным и сущностным классом исчезает управляющий (или он должен подразумеваться?), если да, так как по-твоему это должно выглядеть на на диаграмме классов - реализующией ВИ

4314

Проектирование / Проектирование по ICONIX

« : 07 Февраля 2008, 23:13:46 »

У меня возник вопрос в связи с концепциями проектирования по ICONIX.

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

Далее реализация ICONIX в EA имеет возможность автоматической генерации диаграммы последовательности из диаграммы робастности. При это в рекомендация встретилась интересная фраза:

Boundary and entity classes on a robustness diagram will generally become object instances on a sequence diagram, while controllers will become messages.
Т.е. граничные и сущностные классы становятся объектами-экземплярами на диаграмме последовательности в то время, как управляющие классы становятся сообщениями.

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

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

Это мне показалось не совсем понятным, может кто-то может прояснить мне эту ситуацию?

4315

Примеры / Re: Проверьте диаграмму объектов, плиз

« : 06 Февраля 2008, 19:06:44 »

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

Здесь могут помочь и вычисляемые ассоциации, и небинарные отношения, ассоциативные классы и т.п.

может быть у компании целесообразно будет вести два атрибута грузоотправитель и перевозчик

а возможна ситуация, что компания и Г и П одновременно?

с пакетом функций мне тоже не совсем ясно, что за функции, какое их назначение, как они соотносятсяс тем что компания Г или П или просто К?

4316

Обучение / Re: Обучение по курсу IBM Rational системный аналитик

« : 06 Февраля 2008, 15:32:36 »

Низкий поклон госпоже

4317

Примеры / Re: Проверьте диаграмму объектов, плиз

« : 06 Февраля 2008, 14:38:27 »

2. один пользователь обязательно админ\ да

вопрос: у компании может быть в принципе множество администраторов? или только один?

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

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

6 Каждое право соотносится тоько к одному пользователю \нет, это я исправила
7. 1 право может охватывать несколько функций\нет, это я тоже исправила
8. Но каждая функция соотносится только с 1 правом\ тоже нет, тоже исправила

вопрос, а что такое право? не есть ли это отображение возможности подключения к одной единственной функции, или право - это некоторый набор функций?

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

может у вас есть отчеты, документы регламентирующие эту ситуацию?

4318

Примеры / Re: Проверьте, плиз

« : 05 Февраля 2008, 20:49:03 »

1. одна компания имеет множество пользователей
2. один пользователь обязательно админ
3. в компании множество обозревателей
4. один обозреватель может иметь доступ к функциям разных компаний (вот тут кажется нелогичная у вас связь)
5. Пользователь имеет несколько прав
6 Каждое право соотносится тоько к одному пользователю
7. 1 право может охватывать несколько функций
8. Но каждая функция соотносится только с 1 правом
9. Каждая компания имеет набор функций
10. Одна и та же функция соотносится только одной компании
11. при перевозках одна или несколько компаний обязательно являются  грузоотправителем, при это она самая или другая компания может быть перевозчиком а может и не быть

вот что я прочитал из вашей диаграммы? все ли верно?

4319

Книги, статьи и ресурсы / Re: Требуется книга "Применение объектного моделирования с использованием UML ..."

« : 04 Февраля 2008, 12:32:13 »

у меня есть в бумажном варианте... )))

Спасибо, но я уже заимел электронный вариант на английском за 2007 год

4320

Бизнес-анализ и Целеполагание / Re: Главная, базовая, основная цель бизнеса

« : 02 Февраля 2008, 22:19:50 »

бизнес, как машина для максимизацуии прибыли и бизнес, как живой организм.

Сережа, а почему это следует противопоставлять.
Сейчас слушал "Посткрипутим" с Алексеем Пушковым, был репортаж про Стерлигова - бывшего мультимиллионера, а ныне овцевода. Ушел из бизнеса (большого) потому, что надоело быть рабом денег.

Можно ли считать, что бизнес большой и бизнес малый - две разные ипостасии?