16

Примеры / Re: Uml-модель экономической системы общества.

« : 23 Ноября 2009, 13:24:48 »

Существует каноническая, вполне универсальная схема статической финансово-экономической модели систем (которую, впрочем, чтобы сделать динамической, достаточно при реализации снабдить возможностью выполнения серийных параметризованных пересчетов (если я правильно это называю)). Листовые элементы могут быть самыми различными, они определяются исходя из предметной области, задают смысл регистрам высоких уровней, и здесь приведены мной в качестве иллюстрации возможности формирования требующейся нам модели (я ни в коем случае не претендую на то, что рисунок содержит исчерпывающие перечени сущностей хотя бы на каких-нибудь уровнях). Полагаю, что формирование именно этих перечней и смыслов может и должно являться достойным предметом обсуждения для аналитиков, хотя бы в плане интеллектуального развлечения (вот только размещение данного обсуждения, на мой взгляд, крайне неудачно – когда я сюда пишу, у меня всегда возникают сомнения, не вынесло ли меня в оффтоп). Если я правильно понимаю, это и должно составить словарь модели. Из рисунка видно, что данная модель, сама по себе, не может автоматически определить, кто на свете всех правей – например, капиталисты или коммунисты. Но, почему бы и нет – может быть серия подобных корректно согласованных моделей (параметров и критериев), сформированных с различных конкурирующих точек зрения  (отображаемых прежде всего содержанием регистра "Владельцы") могла бы перевести это спор в рациональное русло. В конце-концов вопрос состоит в том, какой вариант является наиболее эффективным с точки зрения развития Системы (да, конечно, надо сначала договориться о том "что такое "хорошо", и что такое "плохо" для Системы. Но в этом смысле цивилизация подошла к очень способствующему в этом отношении моменту – хорошо то, что позволит живущим сейчас на Земле людям не оказаться последними людьми на этой планете, а плохо, соответственно, иное ...)

17

Примеры / Re: Uml-модель экономической системы общества.

« : 16 Ноября 2009, 12:46:05 »

Очень естественно выглядит структура. Но по нашим “условностям жанра” надо построить UML-модель экономической системы общества с целью объяснить причины экономического кризиса и такого феномена капитализма, как безвозмездное присвоение собственниками средств производства благ, созданных всем обществом. Так что продолжайте предлагать способы решения именно этих задач.

Может быть надо посмотреть на моделирование немножко иначе? - Надо построить модель финансово-экономической системы общества. Правильную модель (я представил всего лишь свое видение "как начинать"). А уж потом, в ходе экспериментов с этой моделью (для того она и нужна), выяснять какие режимы ее функционирования наиболее оптимальны. Иначе получается какая-то подтасовка - специально строим такую модель, которая заведомо не может функционировать никак, кроме как мы ее запрограммировали. А вдруг мы программируем, что 2х2=5 (запрограммировать так - никаких проблем), но на самом-то деле требуется объективный калькулятор?
Кстати, думаю что предположения о большой трудности реализации такой модели, не соответствует действительности. Думаю, что ровно наоборот - именно данная область (перемещения и преобразования "товар-деньги-товар-...") наиболее легко поддается моделированию. Трудоемкость программирования в данном случае всецело зависит от степени детализации модели, но и только. Около 400 лет существует и никогда не подводил метод двойной записи, предназначенный специально для такого моделирования. Требуется лишь, с помощью системного анализа (а то как же ж?), выстроить объективно правильное (честное) отображение предметной области (архитектуру модели). А движки готовые для реализации такой модели - чуть ли не под ногами валяются ...

18

Примеры / Re: Uml-модель экономической системы общества.

« : 09 Ноября 2009, 01:34:57 »

mmm... а разве не более естественно выглядит такая структура (базовая) (или я не врубился в условности жанра?):

19

Теория моделирования и нотации / Re: Явная связь класса с прецедентом - бред?

« : 08 Ноября 2009, 14:40:34 »

Я получил исчерпывающий ответ на свой исходный вопрос (в №14 от AlexTheRaven), и еще много больше, за что всем огромное спасибо. Однако, если говорить только о части ответа, буквально относящейся к исходному вопросу, то ответ оказался обескураживающим и, мне кажется, весьма показательным. Я предполагал что-то подобное (в моем сообщении №12, абзац 4), но реальность превзошла мои ожидания. То, о чем я спрашивал, уже сейчас (прошло всего часов 10, не то что 2 года), представляется мне настолько очевидным, что я просто не представляю, сам себе не верю, что искал и не мог найти этот ответ … наверное много дольше месяца… Я знаю, если не изложу это сейчас, по самой свежей памяти, то уже через пару дней, при обращении ко мне с подобным вопросом, очень вероятно, буду недоумевать точно так же, как Gologen и другие, чего же хочет спрашивающий (даже говорить стыдно). Как мог бы выглядеть ответ на мой исходный вопрос, если бы не существовал эффект вытеснения самых элементарных фактов из сознательной памяти в почти бессознательную: "1. Язык UML не регламентирует отображение семантических (понятийных) связей между сущностями (элементами) диаграмм различных типов, оставляя способ их констатации в документации, при необходимости, в произвольной, на усмотрение автора, форме; 2. В Sparx возможность документирования подобных связей поддерживается очень просто: на любую диаграмму можно физически перетащить любые объекты из дерева модели, и связать их явно одним из доступных в данной диаграмме видом связи (линии и стрелочки в тулзе диаграмм). Данная возможность является чисто сервисной – ответственность за смысл или бессмысленность подобного решения всецело возлагается на автора и его компетенцию; 3. Мне адекватность прямого связывания ВИ и Классов, в частности, представляется весьма сомнительным.", – что-то в этом роде (на 100% в точности содержания не уверен)… и весь разговор был бы много короче. Все…
Да, топик можно закрыть (я должен заблокировать тему? - не нашел в хелпе).

20

Теория моделирования и нотации / Re: Явная связь класса с прецедентом - бред?

« : 08 Ноября 2009, 00:35:30 »

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

Ну это уже максимализм. Разумеется ВИ это цель. Потому что любой функционал Системы, который предусмотрен для взаимодействия с актором, по определению преследует достижение какой-нить нужной актору цели. Но почему нельзя назвать это "функцией"? Мне кажется, это уже дело вкуса или нюанс конкретного разговора.

21

Теория моделирования и нотации / Re: Явная связь класса с прецедентом - бред?

« : 08 Ноября 2009, 00:29:08 »

Связь класса с UC - вполне нормальная вещь, если понятно, для чего она нужна. Что делает ваш класс для UC? Он "аналитический" или относится к тому, что реально есть в коде? Он entity, boundary, control реализации, контейнер для всего этого, или что-то другое? Что вы хотите показать - что класс оперирует понятием, которое представляет собой класс, реализует весь UC, часть (сценарий? поток? триггер? проверку предусловия? постусловия?) UC? Что и до кого вы хотите донести этой связью, поймут ли вас?

В данном случае (но только в данном), класс "док.Путевка" (наследник прототипа "Документ") действительно практически целиком и единолично реализует функционал "Создание партии ..." (т.е., я понимаю, что так бывает не везде и не всегда) и, более того, так "реально есть в коде". Насчет, "до кого хочу донести" и "поймут ли меня" ... видите ли, кроме этих, у меня существует еще один, первичный мотив - я полагаю, с помощью этих рисунков очень удобно думать (придумывать решения). Немаловажно и то, что выяснилось, что в результате, без дополнительных трудозатрат, возникает красивый материал, хорошо воспринимаемый программистами (UC+Activity). Зачем же заниматься почеркушками на бумаге, искать слова для длинных текстов и псевдокодов, если можно делать то же самое весело и сразу в "товарном виде"? Если рассматривать с этой т.з., то так ли уж важно квалифицировать "entity, boundary, control реализации, контейнер для всего этого, или что-то другое? Что вы хотите показать - что класс оперирует понятием, которое представляет собой класс, реализует весь UC, часть (сценарий? поток? триггер? проверку предусловия? постусловия?) UC?" Большая часть из перечисленного - епархия программистов, в этом я им доверяю - поэтому, честно говоря, в этом слабо или совсем не разбираюсь. Неужели мне в UML без этого не обойтись? Надеюсь, что нет.

Опять же, для чего вы используете UC? Они у вас "бизнес", "системные про взаимодействие с actor'ами" или "технические про алгоритмы системы"?

А так ли важно знать это (уметь различать) с самого начала освоения?[/quote]

IMHO (но только IMHO)
- связь UC с аналитическими классами - это правильно, и её выстраивание - работа системного аналитика
- связь UC с отдельным классом реализации - это "мелковато", трудно поддерживать; для того, чтобы показать связь UC с кодом, лучше связывать UC с компонентами, и выстраивание такой связи - работа системного архитектора.

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

Про средства отображения такой связи - в Rational Rose, насколько я помню, была связь через UC Realization, в EA можно рисовать напрямую,

Вот черт! Это же и есть буквальный ответ на исходный вопрос! Действительно, так я еще не пробовал... Попробовал, действительно можно. Единственно, - UC-диаграмма вроде как "засоряется". Поэтому попытаюсь еще разобраться с "но IMHO лучше стереотипировать и комментировать.", но это уже следующий вопрос ...

Чтобы отобразить в EA связь между UC и классом, UC и компонентом - достаточно
- перетащить оба элемента на одну диаграмму из дерева проекта; насколько я пиню, между ними будут доступны связи dependency и trace, но их можно стереотипировать

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

22

Теория моделирования и нотации / Re: Явная связь класса с прецедентом - бред?

« : 07 Ноября 2009, 23:52:31 »

Разница, как мне кажется, в том, что use case на диаграмме вариантов использования и use case как способ описания требований к системе - это не совсем одно и то же. Или почти одно и то же, но с разных точек зрения.

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

23

Теория моделирования и нотации / Re: Явная связь класса с прецедентом - бред?

« : 07 Ноября 2009, 21:57:26 »

В PowerDesigner данное отношение поддерживается явно. Даже по умолчанию у прецедента есть вкладка, предназначенная для ведения связей с реализационными классами и интерфейсами (см. приложенный рисунок).

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

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

В дополнение к связи с классами, у нас используется и связи с объектами БД и некоторыми другими элементами (собственное расширение).

Спасибо, еще один мазок в создание образа Мотаю на ус ...

24

Теория моделирования и нотации / Re: Явная связь класса с прецедентом - бред?

« : 07 Ноября 2009, 21:19:44 »

Именно по UML советую прослушать/просмотреть этот курс.

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

25

Теория моделирования и нотации / Re: Явная связь класса с прецедентом - бред?

« : 07 Ноября 2009, 21:09:04 »

Michaj, Вы не прочитали сообщение №11?

Мой №15, на который я возлагал особые надежды, это именно на №11

... Крэг Ларман в этом случае отлично торкает

Большое спасибо, попробую

26

Теория моделирования и нотации / Re: Явная связь класса с прецедентом - бред?

« : 07 Ноября 2009, 20:55:36 »

<to greesha> но я ведь практически в точности так и трактую понятие "Варианты использования", как вы описали. В чем разница?

27

Теория моделирования и нотации / Re: Явная связь класса с прецедентом - бред?

« : 07 Ноября 2009, 20:41:03 »

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

Где-то в какой-то статье о UML был использован в общем-то штамп о том, что типа "не так страшен волк, как его малюют", - возьмите и попробуйте". Я в принципе из этого и исхожу. Мне UML нужен в той мере, в какой он мне нужен, а не я ему (в конечном счете). Я знаю основы ООП, со мной смело можно гаварить о "наследовании, инкапсуляции и полиморфизме ..." (господи, до чего ж длинные слова). Я не знаю ООП так, как его знают программисты, но и они не знают ООП так, как его знаю я, и стоит оставить их без присмотра, как это на каждом шагу вылазит боком. Я не знаю множества деталей использования ООП в коде, но зато я знаю что такое идея и композиция, гармония (баланс) и стиль применительно к структуре объектной модели приложения и/или его компонентов, и к бизнес-архитектуре в целом, что для программистов как правило пустые звуки, потому что этому их не учат, потому что программистская школа слишком молода и у нее еще не успела сложится своя эстетика. Понесло ... Стоп!

В Вашем случае "класс "док.Путевка" в системе является конкретной реализацией прецедента  "Создание партии продукции""
- совершенно не правильный вывод. Спросите себя что делает класс док.Путевка, для чего он предназначен, какова его ответственность?

Спрашиваю.-Отвечаю: документ путевка есть прогр.компонент, пользовательский интерфейс, в который пользователь вносит перечень очередной порции произведенных изделий.- Это точка, в которой эти изделия вообще впервые возникают в Системе как объекты учета (не путать с элементами справочника, - тут они заведомо присутствуют, но не являются объектами учета, пока не существует связанных с ними остатков). Это, честно, все, что пришло мне в голову Но я все равно не врубился, почему класс не является здесь реализацией прецедента ...

Я думаю тут вам еще мешает что вы мыслите категориями 1С, правильно ли я понимаю?

Относительно 1С совершенно правильно! А вот по поводу "мешает" мог бы поспорить, но лучше не надо... Я действительно являюсь убежденным сторонником той же концепции бухучета и ее воплощения в IT,  которой придерживалась 1С в своих старых бухгалтерских системах. Собственно, первая моя работа в сфере производства ПО, куда меня пригласили в качестве бизнес-аналитика (повезло), подспудно сопровождалась мыслью создать продукт такой же классный, как 1С, но лишенный его недостатков . Тогда еще не существовало 7-ки. Через несколько лет работы (1С7.5 я прозевал) случилось мое знакомство с 1С7.7, и я с изумлением узнал там множество "своих собственных" решений (конвергенция, однако!). Однако к этому времени уже пару лет моя система (ERP) работала на довольно большом предприятии (около 6000 работников, тысячи единиц номенклатуры, несколько десятков одновременно работающих пользователей), где и сейчас работает, где и возник собственно обсуждаемый вопрос. 1С в то время и близко не подходила к подобным масштабам предприятий, да и сейчас только-только подбирается, и никак не подберется ... Но, я думаю, за ней будущее, хотя и не одобряю нового ее, именно концептуально, направления. Вообще, нахожу что в России, в сфере учета, побеждает откровенное невежество, а 1С просто сдалась с этим бороться ...

28

Теория моделирования и нотации / Re: Явная связь класса с прецедентом - бред?

« : 07 Ноября 2009, 18:59:16 »

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

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

29

Теория моделирования и нотации / Re: Явная связь класса с прецедентом - бред?

« : 07 Ноября 2009, 17:35:21 »

К меня создалось впечатление, что Вы неправильно используете Use Case'ы.

У меня тоже Как раз пытаюсь это скорректировать

Вы по каким источникам изучали UML?

Кроме данного сайта, книгой Буча, точного названия нет в голове, она на работе, Уэнди Боггс, Майкл Боггс "UML и Rational Rose", Help в Sparx (но, увы, не очень силен в англ-м ) и прочим, что попадется ... Я не программист, но программеры на работе, которые это, казалось бы, недавно изучали в универе, разбираются в сем, оказывается, еще меньше меня...

30

Теория моделирования и нотации / Re: Явная связь класса с прецедентом - бред?

« : 07 Ноября 2009, 17:08:40 »

Это сообщение я написал до того, как получил два последних ответа в топике, которые практически уже содержат ответы по некоторым моментам данного. Что-то теперь следовало бы в нем изменить, но опасаюсь, что пока буду исправлять, это тоже успеет устареть. Очень боюсь истощить Ваше терпение, но один этот разговор думаю стоит недель, если не месяцев самоварения. Мне кажется, он может помочь и другим новичкам, так как вряд-ли мои вопросы и сомнения уникальны. А на теперь уже предыдущие два ответа, я напишу отдельно.

Если честно, все равно не могу просечь в чем проблема?

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

Что же вы все-таки хотите? Показать некую связь некоего ВИ с неким классом? Так Вам уже много способов дали. Причем denis-itk дал Вам  чисто классический способ через кооперации (во многих местах можно почитать).

Можете не верить, но видимо я в эти места не попадал… Однако прочтя советы denis-itk, я тут же отправился в Sparx с намерением ими воспользоваться. На данном, очень низком этапе своего развития, слова о кооперации классов в контексте какого либо ВИ в моем представлении приобрели образ некоего объекта Collaboration в качестве контейнера в виде рамки на диаграмме, в который следует поместить некие классы, и связать уже эту рамку с ВИ. Но, как оказалось, в диаграмме классов, в ее наборе, нет элемента типа Collaboration … Ладно, зато такой элемент есть в диаграмме ВИ. Попробовал здесь создать Collaboration, и в него из дерева модели перетащить … что? Речь ведь идет об объединении классов … Ну, перетащил в него класс. – На Collaboration возникла пупырышка с название Port (…?). Я понял, что опять делаю что-то не то …

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

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

Теперь о диаграммах - это вообще что? Что это за ВИ "Свободные остатки"?

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

Что это за зависимости "создание"?

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

И что это за компот из "создания", "include" и "invokes".

Думаю что "компот" – это следствие незнания того самого базового контекста, о котором и пытаюсь получить, прямо или косвенно, любые сведения. Например, я четко знаю что такое "эклектика", но только благодаря тому, что я знаю соответствующий контекст эстетики. А вот что такое "компот" приминительно к UML – очень хотел бы узнать.
 

Кстати а почему include в императиве, а invokes в 3 лице?

Потому что Вы первый, кто сказал мне, что это плохо 

Создание ТТН непременно включает Отгрузку со склада ГП?

Да. ТТН это только контейнер с собственными товарно-транспортными реквизитами. Пользователь вручную, из списка допустимых Отгрузок, выполненных ранее кладовщиками на разных складах ГП, включает некоторые из них в данную ТТН в качестве оснований для Приложений к этой ТТН (собственно детальных списков продукции)

А что такое за атрибут Размер(Заказ)? Отличается Размер как атрибут от Размера как класс?

Из-за этого Размера весь сыр-бор. Не очень понимаю вопрос. Предполагаю (но это еще не точно), что должен быть создан класс "Размер_Заказ", который позволит где необходимо в прочих классах, создавать ссылочные аттрибуты на него, дающие доступ к значениям аттрибутов Заказчик, Длина, Ширина и пр. класса "Размер_Заказ". (дело в том, что существавшее до сих пор производство – чисто конвеерное многосерийное производство (стеклопосуда и хрусталь), не предполагавшее на этапе производства (более 100 лет существования) никакого специфицирования по потребителям, а здесь вдруг возникло производство картона (и упаковок из него, но это отдельная песня), включающее еще и его нарезку в любом формате в качестве дополнительного потребительского сервиса…).