61

Теория моделирования и нотации / Re: Самая удобная нотация и инструмент моделирования для проектирования БД

« : 15 Июня 2021, 15:49:53 »

[Вероятно, имеются в виду реляционные БД.]
[Далее следует порция трындежа, который худо-бедно связан с заданными вопросами, но не даёт на них ответа.]
Инструмент (программу) можно подбирать под задачу. Например, чтобы она из имеющихся DDLей сама рисовала что-то удобоваримое, а после перерисовывания генерила новые версии DDL, и чем, чёрт не шутит, помогала рефакторить содержимое БД. Как следствие, такие полезные свойства инструмента могут помочь смириться с несовершенством поддерживаемой нотации.
Можно ставить в вершину угла выразительные возможности нотации (и, как следствие, мириться с несовершенством инструмента, который её поддерживает).
У нотации полно других свойств, которые могут быть важны (и даже быть важнее выразительных возможностей). Например, если нотация привычна Вашим коллегам, то они с бОльшим энтузиазмом воспримут Ваши диаграммы.
[Тут трындёж как бы заканчивается.]
Мне привычен UML. К нему есть профиль, предложенный на сайте Скотта Амблера. С помощью этого профиля можно приспособить стандартную UML-диаграмму классов к моделированию схемы реляционной БД. Амблер не приводит пример с категоризацией, но в актуальной версии UML есть такие штуки как Generalization Set с Power Type-ами. Это позволяет наUMLылить что-то похожее на IDEF1X-ные categorization-отношения.
Недостатков такого решения прорва:
- инструмент для перевода с/в DDL в/с UML почти наверняка не существует;
- приспособленные UML-диаграммы классов не привычны разработчикам БД, они откажутся их читать;
- пляски с Generalization Set и Power Type-ами лишь отдалённо напоминают то, что было в IDFE1X.

62

Теория моделирования и нотации / Re: Неизвестная нотация структуры базы данных

« : 07 Июня 2021, 17:45:34 »

1) С Марсу кажется, что это IDEF1X.
2) Если не только кажется, то это часть ISO/IEC/IEEE 31320-2:2012. От которого не отказались.
3) Не знаю. В Visual Paradigm есть ERD. В них можно указать дискриминатор, но явно на диаграмме он не будет отражаться. Что-то схожее можно нарисовать на UML, но без вороньих/куриных лапок.
4) Не порекомендую.

63

Системный Анализ и Требования / Re: Диаграмма состояний

« : 03 Июня 2021, 00:15:56 »

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

64

Системный Анализ и Требования / Re: Диаграмма состояний

« : 30 Апреля 2021, 07:12:51 »

1. Как корректно отобразить для состояния «Сформировано», что Exit/заблокировать на редактирование произойдет только при переходе в статус «Отправлено»?

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

2. При переходе из статуса «Отправлено» в статус «Возвращено» для переходов «[подтвердить формирование РПРО]» и «[отклонить формирование РПРО]» нужно ли каким-либо образом указывать, что такие переходы возможны только если уведомление №14. Если нужно, то как это возможно отобразить?

Можно указать сторожевое условие на части составного перехода, ведущей в верхний правый ромбик.

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

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

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

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

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

65

Идеи и мозговой штурм / Re: Диаграммы Курта Воннегута

« : 18 Апреля 2021, 15:10:05 »

Интересно. Курт Воннегут несколько раз пытался защитить разные дипломные работы? Вроде в бакалавриате одна дипломная.

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

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

Попадалось что-то про UML для сочинителей детективов, но это неточно, т. к. ссылка потерялась.

66

Идеи и мозговой штурм / Диаграммы Курта Воннегута

« : 06 Апреля 2021, 12:52:03 »

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

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

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

67

Работа / Re: Почему аналитики не читают литературу по специальности?

« : 18 Марта 2021, 12:11:30 »

Удалось найти первоисточник - произведение самого Баркера (примерно 1989 года) или перевод на русский язык (видел примерно в 1993 году)?

https://archive.org/details/casemethod00rich
На всякий случай, ссылка на книжку "Case Method: Entity Relationship Modelling". Если зарегаться на archive.org, то можно читать.

68

UML SysML и пр. / Re: Бертран Мейер -- UML-ненавистник

« : 27 Января 2021, 22:39:43 »

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

69

UML SysML и пр. / Бертран Мейер -- UML-ненавистник

« : 17 Января 2021, 23:29:44 »

В 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) на его странице.

70

Идеи и мозговой штурм / Re: На пути к морфологии сценариев ВИ

« : 16 Января 2021, 18:25:35 »

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

71

Идеи и мозговой штурм / На пути к морфологии сценариев ВИ

« : 12 Января 2021, 23:29:53 »

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

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

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

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

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

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

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

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

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

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

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

72

Работа / Re: Почему аналитики не читают литературу по специальности?

« : 29 Декабря 2020, 14:26:26 »

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

73

Работа / Re: Почему аналитики не читают литературу по специальности?

« : 18 Декабря 2020, 01:57:59 »

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

74

Задачи студентов / Re: Схема работы лифта - кто хочет потренироваться?

« : 16 Декабря 2020, 17:24:30 »

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

75

Работа / Re: Почему аналитики не читают литературу по специальности?

« : 16 Декабря 2020, 12:48:56 »

Пусть так.

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