OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Вторник, 19 Март, 2024 06:34

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 43 ]  На страницу 1, 2, 3  След.
Автор Сообщение
СообщениеДобавлено: Четверг, 02 Апрель, 2009 11:03 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1053
Откуда: Россия, Чебоксары
Навеяно этой темой... Однако, по-моему, вопрос рассматривается недостаточно полно, однобоко как-то, как будто не в реальном мире живём с его реальными задачами... Поэтому хочу добавить ремарку об окружении.

Любой проект является исследовательским в том смысле, что по ходу его приходится изучать особенности окружения (в том числе исполнителя). Вот где тесты необходимы!

Вот примерно как можно представить структуру программного проекта:

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%.

Вот теперь покажите процент применимости доказательного программирования во всех этих случаях.
И процент обязательного тестирования во всех этих случаях.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 03 Апрель, 2009 09:49 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Alexey_Donskoy писал(а):
Вот теперь покажите процент применимости доказательного программирования во всех этих случаях.
Да. И процент применимости правил арифметики. Или грамматики. Или привычки сморкаться в платочек, а не в занавеску.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 03 Апрель, 2009 10:16 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1053
Откуда: Россия, Чебоксары
Так ведь никто ж не призвывает не соблюдать :)
Хотя я действительно написал смешную фразу... Не процент применимости, конечно, а доля в общих затратах на разработку и эксплуатацию.


Кстати сказать, в силу описанного выше возникают два побочных эффекта:

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

2) В огромном кличестве практических случаев попытка минимизировать эту стоимость приводит к нарушению начальной модели (кривым заплаткам). Я не говорю, что это хорошо, я констатирую факт, с которым нельзя не считаться.

Ну а тестирование, как все справедливо отмечают, позволяет сохранить хоть какую-то видимость инварианта (независимости от процесса исправления глюков :lol: )


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 03 Апрель, 2009 12:29 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1538
Откуда: Беларусь, Минск
Цитата:
Модель и алгоритмический слой далеко не всегда составляют главный объём программного проекта!
Но они задают вектор "главному объёму".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 03 Апрель, 2009 12:37 

Зарегистрирован: Понедельник, 05 Июнь, 2006 09:49
Сообщения: 327
Откуда: Ленинград, Емельянов Алексей Николаевич
Я бы сказал - стержень.
Когда и так все рыхло, зыбко иметь стержень дорогого стоит.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 09 Апрель, 2009 18:46 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
В связи с пунктом 3 в первом посте хотелось бы выяснить вот что.
Экстремальное программирование, рефакторинг и модульное тестирование возникли в реальном мире именно в связи с постоянно изменяющимися ( :)) ) требованиями.
Рефакторинг также серьезно применяется при работе с "унаследованным" кодом. Недавно книжка по этому делу вышла - от автора CppUnit и CPPUnitLite.
Я тут для своей книжки по системному программированию слепил некую версию xUnit. И собираюсь в мае поисследовать то же самое на ББ. Удивительно, но мне не удалось найти в сети такую систему для Оберонов.
Значит ли это, что рефакторинг и модульное тестирование не очень нужны в мире оберонов? Или просто народ об этом не знает?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 09 Апрель, 2009 19:35 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2449
Откуда: Россия, Томск
Валерий Лаптев писал(а):
Значит ли это, что рефакторинг и модульное тестирование не очень нужны в мире оберонов? Или просто народ об этом не знает?
Не понимаю, чего тут какими-то "системами" пугать. У меня юнит-тестирование обеспечивается скриптом 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.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 09 Апрель, 2009 20:01 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Александр Ильин писал(а):
Не понимаю, чего тут ...
Да уж... слово "система" тут громко звучит, особенно если как в ББ без мейков ни exe. Разве не очевидно, что для каждого модуля будут какие-то тесты в некоем другом модуле... прогнал, да и всё.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 09 Апрель, 2009 20:54 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2449
Откуда: Россия, Томск
Info21, да, у меня единственное, что пришлось придумывать и городить, - это автоматическую сборку-прогон с помощью Make. Модуль Tests тривиальный. Единственное, до чего руки пока не дошли, - контролировать выброс ASSERT'ов в ответ на некорректные входные данные. Когда сделаю, добавится ещё одна экспортированная процедура в модуль, и всё.

Судя по обилию "систем тестирования", перечисленных в википедии, задача это и в самом деле тривиальная, решённая всеми, кому не лень.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 09 Апрель, 2009 20:56 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Валерий Лаптев писал(а):
Значит ли это, что рефакторинг и модульное тестирование не очень нужны в мире оберонов?

Не совсем так, а можно сказать вот так: в тех условиях, в которых в настоящее время работает большинство применяющих Оберон. Малые команды X сложные, долгосрочные проекты - сложные интенсивно, а не "вширь". Там эти этапы как таковые просто растворяются...
В контексте "конвейера", наверное, это станет востребованным.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 09 Апрель, 2009 21:08 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2449
Откуда: Россия, Томск
Илья Ермаков писал(а):
В контексте "конвейера", наверное, это станет востребованным.
А я просто стараюсь всё новое вместе с тестами писать. Потому что если думать не только "как сделать", но и "как сломать", то точнее спецификация интерфейса получается, и "угловых случаев" больше отыскивается, что впоследствии может привести к переосмыслению дизайна и новой постановке задачи. Другими словами, больше думать приходится на единицу кода... Помню, как я, тестируя одну процедуру, неожиданно для себя обнаружил, что если в параметр ARRAY OF CHAR передать один CHAR, то в процедуре будет строка с LEN() = 1 и без нуля на конце. Пришлось поправить предусловия в некоторых других процедурах, чтобы не так строго требовать там ноль в конце строки.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 09 Апрель, 2009 21:14 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Илья Ермаков писал(а):
... сложные интенсивно, а не "вширь".
Почему же. Вширь тоже сложные. Как раз ощущаю, что пора подумать насчет более жесткой себе дисциплины поименования тестовых процедур в тестовых модулях :) Чтобы уж вообще -- тык! и готово.

Но всё это как-то само собой -- систематические следствия настоящей модульности и модульно-ориентированного программирования.
Не зря Сергей Юрьевич именно модулям целую поэму посвятил :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 09 Апрель, 2009 21:18 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2449
Откуда: Россия, Томск
Кроме того, при работе, когда сроки поджимают, иногда приходится писать такой код, который работает в данном, необходимом здесь и сейчас случае, а не во всех возможных случаях (ибо нет времени изучать и вникать в предмет по полной). Потом, через год, надо добавить ещё один случай, который вдруг понадобился (тоже срочно), и код дополняется или переписывается. Вот тут-то очень поможет автоматический тест, который позволит убедиться, что добавляя второй случай, мы ничего не поломали для первого.

Здесь тест работает по своему прямому назначению: не доказывает отсутствие ошибок, а подтверждает работоспособность решения конкретной проблемы / наличие конкретной фичи.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 10 Апрель, 2009 07:49 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
Я так и подозревал, что для Оберонов фактически не нужна среда типа xUnit.
Именно потому, что базовой единицей декомпозиции является модуль, а не класс. Вместе с рабочим модулем пишем сразу тестирующий. Все остальное в среде ББ просто уже есть.
Таким образом, создатели ББ заранее побеспокоились о Unit тестировании... :)

Тогда задам еще вопрос: а паттерны банды 4-х насколько востреброваны?
Судя по xUnit - примерно на таком же уровне. Поскольку xUnit сама основана на 4-5-6 паттернах.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 10 Апрель, 2009 08:06 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2935
Откуда: г. Ярославль
Валерий Лаптев писал(а):
паттерны банды 4-х насколько востреброваны?


Я изучаю среду BlackBox, держа рядом с собой книжку банды, GoF. ББ построен на различных паттернах. Более того! Эта книга упоминается в документации к ББ, раздел "Приёмы проектирования" :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 10 Апрель, 2009 08:12 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
Иван Кузьмицкий писал(а):
Валерий Лаптев писал(а):
паттерны банды 4-х насколько востреброваны?


Я изучаю среду BlackBox, держа рядом с собой книжку банды, GoF. ББ построен на различных паттернах. Более того! Эта книга упоминается в документации к ББ, раздел "Приёмы проектирования" :)

Ну, в хелпе я тож об этом читал. Но там же фактически только Модель-Вид-Контроллер рассматривается.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 10 Апрель, 2009 10:05 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Вопрос "используются ли паттерны" сам по себе звучит не точно.
Раз есть объекты -- конечные автоматы -- значит, будут протоколы их взаимодействия и, соответственно, на следующем уровне сложности, ансамбли таких объектов -- и, соответственно, организация этих ансамблей.

В этом смысле не использовать паттерны просто невозможно.

Другое дело, что их набор чуть ограничен благодаря сбору мусора и т.п.

MVC
Carrier-Rider-Mapper
фабрика
фасад
синглтон (= просто модуль)
(куда бы еще приткнуть композицию, которая вместо наследования, как-то она у Гаммы и др. тоже называлась, кажется)

А в общем, разобрамшись с ББ, Гамма и др. уже не откровение.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 10 Апрель, 2009 10:21 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
опять же, не забывайте, что написана книжка была в 94 году.
В то время - это было явление.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 10 Апрель, 2009 11:01 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Валерий Лаптев писал(а):
опять же, не забывайте, что написана книжка была в 94 году.
В то время - это было явление.
Не забываю. И что тот же Carrier-Rider был заложен в Оберон где-то в 88, а первая версия Блэкбокса вышла в 93. (Здесь *не* утверждается, упаси бог, что все паттерны придуманы в Обероне.)

Гамма и др. -- в сущности, просто популяризаторы, что тоже важно.
А с другой стороны -- первыми "ухватившие банан".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 10 Апрель, 2009 11:05 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
Категорически согласен. Банда 4 просто написала классификацию. Ну, и назвала грамотно.
А так паттерны в виде неформальных приемов ходили-то уже давно.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 43 ]  На страницу 1, 2, 3  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB