Илья Ермаков писал(а):
На общие вещи информатики (со стороны информ. моделирования) мне часов в моих предметах не хватает (основы алгоритмизации и программирования; технология разработки программных продуктов, САПР, ПО компьютерных сетей - в первых 3-х я плюю на ГОСы и делаю единый курс программирования;...
А наверное, такой курс и есть один из не то, что возможных - лучших способов усвоить и "общие вещи" на конкретных проектах...
Илья Ермаков писал(а):
Очень нужна наработка эталонного пути получения из новичка нормального инженера-программиста за 3 года;...
Да, наверное, раз инженеров - значит, постараться дать ещё и умение верифицировать формально, и выводить программу... часов на теорию и методы этого, конечно, может потребоваться даже при опоре на конкретные примеры
Я, как можно видеть, в основном размышляю о том, как подготовить непрограммиста, взаимодействующего с этим самым инженером-программистом - и так, чтобы "взаимно сокращать опыты быстротекущей жизни"
за счёт лучшего "интеллектуального взаимопонимания". Имеется в виду "представитель заказчика" в части автоматизации/реинжиниринга. Кто этот специалист в организации заказчика (будем говорить о достаточно крупной - в малых всё ещё долго будет "точно по Михайлову", и тут пока трудно предложить альтернативу - впрочем, м.б. у кого-то есть иной опыт)? По опыту - чаще всего выделенный сотрудник/группа, лучше понимающие трудовые процессы оргсистемы; теоретически при наличии службы качества это д.б. её специалист-аналитик - но не секрет, что служба эта обычно занимается тем, что "рисует для сертификации"
И эту ситуацию можно изменить - а заодно создать ещё один фактор привлечения/удержания серьёзных заказчиков - если предложить инструментарий, увязывающий задачи "реинжиниринга" с инженерным проектированием процессов.И вот хорошо бы, чтобы он не только понимал процессы - но и мог ориентироваться в их автоматизированной реализации - чтобы и приёмка решения грамотно и без лишних трат времени/сил проходила, и в процессе разработки он мог оценить (по "человекочитаемой" модели решения), сохраняется ли соответствие нуждам, сформулированным в ТЗ, принять реалистичные корректировки и где-то, возможно, сам предложить сам иные требования - не "переламывающие объективных законов информатики", но более соответствующие задаче, как он её понимает с позиции заказчика. А для этого и нужно, чтобы программисты ориентировались на описание задач "по нейтральной схеме" в визуальной форме - но опять-таки, дабы не тратить время на "картинки, оторванные от реализации" - визуальный язык д.б. просто отображением прогязыка разработки (с возможностью выборочной детализации и/или определения вариантов непосредственно для узлов и/или компактных фрагментов схем - через вершины-области, как указано
в этом сообщении - и вообще редактор должен поддерживать широкие возможности каталогизации, хотя бы перечисленные в связанном сообщении). Отсюда вытекают и следующие соображения.
Во-первых, сквозным проектом для обучения программиста могла бы разработка компонентов среды визуализации/трансляции в исхтексты (то, что я называю РДП-редактором). Тут и теория програмирования, как я понимаю, "во всей красе" - и практика обширная.
Задачи трансляции непосредственно не приводят к системам процессов РВ, однако если представить РДП-приложение как множество совместно протекающих процессов и потребовать, чтобы некоторые из них могли выполняться параллельно - эта составляющая, очевидно, появится.
Сначала студенты делают версию, которая работает, потом её совершенствуют - и делать это можно непрерывно (исходя хотя бы из соображений, приведённых во введении "Искусства мыть слона" ) - и из родственных, на мой взгляд, у Хейвуда и Кармайкла). При этом визуализируемый язык, ессно, тот же, что язык разработки - тогда дело идёт по принципу "раскрутки". А визуальная "нейтральная" модель становится существенной частью документации на изделие - в основном для разработчика, но также и для грамотного приёмщика - и для независимой экспертизы, если таковая потребуется (а вот взаимопонимание, между прочим, должно максимально способствовать исключению таких ситуаций)...
РДП-редактор, конечно, должен стоять и у разработчика, и у заказчика - только сотрудники последнего обычно пользуются лишь частью его возможностей (другие м.б. вообще "закрыты" настройкой).
Конечно, "предметник" изначально будет описывать логику процессов на "родном" диалекте визуального языка - с неформальными текстами вершин - но структурно этот диалект должен предоставлять те же возможности описания, что и гибридный с прогязыком (параллелизм, исключения, ЦД и пр.). И визуализацию структур абстрактных типов - хотя опять-таки "предметнику" привычнее будет описывать алгообъекты через их "внешние схемы" (см. ниже).
При этом исхтексты должны генерироваться как для прогязыка, так и для специф-языка, входного в среде инженерной проработки изделия - на конкретных стандартах можно увидеть, что и в части описания процесса специф-язык (конкретно - Promela) не обязательно точно совпадает с прогязыком (Оберон/АО) - а для верификации ещё нужно фиксировать требования на *TL-языках - и их тоже нужно визуализировать и включать в РДП-документ.
Собственно трансляция в исхтексты - чисто ИТ-профессиональная тема, но есть и вещи, связанные с тем самым взаимодействием и взаимопониманием представителей сторон разработки. В связи с этим, похоже, актуальны темы подготовки (и поддерживающие пособия) и по верификации, и по приведению решения к "доказуемой" форме. При этом подразумевается, что и грамотный "закпред" их сможет изучить - в идеале, конечно, на курсах организации-разработчика или её партнёра на образовательном направлении (вот и небольшая, но область для бизнеса
- а грамотные, в "когнитивно-эргономичной" форме пособия при распространении поспособствуют привлечению на курсы). И пользоваться - приводя внутри заказчика описания коллег к приемлемому виду (а постепенно и обучая сразу нормально описывать) и тем самым сокращая усилия разработчика (ну и свои затраты на эту часть процесса - если действует ценообразование от сложности разработки, конечно).
Во-вторых, что-то нужно и для "внешней схемы" формализации задачи - эти представления также д.б. частью документации и соответствовать текущей версии изделия. И вот здесь видятся два направления.
С одной стороны, нужна некая совокупность "внешних" языков, которыми нетрудно было бы овладеть и рядовому "предметнику", для выражения различных составляющих отчуждённого профессионального знания как элементов ТЗ. Это и та же визуализация техпроцессов (эскизная), и схема ресурсов (входных/выходных/промежуточных объектов), и "пользовательская" спецификация данных (имена, базовые типы, количественные характеристики), и структура/атрибуты исполнителя (как комплекса рабочих мест с со связями по предметам/данным/энергии). Эти языки тоже надо закладывать в РДП-базис (в основном визуальная часть сводится к возможности рисовать граф-схемы - как правило, произвольные, т.е. многосвязные - из соответствующих знаков/макрознаков). И до "предметников" доводить - в форме опять-таки удобных пособий (здесь уже подготовка особая необязательна - разве что по умению пользоваться - но это как часть программы обучения для РДП-редактора).
Для сложных "предметок" добавляются специфические ЯПЗ уровня 6 (тот же Пролог, язык запросов какой-нибудь).
С другой стороны, надо определять интерфейс "человек-машина" (а в какой-то части - и "человек-человек" через данные) как систему форм. И здесь важен опыт систем типа 1С - вспомним, что пользователю там предлагаются формы входных документов его "предметки" как источники исходных данных для процессов, генерирующих данные для выходных документов. Поэтому нужен язык унифицированного представления любых "внешних" языков в РДП-приложении.
По сути это языки описания "полиграфически" форматированных текстов, таблиц (включая динамические, т.е. "электронные") и тех же схем на граф-языках (отдельные типы вершин которых могут содержать те же тексты, таблицы, графику). Вышеперечисленное содержание в приложении тоже представлено через какой-то метаязык (который называл ТФРД) - и отображено оператору в символической, т.е. "человекочитаемой" форме. Оптимально дать специалисту средства визуального конструирования "внешних форм" с фиксацией свойств полей.
В связи с этим актуальна тематика, которую можно объединить названием "Реализация символических ЯПЗ". Т.е. как формировать часть ТФРД, описывающую в РДП-документе тот или иной язык - визуализации исхтекстов или "внешний" - и как увязывать эти части в целое, и как извлекать из их ТФРД-записи данные для содержательной обработки внутри РДП-приложения (и прежде всего трансляции в файлы исхтекста и ретрансляции исхтекста с обновлением ТФРД текущего проекта) - это с одной стороны. А с другой - как представлять "внешние" языковые элементы/конструкции в экранных/печатных формах (отрисовка встроенной пармграфики и вставных изображений, заполнение фигур форматированным текстом, размещение на диосцене при заданных топологических ограничениях, ещё что-то) и конструировать законченные формы для конкретных задач. И это д.б. поддержано соответствующими пособиями - опирающимися уже на среду программирования (тот же ББ) - т.е. как не просто рисовать интерфейсные формы, пользуясь прогязыком/библиотеками, но наполнять их содержанием. И это тоже на сквозном примере создания приложения разработки/документирования в конкретном языковом базисе.
В принципе какие-то вопросы и из такого пособия м.б. интересны для непрограммиста - хотя бы в части понимания того, что, возможно, не получится автоматизированно так же, как "в карандаше и ластике" - но это уже для самообразования больше... Вот такие мысли. Прошу оценить - возможен такой подход, м.б. с какими-то изменениями? Тут существенная проблема, которую вижу - то, о чём Вы писали
в этом сообщении. С этим, кстати, сталкивается и метод проверки моделей... при этом предлагается ограничение типов текстуально определимыми, но такой подход, видимо, оптимален не всегда...
P.S. В качестве отправной точки, как обычно, подразумеваю определения языков
на страницах этого раздела и документа
в этом примере. Некоторые языки-кандидаты на роль "внешних" описал
в этом документе. Что примерно м.б. в документации для заказчика - описал
в этом документе (для обычной организации на текстовой основе - то, что называю "символ-сборкой").
P.P.S. Кстати, для малых заказчиков, но вдруг вознуждавшихся в чём-то подобном (напр., если работают на субподряде у крупной конторы, которая решила ввести "аттестацию" партнёров) возможен путь опять-таки "ИТ-аутсорсинга" по принципу "централизованной бухгалтерии" - внешний подрядчик приходит и не только автоматизирует отдельные задачи, но и описывает бизнес процессы полностью своими силами. И ему опять-таки потребуется РДП-среда...