[Дональд Кнут. Искусство программирования на ЭВМ.]

{09:40} Давно хочу прочитать эту книгу. Хочу, хочу, потом забываю, через некоторое время опять попадается на глаза и опять хочу. Но, честно говоря, так и не определился, действительно ли мне это надо.
У Лёньки, оказывается, есть все тома плюс связанное с ними программное обеспечение. Наверное, попрошу первый том. Если не постесняюсь...

---

{10:01} Мой сегодняшний браузер - Firefox. В моём рейтинге он сейчас на пятом месте. Посмотрим, сможет ли он изменить моё мнение о себе в течение этого дня. ... Ну вот, уже первый минус. После запуска сообщает мне, что обновляется, а потом говорит, что обновления не состоялось и просит меня поискать другие запущенные копии Firefox. А их нет.
{10:35} Удалил Firefox из системы, скачал самую новую версию - 3.6, установил. Пока работает без видимых проблем. Понравилось, как легко можно изменять внешний вид браузера.

---

[Quality Assurance Team Weekly Meeting]

{10:10} Скоро состоится следущий митинг. Не знаю, когда точно, может быть, в среду, но это не важно. Важно то, что не хочется, чтобы на нём опять было скучно. Мне, по крайней мере. Потому что обычно так и случается, нет интересных тем для обсуждения.
Сначала Андрей у всех спрашивает впечатления от прошедшего периода. Обычно никто ничего особенного не рассказывает, ограничиваясь: "Всё было нормально". Скука. Что делать, чтобы этого не было? Нужны события. И начать, как всегда, нужно с себя.
"Кто хочет поучаствовать в разработке системы тестирования?"
Во-первых, нужно интересно рассказать о том, как прошли эти дни. Во-вторых, подготовить список вопросов для других. В-третьих, предложить какие-нибудь темы для обсуждения.
Для этого, к примеру, можно перед самым митингом проглядеть дневник, ведь в нём как раз и отмечаются всё более-менее важные и интересные события.
А ещё можно слушать рассказ кого-то и задавать уточняющие вопросы. Довольно часто это приводит к дискуссии, тема которой, самое интересное, предсказывается с трудом. А ведь это и нужно - внести оживление в ход митинга.

---

[Мартин Фаулер. "UML. Основы".]

Для того, чтобы построить ассоциации между тестами и тест-элементами мне нужен какой-то объект, выступающий от имени всех тест-элементов. Иначе мне придется вырисовывать ассоциации между тестом и всеми тест-элементами, которые он использует... Стоп! А использует ли тест тест-элементы. Я ведь решил, что с тест-элементами тест будет взаимодействовать при посредничестве менеджера тестирования. Соответственно, прямой оссоциации меджу тестом и тест-элементами не будет.
Хорошо. Тогда что такое есть тест? Менеджер тестирования будет работать со всеми тестами. Проектировать ассоциации со всеми - некрасиво, кажется неправильным. Кроме того, если вспомнить "программирование интерфейсами", то реальные объекты сейчас вообще не должны рассматриваться. И вопрос - есть ли у теста интерфейс? У каждого отдельного класса-теста, конечно, есть. Индивидуальный, специфический. Мне не подходит. Значит, нужно создать нечто, общее для всех. И только с этой целью? Подумаю...
Если каждый тест будет общаться с менеджером тестирования с помощью какого-то универсального интерфейса, то можно будет создать ассоциацию один ко многим, то есть один менеджер работает со многими тестами.
Тест - это просто последовательность вызовов тест-элементов и тест-ядер. Никаких дополнительных требований к ним не предъявлятся. Никто к тестам не обращается, они сами по себе. Поэтому их общий интерфейс получается пустым. Тогда для чего он нужен?..
Другое дело тест-элементы. Они должны быть построены по определенному образцу, иметь обязательные методы. Здесь я могу представить общий интерфейс, как раз и задающий нужную структуру. Или общий класс-родитель с абстрактными методами.
Кстати, менеджер тестирования тоже должен иметь свой интерфейс? Или даже интерфейсы. Тестам, к примеру, не нужны все методы менеджера, вот и не нужно им всё видеть. Или можно сделать специального помощника, который будет работать с тестами, которые, в принципе, только и будут делать, что запрашивать исполнение тест-элементов и тест-ядер.
-----
{12:53} Ну вот... Взялся за Фаулера и по ходу перешёл на моделирование системы тестирования. Благодаря новой точке зрения, навеянной чтением, возникли мысли, которых раньше не было. Посмотрим, сильно ли они изменят модель.
-----
А потом ещё подумал и ... В общем, получается, что между тестом и менеджером тестирования вообще нельзя ассоциацию построить. Тест использует менеджер, запрашивая у него услуги, оставаясь при этом полностью от него независимым. Тест вполне может обратиться к другому источнику подобной услуги. Впрочем... Тест оказывается клиентом для менеджера. Соответственно, менеджер каким-то образом регистрирует тест, хотя бы для того, чтобы отметить эту информацию в логе. И тест должен эти данные менеджеру передать, представиться. Вот это - общий метод для всех тестов. Получается, всё-таки есть ассоциация... С другой стороны, сам тест должен же знать, к кому обращаться за услугами. Он должен либо сделать запрос, либо знать об этом заранее. А менеджер должен предоставить тесту информацию о том, какие именно услуги онм может предложить. Да, ассоциация определённо есть. И некоторые методы уже прорисовались. Это и называется программированием интерфейса?..
-----
{14:05} Чтение про диаграммы классов поворачивает мозги под неиспользуемыми ранее углами. Использование различных точек зрения для рассмотрения одного и того же, в принципе, действительно помогает увидеть очень и очень многое. Важно, чтобы эти точки зрения были чётко определены, и сопровождались собственными списками вопросов, на которые нужно ответить. И касается это не только программирования. Чем больше читаю про варианты использования и диаграммы классов, тем больше вижу возможностей применения в обычной жизни. Они и применяются, только неосознанно. Гораздо удобнее вывести это неосознанное в сознательное.

---

{16:59} Обработал ещё одну часть Лёнькиных замечаний - относительно дизайна. 4 из 7 получили дальнейшее продолжение в Мантисе. Исправят ли - вопрос, ибо уже сопротивляются. Но факты зафиксированы документально! :) ~ [...]