106
Примеры / Re: Сценарий использования выдачи книги
« : 31 Марта 2016, 18:27:08 »Леонид, это все Ваши инсинуации
Разумеется. Как и все остальные мои посты на форуме. Но исключительно в хорошем смысле этого слова!
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
Леонид, это все Ваши инсинуации
Ларчик открывается весьма просто, ведением регистра, но регистр замечу не совсем то, о чем тут битва бьется. К тому же атрибут Допустимый срок со всей очевидностью будет сделан историческим.
Регистр по сути и есть один из методов обеспечения историчности.
Хочу с вашей помощью или подсказками спроектировать некое программное обеспечение. Очень хочу сам разобраться во всем...
Вернее мне нужны подсказки и направления на этапе проектирования ПО...
Постановка задачи.
Необходимо спроектировать и разработать программу для учета посещений пациентами приема у врача.
Целью создания ПО является автоматизация учета приема пациентов.
Основные функции программы:
• Ведение справочника пациентов (добавление/изменение/удаление пациента)
• Ведение приема (простановка отметки о посещении приема)
• Отображение пришедших, записанных и не пришедших пациентов
• Вывод данных о занятых и свободных часах на выбранную дату приема (при записи пациента)
Интересно, кроме как в России, где то еще возможны никем не оплачиваемые споры такого интеллектуального уровня и эмоционального напряжения?
Где сказано, что они нужны? Вы смотрели юзкейс?
Почему частота не принципиальна при выборе считать/хранить?
Вы слышали выражение "выводимый атрибут"?
И кто теперь изобретает то, что собеседник не говорил?
Вы сможете объяснить, почему не хранить, а считать контрольную дату в библиотечной системе плохо? Шире, чем наклеив ярлычки "популярные грабли", "система-однодневка"? Пока _объяснения_ нет.
Где я предлагаю "безграничные возможности"?
Вернёмся назад. Из двух предложенных альтернатив безапелляционно вырезается одна и объявляется плохой.
По-моему, всё прозрачно и ясно. "Популярные грабли", "система-однодневка", "плохой метод" видно не только мне.
Вы знаете частоту, когда нужны эти даты?
Вы уверены, что сразу станет плохо, как только начнут менять?
Как менять?
Можно привести пример изменения [для библиотеки], не критичного для метода. Можно привести пример критичного. Вы какое изменение предпочтёте?
Если новичку искусственно сужать пространство выбора, он не наберется опыта. Он будет воспроизводить шаблон, спущенный свыше, и всё.
Ярлык подправьте так, как считаете нужным. Дело в ярлыке, а не в конкретной формулировке написанного на нём.
От решения проводите обобщение до метода, который так же огульно объявляете универсально плохим.
Учить надо оценивать ситуацию а потом, исходя из неё, решать, что хорошо, а что плохо.
И не надо учить, малюя ярлыки: считать всегда плохо, всегда нужно хранить.
Чтобы вернуться в реальный контекст.
При решении учебных примеров?
Вы найдите библиотечного ИТшника и обсудите с ним задачу. Уверен, он покрутит пальцем у виска.
Если мы всё ещё играем в библиотеку, откуда знать, важны ли сроки возврата книг вообще?
...
Я не понимаю Вашего подхода.
Из двух предложенных альтернатив (двух, чтобы новичок видел, что нет одного "правильного" ответа) Вы вырезаете одну (как-будто другой не было). Вырезали и что теперь?
Другие популярные грабли называются YAGNI.
ссылка на файл с тестом: http://ifolder.su/44884035
А можно поподробнее?
Чем с точки зрения нынешних методик нагрузочного тестирования...отличается от
Бизнес-правила
Системой могут пользоваться только сотрудники организации.
Система работает только с файлами с расширением *.txt
Клиент системы может работать только с файлами, расположенными на сервере.
Данные между клиентом и сервером передаются по протоколу FTP
Атрибуты качества продукта
Производительность:
1. Максимальное количество одновременно работающих клиентов не меньше 100
2. Максимальная частота запросов от пользователя (в минуту) не больше 10
3. Количество исполняемых транзакций (в минуту) не меньше 50
4. Длительность типовых транзакций (операций) не больше 10 секунд
Доступность:
Коэффициент доступности серверной части не менее 96%
Допустимое время простоя (в час) не более 3 минут
Безопасность:
Вероятность утечки данных в результате сбоя не должна превышать 0.1%
Масштабируемость:
Стоимость десятикратного увеличения мощности системы не должна превышать 400%
Атрибуты качества использования
Скорость обучения пользованию программой должна быть менее 10 минут
Удовлетворенность пользователей и средняя оценка продукта должны быть на уровне ожиданий.
С другой стороны, если правила библиотеки устанавливают одинаковый срок, на который выдаётся книга, хранить ещё одну дату не обязательно. Она может быть вычислена.