Форум Сообщества Аналитиков
Общий раздел => Примеры => Тема начата: Limon от 26 Марта 2016, 18:47:54
-
Добрый вечер, уважаемые!
Столкнулся с задачей описать usecase выдачи книги читателю библиотекарем (зарегистрировать выдачу в системе).
И вот, как я вижу решение этой задачи:
Краткое описание: Выдача экземпляра книги
Пользователь: Библиотекарь
Предварительное состояние: Система загружена
Запускающее событие(я): Пользователь просит выдать книгу
Цели: Регистрация выдачи экземпляра книги в Системе
Результирующее состояние: Выдача книги зарегистрирована в Системе
1. Библиотекарь находит книгу в справочнике, выделяет её и нажимает кнопку «Выдать экземпляр»
2. Система удостоверяется, есть ли доступные для выдачи экземпляры книги, в противном случае выводит сообщение о том, что доступных для выдачи экземпляров нет. Возвращается к п.1
3. Система отображает интерфейс «Выдача экземпляра книги»
4. Библиотекарь заполняет поля:
a. Инвентарный номер выдаваемой книги – можно выбрать из списка
b. Номер читательского билета, на который выдается книга
И нажимает кнопку «Выдать»
5. Система удостоверяется, что есть возможность выдачи книги на указанный номер читательского билета. В противном случае выводит сообщение о том, что выдача по указанному номеру читательского билета не возможна. Возвращается к п. 4
6. Система вносит данные о выдаче экземпляра книги:
a. Уникальный номер выдачи (генерируется системой)
b. Номер экземпляра выдаваемой книги.
c. Номер читательского билета, на который выдается книга.
d. Дата выдачи книги (генерируется системой)
и выводит сообщение: «Данные о выдаче экземпляра успешно зарегистрированы в системе»
Прошу Вас, знающие люди, укажите мне на мои ошибки.
-
Прошу Вас, знающие люди, укажите мне на мои ошибки.
Уважаемый Limon. А Вам какие указывать ошибки?
Технические ошибки спецификации варианта использования
или
Ошибки логического характера?
-
В первую очередь меня интересуют логические ошибки.
Но и указание на технические ошибки не повредит))
В целом, ошибок масса, да?
-
Пошарьте документ в Google Doc и дайте возможность комментировать.
Что вы нас заставляете возиться с цитатами в 2016-м году?
-
Навскидку
1) Непонятно, кто такой пользователь. Посетитель библиотеки? Его роль в описании туманна: он вроде указан в стартовом событии, непонятно, каким образом он сообщает о своем желании взять книгу и каким образом. Он должен либо сообщить всю информацию до начала процесса оформления, либо участвовать в сценарии как одно из ДЛ
2) Некорректно выделены границы процесса: почему из процесса исключена книговыдача, но включен поиск книги
3) Исключения объединены с шагами happy path (п.п 2 и 5). В шагах объединены действия и системы и ДЛ
4) Не предусмотрено исключение по п.1. , если книга не находится в каталоге
5) Не предусмотрена возможности прервать процесс . Например в п.2 после того, как книга не найдена в каталоге , то библиотекарь зачем то повторяет процесс поиска...
Алистер Коберн рекомендуется...
-
Пошарьте документ в Google Doc и дайте возможность комментировать.
Что вы нас заставляете возиться с цитатами в 2016-м году?
Вот ссылка на документ в google docs
https://docs.google.com/document/d/1p-of8527g2cv5AodrWUohRz3bnWiZsOh8ISmuf1ThSc/edit?usp=sharing
внизу красным выделен сценарий использования, который шел вместе с заданием, как пример
-
2Humbert:
1. Пользователь - читатель, имеющий читательский билет. Предполагается, что до начала процесса он сообщает какая книга ему нужна, а остальная информация известна.
2. Добавил пункт выдачи книги, спасибо.
3. Альтернативный сценарий (исключения) лучше записывать ПОСЛЕ основного сценария?
Не могу понять в каком шаге объедены действия системы и библиотекаря...
4. Согласен, добавлю альтернативный сценарий к первому пункту.
5. Ну... я таким образом хотел прервать процесс выполнения сценария и, возможно, вернуться к поиску новой книги. А каким образом можно прервать процесс выполнения?
-
«Идеальный» юскейс:
Предусловие:
* Читатель проносит книгу мимо камеры системы, выходя из библиотеки
Основной поток:
1. Система распознаёт читателя и книгу и фиксирует факт взятия книги
Всё.
-
2Humbert:
1. Пользователь - читатель, имеющий читательский билет. Предполагается, что до начала процесса он сообщает какая книга ему нужна, а остальная информация известна.
2. Добавил пункт выдачи книги, спасибо.
3. Альтернативный сценарий (исключения) лучше записывать ПОСЛЕ основного сценария?
Не могу понять в каком шаге объедены действия системы и библиотекаря...
4. Согласен, добавлю альтернативный сценарий к первому пункту.
5. Ну... я таким образом хотел прервать процесс выполнения сценария и, возможно, вернуться к поиску новой книги. А каким образом можно прервать процесс выполнения?
1. Что понимается под читательским билетом? Его читатель носит с собой или он хранится в библиотеке? Если библиотека автоматизирована, то каковы его функции? Как про этот билет и что с ним делать узнает система?
2. Если книга выдается в этом сценарии, то как она оказывается у библиотекаря или читателя? Процесс физического поиска кстати тоже может быть неуспешен.
3. Да. Формат сценария хорошо описан у Коберна. Насчет объединения действия SuD и ДЛ я ошибся
5. Если не находится читательский билет, книга в каталоге или физически, то в качестве одной из альтернатив выступает отказ от выдачи книги.
Повторно рекомендую
Alistair Cockburn - Writing Effective Use-Cases
(есть и на русском)
Вы избежите многих ошибок, если хотя бы бегло ознакомитесь с ней.
-
«Идеальный» юскейс:
Предусловие:
* Читатель проносит книгу мимо камеры системы, выходя из библиотеки
Основной поток:
1. Система распознаёт читателя и книгу и фиксирует факт взятия книги
Всё.
1а Система не распознает читателя
1b Система не распознает книгу
1с Система распознает книгу, лежащую рядом с выходом и ошибочно считает, что ее вынес читатель
1d Факт взятия книги не удалось зафиксировать - она числится у другого читателя
.....
Убрали библиотекаря из процесса, поставили считыватели, а сценарий почти не изменился
-
В первую очередь меня интересуют логические ошибки.
Но и указание на технические ошибки не повредит))
В целом, ошибок масса, да?
На самом деле нет каких-то стандартных принципов написания спецификации варианта использования. В принципе Вы можете придумать свой способ и стиль, главное, чтобы он отвечал Вашим целям и был понятен Вашей команде.
Существуют различные рекомендации, которые продиктованы практикой. В нашем FAQ есть пример таких рекомендаций (http://www.uml2.ru/faq-use-cases/). Участники форму уже дали свои рекомендации и советы.
С точки зрения логичности - тут тоже можно спорить, но мне кажется это условие
5. Система удостоверяется, что есть возможность выдачи книги на указанный номер читательского билета. В противном случае выводит сообщение о том, что выдача по указанному номеру читательского билета не возможна. Возвращается к п. 4
должно быть предусловием к выполнению Вашего ВИ. Т.е. можно выдать книгу только тому, у кого все в порядке изначально
-
Спасибо всем, кто проявил активность и помог мне с задачей! :) :)
Уважаемые аналитики, помогите, пожалуйста еще с одной:
Мне требуется дополнить диаграмму сущность-связь для описания модели автоматизации библиотеки. Была дана диаграмма (все, что ченым цветом - было дано) на которой нужно было нарисовать недостающие объекты (дорисованное мной выделено красным цветом). Ссылки из одного объекта на другой, являющиеся реализацией связи один-ко-многим.
Главное требование: необходима возможность вести учет взятых читателями книг (какой читатель когда взял какую книгу).
(http://demo1234124.mcdir.ru/diagramm.jpg)
Всё ли я сделал верно?
-
Уважаемые аналитики, помогите, пожалуйста еще с одной:
Мне требуется дополнить диаграмму сущность-связь для описания модели автоматизации библиотеки.
Нельзя не отметить странность того, от чего Вам предложено отталкиваться. Плюсики и минусики на т. н. "диаграмме сущность-связь" что должны изображать по мнению её составителя? Экземпляр книги на полке (на нескольких полках?), полка в нескольких стеллажах? Как найти экземпляр? К какому стеллажу идти?
Если не обращать внимания на вышесказанное, то Вы скорее всего справились со стоящей перед Вами задачей. Добавлю, что можно отмечать действительную дату возвращения книги и дату, до которой книга должна быть возвращена. Это поможет определять величину задержки книги нерадивым читателем и, например, начислять разные штрафы. С другой стороны, если правила библиотеки устанавливают одинаковый срок, на который выдаётся книга, хранить ещё одну дату не обязательно. Она может быть вычислена.
-
С другой стороны, если правила библиотеки устанавливают одинаковый срок, на который выдаётся книга, хранить ещё одну дату не обязательно. Она может быть вычислена.
Популярные грабли. Все хорошо будет до тех пор, пока этот срок не начнут менять.
-
Популярные грабли. Все хорошо будет до тех пор, пока этот срок не начнут менять.
+100500
Самое простое пойти на некоторую избыточность и запоминать этот срок в атрибуте. А то потом вылезут разные категории читателей, разные категории книг, межбиблиотечный абонемент со своими правилами
-
Популярные грабли. Все хорошо будет до тех пор, пока этот срок не начнут менять.
Другие популярные грабли называются YAGNI. Можно делать вид, будто всерьёз делаешь ПО для библиотеки, а можно делать вид, что даёшь советы по учебному примеру. Что ему больше подходит, каждый решает за себя, не за другого.
-
Другие популярные грабли называются YAGNI.
Согласен. Регулярно сталкиваюсь с последствиями деятельности адептов этой концепции.
-
Популярные грабли. Все хорошо будет до тех пор, пока этот срок не начнут менять.
Угу. Плюс для разных книг срок разный (в зависимости от популярности).
-
Согласен. Регулярно сталкиваюсь с последствиями деятельности адептов этой концепции.
При решении учебных примеров? Вы найдите библиотечного ИТшника и обсудите с ним задачу. Уверен, он покрутит пальцем у виска. Автоматизации в библиотеке подлежит вовсе не работа с читателями.
Если мы всё ещё играем в библиотеку, откуда знать, важны ли сроки возврата книг вообще? Может быть, при входе в круг читателей надо внести залог, размер которого покрывает любой возможный ущерб. Может быть, самодеятельную библиотеку соорудили коллеги по работе, которые хорошо друг друга знают и не видят в задержанной книге повода для претензий друк к другу.
Я не понимаю Вашего подхода. Из двух предложенных альтернатив (двух, чтобы новичок видел, что нет одного "правильного" ответа) Вы вырезаете одну (как-будто другой не было). Вырезали и что теперь?
-
При решении учебных примеров?
В работе.
Вы найдите библиотечного ИТшника и обсудите с ним задачу. Уверен, он покрутит пальцем у виска.
Зачем мне это?
Если мы всё ещё играем в библиотеку, откуда знать, важны ли сроки возврата книг вообще?
...
Я не понимаю Вашего подхода.
Библиотеку? Я отметил в рекомендациях подход, применение которого (безотносительно предметной области) делает жизнь и предметных специалистов, и автоматизаторов значительно ярче и богаче. О чем и отписал.
Из двух предложенных альтернатив (двух, чтобы новичок видел, что нет одного "правильного" ответа) Вы вырезаете одну (как-будто другой не было). Вырезали и что теперь?
Разве я могу что-то вырезать из Вашего текста? Я могу разве что ткнуть пальцем в откровенно неудачное решение, приводящее к массе проблем в ближайшем же обозримом будущем (но не сегодня).
Дабы новичок видел, что не все альтернативы одинаково полезны. Может быть, это убережет его от получения личного опыта (и кто знает - может, даже меня от ликвидации последствий его получения новичком).
-
Зачем мне это?
Чтобы вернуться в реальный контекст.
Библиотеку? Я отметил в рекомендациях подход, применение которого (безотносительно предметной области) делает жизнь и предметных специалистов, и автоматизаторов значительно ярче и богаче. О чем и отписал.
Подход? KICK?
Разве я могу что-то вырезать из Вашего текста?
Да. Можете, Вы это доказали. В тексте было две альтернативы. Осталась одна.
Я могу разве что ткнуть пальцем в откровенно неудачное решение, приводящее к массе проблем в ближайшем же обозримом будущем (но не сегодня).
Массе проблем в решении учебного примера? О каком обозримом будущем идёт речь? О том, в котором модель не высечена из камня, в котором эскиз развивается в решение не по принципу "я знаю, где тут должно положить соломки", а по ходу изучения предметной области?
Дабы новичок видел, что не все альтернативы одинаково полезны. Может быть, это убережет его от получения личного опыта (и кто знает - может, даже меня от ликвидации последствий его получения новичком).
Уберечь новичка от получения личного опыта? Вы уверены, что хотите ему тем самым добра? И я так и не понял, Вы одну и ту же библиотеку устраиваетесь автоматизировать? Где каталогизация? Дублинское ядро? ISBNы где, в конце концов? Давайте уж тогда скажем прямо, что задачу из сообщения, открывшего тему, решать на самом деле не надо, так как она высосана из пальца.
-
Чтобы вернуться в реальный контекст.
Что-то Вы меня совсем не понимаете. Библиотека не при чем. Метод обработки данных, при котором данные пересчитываются каждый раз, когда понадобятся, в надежде на то, что правила пересчета заданы раз и навсегда - плохой метод*. Этому надо учить новичков.
Не стоит в качестве примеров давать новичкам методы, которые чреваты массой проблем даже на близком горизонте. Учить надо хорошему, плохому они сами научатся.
И да, я хочу уберечь новичка от получения "личного опыта". Особенно, если результат может коснуться меня. Ни к чему какому-то чудаку плясать джигу на минном поле в середине проектной команды, которая идет след-в-след.
* за исключением систем-однодневок.
-
Да, не понимаю. Вы говорите о данных, про которые не известно, нужны ли они. На этом шатком основании делаете выводы о решении. От решения проводите обобщение до метода, который так же огульно объявляете универсально плохим. Учить надо оценивать ситуацию а потом, исходя из неё, решать, что хорошо, а что плохо. И не надо учить, малюя ярлыки: считать всегда плохо, всегда нужно хранить.
И всё это ради чего?
-
От решения проводите обобщение до метода, который так же огульно объявляете универсально плохим.
Потому, что он универсально плохой в том контексте, который был упомянут. Исключение я тоже озвучил.
Учить надо оценивать ситуацию а потом, исходя из неё, решать, что хорошо, а что плохо.
Новичку нечем оценивать ситуацию. Наберется опыта - сможет, а пока лучше прислушиваться к тому, чему учат.
И не надо учить, малюя ярлыки: считать всегда плохо, всегда нужно хранить.
Это уже Ваше изобретение, я такого не утверждал.
-
Ну какое исключение, серьёзно. Вы знаете частоту, когда нужны эти даты? [В версии условий игрушечного примера частота = 0.] Вы уверены, что сразу станет плохо, как только начнут менять? Как менять? Можно привести пример изменения [для библиотеки], не критичного для метода. Можно привести пример критичного. Вы какое изменение предпочтёте?
Если новичку искусственно сужать пространство выбора, он не наберется опыта. Он будет воспроизводить шаблон, спущенный свыше, и всё.
Ярлык подправьте так, как считаете нужным. Дело в ярлыке, а не в конкретной формулировке написанного на нём.
-
Вы знаете частоту, когда нужны эти даты?
Достаточно того, что они нужны. Раз в год или каждые 15 минут - уже не принципиально.
Вы уверены, что сразу станет плохо, как только начнут менять?
Да. Любое изменение метода расчета приведет к утрате адекватности данных за предыдущие периоды.
Этот эффект можно компенсировать, вводя противовес в виде приличной системы версионирования методов расчета, формирования отчетности с плавающей математикой и/или иных костылей. Главное - ни в коем случае не оснащать объекты учета нужными атрибутами.
Как менять?
Как угодно. Можно количественно (с месяца на три), можно качественно (разделить один срок на систему сроков для разных видов книг, как было упомянуто выше).
Можно привести пример изменения [для библиотеки], не критичного для метода. Можно привести пример критичного. Вы какое изменение предпочтёте?
Зависит от того, с какой целью Вы собрались привести пример. Мне сие неведомо, так что на Ваше усмотрение.
Если новичку искусственно сужать пространство выбора, он не наберется опыта. Он будет воспроизводить шаблон, спущенный свыше, и всё.
Новичку надо объяснять, "что такое хорошо, что такое плохо". Или предлагаете предоставить новичкам безграничные возможности учиться на собственных ошибках, невзирая на стоимость этого "обучения" для проектной команды (прежде всего, со стороны исполнителя) и результатов работы в целом?
Ярлык подправьте так, как считаете нужным. Дело в ярлыке, а не в конкретной формулировке написанного на нём.
Ничего не понял, если честно. Зачем мне править какие-то ярлыки, которые только Вы и видите?
-
Где сказано, что они нужны? Вы смотрели юзкейс?
Почему частота не принципиальна при выборе считать/хранить?
Нет. Не любое. Новый метод расчёта может обеспечить сохранение адекватности данных, при некоторых изменениях. При других не сможет. Отсюда и был вопрос "как" и разговор о примере.
Вы слышали выражение "выводимый атрибут"? И кто теперь изобретает то, что собеседник не говорил?
Вы сможете объяснить, почему не хранить, а считать контрольную дату в библиотечной системе плохо? Шире, чем наклеив ярлычки "популярные грабли", "система-однодневка"? Пока _объяснения_ нет.
Где я предлагаю "безграничные возможности"?
Вернёмся назад. Из двух предложенных альтернатив безапелляционно вырезается одна и объявляется плохой.
По-моему, всё прозрачно и ясно. "Популярные грабли", "система-однодневка", "плохой метод" видно не только мне.
-
Уважаемые профессионалы, ведя высокоумные дискуссии, пожалуйста, помните о тех, кто обратился к вам за помощью, исходите из его интересов, а не демонстрируйте свое интеллектуальное превосходство и несравненный жизненный опыт, который самый опыт из опытом, а все остальное тлен.
-
Эдуард, вроде все так и есть. Вопросившему ответили, он поблагодарил. Дальше "профессионалы" (кавычки - это я о себе) роются там, где кроется дьявол. Если наш топикстартер осилит этот диалог (при условии, что он еще с нами), наверняка вынесет что-то для себя полезное. Ну а мы просто развлечемся.
-
Где сказано, что они нужны? Вы смотрели юзкейс?
С ваших слов: "Вы знаете частоту, когда нужны эти даты?". Не "если", а "когда".
Почему частота не принципиальна при выборе считать/хранить?
Достаточно, чтобы потребность возникла всего один раз. Если система не сможет ее удовлетворить - это плохая система.
Вы слышали выражение "выводимый атрибут"?
Неоднократно. Правда, не уверен, что мы вкладываем в это выражение идентичный смысл. Какова цель вопроса?
И кто теперь изобретает то, что собеседник не говорил?
При всем уважении, мне достаточно сложно разбираться в Ваших текстах в плане соотнесения отдельных предложений к тому, что говорил я. Если не сложно, пользуйтесь механизмом цитирования, или поясните хотя бы этот момент.
Вы сможете объяснить, почему не хранить, а считать контрольную дату в библиотечной системе плохо? Шире, чем наклеив ярлычки "популярные грабли", "система-однодневка"? Пока _объяснения_ нет.
Что ж, давайте попробуем на пальцах. Рассмотрим период работы сферической библиотеки с января 2015 по июнь 2015.
Выдает она книги на руки, какую-то часть из них нерадивые читатели задерживают. Согласно приказу от, гм, 11.07.2004г, допустимый срок удержания книги на руках составляет 21 день. Этот момент учтен в библиотечной ИС и она исправно штампует ежемесячные, квартальные, полугодовые и годовые отчеты о количестве случаев нарушений сроков, которые идут на подпись директору и отправляются в вышестоящую инстанцию.
12.03.2015г. библиотека получает новый приказ, в котором допустимый срок удержания книги на руках с 01.04.2015г. увеличивается до 48 дней. Автоматизаторы быстренько допиливают математику ИС, и со второго квартала она так же исправно считает просрочки по новым правилам.
Гром грянул 07.07.2015, когда директор библиотеки вернулся с ковра вышестоящего начальника враскоряку. Оказалось, что полугодовой отчет, который он собственноручно подписал и сдал, никак не бьется с квартальными и ежемесячными. Если просто сложить все помесячно, получается больше, чем в полугодовом. Директору библиотеки объявили выговор за попутку сокрытия недостатков в работе вверенного заведения, лишили премии и заставили прилюдно оправдываться. Директор очень зол на всех.
А ларчик, как нетрудно догадаться, открывался просто. Полугодовой отчет был сформирован по новым правилам, в то время как предыдущий квартальный (и первые три ежемесячных) формировались по старым, более жестким.
Теперь можно заменить сферическую библиотеку на сферичекое Управление ГИБДД, а книги - на госномера. Или библиотеку на ФМС, а книги - на разрешения на работу. Вне зависимости от предметной области, блестящее решение автоматизаторов приведет к одним и тем же результатам. Вполне вероятно, что даже финансовым.
Где я предлагаю "безграничные возможности"?
"Если новичку искусственно сужать пространство выбора, он не наберется опыта."
Искусственно сужать пространство выбора = ограничивать возможности получения им опыта. Не сужать пространство = не ограничивать возможности. Т.е. оставить их безграничными. Нет?
Вернёмся назад. Из двух предложенных альтернатив безапелляционно вырезается одна и объявляется плохой.
(тяжело вздыхает) Можно мне иметь собственное мнение по любой из предложенных альтернатив? Можно мне его высказывать в месте, для этого предназначенном? Спасибо.
Что касается вопросов кройки и шиться - я не модератор, я физически не могу что-то откуда-то вырезать.
По-моему, всё прозрачно и ясно. "Популярные грабли", "система-однодневка", "плохой метод" видно не только мне.
Так если Вам все прозрачно и ясно - чего мы тут целый скролл исписали?
-
Интересно, кроме как в России, где то еще возможны никем не оплачиваемые споры такого интеллектуального уровня и эмоционального напряжения?
-
Интересно, кроме как в России, где то еще возможны никем не оплачиваемые споры такого интеллектуального уровня и эмоционального напряжения?
На забугорных форумах видел то же самое. "В интернете кто-то неправ!" - сила великая.
И почему никем не оплачиваемые? Я вот днем пишу, с работы. Так что оплачиваемые наравне с перекурами, чаепитиями и прочими прогулками по нужде.
-
Выдает она книги на руки, какую-то часть из них нерадивые читатели задерживают. Согласно приказу от, гм, 11.07.2004г, допустимый срок удержания книги на руках составляет 21 день. Этот момент учтен в библиотечной ИС и она исправно штампует ежемесячные, квартальные, полугодовые и годовые отчеты о количестве случаев нарушений сроков, которые идут на подпись директору и отправляются в вышестоящую инстанцию.
12.03.2015г. библиотека получает новый приказ, в котором допустимый срок удержания книги на руках с 01.04.2015г. увеличивается до 48 дней. Автоматизаторы быстренько допиливают математику ИС, и со второго квартала она так же исправно считает просрочки по новым правилам.
Гром грянул 07.07.2015, когда директор библиотеки вернулся с ковра вышестоящего начальника враскоряку. Оказалось, что полугодовой отчет, который он собственноручно подписал и сдал, никак не бьется с квартальными и ежемесячными. Если просто сложить все помесячно, получается больше, чем в полугодовом. Директору библиотеки объявили выговор за попутку сокрытия недостатков в работе вверенного заведения, лишили премии и заставили прилюдно оправдываться. Директор очень зол на всех.
А ларчик, как нетрудно догадаться, открывался просто. Полугодовой отчет был сформирован по новым правилам, в то время как предыдущий квартальный (и первые три ежемесячных) формировались по старым, более жестким.
Ларчик открывается весьма просто, ведением регистра, но регистр замечу не совсем то, о чем тут битва бьется. К тому же атрибут Допустимый срок со всей очевидностью будет сделан историческим.
-
Ларчик открывается весьма просто, ведением регистра, но регистр замечу не совсем то, о чем тут битва бьется. К тому же атрибут Допустимый срок со всей очевидностью будет сделан историческим.
Регистр по сути и есть один из методов обеспечения историчности.
-
Ларчик открывается весьма просто, ведением регистра, но регистр замечу не совсем то, о чем тут битва бьется. К тому же атрибут Допустимый срок со всей очевидностью будет сделан историческим.
Регистр по сути и есть один из методов обеспечения историчности.
Не совсем понимаю, что именно имеется ввиду под "регистром". Если что-то вроде журнала "Выдано такому-то до такого-то числа", то тут даже никакого атрибута "допустимый срок" не требуется. "До такого-то числа" вычисляется по правилам, действующим на момент выдачи и не потеряет актуальности при любых последующих изменениях.
В целом, вариантов обеспечения адекватности исторических данных не сильно много, но есть. У меня же писано про нежелательность применения "антипаттерна" даже в целях обучения, даже на куцем примере.
-
В целом, вариантов обеспечения адекватности исторических данных не сильно много, но есть. У меня же писано про нежелательность применения "антипаттерна" даже в целях обучения, даже на куцем примере.
Леонид, это все Ваши инсинуации :)
-
Леонид, это все Ваши инсинуации :)
Разумеется. Как и все остальные мои посты на форуме. Но исключительно в хорошем смысле этого слова! :)