Одна организация передает другой накладную, для первой организации эта накладная является расходной, а для другой приходной. А потом вторая организация может сделать первой возврат. Как это правильно отобразить на UML?

Здравствуйте, es3000, Вы писали:

E>Одна организация передает другой накладную, для первой организации эта накладная является расходной, а для другой приходной. А потом вторая организация может сделать первой возврат. Как это правильно отобразить на UML?

Для начала напишите юзкейс, описывающий достижене определенной цели при взаимодействии организаций ... после этого можно будет рисовать хоть Activity, хоть Sequence диаграмму ... Только нужно будет четко описать условие возврата ...

B>Для начала напишите юзкейс, описывающий достижене определенной цели при взаимодействии организаций ... после этого можно будет рисовать хоть Activity, хоть Sequence диаграмму ... Только нужно будет четко описать условие возврата ...

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

А>Спасибо, а как отобразить на этой диаграмме накладную? Выписку накладной — это действие, две организации — это действующие лица, а накладная чем отображается?

Да... вот — блеск и нищета UML... ну кому это может быть нужно? "Как рисовать накладную на диаграмме"... Мрак.

А>Да... вот — блеск и нищета UML... ну кому это может быть нужно? "Как рисовать накладную на диаграмме"... Мрак.

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

Здравствуйте, es3000, Вы писали:

А>>Да... вот — блеск и нищета UML... ну кому это может быть нужно? "Как рисовать накладную на диаграмме"... Мрак.

E>Очень "умный и полезный" совет! Я вам посоветую не засирать форум такими советами.
E>А кому это нужно... Заказчику, который не понимает программные коды, а понимает только картинки..
E>И все-таки как это отобразить взаимодействие двух организаций на языке UML?
E>Неужели никто не знает?

Привет
вот посматриваю юмл 2.0 — там в активити диаграммах рисуется собственно действие — квадратик с закругленными углами, а объект — то, что появляется, или чем оперируется — прямоугольником. В такой прямоугольник может входить стрелка от начального состояния, из него — стрелочка в экшн — мол, объект передался в экшн. Еще есть интересная штука — в таком прямоугольнике ставится стереотип — <<datastore>> — так вот если в такой прямоугольник входит пунктирная стрелка — это значит, что в хранилище записываются данные — инсерт, если же стрелка идет от хранилища — чтение — селект.

Как эпилог, можна сказать, что юмл версии 2.0 обладает гораздо большей выразительностью по отношениею к своему началу. Этого почти не заметно на класс-диаграммах, тк их концепция была неплохо проработана на то время, но на диаграммах компонентов, размещения и дейсвий — намного удобнее...

Здравствуйте, es3000, Вы писали:

E>А кому это нужно... Заказчику, который не понимает программные коды, а понимает только картинки..

Имхо, еще лучше заказчик поймет хорошо написанный use case.

Здравствуйте, Аноним, Вы писали:

B>>Для начала напишите юзкейс, описывающий достижене определенной цели при взаимодействии организаций ... после этого можно будет рисовать хоть Activity, хоть Sequence диаграмму ... Только нужно будет четко описать условие возврата ...

А>Спасибо, а как отобразить на этой диаграмме накладную? Выписку накладной — это действие, две организации — это действующие лица, а накладная чем отображается?

Накладная, в случае использования Activity diagram with object flow -- как объект должна быть отбражена, в соответствующем состоянии. Но повторюсь -- для начала просто _напишите_ юзкейс (видимо это будет бизнес-юзкейс), а потом посмотрите, нужно ли на UML что-то рисовать ... вполне может оказаться достаточно текста.

Здравствуйте, lazymf, Вы писали:
L>Имхо, еще лучше заказчик поймет хорошо написанный use case.


Вот-вот, только я не могу придумать как правильно нарисовать накладную на use case

B>Накладная, в случае использования Activity diagram with object flow -- как объект должна быть отбражена, в соответствующем состоянии. Но повторюсь -- для начала просто _напишите_ юзкейс (видимо это будет бизнес-юзкейс), а потом посмотрите, нужно ли на UML что-то рисовать ... вполне может оказаться достаточно текста.

в activity diagram в принципе можно отобразить то что мне нужно, но плохо отображаются участвующие лица. А Use case я уже написал, в общем нормально, но все-таки хочется отобразить что один актер делает накладную, которая для него является расходной, а другой актер ее принимает, и для него она является уже приходной.

Здравствуйте, es3000, Вы писали:

E>Вот-вот, только я не могу придумать как правильно нарисовать накладную на use case

Use Case не рисуют, их пишут. То, что в UML называется диаграммой use case — имхо ерунда какая-то, непонятно для чего предназначенная. В лучшем случае такая диаграмма может служить заголовком/иллюстрацией для нормально написанного use case. По написанию use case — очень советую почитать Алистера Коберна Writing Effective Use Cases

Автор(ы): Алистер Коберн
Издательство: Лори
Цена: 365р.

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

.

E>Одна организация передает другой накладную, для первой организации эта накладная является расходной, а для другой приходной. А потом вторая организация может сделать первой возврат. Как это правильно отобразить на UML?

Ваша задача один в один ложится на графическое отображение MS BizTalk,
в виде потока активностей,и связей между ними,

а также его функциональность, реализующую это.

Здравствуйте, es3000, Вы писали:

E>в activity diagram в принципе можно отобразить то что мне нужно, но плохо отображаются участвующие лица. А Use case я уже написал, в общем нормально, но все-таки хочется отобразить что один актер делает накладную, которая для него является расходной, а другой актер ее принимает, и для него она является уже приходной.

1.Действующие лица м.б. отображены в виде swimlines (для UML 1.4).
2. Если нужно отобразить наличие объекта Приходная накладная -- то можно создать активити, которая на вход получает объект Расходная накладная, а на выходе дает объект Приходная накладная.

Если сие для заказчика то то так и малюй как накладная из одного домика летит в другой. Если для программистов — то читай совет ниже во Активити диаграмам.