Размещено на http://www.allbest.ru/

Общие особенности языков программирования и трансляторов

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

Общие характеристики и параметры:

1. Языки программирования предназначены для облегчения программирования. Поэтому их операторы и структуры данных более мощные, чем в машинных языках.

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

3. Для любого языка определяется:

? Множество символов, которые можно использовать для записи правильных программ (алфавит), основные элементы.

? Множество правильных программ (синтаксис).

? "Смысл" каждой правильной программы (семантика).

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

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

Связь структуры программы с языком программирования называется синтаксическим отображением.

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

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

Описание семантики и распознавание ее корректности обычно является самой трудоемкой и объемной частью транслятора.

Транслятор - обслуживающая программа, преобразующая исходную программу, предоставленную на входном языке программирования, в рабочую программу, представленную на объектном языке.В настоящее время трансляторы разделяются на три основные группы: ассемблеры, компиляторы и интерпретаторы.

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

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

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

Обобщенная структура транслятора

Фазы, существующие в компиляторе:

1. Фаза лексического анализа.

2. Фаза синтаксического анализа, состоящая из:

_ распознавания синтаксической структуры;

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

3. Фаза генерации кода, осуществляющая:

_ семантический анализ компонент промежуточного представления или объектной модели языка;

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

Наряду с основными фазами процесса трансляции возможны также дополнительные фазы:

2а. Фаза исследования и оптимизации промежуточного представления, состоящая из:

2а.1. анализа корректности промежуточного представления;

2а.2. оптимизации промежуточного представления.

3а. Фаза оптимизации объектного кода.

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

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

Обобщенная структура компилятора, учитывающая существующие в нем фазы, представлена на рис. 1.4.



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

Лексический анализатор (известен также как сканер) осуществляет чтение входной цепочки символов и их группировку в элементарные конструкции, называемые лексемами. Каждая лексема имеет класс и значение.

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

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

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

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

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

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

ОБЪЕКТЫ. Базовым понятием в объектном подходе является понятие КЛАССА объектов - такого множества предметов реального мира, что все предметы в нем имеют одни и те же характеристики (данные) и правила поведения (методы обработки данных). Тогда ОБЪЕКТ - это типичный представитель (экземпляр, абстрактный представитель) своего класса.

Свойство - характеристика объекта, его параметр. Все объекты наделены определенными свойствами, которые в совокупности выделяют объект из множества других объектов.

Одним из свойств объекта являются метод его обработки.

Метод - программа действий над объектом или его свойствами.

Событие - изменение состояния объекта.

Внешние события генерируются пользователем (например, клавиатурный ввод или нажатие кнопки мыши, выбор пункта меню, запуск макроса); внутренние события генерируются системой.

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

Один объект может выступать объединением вложенных в него по иерархии других объектов.

Схематично связь основных понятий объектно-ориентированного программирования представим следующим образом (рис. 18.5).

Классы в объектно-ориентированном программировании

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

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

Виды классов. В объектно-ориентированной программе встречаются классы трех основных видов:

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

- предметные классы (Entity classes). Они используются для создания объектов, занимающихся обработкой данных. Например, класс Счет относится к предметным. Классы, представляющие людей, материальные объекты и события (например, деловые совещания) являются предметными. В большинстве объектно-ориентированных программ есть хотя бы один предметный класс, по которому создаются объекты. На самом деле в простейшем случае объектно-ориентированная модель данных строится из представления связей между объектами, созданными на основе предметных классов.

- интерфейсные классы (Interface classes). Они занимаются вводом и выводом информации. Например, при работе с графическим пользовательским интерфейсом, то каждое окно или меню, встречающееся в программе, является объектом интерфейсного класса.

Во многих объектно-ориентированных программах используется еще четвертый вид классов - контейнерный (Container classes). Контейнерные классы служат вместилищем нескольких объектов одного и того же класса. Поскольку они собирают объекты вместе, иногда их называют также агрегатами. Контейнерный класс отвечал бы за хранение объектов в определенном порядке, их перебор и, возможно, поиск. Они предоставляют доступ ко всем объектам одного и того же класса.

Виды методов. В классах используются следующие виды методов:

- конструктор (Constructor) - метод, имя которого совпадает с именем класса. Он выполняется при создании объекта. Поэтому конструктор обычно содержит инструкции по инициализации переменных объекта;

- деструктор (Destructor) - метод, выполняемый при уничтожении объекта. Не во всех объектно-ориентированных языках есть деструкторы. Обычно они применяются для освобождения системных ресурсов - например, оперативной памяти, - занимаемых объектом;

- методы чтения (Accessors) - еще их называют get-методами -возвращают значение закрытого атрибута объекта. Именно так внешние объекты обычно получают доступ к инкапсулированным данным.

- методы изменения (Mutators), set-методы, устанавливают новое значение атрибута. Таким образом, внешние объекты изменяют инкапсулированные данные.

Прочие методы, определенные в классе, зависят от назначения класса, то есть от действий, которые он призван выполнять.

Перегрузка классов и методов. Именование классов, атрибутов и методов

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

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

Чтобы наличие контейнерного класса имело смысл, должен существовать какой-то способ искать в нем конкретные объекты. Возможно, вам понадобится поиск по идентификатору служащего, по имени и фамилии либо по номеру телефона. Поэтому класс AllEmployees содержит три метода с именем find. Одному из них передается целое число (код служащего), второму - две строки (имя и фамилия), а третьему - одна строка (номер телефона). Хотя все методы названы одинаково, но их открытые интерфейсы различны, поскольку разграничены комбинации имени и типов входных данных. У многих классов есть перегруженные конструкторы. Один может запрашивать у пользователя ввод интерактивно, другой - читать из файла, третий - получать входные данные, копируя их из другого объекта (копирующий конструктор). Например, в большинстве объектно-ориентированных сред имеется класс Date, поддерживающий инициализацию объекта даты строкой, другим объектом Date и т.д.

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

Именование классов, атрибутов и методов. В объектно-ориентированном программировании имеется несколько соглашений об именовании. Хотя никто не заставляет вас называть свои классы, атрибуты и методы именно так, а не иначе, следование общепринятым правилам обеспечит взаимопонимание с другими программистами и проектировщиками баз данных:

- имена классов начинаются с заглавной буквы, за которой следуют строчные. Если имя класса состоит из нескольких слов, то они разделяются либо символом подчеркивания, например Merchandise_item, либо внутренними заглавными буквами, например Merchandiseltem;

- имена атрибутов и методов начинаются со строчной буквы и могут содержать заглавные или строчные буквы, а также цифры. Если имя атрибута или метода состоит из нескольких слов, то они разделяются либо символом подчеркивания, например product_numb или display_label, либо -внутренними заглавными буквами, например productNumb или displayLabel; - имена методов чтения начинаются со слова get, а за ним следует имя атрибута, значение которого считывается. Например, метод для получения номера изделия будет называться getProductNumber;

- имена методов изменения начинаются со слова set, а после него пишется имя атрибута, значение которого изменяется, например setProductNumber.

Методика объектно-ориентированного проектирования

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

? инкапсуляция (замыкание) свойств данных и программ в объекте;

? наследование;

? полиморфизм.

Инкапсуляция означает сочетание структур данных с методами их обработки в абстрактных типах данных - классах объектов.

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

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

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

Эти связи можно представить на диаграмме (см. рис.4.1). Класс Животное содержит данные, общие для всех видов животных. Подгруппы -Млекопитающее, Рептилия и Рыба - добавляют к этому классу специфичную информацию. Повторять в них общие данные необязательно, так как они наследуются от класса Животное. Другими словами, классы Млекопитающее,

Рептилия и Рыба включают и те четыре атрибута, которые определены в классе Животное. Если вы внимательно посмотрите на рис. 4.1, то заметите, что линии направлены от подгрупп к классу Животное. Это вроде бы противоречит реальному положению дел, ведь данные из класса Животноераспространяются вниз к подгруппам. Такое направление стрелок диктуется принятым соглашением, хотя это и противоречит интуиции.

В объектно-ориентированной терминологии подгруппы называются подклассами или производными классами. Класс Животное является по отношению к ним суперклассом, или базовым классом. Для усвоения понятия наследования надо помнить, что подклассы являются специализациями суперкласса. Таким образом, отношение между базовым и производным классом можно выразить словом «является»:

- млекопитающее является животным;

- рептилия является животным;

- рыба является животным.

Рис.4.1. Связи между классами в программе для зоомагазина

Если слово «является» неадекватно описывает ситуацию, то вы имеете дело не с наследованием. Предположим, к примеру, что вы пишете программу для учета оборудования в пункте проката лыж. Вы создаете класс для товара общего вида и его подклассы для представления конкретных типов сдаваемых напрокат товаров, как показано в первых четырех прямоугольниках на рис. 4.2. Наследование здесь вполне применимо, поскольку и лыжи, и ботинки, и палки являются частными случаями товара.



Рис.4. 2. Наследование и отсутствие наследования в программе для пункта проката лыж.

Однако, когда вы переходите к рассмотрению товаров и клиентов, берущих их в аренду, возникают проблемы. Хотя между арендатором и товаром существует непосредственная связь, это не наследование: ведь словом «является» ее не описать. Взятый напрокат товар не является арендатором! программирование псевдокод модульный

Ситуация с товарами и сдаваемым напрокат инвентарем сложнее. Классы Инвентарь, Лыжи, Ботинки и Палки описывают типы товаров, но не материальные предметы. Например, в пункте проката может быть много пар однотипных лыж и много пар ботинок одной модели и размера. Поэтому конкретный сдаваемый напрокат предмет описывается классом Предмет проката.

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

Рис. 4.3. Множественное наследование в программе для пункта проката лыж.

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

Класс Пара лыж наследует информацию о типе предмета от класса Лыжи. Он также получает данные о сдаваемом напрокат предмете от класса Предмет проката. Объект класса Пара лыж отражает пару лыж, а также сдаваемый напрокат предмет.

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

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

Множественное наследование.

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

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

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

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

Для решения этой проблемы можно воспользоваться преимуществами, которые дает полиморфизм (Polymorphism), а именно возможностью иметь разные тела у методов с одним и тем же именем, но принадлежащих различным классам в одной иерархии наследования. Класс Инвентарь включает в себя прототип метода printCatalogEntry, который лишь описывает его открытый интерфейс. В этом классе у метода нет тела, то есть не сказано, какие конкретные действия он должен выполнить (такой метод называется абстрактным). В каждом подклассе он переопределяется -пишется необходимый код.

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

Структурное проектирование и программирование

Нисходящее проектирование

Метод нисходящего проектирования предполагает последовательное разложение общей функции обработки данных на простые функциональные элементы ("сверху-вниз").

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

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

? определяются цели автоматизации предметной области и их иерархия (цель-подцель);

? устанавливается состав приложений (задач обработки), обеспечивающих реализацию поставленных целей;

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

? определяются необходимые для решения задач функции обработки данных;

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

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

Функции ввода-вывода информации рекомендуется отделять от функций вычислительной или логической обработки данных.

По частоте использования функции делятся на:

? однократно выполняемые;

? повторяющиеся.

Широко используемые функции приобретают ранг стандартных (встроенных) функций при проектировании внутренней структуры программного продукта.



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

Модуль характеризуют:

* один вход и один выход -- на входе программный модуль получает определенный набор исходных данных, выполняет содержательную обработку и возвращает один набор результатных данных, т.е. реализуется стандартный принцип IРО (Input- Process-Output -- вход-процесс-выход);

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

* логическая независимость -- результат работы программного модуля зависит только от исходных данных, но не зависит от работы других модулей;

* слабые информационные связи с другими программными модулями -- обмен информацией между модулями должен быть по возможности минимизирован;

* обозримый по размеру и сложности программный элемент.

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

Каждый модуль состоит из спецификации и тела. Спецификации определяют правила использования модуля, а тело -- способ реализации процесса обработки.

Модульная структура программных продуктов

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

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

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

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

* принятие основных решений в алгоритме выносится на максимально «высокий» по иерархии уровень;

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

В результате дальнейшей детализации алгоритма создается функционально-модульная схема (ФМС) алгоритма приложения, которая является основой для программирования.



Размер модуля измеряется числом содержащихся в нем операторов или строк. Обычно рекомендуются программные модули размером от нескольких десятков до нескольких сотен операторов.

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

Сцепление модуля - это мера его зависимости по данным от других модулей. Характеризуется способом передачи данных. Единственным видом сцепления модулей, который рекомендуется для использования современной технологией программирования, является параметрическое сцепление (сцепление по данным по Майерсу) - данные передаются модулю либо при обращении к нему как значения его параметров, либо как результат его обращения к другому модулю для вычисления некоторой функции. Такой вид сцепления модулей реализуется на языках программирования при использовании обращений к процедурам (функциям).

Рутинность модуля - это его независимость от предыстории обращений к нему. Модуль будем называть рутинным, если результат (эффект) обращения к нему зависит только от значений его параметров (и не зависит от предыстории обращений к нему).

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

Элементы структурного программирования

Первый шаг разработки программного модуля в значительной степени представляет собой смежный контроль структуры программы снизу. В завершении этого шага выбирается язык программирования.

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

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

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

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

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

Структурное программирование

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

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

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



Основными конструкциями структурного программирования являются: следование, разветвление и повторение (см. Рис. 3.1). Компонентами этих конструкций являются обобщенные операторы (узлы обработки) S, S1, S2 и условие (предикат) P. В качестве обобщенного оператора может быть либо простой оператор используемого языка программирования (операторы присваивания, ввода, вывода, обращения к процедуре), либо фрагмент программы, являющийся композицией основных управляющих конструкций структурного программирования. Существенно, что каждая из этих конструкций имеет по управлению только один вход и один выход. Тем самым, и обобщенный оператор имеет только один вход и один выход.

Пошаговая детализация и понятие о псевдокоде

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

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

должно содержать:

? начало модуля на базовом языке, т.е. первое предложение или заголовок (спецификацию) этого модуля [8.1];

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

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

? последнее предложение (конец) модуля на базовом языке.

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

Контроль программного модуля.

Применяются следующие методы контроля программного модуля:

? статическая проверка текста модуля;

? сквозное прослеживание;

? доказательство свойств программного модуля.

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

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

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

Инструментальные средства автоматизации разработки ПС

В настоящее время существуют несколько сред программирования «под Windows», использующих объектно-ориентированный подход и включающих мощные библиотеки объектов. В качестве примеров можно назвать среды разработки Visual C++, Delphi, C++Builder, которые позволяют сравнительно легко создавать сложнейшие приложения Windows. Эти пакеты автоматизируют многие операции создания приложения, предлагая разработчику большое количество различных шаблонов и заготовок, начиная от заготовки будущего приложения.

Примечание. Visual C++ является наиболее универсальным из названных трех пакетов, но и, соответственно, самым сложным. Он использует развитую объектную модель C++ и имеет более мощную по сравнению с Delphi и C++Builder библиотеку объектов. Интерфейс и средства Visual C++ ориентированы на профессиональные разработки высокого уровня.

Delphi и C++Builder используют идентичные среды и одну и ту же библиотеку объектов VCL. Практически эти среды различаются только языком разработки: Delphi использует язык на основе Object Pascal, a C++Builder, как указано в названии, C++. Используемые объектные модели также во многом похожи.

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

Инструментальные средства разработки и сопровождения программных средств

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

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

* редакторы,

* анализаторы,

* преобразователи,

* инструменты, поддерживающие процесс выполнения программ.

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

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

Совокупность инструментальных сред можно разбивать на разные классы, которые различаются значением следующих признаков:

* ориентированность на конкретный язык программирования,

* специализированность,

* комплексность,

* ориентированность на конкретную технологию программирования,

* ориентированность на коллективную разработку,

* интегрированность.

В настоящее время выделяют три основных класса инструментальных сред разработки и сопровождения ПС:

* инструментальные среды программирования,

* рабочие места компьютерной технологии,

* инструментальные системы технологии программирования.

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

* среды общего назначения,

* языково-ориентированные среды.

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

Имеются некоторые трудности в выработке строгого определения CASE-технологии (компьютерной технологии разработки ПС). CASE - это абревиатура от английского Computer-Aided Software Engineering (Компьютерно-Помогаемая Инженерия Программирования). Под CASE может пониматься и инженерия всего жизненного цикла ПС (включая и его сопровождение), но только в том случае, когда программы частично или полностью генерируются по документам, полученным на указанных ранних этапах разработки. В этом случае CASE-технология стала принципиально отличаться от ручной (традиционной) технологии разработки ПС: изменилось не только содержание технологических процессов, но и сама их совокупность.

В настоящее время компьютерную технологию разработки ПС можно характеризовать использованием

* программной поддержки для разработки графических требований и графических спецификаций ПС,

* автоматической генерации программ на каком-либо языке программирования или в машинном коде (частично или полностью),

* программной поддержки прототипирования.

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

Инструментальные системы технологии программирования.

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

С учетом обсужденных свойств инструментальных систем технологии программирования можно выделить три их основные компоненты:

* репозиторий,

* инструментарий,

* интерфейсы.

Инструментарий - набор инструментов, определяющий возможности, предоставляемые системой коллективу разработчиков..

Интерфейсы разделяются на пользовательский и системные. Пользовательский интерфейс обеспечивает доступ разработчикам к инструментарию. Он реализуется оболочкой системы. Системные интерфейсы обеспечивают взаимодействие между инструментами и их общими частями. Системные интерфейсы выделяются как архитектурные компоненты в связи с открытостью системы - их обязаны использовать новые (импортируемые) инструменты, включаемые в систему.

Различают два класса инструментальных систем технологии программирования: инструментальные системы поддержки проекта и языково-зависимые инструментальные системы.

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

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

Сценарии: высокоуровневое программирование для XXI века

В условиях постоянного роста производительности компьютеров и изменений в масштабах и номенклатуре приложений все большую значимость приобретает такой инструмент, как языки сценариев (scripting languages). Одно из фундаментальных изменений в подходе к программированию за последние 15 лет связано с переходом от традиционных языков программирования систем, таких как Си или С++, к языкам описания сценариев наподобие Perl или Tcl. На практике многие специалисты так или иначе вовлечены в этот процесс, но далеко не все осознают, что на самом деле происходит. В данной статье мы попытаемся объяснить, почему в следующем столетии языки сценариев лучше подойдут для решения многих задач, чем языки программирования систем.

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

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

Языки высокого уровня

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

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

? последовательности вызова процедур генерируются автоматически, а программисты могут не беспокоиться о пересылке аргументов в стек вызова и из него;

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

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

Типизация

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

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

Языки сценариев

Языки Perl [4], Python [5], Rexx [6], Tcl [7], Visual Basic и оболочки Unix (shell) представляют стиль программирования, отличный от присущего языкам программирования систем. Этот стиль предполагает, что набор полезных в контексте решаемой задачи компонентов уже существует и остается должным образом их скомбинировать. Например, Tcl и Visual Basic могут служить для размещения на экране набора управляющих элементов пользовательского интерфейса, а написанные на shell командные файлы позволяют собрать программы-фильтры в конвейеры. Хотя языки сценариев часто используются для расширения свойств компонентов, они мало пригодны для программирования сложных алгоритмов и структур данных, обычно как раз и обеспечиваемых компонентами. Вот почему языки сценариев часто называют склеивающими языками (glue languages) или языками интеграции систем (system integration languages).

Бестиповость

Существует тенденция делать языки сценариев бестиповыми для упрощения связывания компонентов. Все сущности выглядят и ведут себя одинаковым образом, а значит могут стать взаимозаменяемыми. Например, в Tcl или Visual Basic переменная может в один момент содержать строку, а в следующий - целое число. Код и данные часто взаимозаменяемы, так что программа может генерировать другую программу и затем исполнять ее. Универсальным способом представления для различных сущностей программы в языках сценариев служат цепочки символов.

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

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

Чтобы оценить по достоинству бестиповые языки, рассмотрим следующую команду на Tcl:

button .b -text Hello! -font (times 16) - command (puts hello)

Эта команда создает новую управляющую кнопку, предназначенную для отображения цепочки символов шрифтом Times размером 16 кеглей, и печатает короткое сообщение, когда пользователь щелкнет по этой кнопке. Команда смешивает шесть разных типов сущностей в один оператор: имя команды (button), управление кнопкой (.b), имена свойств ( -text, -font, -command), простые строки (Hello! и hello), описание шрифта (Times 16), включающее имя гарнитуры (Times) и размер (16), и, наконец, еще одну Tcl-команду (puts hello). Все эти сущности представляются единообразно, посредством цепочек символов.

При реализации на Java тот же пример требует 7 строк кода в двух методах. При использовании C++ и библиотеки базовых классов MFC потребуется около 25 строк в трех процедурах.



Интерпретируемость

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

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

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

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

Разные средства для разных задач

Языки сценариев не могут заменить языки программирования систем (впрочем, верно и обратное). Каждый из двух типов языков имеет собственную нишу. Если при создании приложений необходимо склеивать компоненты и интегрировать системы, то языки сценариев позволят сделать это в 5-10 раз быстрее. В то же время особенности языков программирования систем облегчают реализацию сложных алгоритмов и структур данных. Кроме того, языки программирования систем позволяют писать программы в 10-20 раз более быстрые, чем языки сценариев, поскольку содержат намного меньше операций проверки во время исполнения.

...