OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Воскресенье, 16 Июнь, 2019 17:43

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




Начать новую тему Ответить на тему  [ Сообщений: 7 ] 
Автор Сообщение
СообщениеДобавлено: Понедельник, 19 Апрель, 2010 22:11 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9121
Откуда: Россия, Орёл
Пока публикую в этом разделе, планируется введение раздела "Программная инженерия", куда отсюда темы и перенесём.

Статья "От ремесла к инженерии; от мастерской - к заводу программных систем".



Подготовлена в качестве пленарного доклада для конференции "Новые информационные технологии-2010" (http://nit.miem.edu.ru/).
К сожалению, до типографии не успела и в сборнике напечатана не будет.


Вложения:
a-042-sudak-lection-2010-eie.odt [59.86 КБ]
Скачиваний: 564
Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 20 Апрель, 2010 08:36 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3055
Откуда: Астрахань
1. Статья понравилась.
2. Можно толкнуть в журнал. Например, в Открытое образование. Или в инет-журнал "Наука и образование".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 20 Апрель, 2010 08:52 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9121
Откуда: Россия, Орёл
Ну, у меня подходов на них нет - а времени их налаживать - тоже :)

Статья в первую очередь писалась как изложение сформировавшейся к настоящему моменту в голове картины. Как докУмент, на который можно посылать, не повторяя сто раз одно и то же.


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

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3055
Откуда: Астрахань
Илья Ермаков писал(а):
Ну, у меня подходов на них нет - а времени их налаживать - тоже :)

Статья в первую очередь писалась как изложение сформировавшейся к настоящему моменту в голове картины. Как докУмент, на который можно посылать, не повторяя сто раз одно и то же.

Да там никаких подходов и не надо. Просто пишете главреду непосредственно по адресу. Он быстро отвечает...
В Открытом образовании единственное условие - быть подписанным на журнал. Без этого не печатают.
Так я подписан, если что... :)
Сейчас они формируют третий номер. В крайнем случае, в четвертый можно.
Журнал по тематике - как раз самое то...


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

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Илья Ермаков писал(а):
Подготовлена в качестве пленарного доклада для конференции "Новые информационные технологии-2010" (http://nit.miem.edu.ru/).
К сожалению, до типографии не успела и в сборнике напечатана не будет.

Да, хорошо сказано... Как обычно, возникают и общие вопросы, и конкретные - теоретические и практические. Конкретные для удобства выделю в другие сообщения - см. теорию и практику; здесь в общем по некоторым положениям.
О нефиксации процесса неформального созидания в п.6 Разд.II (что уже хорошо известно в виде правила "указывай человеку-исполнителю, ЧТО делать, но не указывай, КАК" :)) - регламентация процессов создания действительно проскальзывает в документах СМК. В то же время никого, наверно, не удивляет существование техподготовки производства, где ставится задача именно разработки некоего процесса создания (ну и обеспечивающих его систем инструмента и приспособлений). В чём тут дело? Полагаю, в том, что исполнитель такой задачи поднимается по отношению к задаче, решаемой созидаемой системой, на более высокий уровень рассмотрения, где процесс созидания системы-решателя автоматически становится
"тем, ЧТО", а не "тем, КАК" - и тем самым оказывается не жёстко фиксированным процесс создания процесса, что и нужно для творчества. Именно это имеется в виду, когда говорят, допустим, о реинжиниринге. Другое дело, что этот процесс в отчуждённом виде будет вполне формальным (не "интеллектуальным", как в сознании, а "интеллектным") - иначе не получится хотя бы по тому же Фридланду - и для творческого созидания во многом рамочным, как та же ТРИЗ. Видимо, это хорошо понимал тот же Грабин - тоже не фиксируя, КАК трудиться разработчику, а только связывая его нормами, ЧТО должно получиться (система/процесс с соблюдением стандартов при минимальной трудоёмкости). В своей отрасли он именно это рассматривал как ключ к преодолению того, что "типовой характер решаемых задач и конвейерный стиль работы способствует сужению кругозора <разработчиков>", что видно из выдержки в этом сообщении - не будет ли это справедливо и для программной инженерии?
    Кстати, автор книги по ТРИЗ, выдержка из которой в этом сообщении хорошо сказал: "любая деятельность вырастает из принципов её организации" (Орлов М.А., с.8). Поэтому общее представление о процессе созидания д.б. зафиксировано (отчуждено в документальной форме на общеприменимом комплексе языков) - что не мешает человеку, восприняв его, в конкретном случае действовать по-своему ("ТРИЗ не заменяет творческого мышления, а только является его инструментом" - с. 66, "... конечно, каждая техническая задача по-своему индивидуальна... Магической формулы <поиска решения> нет, но есть приёмы, достаточные для большинства случаев." - с.56). В целом получается то, что выражено "правилом братьев Стругацких" - "инструкция - для тех, кто ещё не умеет" :) - воспринял человек/коллектив инструктивно формализованный опыт и стал применять его в чём-то по-своему.
Весьма возможно, "мёртвые" примеры фиксации были основаны как раз на отсутствии вышеуказанного иерархического подъёма, попытках дать "раз и навсегда" методику КАК - и в системе ИСО900Х, боюсь, т. зр. и правда не самая оптимальная... Реалистичная и проверенная практикой организация коллективного процесса применительно к ИТ, IMHO, содержится в методологии IDEF.

Опираясь на результат предыдущей смены уровня рассмотрения, можно подняться ещё раз - и при этом вырастает разновидность той самой "иерархии абстракций", об умении строить которую "поэтапно и аккуратно" Илья тоже говорил здесь в п.3 Разд.II. Да, велика инерция - впервые об этом принципе как основе представления о ПО (да и вообще о сложных системах) я, скажем, прочитал ещё в "Современном компьютере" в статье об ОС - но прошло четверть века, а необходимость этого надо ещё доказывать ;)

В пп.3,4 Разд.I существенное место занимает установление связи математики и информатики. Кроме того, о чём говорил Паронджанов - когнитивной неэргономичности математики (у Ильи "неприученность математиков к хорошей организации формальных текстов — к глубокому
структурированию, простоте и ясности выражения") - здесь надо вспомнить, что существует логика и математика "здравого смысла", что выявлено в попытках построения интеллектных инфорсим. Её "не учат в школе", но именно она служит основой как деятельности, так и её объяснения - для большинства людей единственной. Поэтому "строгой" математики и информатики мало - нужно исходить и из "нестрогой", рассчитанной на исполнение интеллектом, о чём подробнее в этом сообщении. И только для программирования информашин нужно выделять ограниченную часть модели деятельности, которую можно строго математизировать, и так её и рассматривать как часть.

Что из этого вытекает? Прежде всего необходимость учить общим формальным законам решения задач прежде, чем напускать на конкретные задачи получаемой специальности. Помнится, во втузах есть курс "Основы технического творчества" - но достигает ли он такой цели? Если нет - как бы не пришлось включать этот вопрос в курс общей информатики...

Очень интересна аналогия доказательного синтеза программ и материальных конструкций по результатам расчёта на прочность в п.5 Разд.I - в то же время в сопромате на каждом шагу встречаются "коэффициенты запаса" на неопределённость свойств (прежде всего физических) рассчитываемого объекта. Видимо, что-то должно играть эту роль и для объектов программирования?
Положение о взгляде "между строк" формальной информодели вызывает тоже очень естественную аналогию с тем, как создатель материальных систем по чертежу представляет себе (или симулирует машинно) объект в рабочем движении (всё ли при этом происходит, как задумано) и его элементы (детали, узлы, агрегаты) в процессе создания - обеспечивается ли прежде всего "собираемость", а затем - нужная трудоёмкость сборки? И здесь, думаю, в основе лежат физические состояния информашины как исполнителя - именно их закономерной сменой обеспечивается правильный переход от команды к команде - а если готовят не проектировщика/эксплуатационника оборудования, то надо давать лишь некие понятия об этих состояниях.
Далее, конечно, идут логические состояния, и здесь возникает вопрос - Вейценбаум в приведённой цитате, полагаю, совершенно прав - а что будет альтернативой программированию обработки "специальных случаев" (читай - исключений?)? Имеется в виду, что они исключаются логикой (скажем, контролем данных, чтобы не получались недопустимые значения) и/или что-то иное?

Ну, понимание программы как конструкции, IMHO, лучше всего формируется при визуальном представлении её структуры - как и сделано в техноязыке... И в сопоставлении визуального с текстовым, наверное, проще всего вырабатывать умение находить подобие и совершать переходы.
И действительно, как хорошо было бы "выбрать язык один раз", как о том пишется в п.5 Разд.II...

О структурировании информационных фондов в п.6 Разд.II - основой для этого, IMHO, д.б. документ, обеспечивающий структуризацию. Такой принцип установил Паронджанов, говоря о схематизации знаний - и нужен стандарт на схематизирующий проектный документ, позволяющий сочинителю создавать свою структуру, но из типового множества элементов, понимаемых однозначно всеми участниками. Об этом опять-таки подробнее в другом сообщении.

Хотелось бы публикации и её обсуждения... хотя сегодня, пожалуй, уже формируется другая культура, в т.ч. научная, центричная относительно не натуральной периодики, а как раз инфорсетевых СМИП, напр. данного ресурса - но нормативно это не закреплено. :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 23 Апрель, 2010 08:22 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9121
Откуда: Россия, Орёл
Драконограф писал(а):
Очень интересна аналогия доказательного синтеза программ и материальных конструкций по результатам расчёта на прочность в п.5 Разд.I - в то же время в сопромате на каждом шагу встречаются "коэффициенты запаса" на неопределённость свойств (прежде всего физических) рассчитываемого объекта. Видимо, что-то должно играть эту роль и для объектов программирования?


Ну, например, при вещественной арифметике начинаются большие такие тонкости в свойствах программ.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 06 Май, 2010 12:59 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
На сообщение viewtopic.php?p=46395#p46395
Илья Ермаков писал(а):
Ну, например, при вещественной арифметике начинаются большие такие тонкости в свойствах программ.

Ну да, нарушение законов арифметики, справедливых для целых чисел :) А чтобы это не сильно напрягало - вводим один/два/много лишних разрядов для точности - аналогия прямая. Правда, с позиций Математики-2 иногда надо также проверить решение на сохранение корректности и при необходимости преобразовать - так сказать, выбрать другую конструкцию для работы под такой нагрузкой :D.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 7 ] 

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


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

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


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

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