programming.systems.cpp.09.ide (1119533), страница 3
Текст из файла (страница 3)
Makefile (для модельного SQL-интерпретатора):client: client.occ -o client client.oserver: server.o parse.o getlex.o table.occ -o server server.o parse.o getlex.otable.o: table.c table.hcc –c table.cparse.o: parse.c parse.hcc –c parse.cgetlex.htable.hgetlex.o: getlex.c parse.hcc –c getlex.cgetlex.hserver.o: server.c parse.hcc –c server.cgetlex.hclient.o: client.ccc –c client.cclean:rm *.oall:clientservertable.oНекоторые дополнительные возможности создания Make-файловВ начале файла можно вводить макросы для обозначения каких-либо частоповторяющихся фрагментов текста файла в виде:имя = текст ,а затем там, где нужно, использовать введенные имена таким образом:$(имя) .Некоторые предопределенные макроопределения:$@ - полное имя текущей цели,$* - имя текущей цели без типа файла (суффикса),$? - список зависимостей, которые обновились с момента предыдущегообновления цели,$< - полное имя исходного файла, к которому применяется правилотрансформации.В язык для Makefile введены некоторые предопределенные правила суффиксов поумолчанию для стандартного получения результирующих файлов по исходным файлам.Например, правило трансформации .с.о означает, что для того, чтобы получитьфайл с расширением .о (если есть файл с расширением .с), надо выполнить указаннуюкоманду.Строка, начинающаяся символом '#' , является комментарием.Пустые строки игнорируются.Любая строка, оканчивающаяся символом '\', продолжается на следующую строку.gcc -MM позволяет сгенерировать фрагмент make-файла с зависимостями модулей.Пример 2.
Makefile (для модельного SQL-интерпретатора):сс = gccserv_o = server.o parse.o getlex.o table.oclient: client.o$(cc) -o client client.oserver: $(serv_o)$(cc) -o server $(serv_o).с.о:$(cc) -с $*.ctable.c:parse.c:getlex.c:server.c:table.hparse.h getlex.h table.hparse.h getlex.hparse.h getlex.hclean:rm *.oall:client serverСистемы контроля версийСистема контроля версий в самом общем понимании осуществляетотслеживание версий (ревизий) некоего набора объектов (например,файлового дерева).Применительно к процессу разработки ПП говорят• об управлении исходным кодом (source control),при этом отслеживаются ревизии исходного кода ПП и других ресурсов,необходимых для сборки ПП,• или об управлении конфигурациями (configuration management),при этом отслеживаются ревизии всего окружения, в том числесопутствующих материалов, таких как файлы данных и документация.Система контроля версий позволяет фиксировать ревизии исходногокода ПП, возвращаться к любой из них, отслеживать авторствоизменений, производить анализ истории изменений и т.
д.Системы контроля версийРазвитие систем контроля версий• Старейшие системы:SCCS (1972), RCS (1982)– отслеживается один файл на одной машине– рядом с файлом хранится история всех его ревизий• Проектные клиент-серверные системы:CVS (1990), SVN (2000)––––поддерживается отслеживание файлового деревафиксируется ревизия дерева в целомистория ревизий хранится в репозитории (на сервере)работа с кодом ведется в рабочих копиях• Распределенные системы:BitKeeper (1998), Darcs (2002), Git (2005), Mercurial (2005)– каждая рабочая копия может иметь собственный репозиторий– работа с репозиторием не требует доступа к серверу– возможна децентрализованная разработкаКонтроль версий: основные понятияСущностиОперации• Дерево• Ревизия• Набор изменений(changeset)• Ветка• Репозиторий• Рабочая копия• Фиксация (commit)• Обновление на ревизию• Ветвление• Слияние (merge)• Передача изменений(pull/push)История изменений дереваИстория изменений дереваВеткиКонтроль версий: классификацияПо расположению репозитория:• централизованные (CVS, SVN),• распределенные (Git, Mercurial, Darcs),• комбинированные (Bazaar).По объекту отслеживания:• отслеживающие ревизии (CVS, SVN),• отслеживающие наборы изменений:– наборы изменений организованы в ациклический орграф (Git,Mercurial)– наборы изменений организованы как набор патчей (Darcs)Централизованные системыРаспределенные системыПриемы работы с системами контроля версий1.
Линейная работа. Последовательная фиксацияпрогресса работы над ПП.2. Совместная линейная работа. Совместная работа сфиксацией по принципу «кто успел» и последующимслиянием изменений.3. Ветки для разработки, в которых новаяфункциональность дорабатывается до готовности квыпуску версии ПП.4. Ветки для тестирования.5. Ветки для сопровождения старых версий.6.
Метки (тэги) для фиксации значимых ревизий(например, версий ПП).7. Анализ истории (в том числе аннотирование кода).Режим аннотирования кодаПопулярные современные системы1. Git– Высокая скорость– Github2. Mercurial– Простота в использовании– Кроссплатформенность3.
Subversion (SVN)– Централизованная системаКогда следует применятьсистемы контроля версий?ВсегдаCASE-средстваCASE-средства (Computer Aided Software Engineering) –программные средства, поддерживающие полуавтоматическуюразработку комплексного ПП на всех стадиях его жизненного цикла.Основные характерные особенности CASE-средств: наличие мощных графических средств для описания идокументирования ПП, обеспечивающие удобный интерфейс сразработчиком и развивающие его творческие возможности; интеграция отдельных компонент CASE-средств, обеспечивающаяуправляемость процессом разработки программной системы; наличие средств автоматического или автоматизированногокодирования и документирования ППСовременные CASE-средстваПримером наиболее известного CASE-средстваявляется объектно-ориентированное CASE-средствоRational Rose (компании Rational Software Corporation).В основе работы Rational Rose лежит построениедиаграмм и спецификаций унифицированного языкамоделированияUML (Unified Modeling Language),определяющих архитектуру проекта, его статические идинамические аспекты.UML — язык для определения, представления,проектирования и документирования программных системразличной природы.Некоторые дополнительные возможностисовременных систем программированияСуществует множество других программных средств, помогающих впроектировании, модификации и кодировании программ.
Например,• системы, преобразующие программы на процедурном (императивном)ЯП в программы на ООЯП (поскольку ОО программы считаются болеепростыми в сопровождении, это бывает полезно),• системы, анализирующие исходный код, с целью получениявысокоуровневых абстракций (например, Java диаграммы UML),• средства, предоставляющие среду разработки программ подиаграммам UML,• средства сборочного программирования (из готовых программныхмодулей, официально распространены достаточно слабо в связи сразличными правовыми проблемами копирования модулей, низкимкачеством модулей и их плохой документацией).Статистика отмечает, что около 80% программного обеспечения создаетсяпо уже имеющемуся.Следовательно, большой интерес представляют собой репозитории,поддерживающие архивы, документацию и интеллектуальный поиск нужныхпрототипов и фрагментов проектов программ для реализации эффективногосборочного программирования.Q&A.