DAY17 (1114707)

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

Текст из файла

8

Лекция №17

Лекция №17

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

Глава V. Системы программирования

Этапы разработки программного обеспечения

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

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

• проектирование;

• кодирование;

• тестирование;

• отладка.

Итак, рассмотрим каждый из этих этапов.

Этап проектирования

Многим подумают: «А зачем вообще нужно проектирование?». Лучше сразу «браться за работу». (Как в известном анекдоте: «А что тут делать - надо трясти ...»). На сегодняшний день достаточно сложно, пожалуй, практически невозможно создавать более или менее серьезное программное обеспечение без этапа проектирования, такого же долгого и детального периода, который проходит во время проектирования любого технического объекта. Следует понять, что те программы, которые пишутся студентами в качестве практических и дипломных задач не являются по сути дела программами - это игрушки, так как их сложность невелика, объемы незначительны, и такого рода программы можно писать «слегка». Реальные же программы так не создаются, так же, как и не создаются сложные технические объекты. Никто никогда не может себе представить, чтобы какая-нибудь авиационная компания продекларировала создание нового самолета и дала команду своим заводам «слепить» лайнер с такими-то параметрами. Так не бывает. Каждый из элементов такого объекта, как самолет, проходит сложнейший этап проектирования.

Например, фирма Боинг подняла в воздух самолет “Боинг-777”, замечательность этого факта заключается в том, что самолет взлетел без предварительной продувки в аэродинамической трубе. Это означает, что весь самолет был спроектирован и промоделирован на программных моделях, и это проектирование и моделирование было настолько четким и правильным, что позволило сразу же поднять самолет в воздух. Для справки - «продувка» самолета в аэродинамической трубе стоит сумасшедшие деньги.

Примерно та же ситуация происходит при создании сложных современных программных систем. В начале 80-х(?) была начата СОИ (стратегическая оборонная инициатива), ее идея была в том, чтобы создать сложной технической системы, которая бы в автоматическом режиме установила контроль за пусковыми установками СССР и стран Варшавского блока, и в случае фиксации старта с наших позиций какого-то «непродекларированного» объекта автоматически начиналась война. То есть запускались бы средства уничтожения данного объекта и средства для ответных действий. Реально тот департамент вооруженных сил, который занимался этим проектом, испытал ряд кризисов в связи с тем, что ведущие специалисты в области программного обеспечения отказывались участвовать в реализации этого проекта из-за невозможности корректно его спроектировать, потому что система обладала гигантским потоком входных данных, на основе которых должны были быть приняты однозначные решения, ответственность за которые оценить весьма сложно. На самом деле эта проблема подтолкнула к развитию с одной стороны - языков программирования, которые обладали надежностью, в частности, язык Ада, одной из целью которого было создание безошибочного ПО. В таких языках накладывались ограничения на места, где наиболее вероятно возникновение ошибки (межмодульные интерфейсы; выражения, где присутствуют разные типы данных и т.п.) Заметим, что язык C не удовлетворяет требованиям безопасности. С другой стороны - к детальному проектированию, которое бы позволяло некоторым формальным образом описывать создаваемый проект и работать с проектом в части его детализации. Причем, переход от детализации к кодированию не имел бы четкой границы. Понятно, что это есть некоторая задача не сегодняшнего, а завтрашнего дня, но реально разработчики программ находятся на пути создания таких средств, которые позволили бы совместить проектирование и кодирование. Сегодняшние системы программирования, которые строятся на объектно-ориентированном подходе, частично решают эту проблему.

Проектирование должно включать в себя следующие этапы:

• проектирование функциональных возможностей;

• проектирование структур данных программы;

• проектирование структуры программы и организация взаимосвязей между основными модулями;

• проектирование этапа внедрения в систему.

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

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

Это вкратце все о первом и очень важном этапе жизненного цикла разработки - этапе проектирования.

Этап кодирования

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

Основной компонент системы кодирования - инструмент - язык программирования. В голове каждого программиста лежит иерархия языков программирования - от машинного кода и ассемблера до универсальных языков программирования (FORTRAN, Algol, Pascal, C и т.д.), специализированных языков (SQL, HTML, Java, различных визуальных средств и т.д.) Замечу, что «продвинутые» системы программирования на этом этапе могут опираться на результаты этапа проектирования.

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

1. Обеспечение корректной работы с версиями программы

Make-файлы.

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

Существует другое более изящное и довольно простое решение - make-файлы. Название происходит от соответствующей команды ОС UNIX. Суть make-файла заключается в том, что в текстовом файле описываются все зависимости исходных, объектных и исполняемых файлов с учетом их версий. В частности можно сказать, что некоторый исполняемый файл зависит от группы объектных файлов, и если эта связь нарушена, то надо выполнить команду редактирования связей (link ...). Что означает нарушение зависимости и что означает связь? Make-команда проверяет существование этих объектных файлов. Если они существуют, то времена их создания должны быть более ранние, чем время создания исполняемого файла. В том случае, если это правило нарушено (а это проверяет make-команда), то будет запущен редактор связей (link), который заново создаст исполняемый файл. Тем самым такое средство позволяет нам работать с программой, состоящей из большого количества модулей, и не заботиться о том, соответствует ли в данный момент времени исполняемый файл набору объектных файлов или не соответствует (можно просто запустить make-файл).

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

Система контроля версий.

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

2. Работа с модульными программами

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

• с поддержкой независимой компиляции модулей;

• с поддержкой раздельной компиляции модулей.

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

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

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

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

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

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

Характеристики

Тип файла документ

Документы такого типа открываются такими программами, как Microsoft Office Word на компьютерах Windows, Apple Pages на компьютерах Mac, Open Office - бесплатная альтернатива на различных платформах, в том числе Linux. Наиболее простым и современным решением будут Google документы, так как открываются онлайн без скачивания прямо в браузере на любой платформе. Существуют российские качественные аналоги, например от Яндекса.

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

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

Список файлов лекций