http://www.nadomnik.by.ru/


"Программирование за одну минуту" или гибрид дятла со слоном

Snake graphics@hotbox.ru

Часть первая. По две стороны баррикад.

Поводом для очередного массового топтания пальцев по клавиатуре, результатом которого и стал сей опус , стала статья господина Константина Вавилова в 306-м номере "IZone" "Программирование за... 1 (одну) минуту". Планировалась статейка небольшая, а вот что вышло - судить вам.

Я тут, господа, пятку сломал... Ну и появилось много свободного времени. Знай себе валяйся да читай себе в удовольствие. А сегодня от безделья так на "хи-хи" пробивает, что спасайся кто может. Ну и как раз статейку в 306-м "IZone" прочитал. На тему "Программирование за... 1 (одну) минуту". Первое, что пришло мне в голову после прочтения - анекдот. "Скрестили ученые дятла со слоном. Неуклюжий долбила не попадает по насекомым, зато легко валит дерево с одного удара..."

Ну ладно, после того как истерический смех с повизгиванием, дрыганьем ногами и прочими признаками съезжающей крыши стих и на смену ему пришло слабое подрыгиванье с глубокими охами, сел топтать кнопки с целью как-нибудь объяснить народу причину такого воздействия вроде - бы невинной и вполне серьезной статьи.

Сразу хочу извиниться перед господином Вавиловым за первых два абзаца. Смех вызвала не сама статья, не теория и уж ни в коей мере стиль ее изложения. Нет. Просто сразу в голове сложилась картинка, что будет, если реализовать сию теорию и во что превратится процесс создания приложения, потом его сопровождения и модификации. Хотя и есть некоторые слова недовольства, вызванные прямыми подачами, что, дескать (дальше пошла цитата) "Большинство программистов, мягко говоря, не любит алгоритмы, скорее всего потому, что все равно придется выдумывать что-то свое по ходу кодирования." (конец цитаты). Не, так дело не пойдет. Ну и еще одна цитата: "В итоге программист (чаще всего один) является единственным держателем важнейшей ЛОГИЧЕСКОЙ информации и становится абсолютно неважным, что было придумано до программной реализации". Ну и последняя цитата: "принцип прост - ОТДЕЛЕНИЕ ЛОГИКИ ОТ ПРОГРАММИСТА-ИСПОЛНИТЕЛЯ (специалиста, понимающего особенности системы и языка и ответственного, в первую очередь, за программную корректность), АВТОМАТИЧЕСКОЕ ПОЛУЧЕНИЕ ТЕКСТА ЛОГИЧЕСКОЙ ЧАСТИ ПРОГРАММЫ ИЗ СХЕМЫ АЛГОРИТМА (программирование за одну минуту) и, идеально, сосредоточение логики в одном месте программы. Я уверен, что эти "плюсы" автоматного программирования неоспоримы". Ну и ладно, не будем вспоминать прямой наезд на программистскую братию сразу после этой цитаты и пойдем дальше.

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

Ладно, пойдем по пунктам, а то что-то я языком, то есть пальцами, растрепался - расстучался кому как удобнее. Коснемся краеугольного камня об непростых отношениях аналитиков, то есть разработчиков логической части ПО, и программистов, которых хлебом не корми, а дай при реализации вывинтить что-то совсем непохожее задуманному. Как уже сказал господин Вавилов, "в алгоритмах постоянно не учитывается то, что нужно программистам для реализации, а текст программы мало похож на алгоритм". И еще вдобавок, "глюки", как тонко заметил господин Вавилов, "не глюки Windows и неправильное использование функций языка, а логически неправильное выполнение". Сказка, да? Натуральная. Типа открываю я фанту и брык - очнулся весь в пупырышку в вытрезвителе. Почти по братьям Гримм.

Тут сразу разродимся речью на тему взаимодействия аналитиков и программистов. Поехали. Пункт первый - аналитики. В их задачу входит общение с заказчиком, выяснения, чего собственно ему надо, к каком виде он будет подавать данные, в каком забирать, сколько данных будет на входе, сколько и в каком виде на выходе и прочие невкусные вещи. Воооот. Эта вся информация по задаче у них в головах варится, варится и отрыгивается (или рождается, как кому нравится) в виде технического задания для программистов. Что включает в себя техническое задание. Прежде всего это чистая логика, то есть как именно должна работать программа. То бишь тот самый алгоритм, который так люб господину Вавилову. И подразумевается, что от этого алгоритма отходить никуда нельзя. Естественно. Потому как это утверждение правильно. Пункт второй - это программист. Берет он в руки техническое задание и начинает строго по нему работать, а программа, чучело стоеросовое, рожает такие глюки, которые правильно понять можно с любой позиции, только не с позиции разработанного аналитиками алгоритма. Почти по господину Вавилову.

А знаете, какой принцип придумали у нас в конторе, чтобы такого положения вещей избежать? А сейчас расскажу. Даже название ему очень емкое дали. Называется этот принцип "В дыню". Во как. Программа глючит, да причем при этом отходит от написанного алгоритма в техническом задании - выход простой. В дыню программисту. Или бывает и так. Народ тестит - тестит, со всех сторон пальцами колупает, радостно говорит - все пучком, пациент жив. Приходит заказчик и тихо себе так дает дуба с последующим тихим (или громким) изливанием эмоций во все стороны. А тут оказывается, что в дыню надо давать аналитику, который на самом деле пишет одно, а думает совсем другое. Даже нет жалости к личности, у которой косноязычие пронизывает весь организм до кончиков пальцев... Это я к тому, что вступление, которое избрал господин Вавилов, есть не что иное, как пересказывание какой-то популярной сказки. Ну ладно, обещал никого не хаять.

А цель всего этого пока сказать, что дескать, автоматное логическое программирование, точнее его применение при разработке ПО, как говорит господин Вавилов, "позволяет обойтись без кодирования (написания текста логической части программы) человеком, обойтись без его собственных придумок, не говоря уже об ошибках при наборе текста!!! Что задумано в алгоритме, то и будет в программе!!!". Сказали. Ну и? А то, что сие есть еще большая сказка. Нет, не так. В некоторых областях, таких как разработка микроконтроллеров, схем автоматического управления, во всех случаях, где есть ограниченный набор команд - на ура. Восхваляем и превозносим принцип логического программирования. Разработали алгоритм, получили на основании его текст, зашили в ПЗУ - и вуаля. Все работает. Лебедка ездит, автоматика работает. Все прекрасно и чудесно. Безо всякой иронии. Сама такая система даже в железе спроектирована для того, чтобы работать с четким набором переменных и состояний, она заточена под это. Железо создается исходя из ПОТРЕБНОСТЕЙ ПРОГРАММЫ. Тут то и отличие. Для таких систем применение автоматного логического программирования - то что доктор прописал. Разрабатываете вы с нуля, допустим, систему безопасности грузового лифта, продумали, по какому алгоритму она будет работать, с какими воздействиями, какая информация на входе и какие действия требуются. И начинаете все это реализовывать в железе. Реализовали. Молодцом. И потом ввели алгоритм в некое программное средство, которой выдало текст на тех же С, или еще проще, на Ассемблере в командах того процессора или контроллера, который вы применили в железной реализации своей системы безопасности того самого грузового лифта. Зашили вы его в ПЗУ и горя не знаете. Все работает. Ну в общем вы поняли, к чему я веду. А тут я и поверну. Пока не будем трогать саму мысль о правильности и удобстве автоматного логического программирования. Представим, что сей алгоритм уже стал стандартом де-факто при разработке ПО. То есть происходит все так, как говорит господин Вавилов: "Постановщик разрабатывает алгоритм, рисует его, получает текст логической части программы, а программист корректно, профессионально интегрирует этот текст в программу и делает все вспомогательные функции (не тратя время на логику)".

Ни у кого волосы дыбом не встали? Я меня только приступы хохота... Хотя если подходить серьезно, то должны были волосы встать, но я уже говорил - на "хи-хи" меня сегодня пробивает. Ладно, отойдем пока от прекрасного завтра и посмотрим на страшное сегодня. Да, программы работают часто не так, как задумывали аналитики. Поэтому у аналитиков есть затаенная голубая мечта, идущая сразу на втором месте после желания видеть всех программистов в гробу в белых тапках. А мечта эта выглядит так: разработать некую оболочку, которая позволила бы нарисовать логически выверенный аналитиком алгоритм на входе и на выходе получить рабочее ядро программы, функции которого стопроцентно соответствуют задуманному. А к этому ядру безрукие программисты присобачат че им там конкретно надо в плане работы с системой и дело в шляпе. Главное - логика-та стопроцентно будет правильной и программист ее уже перепутать не сможет. Прекрасная такая мечта.

И у программистов есть голубая мечта. Только у каждого своя. И у некоторой категории - видеть аналитиков в гробу в белых тапках, а лучше в кедах, и чтобы эти кеды торчали над поверхностью горячей смолы. Из котла в аду. Это я к чему? А к тому, что по ходу такая именно ситуация вокруг господина Вавилова. С чего я это взял? Начнем цитировать источник. Цитата: "Но что-то не склеивается у нас, у постановщиков и программистов. В алгоритмах постоянно не учитывается то, что нужно программистам для реализации, а текст программы мало похож на алгоритм. Таким образом, всегда существуют два алгоритма - на бумаге в виде блок-схем или логических схем (для отчетности и документации проектных решений) и основной (и, пожалуй, главный) в голове программиста (сохраняемый, правда, еще в текстовом виде программы)". Так. Хорошо. А почему такая ситуация возникает? И ситуация эта возникает очень и очень часто в задачах, когда аналитик пишет техническое задание, исходя только из своих позиций и соображений. Или наоборот, начинает придумывать, как в программе организовывать потоки данных. Или еще какую-нибудь краеугольную в его понимании проблему. Я за свою практику работы программистом видел много технических заданий, но только одно осталось у меня в качестве примера идеального техзадания. Да, я еще не сказал о том, что чем сложнее проект, тем запутанней зачастую техзадание и тем больше трений между аналитиками и программистами. А теперь о том задании, которое уде довольно много лет лежит у меня в ящике письменного стола. Проект - учет заработной платы транспортного предприятия. Техзадание включает в себя детальное описания входных данных и выходных, а также всю логику. Огромное количество как того, так и другого. Но! Само написание. В техзадании была детально описана логика расчетов. Но эмпирически. То есть на языке бухгалтера и расчетчика. Это шло приложением. А основное техническое задание включало в себя детальное описание того, что в каждой конкретной операции должно выводиться на экран, что должен давать пользователь. То есть описывалось только взаимодействие с пользователем. И в начале каждого блока такого описания приводилась ссылка на алгоритм, который должен был работать в этом случае. Написанная программа соответствовала на все 100 процентов техническому заданию.

К чему я веду? Любое ПО состоит из трех частей. Алгоритм расчета, интерфейс (алгоритм взаимодействия с пользователем), и чисто программная часть, задача которой - взаимодействие с системой и формирование избранной программистом структуры данных. Это конечно мнение сугубо лично мое, так что кому не нравится, делите на столько частей, сколько вам по душе. Так вот. Постановщики всегда разрабатывают алгоритм расчета. А дальше? Если алгоритм взаимодействия с пользователем разрабатывает программист, то он делает это исходя только из своих мыслей и ессно в документации этого нет и быть не может. А вот эту самую "чисто программную часть" разрабатывает только программист, аналитику и всем остальным она по фене по той же самой простой причине, по которой Вам нет дела до распределения молекул спирта и воды в рюмке с водкой. Вы ведь пьете водку чтобы расслабиться (ну там нажраться, или попеть хором, или как прелюдию к поэтическому валянию рожей в салате - это как кому нравится). Так и эта самая "чисто программная часть" - всего лишь средство, связующее интерфейс и расчетные алгоритмы. Так вот, господа постановщики. Как только техническое задание будет включать в себя алгоритм взаимодействия с пользователем в добавок к расчетному алгоритму, тогда и отпадет ситуация "Таким образом, всегда существуют два алгоритма - на бумаге в виде блок-схем или логических схем (для отчетности и документации проектных решений) и основной (и, пожалуй, главный) в голове программиста". Если хотите полное соответствие разработанному на бумаге алгоритму, разрабатывайте его в достаточном объеме. А третья часть ПО, которая "чисто программная", Вас и не заинтересует никогда. А в ситуации, которую описывает господин Вавилов "не глюки Windows и неправильное использование функций языка, а логически неправильное выполнение" - так тут все чаще всего просто - программисту в дыню. Так что продуманное техзадание полностью снимает все трения в будущем и дает гарантию полного соответствия логики, придуманной постановщиком, и логики программной реализации. Почти правда.

Ладно, страшное сегодня с двумя сторонами фронтовой полосы (постановщиков и программистов) рассмотрели, уяснили, что при наличии хорошо продуманного технического задания количество боевых действий и взаимных обвинений значительно уменьшается, вот и чудненько. Теперь рулим дальше, в прекрасное завтра, где, как обещает нам господин Вавилов, можно будет "обойтись без кодирования (написания текста логической части программы) человеком, обойтись без его собственных придумок, не говоря уже об ошибках при наборе текста!!! Что задумано в алгоритме, то и будет в программе!!!". Пока не касаясь страшных черт самого автоматного логического программирования, посмотрим на человека, который будет продумывать алгоритм. Ведь как мне думается, чтобы получить программу, алгоритм для начала надо написать. Рулим в этом направлении. Допустим, мы научили постановщика страшного сегодня проектировать расчетные алгоритмы и вдобавок к ним еще и интерфейсное решение. Ну тогда задача перед постановщиком прекрасного завтра стоит за малым - продумывать и разрабатывать еще и ту хитрую "чисто программную часть". Господа постановщики, а ведь вам для этого придется проглотить тот объем информации, который живет в голове программистов. Нет, не знание языка программирования. Скорее знание аппаратной платформы, умение работать с ресурсами, навыки разработки структуры данных, методики организации хранилищ данных, методы оптимизации, организации и взаимодействия потоков данных и еще много-много вещей, которые необходимы для создания этой самой "чисто программной части" любого ПО. Она, хитрая, вроде не видна, а на самом деле без нее как ни вертись, а дела не будет. Ах, да. Еще и развить в себе дискретное мышление (не помню, откуда эта фраза взялась, но так кто-то ярко описывал, чем отличается мышление программиста и обычного человека), то есть научиться мыслить категориями, которые больше понятны для ЭВМ, чем для обычного человека. Ну скажите честно, оно Вам надо? Ведь пока постановщик всего этого не достигнет, он не сможет полностью написать (нарисовать, создать - кому как нравится) алгоритм, который можно будет потом преобразовать в готовое ПО без участия программиста... То есть при полной реализации мечты постановщика, кода можно будет "обойтись без кодирования (написания текста логической части программы) человеком, обойтись без его собственных придумок, не говоря уже об ошибках при наборе текста!!! Что задумано в алгоритме, то и будет в программе!!!", ну тогда постановщику необходимо будет стать универсальным, стать той единицей, которая сотворит алгоритм и некий комплекс, основываясь на неважно каком принципе выдаст готовое ПО. Чудненько. А теперь возникает вопрос: кто перед нами? Постановщик? Или программист? Ведь он должен будет иметь навыки и знания как одного, так и второго. Хороший вопрос. Так все таки кто? Постановщик, который решил обзавестись навыками программиста и разрабатывать алгоритм "от и до", или программист, который решил плюнуть на постановщика и после беседы с заказчиком реализовал все сразу? А так сходу и не скажешь. А вы представляете уникума, который сможет достичь такого уровня. Есть талантливые постановщики. Их мало в сравнении с общим числом. Точно так же есть талантливые программисты. Их тоже мало. А людей, которые одновременно будут и талантливыми программистами и талантливыми разработчиками, Вы думаете, много найдется? Единицы. Слишком разное мышление у программиста и разработчика. А теперь представьте, сколько нужно будет платить такой единице "универсального" типа...

Предлагаю не лезть в это самое светлое завтра, на кой черт оно нам надо. Будем жить страшным сегодня, только будем разрабатывать технические задания полнее, четче. И тогда не придется видеть несоответствия. Их просто не станет. Все будет соответствовать техзаданию, за исключением той самой подводной части айсберга, которую будет рожать в своем мозгу программист для того, чтобы все вертелось, и которая никого никогда и не заинтересует. Вы ведь как постановщик просили соответствующих расчетных алгоритмов и выходных данных? Есть, все работает. Если Вы хороший постановщик, Вы просили еще и такой алгоритм взаимодействия с пользователем. И это есть. Так Вас остальное и не заинтересует. Все живет и порхает. Само существование программистов как лагеря и постановщиков как лагеря можно сказать неизбежно, так как уж очень разное у них мышление и набор знаний.

Блииииин, я тут глянул, сколько я уже понаписал... Нифига себе... Разошелся. Ну ладно, я ж так и не рассказал, почему в моем мозгу всплыл анекдот про гибрид дятла со слоном. Это мне сам принцип автоматного логического кодирования, изложенный господином Вавиловым, навеял. Сейчас, вот только кофе хлебну и продолжу...

Часть вторая. Гибрид дятла со слоном.

Ну вот, кофе хлебнули и плывем дальше. Сейчас мы будем, как бы это помягче сказать, в общем будем некоторым образом поливать грязью этот самый принцип автоматного ЛОГИЧЕСКОГО программирования. Кто-то скажет, что я вроде собирался быть третейским судьей, никого на хаять... А тех кто так скажет, пошлем к началу статьи, где я еще и сказал, что славное начинание нужно хоронить сразу. Ну в принципе ладно, поливать грязью будем с позиции применения сего алгоритма для разработки ПО в средах Windows и подобных языками высокого уровня. А возносить на пьедестал почета (до определенного уровня) будем с позиции применения сего алгоритма в областях разработки микропроцессорных систем и контроллеров. Поехали.

Для начала насыпаем цитат, касающихся принципа автоматного логического кодирования. Цитата первая: "ВСЯ логика программы строится на основе селектора (switch в языке Си, case - в Паскале) и ВСПОМОГАТЕЛЬНО используется старый добрый оператор условия if-else". Хорошо. Вторая: "...очень простое и одновременно необычайно важное обстоятельство - В ЛЮБОЙ МОМЕНТ ВРЕМЕНИ ИЗВЕСТНЫ ЗНАЧЕНИЯ ВСЕХ ВЫХОДНЫХ ПЕРЕМЕННЫХ". Еще лучше. Ну и третья: "...гораздо более важное - В ПРОГРАММЕ МОЖНО ОБОЙТИСЬ БЕЗ ПРОМЕЖУТОЧНЫХ ЛОГИЧЕСКИХ ПЕРЕМЕННЫХ". Замечательно. И последняя: "в качестве аргументов в условии выступают переменные, которые являются глобальными ВХОДНЫМИ переменными для ВСЕЙ программы, их не надо выдумывать, они есть всегда и сразу и изменяют их значения не внутренние процессы, а внешние, никак не зависящие от логики программы". Просто чудесно. Дальше цитировать не будем, так как господин Вавилов далее предлагает приведение работы с интерфейсом к принципам автоматного логического программирования. Причем с интерфейсом Windows. О как... Да только делает он это с позиций систем автоматического управления технологическим процессом. Это правильно, он в этой области работает.

Начинаем тихонько возносить на пьедестал принцип автоматного логического программирования. Он идеально подходит для систем, работа которых основана на принципах состояний. Ну как говорит сам господин Вавилов, "Основой всего служит нечто - СОСТОЯНИЕ. Необходимо добавить еще только одно слово - ОЖИДАНИЕ. Получаем, на мой взгляд, вполне достаточное определение "СОСТОЯНИЕ ОЖИДАНИЯ". Ожидают в состоянии появления признаков, значений или событий". Очень хорошо. Знаете, когда я хорошо подумал над принципом автоматного логического кодирования, я пожалел, что не знал его несколько лет назад, когда разрабатывал дипломный проект. Вкратце суть там была в следующем: управление электронным устройством, блоком бесперебойного питания. Задача была в получении на выходе сигнала синусоидальной формы заданных характеристик при любых колебаниях входных параметров. Да, при реализации алгоритма мне пришлось продумать реакции системы при различных изменениях сигнала на входе, при различных граничных событиях (ну короче понятно) и написать алгоритм, по которому должна была работать система. Вот если после этого поставить на рельсы принцип автоматного логического программирования, сразу можно было получить на том же ассемблере готовую прошивку ПЗУ, присобачить к ней микропроцессор и вперед. Но в то время я об таком способе не знал, и потому у меня получилось то же ПЗУ, но с кучей логики на входе.... В общем яркий пример программисткой реализации...

Ладно, бочку меда в виде яркой пригодности принципа логического программирования для разработки ПО для АСУ ТП мы налили, щас туда и ложку дегтя плюхнем... Плюхаем. А ведь железо подбиралось при конструировании не самостоятельно, а в соответствии с задачами, которые оно будет решать. ПЗУ подбиралось под требуемую частоту, которую диктует алгоритм, управляющие органы тоже выбирались с немаловажным критерием быстродействия... В общем, Вы наверное уже поняли, к чему я веду? Железо затачивалось в определенной степени (а часто в довольно большой) под алгоритм. Очень хорошо. А если бы существовал уже комплект железа, под который нужно написать алгоритм? Не цитируя приведенную господином Вавиловым программу, давайте предположим такую ситуевину: процесс не меняется, исполнительное железо тоже, а вот входных переменных скажем 30, а прочитать и помнить можем только 20. А вот железо, ПЗУ или контроллер, не позволяет больше. Кто там из программистов начал кричать "Прочитаем частями, потом будем делать выборки и работать"? Тихо. Принцип автоматного логического программирования гласит, что в любой момент времени известны значения всех выходных переменных, а все входные переменные являются глобальными для всей программы. И более того, локальных переменных нет вообще. Так что если входных тридцать, то они постоянно сидят в памяти. А иначе, батенька, это уже отход от принципов автоматного логического программирования.

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

Пойдем дальше. Вкратце напомним принципы, по который функционируем многозадачная операционная система. Существует два типа многозадачности. Потоковая и процессная. Процесс - это программа или приложение, находящееся в стадии выполнения. Процессная многозадачность заключается в том, что операционная система может выполнять несколько программ одновременно. Поток - это самостоятельно отдельно выполняемая часть программы. Один процесс может имеет как минимум один поток. Как же все это работает? В многозадачной операционной среде (чтобы не абстрагироваться, возьмем всеми любимую (в общем характеристику можете придумать сами) операционную систему Windows старше цифры 95) существуют несколько процессов одновременно. Менеджер очереди процессов следит за тем, чтобы каждый из процессов получал свою долю процессорного времени. То есть происходит все равно дискретное выполнение каждого процесса и по очереди, но благодаря высокому быстродействию процессора возникает иллюзия одновременного выполнения. Давайте посмотрим, как все это происходит по шагам. Допустим, у нас в существует одновременно три процесса. Ну запущено одновременно три программы в общем случае. Менеджер процессов (часть операционной среды) отдает управление первой программе. Сама программа записывается в память, все переменные, нужные ей для работы, записываются туда же и программа использует ресурсы процессора, винчестера и пр. в тот период времени, который ей отведен менеджером процессов, то есть собственно операционной средой. Что происходит далее. Менеджер процессов отдает ресурсы второму процессу (программе). Что происходит при этом. Первая программа выгружается из памяти, ее данные тоже, в память записывается вторая программа, данные для ее работы и второй программе отдаются ресурсы аппаратной части для работы. Точно так же и при переходе к третьему процессу. Второй из памяти выгружается, третий туда записывается. Это конечно просто упрощенная картинка, но она в общих чертах описывает работу при потоковой многозадачности. На самом деле все гораздо сложнее, но не будем лезть в дебри. Что же получается? А получается, что для корректной работы в многозадачной операционной среде рождаются такие требования к ПО, написанному под нее. Требование 1. Компактность программного кода. Ведь с программным кодом операционная среда будет манипулировать, полностью или частично перебрасывая его из рабочей зоны памяти в страницы файла подкачки и наоборот. Требование 2. Как можно меньшие требования к свободной памяти, предъявляемые программой. Это опять же связано с тем, что операционной среде придется эти данные перебрасывать из ОЗУ в файл подкачки и назад.

Кто-то скажет, что эти требования не новы, что они же были актуальны и при разработки приложений под DOS. Согласен, если эти требования выполняются, это хорошо для любой операционной среды. А теперь обратимся к АЛП. Основной правило - в любой момент времени известны все значения выходных переменных. На практике означает, что ВСЕ выходные переменные должны существовать в памяти во время всего выполнения программы. Нерационально. Память-то не резиновая. Точно так же и с входными переменными. АЛП гласит, что они должны быть глобальными. И если я хочу использовать в потоке только 1% из них, то я все равно должен в памяти держать все переменные, потому что они глобальные в рамках процесса. Опять нерационально. В общем при использовании АЛП у меня получается монстрообразный гибрид дятла со слоном, у которого требования к памяти растут прямо пропорционально количеству входных и выходных переменных. Нет, так дело не пойдет.

Я сознательно не буду давать рекомендации, по какому же принципу разрабатывать ПО. Я постарался дать картинку, что будет, если пользоваться АЛП в чистом виде. Но чтобы подвести сему опусу какую-то законченную логическую черту, я вновь спрошу господина Вавилова: что по-вашему значит несоответствие логики в виде блок-схемы и ее программной реализации? Даю наглядный пример. Будем рассматривать логику начисления алиментов человеку на его зарплату. Просто и незатейливо. Есть человек, у него есть табельный номер, у него есть начисленные суммы по видам начислений, есть процент алиментов. Есть в общем случае признак, по которому нужно считать этому человеку алименты, позволяющий выделить этого человека из всего списка работников. Итак, переменные.
Tabn - табельный номер
Summa - сумма начисленная
alim - признак, что человеку нужно начислять алименты
summa_alim - сумма начисленных алиментов
Отдельно вынесем переменную pr - процент начисления алиментов. Сделаем ее динамической с таким условием: если до 100 гривен начислено, то это 10%, если от 100 до 200 начислено, то это 15%, если от 200 до 300, то это 33%, если от 300 до 1600 - то 66%, а если свыше 1600 начислено, то все равно 66%, но облагаем сумму только в 1600 грн.
И сама организация списка. Данные всех работников находятся в таблице, каждая строка которой содержит поля Tabn, Summa, alim, summa_alim. Каждый работник при этом характеризуется своей строкой.
Пойдем со стороны постановщика. Разрабатываем алгоритм расчета. В самом простом случае он будет выглядеть так:
1. Формируем новый список работников из исходного. В него включаются только те работники, у которых признак alim = 1.
2. Становимся на первую запись в списке.
3. Получаем значение суммы для данной записи.
4. Получаем значение процента для данной записи.
5. Вычисляем summa_alim для данной записи как summa_alim=summa*pr/100
6. Записываем значение в поле
7. Если запись не последняя, переходим на следующую запись и в пункт 3, иначе идем к п.8.
8. Переносим значения из нового списка в старый.
9. Завершаем выполнение.
Допустим, что старый список хранится в таблице spisok1, а новый в таблице spisok2.
Пункт 4 постановщик реализует как структуру вложенных проверок условий, чтобы получить значение процента. А может вынести его в отдельную процедуру и обращаться к ней со значением суммы, а она будет ему отдавать значение процент. Эти пути абсолютно в плане логики одинаковые. Постановщик нарисует блок-схему. Да, со всех позиций алгоритм хорош. И оптимизация есть - в первом пункте мы ограничили количество обрабатываемой информации, и работаем вследствие этого только с нужными данными, и сама структура алгоритма четкая и линейная. Программист на нее глянет и сделает совсем не так.
Ну наверное все поймут, что запись summa_alim=f_alim(summa) означает, что переменной summa_alim присваивается выходное значение функции f_alim при передаче сей функции в качестве входного параметра переменной summa.
Так опять вернемся к действию программиста. Например при использовании СУБД MS SQL Server (система управления базами данных) технология буде такой:
Формируем функцию получения процента для конкретной суммы (здесь будет точно такой алгоритм, который написал и постановщик в п.4).
Этот пункт не входит пока в прямую реализацию алгоритма. Это просто вынесение куска алгоритма в отдельно существующий объект. Получилась функция f_alim, которая берет входной параметр и на основании его значения формирует выходной параметр. А потом сразу реализуем весь алгоритм. Одной командой:

update spisok1 set summa_alim=summa*f_alim(summa)/100 where alim=1

Ну или по-русски "изменить spisok1 установить summa_alim=summa*f_alim(summa)/100 где alim=1"

Все. О каком соответствии нарисованной блок-схемы и ее программной реализации может идти речь? А тем не менее все верно. Получив такую команду, СУБД сформирует набор записей, соответствующих условию alim=1, и для каждой записи выполнит вызов функции f_alim, передав ей соответствующее значение поля summa, вычислит произведение выходного значения и поля summa и результат запишет в поле summa_alim. Налицо полное соответствие логики вычислений при полном несоответствии программной реализации блок-схеме. Но может быть и другая ситуация. На языке программирования СУБД MS SQL Server программист может написать программный код, блок-схема которого будет полностью соответствовать блок-схеме, предложенной разработчиком. О чем это говорит? Для данного конкретного примера - это просто плохой программист.

Дальше - больше. Любой программист, работающий в такой же СУБД, сразу же поймет, о чем речь, прочитав это команду. В его голове мгновенно возникнет блок схема, по которой преобразовываются данные этой командой. Так вот мы и уперлись в различие мышления программиста и постановщика. Программист мыслит концепциями и идеями, присущими тому программному комплексу, с которым данный программист работает. У него другое понятие о логике. Если по логике разработчика для получения конечного результата необходим какой-то набор осмысленных логических действий, то по логике программиста одно действие, или комплекс действий, но совершенно иных, чем в логике постановщика.


Ладно, обобщаем все написанное. Любой проект содержит две основные логические линии - расчетные алгоритмы и алгоритмы взаимодействия с пользователем. Постановщик разрабатывает логическую концепцию и реализацию этих алгоритмов. Дальше проект попадает к программисту. И вот тут возникает две неизбежности. Первая. Проект разбивается на три основные линии: взаимодействия с пользователем, расчетная часть и основной движок программы, задача которого в большей степени состоит в манипулировании данными - хранение, преобразование, перемещение. При программной реализации без этого никак. А дальше неизбежное. Алгоритмы взаимодействия с пользователем при достаточной проработке постановщиком остаются одинаковыми на бумаге в виде блок-схемы и в программной реализации. Программная реализация расчетных алгоритмов обязательно будет отличаться от разработанной блок схемы. Всегда. Потому что будут использоваться средства и решения той программной среды, в которой писался код. Конечно, можно возразить, что на разных языках программирования можно написать код, блок-схемы которого будут идентичны для каждого из используемых языков. Но чаще всего такой код - это просто плохой стиль программирования, не реализующий средств инструмента разработки. Так что несоответствие блок-схемы алгоритма и текста его программной реализации при хорошем уровне программирования будет всегда. Все, две части, в рамках которых сталкиваются лбами постановщики и программисты, исчерпаны. Дальше углубимся в АЛП. Вспомним, как развивались Языки программирования. Сначала был просто машинный код. Программисты работали с помощью прямого кодирования командами процессора. Потом появился Ассемблер - язык уже высокого уровня, понятного больше человеку. Появилось понятие операторов - когда с помощью семантического обозначения программист мог описать несколько машинных кодов. Появились компиляторы, задача которых была в преобразовании семантического кода в команды процессора. А язык высокого уровня развивался далее. Появлялось понятие циклов, понятие процедур, функций, программист уже мыслит не машинным кодом, а семантическими концепциями того языка программирования, на котором пишет. Языки программирования стали делится на функциональные группы. Становились разделенными семантически, разрабатывались принципы программирования для различных языков и общепринятые... И сейчас уже мы имеем ситуацию, когда программист имеет в своем распоряжении множество языков программирования, предназначенных для решения различных задач. Например, с базами данных мы работаем с помощью одних систем управления на их внутреннем языке, интерфейс пишем с помощью средств на другом языке, промежуточные средства контроля и отображения создаем с помощью третьего языка программирования. А процессор как работал на машинных кодах, так и работает. Вся та многосложная семантика предназначенных для разных сфер языков программирования компилятором все равно преобразуется в машинный код. Поэтому снова обратимся за цитатой к господину Вавилову.Однородность - одна из основ автоматной теории - позволяет обойтись без кодирования (написания текста логической части программы) человеком, обойтись без его собственных придумок, не говоря уже об ошибках при наборе текста!!! Что задумано в алгоритме, то и будет в программе!!! Программисту остается сделать только несколько вещей, чисто "программизмических", системо-языко-зависимых: правильно вызвать данную функцию (автомат), в том числе правильно передать при вызове входную информацию (признаки и значения), и правильно выполнить выходные функции (как правило, в одно тривиальное действие). Вот здесь, и только здесь, нужны квалифицированные знания языка и его возможностей. Да вот только лучше не использовать здесь понятия "язык программирования". А использовать понятие "среда разработки". И от ее возможностей зависит программная реализация разработанного постановщиком алгоритма. А если логику реализовывать, не привязываясь к возможностям среды разработки, то полученное решение будет неоптимальным. Нерациональным. Медленным и ресурсоемким. Это как в жизни. Есть входная переменная - труба. В одной среде разработки есть инструмент - ножовка. С помощью инструмента можно изменить значение входной переменной и получить выходную переменную в виде отрезка трубы. И точно так же в другой среде разработки с помощью болгарки можно получить те же значения выходной переменной в виде отрезка трубы и изменить значение входной переменной. Но за меньшее время и ценой меньших усилий. Так вот здесь болгарка - уже инструмент той среды разработки, в которой мы строим алгоритм отрезания трубы. Потому и нужен программист. Логика, которую разработал постановщик - это одно, а выбрать средства для программной реализации этого алгоритма - это уже задача программиста. А веду я к тому, что современное программирование - это прежде всего использование тех ресурсов и возможностей, которые предоставляет среда разработки. А АЛП - это прежде всего алгоритм общения с процессором. Именно к нему приводят компиляторы все те семантические структуры, которые программист пишет в средстве разработки. Общение с центральным процессором. Количество входных переменных - число разрядов входной шины, выходные переменные - значения регистров, стека и счетчика команд. Промежуточные переменные отсутствуют как явление...

АЛП - это метод конечного взаимодействия. Использовать его принципы для программирования на языках высокого уровня невозможно физически, а почему - я уже описывал выше, во что тогда превратятся программы. А на вопрос господина Вавилова "Уважаемые программисты, вы же такие умные, крутые и все такое, ну неужели вам не придумать, как применить в Windows такие замечательные решения?" отвечу просто. Господин Вавилов, мы эти замечательные решения применяем на каждом шагу. Ведь сказал же я уже, что АЛП - технология конечного взаимодействия. Если я пишу систему, основанную на ядре и нескольких потоках, мне без принципов АЛП никак не обойтись. Углубляться почему не буду, статья и так вышла достаточно объемной. Приведу простые примеры реализации. Любая СУБД - если я в одну процедуру помещаю несколько алгоритмов, то входные переменные процедуры глобальные для каждого из алгоритмов внутри, и выходные значения процедуры должны формироваться каждым алгоритмом. А зачем? А потому что реляционные СУБД с многопоточным функционированием строятся на основании схемы ядро-поток и работа с потоками ведется на принципах АЛП. Внутренний набор переменных самого ядра - это для потока не промежуточные переменные, это его выходные переменные, характеризующие состояние ядра. Таки образом достигается полная однородность обращений к ядру и легкое переключение выполнения от потока к потоку - выгрузил поток из памяти в своп, загрузил второй - и вся беда. Вот где применяется АЛП постоянно - организация взаимодействия. Ведь ядро СУБД или сложный движок программы - это тот же процессор и общаться я с ним должен на АЛП, как с любой железкой. Дал я макрокоманду взаимодействия с ядром. Во входные переменные я поставил нужные мне значения, на вход подал команду на языке ядра, ядро ее отработало, сказало, что задача выполнена с таким-то кодом завершения и открыло моему потоку доступ к чтению выходных переменных. Выполнение потока может быть продолжено. А ведь я не зря сказал "макрокоманда". Выполнение макрокоманды может включать в себя целый алгоритм действий ядра. И все это будет выполняться в лучших традициях АЛП, да вот только я этого не увижу. Я дал макрокоманду, ядро сказало "щас сделаем, ты пока стой жди", а как отработало, сказало "все, работай дальше забирай данные". А вот пока процесс, запустивший выполнение макрокоманды, ждет, ядро выкручивает тот самый алгоритм, выполнение которого производит макрокоманда, да четко по принципу АЛП. Промежуточных переменным для отдельно взятого потока в ядре возникнуть не может, набор входных переменных есть и стабилен, набор выходных переменных четко оговорен. Выполнение алгоритма завершено, ядро дает команду потоку продолжать работу. Все как с центральным процессором.

Так что применение АЛП для разработки ПО на языке высокого уровня не имеет смысла... Для разработки последовательности машинных кодов, для формирования обращений к программному ядру - пожалуйста. Но не для абстрагирования от языка программирования. Язык программирования для того и создавался, чтобы своей семантикой давать программные инструменты, с помощью которых программисту дана возможность одним словом выразить сложные алгоритмы взаимодействия и преобразования данных. Так, про АЛП все-таки закончили... Про то, что используем его достаточно часто при организации взаимодействия частей программы, тоже сказали. Про то, почему блок-схема постановщика не соответствует программной реализации, тоже сказали. А то, что отделение логики от программиста-исполнителя, как мечтает господин Вавилов, это очень плохо, я думаю Вы и сами поняли. Тем, какие программы будут нас окружать, если мы возьмем на вооружение АЛП при высокоуровневом программировании, я тоже вроде Вас попугал... Ну что еще сказать. До встречи. Заходите через недельку в гости на http://www.graphics.hotbox.ru/ - проект как раз начнет работать.

 


Copyright © "Internet Zone", http://www.izcity.com/, info@izcity.com