Файл: "История развития программирования в России".pdf

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

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

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

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

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

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

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

Эффективность создания, тестирования и использования программы хорошо иллюстрируется языком АПЛ. При использовании этого языка для решения некоторого класса задач проектирование, кодирование, тестирование, модификация и выполнение программы отнимает у программиста минимальное количество времени и энергии. АПЛ может быть назван эффективным в полном смысле слова — он позволяет минимизировать суммарное время и энергию, затрачиваемые на решение задач на ЭВМ.

---

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

2.2 Некоторые аспекты объектно-ориентированного программирования

Если приемы процедурного программирования концентрируются на алгоритмах, то объектно-ориентированное программирование (ООП) концентрируется на сути задачи. Элементы программы разрабатываются в соответствии с объектами, присутствующими в описании задачи. Отсюда и терминология - «Объектно-ориентированное программирование». При этом первичными считаются объекты (данные), которые могут активно взаимодействовать друг с другом с помощью механизма передачи сообщений (называемого также и механизмом вызова методов). Функция программиста - определить объекты, взаимодействие которых после старта программы приведет к достижению необходимого конечного результата.

Общий подход к ООП включает в себя следующие концепции^[9]:

1) наличие типов, определенных пользователем;

2) скрытие деталей реализации (инкапсуляция);

3) использование кода через наследование; разрешение интерпретации вызова функции во время выполнения программы (полиморфизм).

Известно, что реальные/физические объекты окружающего мира обладают тремя базовыми характеристиками:

1. набором свойств, характеризующих объект;
2. способностью объекта изменять свойства;
3. способностью реагировать на события как в окружающем мире, так и внутри самого себя.

Хотя термины «тип данных» (или просто тип) и «абстрактный тип данных» звучат похоже, они имеют различный смысл. В языках программирования тип данных (переменной) обозначает множество значений, которые может принимать эта переменная. Абстрактный тип данных (АТД) определяется как математическая модель с совокупностью операторов, определенных в рамках этой модели. Таким образом, классы могут служить простым примером АТД.

---

Разработку класса - абстрактного типа данных рекомендуется начинать с разработки информационной и математической моделей реального или физического объекта, как это показано в схеме, представленной на рис. 1.

Рис. 1. Схема процесса создания программной модели (класса) в рамках ООП.

В соответствии с этой схемой на начальном этапе исследования задачи нужно выделить физические объекты. После чего нужно определить свойства, характеризующие каждый физический/реальный объект. Следует отметить, что из множества свойств объекта следует взять только те, которые необходимы для решения задачи. Во избежание избыточности следует выяснить: какие из свойств являются базовыми; какие свойства можно получить на основании базовых свойств, какие свойства будут меняться; как воздействовать на объект с целью изменения его свойств; в каких процессах будет задействован объект и как это отразится на его свойствах (действия над объектом).

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

Построение математической модели сводится к записи математических соотношений, связывающих результаты или новые свойства с исходными данными. Эти соотношения, как правило, представлены в аналитическом виде формулами.

Информационная и математическая модели служат основой для построения программной модели объекта или класса.

Построение класса начинается с разработки его интерфейса. Поля класса формируются из информационной модели. А в методы класса, помимо стандартных методов (конструкторов и деструктора), включаются методы, связанные с изменением свойств объекта, получением новых свойств как воздействием на объект, так и на основании соотношений, заявленных в математической модели.

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

---

Выделение объектов само по себе не является простой задачей. Для выделения объектов в части анализа и исследования задачи значительное место отводится разработке концептуальной модели функционирования пользовательского интерфейса. Аспекты, которые следует учитывать при разработке концептуальной модели функционирования пользовательского интерфейса

Важность этапа разработки концептуальной модели пользовательского интерфейса сложно переоценить также из-за возросших требований к качеству программного продукта как на отечественных, так и на западных рынках, т.к. в оценку программного продукта входит качество интерфейса, обеспечивающего взаимодействие пользователя с программой. В. Головач [2] отмечает четыре основных критерия качества интерфейса, а именно:

• • скорость работы пользователей;
  • количество человеческих ошибок;
  • скорость обучения;
  • субъективное удовлетворение (подразумевается, что соответствие интерфейса задачам пользователя является неотъемлемым свойством интерфейса).

Скорость выполнения работы является важным критерием эффективности интерфейса. Длительность выполнения работы пользователем состоит из: o длительности восприятия исходной информации;

o длительности интеллектуальной работы (пользователь думает, что он должен сделать); o длительности физических действий пользователя; o длительности реакции системы.

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

сознания, т. е. знания из областей когнитивной и инженерной психологии, а также эргономики.

Согласно Дональду Норману, на которого ссылается В. Головач, взаимодействие пользователя с системой (не только компьютерной) состоит из семи шагов:

• • • формирование цели действий;
    • определение общей направленности действий;
    • определение конкретных действий;
    • выполнение действий;
    • восприятие нового состояния системы;
    • интерпретация состояния системы;
    • оценка результата.

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

---

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

Заключение

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

Вышесказанное приводит к мысли о том, что организации взаимодействия программиста и машины также потребует переработки. С самого зарождения синтаксис языков программирования эволюционировал по пути улучшения структурированности, читаемости и понятности программы для программиста. Однако, на данный момент улучшением синтаксиса добиться наглядности и удобства работы с параллельными программами пока не удаётся. Вероятно, решение будет найдено в уже существующих концепциях. Так, например, ещё в 1974 году в Массачусетском технологическом институте был разработан MIT Static Dataflow Machine — аппаратная реализация машины с статической архитектурой потока данных^[10]. В ней управление вычислениями проводилось при помощи самих данных, а не с помощью потока управления — то есть, была решена одна из основных проблем текущей архитектуры — наличие счётчика инструкций. Эта идея не получила развития в связи со сложностью реализации и программирования в 80-х годах и была постепенно забыта, однако с появлением графических ускорителей идея была вновь использована. Многие графические чипы последних лет используют в том или ином виде элементы архитектуры с потоком данных. Другим направлением может стать разработка средств визуального программирования, которые уже применяются сегодня в некоторых специализированных областях программирования. Примерами успешных решений можно считать: LabView, Algorithm Builder и HiAsm — однако, каждый из этих инструментов сильно привязан к своему набору решаемых задач, что не позволяет говорить о необходимом уровне универсальности, сопоставимым, например с языком C. Учитывая описанные выше проблемы, можно предположить, что будущее языков программирования будет связано с увеличением значимости средств автоматизации программирования. Такого рода инструментарий уже сейчас применяется в некоторых специализированных областях, так, например, при разработке интеллектуальных систем и систем принятия решений. В дальнейшем такого рода технологии, вероятно, позволят переложить большую часть работы программиста на машину^[11] — что в свою очередь вновь повысит уровень абстракции, снижая эффективность и повышая качество программ.

---