OberonCore https://forum.oberoncore.ru/ |
|
О задачах, проектировании и тестировании https://forum.oberoncore.ru/viewtopic.php?f=5&t=1437 |
Страница 1 из 3 |
Автор: | Alexey_Donskoy [ Четверг, 02 Апрель, 2009 11:03 ] |
Заголовок сообщения: | О задачах, проектировании и тестировании |
Навеяно этой темой... Однако, по-моему, вопрос рассматривается недостаточно полно, однобоко как-то, как будто не в реальном мире живём с его реальными задачами... Поэтому хочу добавить ремарку об окружении. Любой проект является исследовательским в том смысле, что по ходу его приходится изучать особенности окружения (в том числе исполнителя). Вот где тесты необходимы! Вот примерно как можно представить структуру программного проекта: 1. Модельно-Алгоритмический слой: 1.1. Формальная модель системы (включая мат.модель процессов, структуру данных и т.п.). 1.2. Алгоритмическое решение в рамках модели. 2. Относительно статические внешние связи (внешние по отношению к модельно-алгоритмическому слою): 2.1. Неопределённости спецификаций (идеального ТЗ мне не посчастливилось увидеть ни разу ); причём итерационное уточнение их приводит к п. 3.1. 2.2. Особенности исполнителя (хардваре, ОС, библиотеки, собственные паттерны и т.п.). 2.3. Неполнота документации по исполнителю (включая ОС, компиляторы и т.п.). 3. Динамические внешние воздействия: 3.1. Произвольные изменения спецификаций как во время проектирования, так и во время эксплуатации. 3.2. Форс-мажорные обстоятельства окружения в широком смысле (от таких действий юзера, которые предусмотреть заранее невозможно, до очередного распоряжения Центробанка, которое ставит всё с ног на голову и противоречит здравому смыслу, и вступает в силу уже вчера). 3.3. Технические форс-мажорные обстоятельства (полные или частичные изменения платформы, транспорта и т.п.). 3.4. Несоответствие исполнителя документации. Ну и т.д. Естественно, вес каждой из перечисленных составляющих проекта различен. Возможны крайние случаи, например: - научно-исследовательская задача (где цель есть получение модели) - 1:80%, 2:5%, 3:15%; - инженерно-исследовательская задача (освоение новой платформы, языка и т.п.) - 1:10%, 2:30%, 3:60%; - типовая задача (бухгалтерия какая-нибудь, которй много лет занимались и всё наработано... ну, там новый отчёт родить... затраты пропорциональны количеству форм) - 1:5-20%, 2:10-45%, 3:50-85%. Вот теперь покажите процент применимости доказательного программирования во всех этих случаях. И процент обязательного тестирования во всех этих случаях. |
Автор: | Info21 [ Пятница, 03 Апрель, 2009 09:49 ] |
Заголовок сообщения: | Re: О задачах, проектировании и тестировании |
Alexey_Donskoy писал(а): Вот теперь покажите процент применимости доказательного программирования во всех этих случаях. Да. И процент применимости правил арифметики. Или грамматики. Или привычки сморкаться в платочек, а не в занавеску.
|
Автор: | Alexey_Donskoy [ Пятница, 03 Апрель, 2009 10:16 ] |
Заголовок сообщения: | Re: О задачах, проектировании и тестировании |
Так ведь никто ж не призвывает не соблюдать Хотя я действительно написал смешную фразу... Не процент применимости, конечно, а доля в общих затратах на разработку и эксплуатацию. Кстати сказать, в силу описанного выше возникают два побочных эффекта: 1) Влияние окружения на стоимость разработки (стоимость в любых ресурсах) зачастую существенно. И эта стоимость зачастую превышает стоимость начальной модели и её алгоритмического решения. 2) В огромном кличестве практических случаев попытка минимизировать эту стоимость приводит к нарушению начальной модели (кривым заплаткам). Я не говорю, что это хорошо, я констатирую факт, с которым нельзя не считаться. Ну а тестирование, как все справедливо отмечают, позволяет сохранить хоть какую-то видимость инварианта (независимости от процесса исправления глюков ) |
Автор: | Valery Solovey [ Пятница, 03 Апрель, 2009 12:29 ] |
Заголовок сообщения: | Re: О задачах, проектировании и тестировании |
Цитата: Модель и алгоритмический слой далеко не всегда составляют главный объём программного проекта! Но они задают вектор "главному объёму".
|
Автор: | Axcel [ Пятница, 03 Апрель, 2009 12:37 ] |
Заголовок сообщения: | Re: О задачах, проектировании и тестировании |
Я бы сказал - стержень. Когда и так все рыхло, зыбко иметь стержень дорогого стоит. |
Автор: | Валерий Лаптев [ Четверг, 09 Апрель, 2009 18:46 ] |
Заголовок сообщения: | Re: О задачах, проектировании и тестировании |
В связи с пунктом 3 в первом посте хотелось бы выяснить вот что. Экстремальное программирование, рефакторинг и модульное тестирование возникли в реальном мире именно в связи с постоянно изменяющимися ( ) ) требованиями. Рефакторинг также серьезно применяется при работе с "унаследованным" кодом. Недавно книжка по этому делу вышла - от автора CppUnit и CPPUnitLite. Я тут для своей книжки по системному программированию слепил некую версию xUnit. И собираюсь в мае поисследовать то же самое на ББ. Удивительно, но мне не удалось найти в сети такую систему для Оберонов. Значит ли это, что рефакторинг и модульное тестирование не очень нужны в мире оберонов? Или просто народ об этом не знает? |
Автор: | Александр Ильин [ Четверг, 09 Апрель, 2009 19:35 ] |
Заголовок сообщения: | Re: О задачах, проектировании и тестировании |
Валерий Лаптев писал(а): Значит ли это, что рефакторинг и модульное тестирование не очень нужны в мире оберонов? Или просто народ об этом не знает? Не понимаю, чего тут какими-то "системами" пугать. У меня юнит-тестирование обеспечивается скриптом GNU Make на 37 строк и единственным модулем Tests из 70 строк (включая комментарии по использованию). Экспортированные процедуры:PROCEDURE Begin* (testName: ARRAY OF CHAR); PROCEDURE Report* (ok: BOOLEAN); PROCEDURE End* (); Экспортированные переменные: haltOnError*: BOOLEAN; (** if TRUE, then the next Report (FALSE) will HALT *) Для каждого модуля собирается тестовый консольный Exe, затем все тесты прогоняются до первой ошибки (или дальше, в зависимости от haltOnError). End() нужен для красоты - чтобы группировать тесты. PS: Работаю на XDS Oberon-2. |
Автор: | Info21 [ Четверг, 09 Апрель, 2009 20:01 ] |
Заголовок сообщения: | Re: О задачах, проектировании и тестировании |
Александр Ильин писал(а): Не понимаю, чего тут ... Да уж... слово "система" тут громко звучит, особенно если как в ББ без мейков ни exe. Разве не очевидно, что для каждого модуля будут какие-то тесты в некоем другом модуле... прогнал, да и всё.
|
Автор: | Александр Ильин [ Четверг, 09 Апрель, 2009 20:54 ] |
Заголовок сообщения: | Re: О задачах, проектировании и тестировании |
Info21, да, у меня единственное, что пришлось придумывать и городить, - это автоматическую сборку-прогон с помощью Make. Модуль Tests тривиальный. Единственное, до чего руки пока не дошли, - контролировать выброс ASSERT'ов в ответ на некорректные входные данные. Когда сделаю, добавится ещё одна экспортированная процедура в модуль, и всё. Судя по обилию "систем тестирования", перечисленных в википедии, задача это и в самом деле тривиальная, решённая всеми, кому не лень. |
Автор: | Илья Ермаков [ Четверг, 09 Апрель, 2009 20:56 ] |
Заголовок сообщения: | Re: О задачах, проектировании и тестировании |
Валерий Лаптев писал(а): Значит ли это, что рефакторинг и модульное тестирование не очень нужны в мире оберонов? Не совсем так, а можно сказать вот так: в тех условиях, в которых в настоящее время работает большинство применяющих Оберон. Малые команды X сложные, долгосрочные проекты - сложные интенсивно, а не "вширь". Там эти этапы как таковые просто растворяются... В контексте "конвейера", наверное, это станет востребованным. |
Автор: | Александр Ильин [ Четверг, 09 Апрель, 2009 21:08 ] |
Заголовок сообщения: | Re: О задачах, проектировании и тестировании |
Илья Ермаков писал(а): В контексте "конвейера", наверное, это станет востребованным. А я просто стараюсь всё новое вместе с тестами писать. Потому что если думать не только "как сделать", но и "как сломать", то точнее спецификация интерфейса получается, и "угловых случаев" больше отыскивается, что впоследствии может привести к переосмыслению дизайна и новой постановке задачи. Другими словами, больше думать приходится на единицу кода... Помню, как я, тестируя одну процедуру, неожиданно для себя обнаружил, что если в параметр ARRAY OF CHAR передать один CHAR, то в процедуре будет строка с LEN() = 1 и без нуля на конце. Пришлось поправить предусловия в некоторых других процедурах, чтобы не так строго требовать там ноль в конце строки.
|
Автор: | Info21 [ Четверг, 09 Апрель, 2009 21:14 ] |
Заголовок сообщения: | Re: О задачах, проектировании и тестировании |
Илья Ермаков писал(а): ... сложные интенсивно, а не "вширь". Почему же. Вширь тоже сложные. Как раз ощущаю, что пора подумать насчет более жесткой себе дисциплины поименования тестовых процедур в тестовых модулях Чтобы уж вообще -- тык! и готово.Но всё это как-то само собой -- систематические следствия настоящей модульности и модульно-ориентированного программирования. Не зря Сергей Юрьевич именно модулям целую поэму посвятил |
Автор: | Александр Ильин [ Четверг, 09 Апрель, 2009 21:18 ] |
Заголовок сообщения: | Re: О задачах, проектировании и тестировании |
Кроме того, при работе, когда сроки поджимают, иногда приходится писать такой код, который работает в данном, необходимом здесь и сейчас случае, а не во всех возможных случаях (ибо нет времени изучать и вникать в предмет по полной). Потом, через год, надо добавить ещё один случай, который вдруг понадобился (тоже срочно), и код дополняется или переписывается. Вот тут-то очень поможет автоматический тест, который позволит убедиться, что добавляя второй случай, мы ничего не поломали для первого. Здесь тест работает по своему прямому назначению: не доказывает отсутствие ошибок, а подтверждает работоспособность решения конкретной проблемы / наличие конкретной фичи. |
Автор: | Валерий Лаптев [ Пятница, 10 Апрель, 2009 07:49 ] |
Заголовок сообщения: | Re: О задачах, проектировании и тестировании |
Я так и подозревал, что для Оберонов фактически не нужна среда типа xUnit. Именно потому, что базовой единицей декомпозиции является модуль, а не класс. Вместе с рабочим модулем пишем сразу тестирующий. Все остальное в среде ББ просто уже есть. Таким образом, создатели ББ заранее побеспокоились о Unit тестировании... Тогда задам еще вопрос: а паттерны банды 4-х насколько востреброваны? Судя по xUnit - примерно на таком же уровне. Поскольку xUnit сама основана на 4-5-6 паттернах. |
Автор: | Иван Кузьмицкий [ Пятница, 10 Апрель, 2009 08:06 ] |
Заголовок сообщения: | Re: О задачах, проектировании и тестировании |
Валерий Лаптев писал(а): паттерны банды 4-х насколько востреброваны? Я изучаю среду BlackBox, держа рядом с собой книжку банды, GoF. ББ построен на различных паттернах. Более того! Эта книга упоминается в документации к ББ, раздел "Приёмы проектирования" |
Автор: | Валерий Лаптев [ Пятница, 10 Апрель, 2009 08:12 ] |
Заголовок сообщения: | Re: О задачах, проектировании и тестировании |
Иван Кузьмицкий писал(а): Валерий Лаптев писал(а): паттерны банды 4-х насколько востреброваны? Я изучаю среду BlackBox, держа рядом с собой книжку банды, GoF. ББ построен на различных паттернах. Более того! Эта книга упоминается в документации к ББ, раздел "Приёмы проектирования" Ну, в хелпе я тож об этом читал. Но там же фактически только Модель-Вид-Контроллер рассматривается. |
Автор: | Info21 [ Пятница, 10 Апрель, 2009 10:05 ] |
Заголовок сообщения: | Re: О задачах, проектировании и тестировании |
Вопрос "используются ли паттерны" сам по себе звучит не точно. Раз есть объекты -- конечные автоматы -- значит, будут протоколы их взаимодействия и, соответственно, на следующем уровне сложности, ансамбли таких объектов -- и, соответственно, организация этих ансамблей. В этом смысле не использовать паттерны просто невозможно. Другое дело, что их набор чуть ограничен благодаря сбору мусора и т.п. MVC Carrier-Rider-Mapper фабрика фасад синглтон (= просто модуль) (куда бы еще приткнуть композицию, которая вместо наследования, как-то она у Гаммы и др. тоже называлась, кажется) А в общем, разобрамшись с ББ, Гамма и др. уже не откровение. |
Автор: | Валерий Лаптев [ Пятница, 10 Апрель, 2009 10:21 ] |
Заголовок сообщения: | Re: О задачах, проектировании и тестировании |
опять же, не забывайте, что написана книжка была в 94 году. В то время - это было явление. |
Автор: | Info21 [ Пятница, 10 Апрель, 2009 11:01 ] |
Заголовок сообщения: | Re: О задачах, проектировании и тестировании |
Валерий Лаптев писал(а): опять же, не забывайте, что написана книжка была в 94 году. Не забываю. И что тот же Carrier-Rider был заложен в Оберон где-то в 88, а первая версия Блэкбокса вышла в 93. (Здесь *не* утверждается, упаси бог, что все паттерны придуманы в Обероне.)В то время - это было явление. Гамма и др. -- в сущности, просто популяризаторы, что тоже важно. А с другой стороны -- первыми "ухватившие банан". |
Автор: | Валерий Лаптев [ Пятница, 10 Апрель, 2009 11:05 ] |
Заголовок сообщения: | Re: О задачах, проектировании и тестировании |
Категорически согласен. Банда 4 просто написала классификацию. Ну, и назвала грамотно. А так паттерны в виде неформальных приемов ходили-то уже давно. |
Страница 1 из 3 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |