Реферат: Процесс разработки ПО и ЯП

Все в этой книге может оказаться ошибкой.

Р. Бах. Иллюзии

Поскольку процесс программирования есть процесс переноса мыслей от разработчика к компьютеру, ЯП исполняет роль интерфейса, шлюза между человеком и компьютером

Для начала введу понятие "карта". В психологии "перцептивная карта реальности" определенна как индивидуальная модель восприятия каждого человека, являющаяся результатом его предшествующего опыта. Т.е. что у человека в голове. Допустим, стол ассоциируется у русскоязычного человека со словом стол, у француза со словом table, у англичанина или американца со словом Desktop. Переводя на язык компьютеров, карта - это содержимое памяти компьютера. И человек и компьютер реагируют на внешние события (т.е. входную информацию) в соответствии с содержимым своей карты. Допустим, индонезиец слово "Кретин" воспримет как "кудрявый", а слово "сука" как "любить". О фразах "Хулиа, пидерас лас охуэлас?" - "Юля, ты попpосишь блинчиков?" и "Ун трахэ негро пара ми ньета" - "Черный костюм для моего племянника я уже не говорю. Аналогично, компилятор C++, встретив "{" воспримет ее как начало логического блока, а компилятор Паскаля - как начало комментария.

Для осуществления коммуникации (т.е. для передачи информации) между двумя субъектами (компьютеры, люди...) необходимо, чтобы их карты хотябы частично совпадали. Необходимая часть как раз и есть язык. Допустим, компьютер под Windows может общаться с NetWare сервером лишь говоря на его "языке"(интерфейс IPX/SPX).Работая с Unix, вы не сможете использовать команды Dos, а с Dos - Unix. Аналогично, общаться с иностранцами Вы сможете лишь на известном обоим языке. Более того для общения с профессором и со слесарем Вы вероятно тоже выберете разные "интерфейсы". В психологии подбор интерфейса под собеседника носит названия подстройка. На ней основан Эриксоновский гипноз и НЛП.С помощь ю её можно навести транс и вывести человека из комы.

Для осуществления же не просто коммуникации, а эффективной коммуникации необходимо более полное совпадение карт. Если язык общения не будет родным, то субъект коммуникации будет терять ресурсы на "перевод". Допусти сервер под ОС Linux эмулируя сервер WinNT будет показывать значительно меньшую производительность, чем та на которую он способен будь этот интерфейс для него родным. Аналогично программист, общаясь с бухгалтером, будет тратить время на перевод "проводок" в транзакции.

Процесс разработки ПО и ЯП

На рисунке изображен процесс разработки ПО с точки зрения ЯП.

Здесь я рассмотрю разработку ПО как процесс последовательной детализации.

Справа изображен пользователь, от которого программисту поступает небольшое количество информации. Слева изображен компьютер, которому, в конечном счете, разработчик должен будет представить программу в бинарных кодах, т.е. очень большое количество информации.

Пунктирными линиями изображены уровни детализации, такие как ЯП C++ или Техническое задание. В процессе разработки программист движется справа налево от пользователя к компьютеру. На рисунке разработчик находится примерно на уровне проектирования программы.

Детализация проводится либо автоматически, к примеру, использование генерации кода по спецификациям, допустим, Corba IDL или генерация кода программы по графическим спецификациям интерфейса в JBuilder, либо вручную, к примеру, кодирование в двоичных кодах подпрограммы по спецификации на ЯПВУ или реализация класса по спецификациям.

Естественно, первый вариант существенно повышает производительность труда разработчика. Т.е. допустим если разработчик на уровне технического задания тратит 5 минут то на уровне проектирования ему потребуется 50, а на уровне реализации 250. Именно поэтому эволюция ЯП да и программирования в целом движется в направлении от компьютера к человеку.

Я имею в виду не всю длительную и трудоемкую стадию анализа, а лишь формальное описание требований к ПО на его уровне. Поэтому приводимые данные не следует рассматривать как преуменьшения значимости стадии анализа.

На каждом уровне абстракции существуют свои языки. ЯП же выступает как интерфейс на различных уровнях. При этом за спецификацией (справа пунктирных линий на рисунке) скрывается спецификация(слева пунктирных линий на рисунке). К примеру, спецификация цикла For скрывает его реализацию также как спецификация класса скрывает спецификацию его.

Касательно языка:

Чем ближе ЯП к компьютеру и дальше от разработчика, тем больше будет размер исходного кода программы на нем, сложность его написания, широта возможностей, предоставляемых языком, и качество генерируемого кода. Из близости к человеку будут следовать переносимость разрабатываемого ПО и его безопасность, низкий уровень детализации и, естественно, более высокий уровень ЯП.

Впрочем, отмечу, что преимущества и недостатки ЯП обусловлены не только этими факторами, к примеру, типизация неадекватна ни человеку, ни машине. Она возникает на промежуточном уровне - 3GL отсутствуя на предыдущем - ассемблеры и на последующих - сценарные и неимперативные языки

Её существование обусловлено лишь небезошибочностью работы человека и недопустимостью таких ошибок в программной инженерии.

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

Длина прямоугольника ("вертикальный размер языка") обозначает широту средств языка по областям применения. Фактически спектр типов приложений, на которые этот язык рассчитан.

Поясню на примере - PL/1 и C++ одинаково годятся и для разработки финансового пакета, и для компьютерной игры. Они имеют большую "высоту" средств.

MatLab, JavaScript имеют маленькую "высоту". Их эффективно можно использовать лишь в той единственной области, для которой они созданы (в данном случае математика и Web - скрипты).

Как известно, длина, умноженная на ширину, даёт площадь. Это объем средств языка.

Есть мнение, что сложность и размер языка должны быть соразмерны с размерами задачи.

Хотя не все специалисты и ученые согласны с тезисом, что сложность и размер языка должны быть соразмерны с размерами задачи. К примеру, Вирт разработал ОС Oberon на очень простом языке Oberon с минимальными средствами.

Тут есть два крайних варианта:

В ЯП следует включать только такие концепции и конструкты, без которых совершенно невозможно обойтись. Яркий пример - Оберон

--> ЧИТАТЬ ПОЛНОСТЬЮ <--