инт.среды. 5. Системы программирования

• Название: 5. Системы программирования
• Дата: 05.09.2022
• Размер: 175.93 Kb.
• Имя файла: инт.среды.docx
• Тип: Документы; #663216
• страница: 2 из 7

Электронная почта

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

Электронный календарь

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

Интранет

Термином интранет обозначают корпоративные информационные системы, построенные на принципах, заимствованных из сети Интернет. По сути, интранет - это перенос хорошо известных сетевых технологий во внутрикорпоративные сети. Внутренняя сеть позволяет создать целостный портрет организации и обрести радикально новую систему внутренних коммуникаций и доступа к информационным ресурсам. Интранет может быть значительно "умнее" Интернета, потому что он контролируем, и в него можно инвестировать значительно больше знаний и средств. В качестве серверов итранета можно использовать хорошо известные серверы Интернета, например Apache (http://www.apache.org/).

5.2.2.3. Средства оценки качества

Для сравнения качества программных продуктов применяются количественные методы оценки. Среди программ оценки качества отметим Metricate компании Software Productivity Centre (http://www.spc.ca/)), которая анализирует все аспекты деятельности компаний по производству программного обеспечения. Это - эффективность технологических процессов, качество программного кода, уровень управления проектами, стоимость выполнения различных этапов, производительность получаемой системы, продуктивность труда разработчиков и качество готовых изделий.

5.2.3. Анализ требований и проектирование

5.2.3.1. Системы на основе структурной методологии

Для анализа требований и проектирования на основе структурной методологии могут быть применены следующие системы:

• 
  Silverrun ModelSphere (компании magma solutions GmbH (http://www.spc.ca/)) - поддерживает методы DATARUN, Гейна-Сарсона, Йордона, Мартина и др.;
  
• 
  Oracle Designer (компании Oracle (http://www.oracle.com/)) - поддерживает CASE*Method Баркера;
  
• 
  ERwin (компании Computer Associates International, Inc. (http://www.cai.com/)) - поддерживает диаграммы функционального моделирования.
  

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

Из отечественных систем укажем следующие:

• 
  ДРАКОН - поддерживающая ДРАКОН-схемы [Паронджанов 1999];
  
• 
  CASE-Аналитик (компании Эйтекс) - поддерживающая подход Гейна-Сарсона. Система работает с иерархией диаграмм, последовательно детализирующих модель (рис. 5.1).
  

В состав системы САSЕ.Аналитик входят [Калянов 1996]:

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

5.2.3.2. Системы на основе объектно-ориентированной методологии

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

• 
  Rational Rose (компании Rational Software Corporation (http://www.rational.com/));
  
• 
  Together Control Center (компании TogetherSoft Corporation (http://www.togethersoft.com/)).
  

Перечислим основные достоинства и возможности системы Rational Rose:

• 
  система прошла достаточно долгий путь развития и совершенствования. Она поддерживает язык UML и ряд ранних языковых нотаций (например, Воосh и ОМТ (Object Modeling Technique));
  
• 
  система реализована на обеих наиболее распространенных операционных системах - Unix и Windows;
  
• 
  система имеет три основные модификации. Пользователь имеет возможность выбрать одну из них, устраивающую его по финансовым соображениям:
  
  • 
    Enterprise - с возможностью генерации кода на языках Visual C++, Visual BASIC, Java, CORBA IDL Еще совсем недавно существовала поддержка языка Smalltalk;
    
  • 
    Professional - возможность генерации кода на одном из перечисленных языков;
    
  • 
    Modeler - без языковой поддержки;
    
• 
  система поддерживает восстановление спецификаций из кода;
  
• 
  система поддерживает генерацию проектной документации.
  

Система обладает удобным рабочим интерфейсом, в который входят:

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

5.2.4. Программирование (реализация)

5.2.4.1. Трансляторы

Диван был транслятором. Он создавал вокруг себя поле, преобразующее, 
говоря просто, реальность действительную в реальность сказочную. 
Аркадий и Борис Стругацкие. "Понедельник начинается в субботу"

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

• 
  компиляторы;
  
• 
  декомпиляторы;
  
• 
  интерпретаторы.
  

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



Обратим внимание на то, что многие другие программные инструменты могут рассматриваться как языковые трансляторы, например:

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

5.2.4.2. Компиляторы

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

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



Далее мы расскажем об основных программах, входящих в состав компилятора. В сети Интернет подробный обзор таких программ можно найти на сайте Compiler Construction Tools (http://catalog.compilertools.net/).

• 
  Драйвер (диспетчер, монитор) - это программа, последовательно вызывающая все остальные компоненты компилятора.
  
• 
  Препроцессор - программа, которая выполняет модификацию данных с целью их подготовки для ввода в другую программу. Модификация может заключаться в простом переформатировании или применении макрорасширений.
  
• 
  Анализатор - компонент компилятора, осуществляющий последовательно:
  
  • 
    лексический анализ, на котором входная программа, представляющая собой поток символов, разбивается на лексемы - конструкции (слова) языка;
    
  • 
    синтаксический анализ, в процессе которого происходит разбор структуры программы;
    
  • 
    контекстный анализ, во время которого выявляются зависимости между частями программы, включая анализ типов, областей видимости, соответствие параметров и т. п.
    
• 
  Оптимизатор - компонент, выполняющий преобразования программы (как правило, на основе промежуточного представления) с целью улучшения ее характеристик (оптимизации) по одному или ряду параметров. Как правило, оптимизацию проводят по времени исполнения с целью получения более эффективной программы или по пространству - месту, которое файл с откомпилированной программой будет занимать. На рис. 5.4 представлено три основных подхода к оптимизации.
  
• 
  Кодогенератор - компонент, завершающий компиляцию и порождающий на основании промежуточного представления программы либо ассемблер, либо объектный код.
  

5.2.4.3. Системы генерации трансляторов

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

С точки зрения существующих алгорифмов синтаксического анализа, все языки и порождающие их грамматики делятся на два класса LL(n) и LR(n). Этот теоретический раскол в классе грамматик, распознаваемых анализаторами, построенными по принципу снизу вверх, и анализаторами, реализующими принцип сверху вниз, естественным образом наложил свой отпечаток и на практические реализации систем. В результате существуют системы с входными языками, специфицируемыми LR(n) и LL(n) грамматиками соответственно. Исторически первой системой, реализующей синтаксически управляемую трансляцию, была система уасс, входной язык которой принадлежит к классу LR(1) или, более точно, LALR(1). Система уасс, разработанная в 1972 году в рамках проекта Unix, успешно используется до сих пор, что, конечно, не может не свидетельствовать в пользу простоты и мощности идей, положенных в ее основу.

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

• 
  BISON - реализация уасс, написанная в рамках проекта GNU (http://www.gnu.org/software/bison/bison.html);
  
• 
  PCYACC (компании Abraxas Software (http://www.abxsoft.com/pcyacc.htm)). Это коммерческая реализация уасс, включающая в себя различные утилиты, упрощающие процесс разработки трансляторов. Среди них: документатор, отладчик, библиотекарь и т. д. В поставку включены спецификации грамматик многих современных языков программирования (С, C++, SQL и т. д.);
  
• 
  Yacc++ (компании Compiler Resources, Inc. (http://world.std.com/

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

Естественное желание разработчиков пользоваться давно написанными средствами, прошедшими не один год тестовых испытаний в реальных проектах, отрицательно сказалось на количестве систем, транслирующих входные языки класса LL(n), т. е. реализующих двойственный подход к проблеме. Тем не менее, в рамках некоторых учебных проектов, а также в рамках проекта "Оберон" был создан ряд таких систем. Среди них следует отметить:

• 
  SYNTAX - технологический комплекс, созданный в Санкт-Петербургском государственном университете под руководством профессора Б. К. Мартыненко (http://www.niimm.spb.su/mbk/syntax/syntax.html).
  

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

• 
  DEPOT4 (авторская разработка Юргена Лампе (Jurgen Lampe) (http://%20www.math.tu-dresden.de/wir/depot4/depot4.html)). Это система, генерирующая трансляторы, работающие по принципу рекурсивного спуска. При этом допускается возможность регулированного отката при обнаружении неоднозначностей. Таким образом, при наличии требования на отсутствие левой рекурсии в правилах грамматики сама грамматика может быть и не LL(1). Естественно, что чем ближе грамматика к классу LL(1), тем более быстрый транслятор можно будет с нее получить;
  
• 
  LLGEN (является частью большого учебно-коммерческого проекта, известного под названием Amsterdam Compiler Kit - АСК (http://www.cs.vu.nl/vakgroepen/cs/ack.html)). Она также генерирует трансляторы, работающие по принципу рекурсивного спуска.
  

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

• 
  ALE - Attribute-Logic Engine (авторская разработка Боба Карпентера (Bob Carpenter) и Джеральда Пенна (Gerald Penn) (http://www.cs.toronto.edu/gpenn/ale.html)). Система, базирующаяся на принципах искусственного интеллекта;
  
• 
  EAG (ftp://hades.cs.kiin.nl/pub/eag/). Система, в основе которой лежат расширенные аффиксные грамматики;
  
• 
  PRECC (авторская разработка Питера Брюера (Peter Breuer) и Джонатана Боуена (Jonathan Bowen) (http://www.afm.sbu.ac.uk/precc/)). Это система, позволяющая грамматике входного языка быть контекстно-зависимой.
  

5.2.4.4. Системы анализа корректности программного кода

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

• 
  lint (компании Sun Microsystems, Inc. (http://www.sun.com/)) для языка программирования С;
  
• 
  PC-lint и FlexeLint (компании Gimpel Software (http://www.gimpel.com/)) анализируют программный код на языках С и C++.
  

5.2.4.5. Интерпретаторы

Не существует фактов, есть лишь их интерпретация. 
Ф. Ницше

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

5.2.4.6. Декомпиляторы

Декомпилятор - программа, позволяющая по программе на языке низкого уровня (обычно это коды некоторой машины) получить программу на высокоуровневом языке, в некотором смысле ей эквивалентную. Под эквивалентностью чаще всего понимают эквивалентность внешних проявлений работы исходной программы и декомпилированной (http://www.it.uq.edu.au/groups/csm/dcc.html).

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

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

Теория анализа потоков управления появилась давно, т. к. анализ активно применялся в компиляторах практически с момента их появления. Однако анализ потоков управления при компиляции имеет свою специфику - он используется в основном для целей оптимизации. Большинство алгоритмов анализа потоков управления, которые ориентированы на декомпиляцию, ставят своей целью уменьшение количества goto-выражений посредством введения новых логических переменных, дублирования кода (code replication) или использования конструкций высокого уровня, недоступных в большинстве широко используемых языков, таких как Pascal, С или C++.

В работах Кристины Цифуентес (Cristina Cifuentes) (http://www.itee.uq.edu.au/cristina) представлены алгоритмы, использующие минимальный набор инструкций высокого уровня: циклы типов while и do...while, if- и case-выражения. Управление выполнением объемлющих конструкций из вложенных не допускается. Причем эти алгоритмы используют оператор goto лишь тогда, когда граф управления не может быть структурирован никаким иным способом в пределах перечисленных конструкций.

Анализ практических достижений в области декомпиляции языка Java выполнил Дэйв Дайер (Dave Dyer) (http://www.javaworld.com/). Он сравнил между собой три наиболее известных к середине 1997 года декомпилятора: DejaVu, Mocha и WingDis. Дайер предложил систему тестирования декомпиляторов, основанную на интересной классификации допускаемых ими ошибок. В соответствии с этой системой все ошибки делятся на шесть категорий. "Тяжесть" ошибки возрастает с номером категории. Ошибки, в результате которых декомпилированная программа перестает собираться, но которые могут быть легко исправлены (например, отсутствие явного приведения типов там, где оно с очевидностью должно быть), относятся к первой, самой легкой категории, тогда как генерация правильного, но нечитаемого текста на Java считается ошибкой третьей категории. Заметим, что некоторые ошибки, проявляясь у одних декомпиляторов, полностью отсутствуют у других. Это свидетельствует о жизнеспособности такой классификации - она позволяет определить области, в которых одни декомпиляторы имеют преимущество над другими.

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

• 
  Mocha и Crema входят в состав программного продукта Jbuilder компании Borland Inc. (http://www.borland.com/));
  
• 
  Source Tee Java Decompiler (компании SourceTee Software Co. (http://www.srctec.com/decompiler/));
  
• 
  Jad (авторская разработка Павла Кузнецова (http://www.sai.msu.su/sal/F/1/JAD.html)).
  

5.2.4.7. Усложнители декомпиляции (шифраторы, обфускаторы)

Практические успехи в области декомпиляции языков программирования (и особенно языка Java) оказались столь велики, что в последнее время были проведены значительные исследования в области защиты программ от декомпиляции (http://www.cs.washington.edu/homes/douglas/publish/). Существует специальный класс программ (шифраторов, обфускаторов), усложняющих декомпиляцию. Такие программы используют два основных подхода.

• 
  Общее (универсальное) усложнение.
  
• 
  Целенаправленное усложнение (направленное против конкретного декомпилятора).
  

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

5.2.4.8. Системы управления компиляцией и построением программ

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

• 
  make (компании Sun Microsystems Inc. (http://www.sun.com/)) входит в состав операционной системы Solaris;
  
• 
  GNU Make (организации Free Software Foundations (http://www.gnu.org/software/raake/make.html));
  
• 
  Jmk - Make in Java (общинная разработка (http://sourceforge.net/projects/NO).
  

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

Файл с инструкциями имеет свой синтаксис.

• 
  Строка комментариев начинается с символа диез #.
  
• 
  Пустые строки игнорируются.
  
• 
  Любая строка, оканчивающаяся символом обратная наклонная черта \, продолжается на следующую строку. Все символы пробела и табуляции вокруг наклонной черты сжимаются в один символ пробела.
  
• 
  Если строка выглядит следующим образом <цель>: [<зависимости>], то это означает, что цель определяется зависимостями и соответственно для того, чтобы добиться выполнения целей, необходимо выполнить зависимости.
  
• 
  Строка, идущая за строкой с указанием цели, должна иметь вид <пробел_или_табуляция> <команда>. Указанная команда будет передана командному интерпретатору в случае, если цель нуждается в обновлении.
  
• 
  Команда [<пробел_или_табуляция>] <имя> = <значение> позволяет изменнять значение переменной. Любая строка, содержащая знак равенства, является макроопределением. Такая строка связывает строку <значение> с именем <имя>.
  
• 
  Любое слово в файле описаний, начинающееся с символа $, является использованием макроопределения. Включенное в любом месте файла описание $ (<имя>) будет заменено на его существующее макроопределение. Если <имя> является одиночным символом, то разрешено использование макроопределения в упрощенном виде $<имя>.
  
• 
  Некоторые макроопределения являются предопределенными. Они могут использоваться только в правой части строки правила, в других макроопределениях и в строках команд. Приведем примеры предопределенных макроопределений:
  
  • 
    $@ - означает полное имя текущей цели;
    
  • 
    $* - имя текущей цели с отброшенным типом файла (суффиксом);
    
  • 
    $? - список зависимостей, которые обновились с момента предыдущего получения цели;
    
  • 
    $< - полное имя исходного файла, к которому применяется правило трансформации.
    
• 
  Обычно существует некоторая база предопределенных правил суффиксов и динамических макроопределений. Они являются правилами по умолчанию для стандартного получения результирующих файлов по исходным файлам. Все они сведены в специальный файл. Например, правило трансформации .cc.о определяется как $(COMPILE.cc) $(OUTPUT_OPTION) $<. Это означает, что для того, чтобы получить файл .о (если есть .сc), надо выполнить указанную команду. Динамическое макроопределение $ (COMPILE.сс) определяется в той же базе как $(ссс) $(CCFLAGS) $ (CPPFLAGS) -с.
  

Пример файла с инструкциями приведен в листинге 5.1. Именование каталогов дано в стиле операционной системы Unix.