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

×


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

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


Сообщения - [прилетело НЛО и...]

Страницы: « 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 34 35 »
76
1. Как корректно отобразить для состояния «Сформировано», что Exit/заблокировать на редактирование произойдет только при переходе в статус «Отправлено»?
Не используйте действие по выходу, т. к. оно выполняется при любом выходе. Вы можете это действие приписать на те переходы, для которых оно актуально.
[В сторону] невполне ясно, как строится модель. Так как события "отредактировать" игнорятся вне "создать извещение", то независимо от того, заблокируете или нет, отредактировать в "Отправить" и проч. не выйдет.
2. При переходе из статуса «Отправлено» в статус «Возвращено» для переходов «[подтвердить формирование РПРО]» и «[отклонить формирование РПРО]» нужно ли каким-либо образом указывать, что такие переходы возможны только если уведомление №14. Если нужно, то как это возможно отобразить?
Можно указать сторожевое условие на части составного перехода, ведущей в верхний правый ромбик.

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

Вообще говоря, на стандартных диаграммах состояний не бывает ромбиков в которые входят несколько переходов. Вместо них чёрные кружки (переходные псевдосостояния).

Если написать название в виде действия "Создать извещение", то это не означает, вообще говоря, что что-то будет делаться. Мысленно заменив такое называние на State0, получаем диаграмму с тем же смыслом (если стандартно читать).

Неясно, зачем событие и do-деятельность названы одинаково: "Отредактировать".  [Если у Вас в ходу свои правила чтения/составления UML-диаграмм состояний, то и славно.]

Неясно, зачем некоторые события взяты в прямоугольные скобочки: [получен ответ...]. [Если у Вас в ходу свои правила чтения/составления UML-диаграмм состояний, то и славно.]

77
Интересно. Курт Воннегут несколько раз пытался защитить разные дипломные работы? Вроде в бакалавриате одна дипломная.
К. В. после войны учился в "специалитете" на антрополога -- уникальной программе сочетающей B.S.+M.S.. Кажется, было две попытки и темы были разные, но на общей ключевой идее. В итоге ему дали почётную степень за "Колыбель для кошки". Примечательно, что К. В. преподавал в вузах, при этом неясно, было ли это до или после присвоения степени.

Говорят UML уже не используется в it-разработке, пора начать активно внедрять его в другие области человеческой деятельности. Как я понимаю, для конструирования сюжета. Тут можно обсудить, какие диаграммы и как следует использовать, чтобы проектировать бестселлеры :)
Попадалось что-то про UML для сочинителей детективов, но это неточно, т. к. ссылка потерялась.

78
Предлагается продолжить наши междисциплинарные инопланетные штудии.

Недавно перевели книжку ученицы Курта Воннегута Сьюзен Макконелл "Курт Воннегут. Пожалейте читателя. Как писать хорошо". Объёмный томик для каждого, у кого 15-20-летие совпало с выпуском романов К. В. на русском. Из книги можно узнать про Kurt Vonnegut Story Chart -- диаграммы, положенные в основу дипломных работ, которые Курт Воннегут [безуспешно] пытался защитить в бакалавриате. Выглядят story chart-ы примерно так:

На ютьюбе нагугливается ролик с выступлением К. В., где видно, как он рисует story chart-ы, и поясняет, как визуализируется смена состояний главного героя в ходе изложения. Линия идёт выше -- главный герой счастливее, ниже -- несчастнее.
Можно заметить, что story chart -- это фрагмент UML-диаграммы синхронизации. Ещё бы чуть и К. В. изобрёл бы их. Ему стоило догадаться, что помимо протагониста есть антагонист и всякие дейтерагонисты с тритагонистами. И их состояния также меняются. И полный story chart должен включать не одну линию жизни, а несколько, на которых соотношение счастья/несчастья персонажей меняется синхронно.

79
Удалось найти первоисточник - произведение самого Баркера (примерно 1989 года) или перевод на русский язык (видел примерно в 1993 году)?
https://archive.org/details/casemethod00rich
На всякий случай, ссылка на книжку "Case Method: Entity Relationship Modelling". Если зарегаться на archive.org, то можно читать.

80
Ксенолингвист барахлит при переводе bbcode с марсианского. Прошу прощения. Фиксануло.

81
В 1997м Б. Мейер составил и опубликовал фельетон "UML: The Positive Spin" ("UML: Позитивная раскрутка") и выступил в роли одного из первых UML-хэйтеров. В фельетоне от лица студента как бы составлено письмо своему профу с требованием повысить оценку, заниженную якобы по политическим причинам.
Вывод в этом фельетоне вполне может быть в жилу тем, кто считает UML не годным, кто коллекционирует и сам зачастую рисует т. н. "смешные UML-диаграммы":
UML назван...
Цитировать
...замечательной само-подпитывающейся машиной, посвященной от А до Я созданию нового рынка, свободного от каких-либо трудностей, связанных с неприятным процессом разработки программного обеспечения: Книги по UML! Курсы UML! Курсы по книгам! Книги по курсам! Книги по книгам! Вводные курсы для подготовки к курсам повышения квалификации! Курсы для преподавателей! Редакции! Журналы по UML! Конференции! Мастер-классы! Учебники! Стандарты! Комитеты! Футболки!
Готовя очередное выступление на аналитическом слёте, посвящённое тому, почему UML не взлетел, можно обратить внимание на классические тезисы БМ и продолжить многолетнюю традицию, заложенную им.
Остальным читателям страничка даст путь к книге по "европейскому UML" -- BON (Business Object Notation). Книга называется "Seamless Object-Oriented Software Architecture — Analysis and Design of Reliable Systems". Она выложена одним из двух авторов (Kim Waldén) на его странице.

82
Идея не претендует на новизну.
Идея не претендует на осуществимость.
В упомянутых книгах паттерны понимаются в другом ключе, насколько могу судить. Например, авторы "Patterns for Effective Use Cases" называют паттернами свои советы о том, как реализовать юзкейсописательство, и прочие придуманные ими юзкейсо-хаки. "Паттерны" Проппа другого сорта, это выявленные общие шаблоны, схемы. Понятно, что он их придумал/разглядел/выявил. Но делал это на материале, полученном извне. Мне не попадалось книг, в которых бы приводились советы и решения, составленные по итогам анализа сценариев ВИ, написанных не самими авторами этих книг. Тот же Коберн приводит сторонние тексты как иллюстрации своих положений, не как почву из которой эти положения выросли. К слову в "PfEUC" нет и мысли о расширении видов действующих лиц.

83
[Раскапывать нектротреды иногда приедается.]

Переиздали два труда В. Я. Проппа "Морфологию волшебной сказки" и "Исторические корни волшебной сказки". В первом из них коротко изложены результаты работы по выявлению паттернов в огромном массиве т. н. "волшебных" сказок. Разнородное скопище сказок со всего Мира было сведено группой под руководством В. Я. Проппа к набору довольно простых схем.

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

Итак, Пропп & Co выяснили, что волшебная сказка не является свободно составленным сочинением, а скомпонована по определённым правилам. Она -- противоестественный текст, притворяющийся обычным. Какого же рода текстом является сценарий ВИ, как я полагаю.

В сказке, увиденной через призму Проппа, принимают участие _действующие_лица_. Как и в сценарии ВИ.

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

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

Поступки сгруппированы Проппом в т. н.  "круги". Это позволяет ему определить тип действующего лица сказки. Что-то подобное есть и в сценариях ВИ. По шагам ДЛ мы можем догадаться является ли оно основным или второстепенным в данном ВИ. Вот только в сказках типов ДЛ много больше двух/трёх: вредитель, даритель, помощник, царевна, герой, псевдогерой и др.. Коберну тут не угнаться. Но что если...

...Что если пойти путём не Коберна, а Проппа. Собрав массив сценариев ВИ можно попытаться выявить не a priori заданные схемы и правила, а те, которые идут от естества самих сценариев. Что если  ДЛ Время -- это "псевдогерой", а бухгалтерская прога, с которой надо "поженить" нашу будущую систему -- "сказочная царевна"?

Собственно в этом и заключается бредовая идея, которую предлагается тут посолить, по-крекс-фекс-пексить и закопать: сдвинуть парадигму сценария ВИ как текста, сгенерённого по правилам, забыть ненадолго о правилах и провести обратную инженерию -- восстановить правила из текстов сценариев, а затем сравнить восстановленное с тем, что продиктовано в WEUC и в прочих книженциях.

О том, что Пропп изучил "способы сочетания рассказов" (на наши деньги это способы соединения частей сценариев ВИ таких как подчинённые и альтернативные сценарии, и сценарии связанных ВИ) я умолчу.

84
Дельные заметки.
В таких случаях я пытаюсь смириться с тем, что авторы подбирают примеры для иллюстрации чего-то в тексте, и когда иллюстрация случилась, пример бросают на полдороге. Это не отмазывает от критики, конечно.
Диаграмма с foreign key не содержит никаких других  candidate key кроме primary, поэтому строго судить затруднительно. И по идее всюду в теории реляционных данных рассматриваются множества полей (математические, т. е. без повторных вхождений). Допускает ли SQL повторы, затрудняюсь сказать.

85
Поисковики предлагают русский наколеночный перевод, в котором диаграммы даны псевдографикой. Ну или амазон, где книга всё ещё включена в ассортимент книжной выпечки.
Как замена нашёлся сайт: http://www.entitymodelling.org/
Не совсем то, но картинки занимательные.

86
Могу попытаться пояснить, что в решениях Марша и Йордана нет _списков_ событий_, нет _потоков_событий_, нет сценариев. Они представляют собой что-то вроде конечных автоматов.
Если пытаться перекладывать такие решения в терминах ВИ, то мы получим что-то очень далёкое от целей пользователей лифта: "Обработать нажатие кнопки вызова", "Обработать сигнал датчика о прибытии на этаж". Проблематично составить сценарий "Переместиться с этажа N на этаж M" из набора таких псевдоВИ уровня "моллюска".

87
Пусть так.

Добурило до куриных/вороних лапок по рецепту Баркера. Отвал башки. Благодарю.

88
Vadim, Вам спасибо за составление подборки.
Так как мало что нового выходит на русском, она актуальна и, полагаю, останется актуальной надолго.

89
Хэдхантинг, конечно, интересный [см. выше].

Форум мало активен и кого хотят уловить в 3 сосны (3 мессаги в разные темы), мне неясно.

Если придерживаться темы, то почему бы не рассказать, зачем читать несколько книг "об одном и том же". Берём список Vadim'а, надеясь, что он не против, и смотрим:
1. Дж.Рамбо, М.Блаха "UML 2.0. Объектно-ориентированное моделирование и разработка", 2-е издание, 2007
Книга -- уникальный сборник упражнений, незаменима для тренировки, самопроверки. Книга показывает в чём силён один из 3-х другей (и в чём не силён).

2. Джим Арлоу и Айла Нейштадт "UML 2 и Унифицированный процесс", 2-е издание, 2008
Чуть ли не единственная с внятным сообщением про OCL, с адекватным UML 2.0 описанием диаграмм деятельности. При сравнительно большом количестве переведёнок по RUP Арлоу+Нейштадт -- диковинка с рассмотрением унифицированного процесса не в версии от Rational.

3. Три амиго "UML. Специальный справочник", 2006
Т. к. текст стандарта UML всё ещё не переведён на русский, то это частичное восполнение этой лакуны.

4. OMG Unified Modeling LanguageTM (OMG UML), Superstructure Version 2.2
Так как переведённые книги вышли с привлечением наших российских переводчиков, то исходный текст стандарта незаменим при продирании сквозь перевод.

5. М.Фаулер "Паттерны анализа", 1999 (англ)
Все книги Фаулера отличает комфортная подача материала. И это не фан-сервис, а умение передать свою мысль. Конкретно эту книгу не читало, поэтому такое невнятное написало тут.

6. Л.Мацяшек "Анализ требований и проектирование систем. Разработка информационных систем с использованием UML", 2-е издание
Автор "австралийского UML" пишет про ORM, что бывает на русском не часто. В книге неплохие примеры. Автор до сих пор на своём сайте поддерживает странички с материалами к своим книгам: лекционные слайды, файлы моделей для разных сред.

7. Р.Баркер "Моделирование отношений сущностей", 1989
ERD? Не читало. Я тогда ещё под треножник пешком ходило. В марсианских букинистах мне такое не попадалось.

8. М.Фаулер "UML. Основы", 3-е издание
Все книги Фаулера отличает... Ах да, о чём это я. "Дистиллированный UML" -- задорное введение в язык со сниженным порогом входа. Те, кто уверены, что UML прост и всем понятен, возможно, находятся под обаянием этой книги.

9. Г. Буч, Язык UML. "Руководство пользователя. Второе издание. Описание версии UML 2.0 Исчерпывающее руководство по языку UML от его создателей"
Это вторая заплата на прореху, образовавшуюся из-за отсутствия перевода стандарта UML на русский.

10. К. Вигерс, "Разработка требований к программному обеспечению"
В глазах существа из UML-вселенной, книга выделяется из перечисленного ряда тем, что объясняет и доказывает, что UML аналитику не нужен.

90
А я слышал про людей, которые после работы уборщицей становились генеральными директорами крупных предприятий или руководителями департаментов государственных органов (министерств, агенств и служб).
Как-то этот фрагмент всплыл и зацепил взгляд. Что-то в нём такое на злобу дня.

Страницы: « 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 34 35 »