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

×


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

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


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

Страницы: « 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 »
496
Где сказано, что они нужны? Вы смотрели юзкейс?
Почему частота не принципиальна при выборе считать/хранить?
Нет. Не любое. Новый метод расчёта может обеспечить сохранение адекватности данных, при некоторых изменениях. При других не сможет. Отсюда и был вопрос "как" и разговор о примере.
Вы слышали выражение "выводимый атрибут"? И кто теперь изобретает то, что собеседник не говорил?
Вы сможете объяснить, почему не хранить, а считать контрольную дату в библиотечной системе плохо? Шире, чем наклеив ярлычки "популярные грабли", "система-однодневка"? Пока _объяснения_ нет.
Где я предлагаю "безграничные возможности"?
Вернёмся назад. Из двух предложенных альтернатив безапелляционно вырезается одна и объявляется плохой.
По-моему, всё прозрачно и ясно. "Популярные грабли", "система-однодневка", "плохой метод" видно не только мне.

497
Ну какое исключение, серьёзно. Вы знаете частоту, когда нужны эти даты? [В версии условий игрушечного примера частота = 0.] Вы уверены, что сразу станет плохо, как только начнут менять? Как менять? Можно привести пример изменения [для библиотеки], не критичного для метода. Можно привести пример критичного. Вы какое изменение предпочтёте?
Если новичку искусственно сужать пространство выбора, он не наберется опыта. Он будет воспроизводить шаблон, спущенный свыше, и всё.
Ярлык подправьте так, как считаете нужным. Дело в ярлыке, а не в конкретной формулировке написанного на нём.

498
Да, не понимаю. Вы говорите о данных, про которые не известно, нужны ли они. На этом шатком основании делаете выводы о решении. От решения проводите обобщение до метода, который так же огульно объявляете универсально плохим. Учить надо оценивать ситуацию а потом, исходя из неё, решать, что хорошо, а что плохо. И не надо учить, малюя ярлыки: считать всегда плохо, всегда нужно хранить.
И всё это ради чего?

499
Зачем мне это?
Чтобы вернуться в реальный контекст.

Библиотеку? Я отметил в рекомендациях подход, применение которого (безотносительно предметной области) делает жизнь и предметных специалистов, и автоматизаторов значительно ярче и богаче. О чем и отписал.
Подход? KICK?

Разве я могу что-то вырезать из Вашего текста?
Да. Можете, Вы это доказали. В тексте было две альтернативы. Осталась одна.
 
Я могу разве что ткнуть пальцем в откровенно неудачное решение, приводящее к массе проблем в ближайшем же обозримом будущем (но не сегодня).
Массе проблем в решении учебного примера? О каком обозримом будущем идёт речь? О том, в котором модель не высечена из камня, в котором эскиз развивается в решение не по принципу "я знаю, где тут должно положить соломки", а по ходу изучения предметной области?

 
Дабы новичок видел, что не все альтернативы одинаково полезны. Может быть, это убережет его от получения личного опыта (и кто знает - может, даже меня от ликвидации последствий его получения новичком).
Уберечь новичка от получения личного опыта? Вы уверены, что хотите ему тем самым добра? И я так и не понял, Вы одну и ту же библиотеку устраиваетесь автоматизировать? Где каталогизация? Дублинское ядро? ISBNы где, в конце концов? Давайте уж тогда скажем прямо, что задачу из сообщения, открывшего тему, решать на самом деле не надо, так как она высосана из пальца.

500
Согласен. Регулярно сталкиваюсь с последствиями деятельности адептов этой концепции.
При решении учебных примеров? Вы найдите библиотечного ИТшника и обсудите с ним задачу. Уверен, он покрутит пальцем у виска. Автоматизации в библиотеке подлежит вовсе не работа с читателями.
Если мы всё ещё играем в библиотеку, откуда знать, важны ли сроки возврата книг вообще? Может быть, при входе в круг читателей надо внести залог, размер которого покрывает любой возможный ущерб. Может быть, самодеятельную библиотеку соорудили коллеги по работе, которые хорошо друг друга знают и не видят в задержанной книге повода для претензий друк к другу.
Я не понимаю Вашего подхода. Из двух предложенных альтернатив (двух, чтобы новичок видел, что нет одного "правильного" ответа) Вы вырезаете одну (как-будто другой не было). Вырезали и что теперь?

501
Полагаю, что речь идёт о диаграммах размещения. Примеры диаграмм, нарисованных в EA:
http://sparxsystems.com/enterprise_architect_user_guide/12.1/building_models/deploymentdiagram.html
http://www.sparxsystems.com.au/resources/tutorial/physical_models.html

502
Популярные грабли. Все хорошо будет до тех пор, пока этот срок не начнут менять.
Другие популярные грабли называются YAGNI. Можно делать вид, будто всерьёз делаешь ПО для библиотеки, а можно делать вид, что даёшь советы по учебному примеру. Что ему больше подходит, каждый решает за себя, не за другого.

503
Уважаемые аналитики, помогите, пожалуйста еще с одной:
Мне требуется дополнить диаграмму сущность-связь для описания модели автоматизации библиотеки.
Нельзя не отметить странность того, от чего Вам предложено отталкиваться. Плюсики и минусики на т. н. "диаграмме сущность-связь" что должны изображать по мнению её составителя? Экземпляр книги на полке (на нескольких полках?), полка в нескольких стеллажах? Как найти экземпляр? К какому стеллажу идти?
Если не обращать внимания на вышесказанное, то Вы скорее всего справились со стоящей перед Вами задачей. Добавлю, что можно отмечать действительную дату возвращения книги и дату, до которой книга должна быть возвращена. Это поможет определять величину задержки книги нерадивым читателем и, например, начислять разные штрафы. С другой стороны, если правила библиотеки устанавливают одинаковый срок, на который выдаётся книга, хранить ещё одну дату не обязательно. Она может быть вычислена.

504
Я бы посмотрел в сторону Interrupting Edge (http://www.uml-diagrams.org/activity-diagrams.html). Другой способ все-таки использовать не диаграммы деятельностей, а диаграммы автоматов.
Дельный совет как по части возможностей диаграмм деятельности для решения обозначенной задачи, так и по части переосмысления выбора вида диаграмм.
В сети есть пример, поясняющий использование interrupting edge:

505
Примеры / Re: Продажа автомобилей
« : 26 Марта 2016, 12:47:22 »
Я полагаю, что некоторый смысл может иметь построение эскизной диаграммы ВИ, отражающей начальный набор действующих лиц и ВИ. На таком эскизе связи между ВИ не моделируются. Затем после составления описаний ВИ можно строить структурированную версию диаграммы.

506
нужно создать комплексное надсостояние с переходом из псевдосостояния выхода в само себя (см. пример во вложении).
Не оправдано использование псевдосостояния выхода, в которое не входит никакой переход. Смысл диаграммы без него будет ровно таким же.

507
Примеры / Re: Продажа автомобилей
« : 26 Марта 2016, 10:25:23 »
Поправил диаграмму. Надеюсь, что теперь я всё правильно понял. За исключением замечания по поводу перехода к уровню реализации, но с этим постараюсь что нибудь придумать этой ночью.
Если продолжать рассмотрение примера, то следует заметить, что рисование структурированной диаграммы ВИ (со связями между ВИ: <<include>>, <<extend>>) оправдано лишь после того, как составлены описания ВИ. В отрыве от описаний пунктирные стрелочки несут мало смысла и являются лишь поводом для гипотез, действительно ли "выбор автомобиля" является частным случаем "выбора клиента".

508
Друзья,

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

509
"Ты не мудри, ты пальцем покажи...", - из очень "бородатого" анекдота  ;D
Пример диаграммы, в которой один объектный курсор форкается и передаётся двум принимающим узлам, дан во вложении к этому сообщению.

510
Тоже быльём поросло, но я как НЛО могу встрять. Своё встревание предваряю замечанием, что, на мой взгляд, часть стандарта UML, описывающая объектные потоки в моделях деятельности, очень перемудрённая .

По стандарту fork подразумевает параллелизм, в том смысле, что он может его реализовать. Но параллелизм [после fork] возникает не во всех случаях. Если fork для объектных потоков, это значит, что любой входящий объектный токен копируется на каждый исходящий объектный поток. Если их готовы принять узлы, куда ведут потоки, то они [параллельно] проходят дальше. Если не готовы, то они стоят и ждут, когда их примут.

Datastore по стандарту не занимается рассылкой копий объектных токенов как таковой. Datastore сохраняет в себе копии всего того, что в него пришло (в единственном экземпляре). И за счёт этого "размноженный объектный токен" может пройти по разным исходящим потокам. 

P. S. Два объектных потока, исходящих из деятельности, предполагают, что у неё есть два выходных параметра (объектных узла), и из каждого такого узла, в общем случае, выйдут разные объектные токены. То есть, для объектных потоков такая конструкция не аналогична fork, как в случае потоков управления. Придётся либо помещать "объектный fork" явно вне деятельности, либо моделировать размножение внутри деятельности с явным указанием двух или более однотипных out-параметров, через которые будут выходить копии токенов.

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