Тема 5.Отладка и тестирование программ.(6 час)

Лекция 11. Отладка программ. Инструменты. Методика отладки.

Процедура отладки. Поиск ошибок, допущенных при разработке – проявляется в остановах, зацикливаниях, снятиях, непонятных результатах. Ошибки design и run периода. Порядок отладки – отработка системных сообщений, выяснение подозрительных зон в программе, окаймление SHE фреймами и генерация системных сообщений и сообщений разработчика, создание контрольных точек и тестов для подозрительных участков.

Инструменты отладки. Декомпиляторы, отладчики и дизассемблеры- состав, возможности, порядок использования. Использование debuggers – меню, возможности, команды. Дизассемблирование, — перевод двоичных кодов процессора в удобочитаемые мнемонические инструкции. «Дизассемблер IDA относится к интенсивно развивающимся продуктам, — постоянные совершенствования и бесконечные изменения, вносимые разработчиками, породили множество версий, из которых наибольшее распространение получили 3.84, 3,84b, 3,85, 4.0, а некоторые до сих пор предпочитают использовать IDA 3.6. К сожалению, даже близкие версии плохо совместимы между собой — прототипы и поведение функций встроенного языка находятся в постоянном изменении, затрудняя создание переносимых скриптов. Существуют три различных пакета поставки дизассемблера — стандартная (IDA Pro Standard), прогрессивная (IDA Pro Advanced) и демонстрационная (IDA Pro Demo). В каждый пакет поставки (за исключением демонстрационного) входят две ипостаси — одна графическая под Windows-32 (в дальнейшем обозначаемая как IDAG) и три консольных для MS-DOS, OS/2 и Windows-32. B демонстрационный пакет входит лишь одна графическая ипостась. Обе ипостаси обладают сходными функциональными возможностями, поэтому в книге будет описана лишь одна из них, скомпилированная для исполнения в среде Windows-32 (в дальнейшем обозначаемая как IDAW).

Две категории дизассемблеров - автономные и интерактивные. Автономные требуют у пользователя все необходимые им указания до начала процесса дизассемблирования и не позволяют вмешиваться в сам процесс. Интерактивные позволяют "вручную" управлять процессом дизассемблирования программы. В любой момент пользователь имеет возможность вмешаться в сам процесс: отличить адреса от констант либо определить границы инструкций и т. д. Соответственно, интерактивные дизассемблеры имеют хорошо развитый пользовательский интерфейс, а IDA имеет даже собственный си-подобный язык скриптов.

IDA обладает развитым файловым вводом-выводом, что открывает поистине неограниченные возможности. Можно самостоятельно загружать файлы любых форматов, создавать отчеты и листинги любых видов. Можно распаковывать или модифицировать исполняемые файлы, при желании — работать с принтером или, например, модемом! Все это богатство возможностей реализуется относительно небольшим набором стандартных функций Си. Работа с файлами в IDA-Си ничем не отличается от "классического" Си. За тем, может быть, исключением, что ввиду отсутствия массивов в их общепринятом понимании используется посимвольный, а не блочный обмен. Процесс дизассемблирования кажется очень сложным, но часто применяемым.

Описание программы Общие сведения

Ильфак Гильфанов – разработчик утилиты IDA, Паша Руснак, который написал движок базы данных, используемый в IDA. Без этой базы данных, универсальной во многих отношениях, IDA просто не было, Юрий Харон, удивительный программист, пишущий очень грамотный и эффективный код, помощь которого в развитии IDA просто невозможно переоценить. Первые строки для IDA были написаны в декабре 1990. После этого она развивалась с большими паузами. В IDA много кода от пользователей - некоторые процессорные модули были подарены благодарными пользователями, а столько было информации об ошибках, предложений по улучшению, новых идей - всего не перечесть. Первые версии IDA были предназначены для работы под MS DOS с 640кб памяти.

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

Система типов построена таким образом, чтобы ее можно было применить к любому процессору, поэтому тут речь идет не только о MS Windows. IDA уже поддерживает UNIX API. В принципе, можно ее расширить и на другие платформы, включая микроконтроллеры и встроенные системы. IDA может работать под управлением трёх операционных систем, количество платформ, для которых она может дизассемблировать файлы - практически не ограниченно. Назовите практически любую современную операционную систему, и окажется, что IDA сможет анализировать выполняемые файлы для нее. IDA поддерживает более 32-х видов процессоров.

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

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

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

IDA Pro - это интерактивный дизассемблер и отладчик одновременно. Она позволяет превратить бинарный код программы в ассемблерный текст, который может быть применен для анализа работы программы. Название IDA Pro происходит от английского Interactive Disassembler. IDA используется для анализа вирусов (antivirus companies), исследования защит систем (software security auditing), обратной инженерии (reverse engineering). Хотя IDA и не является декомпилятором (decompiler), она содержит отладчик (debugger) и может анализировать программы на высоком уровне. IDA не является автоматическим дизассемблером типа Sourcer'а. Это означает, что IDA выполняет дизассемблирование лишь тех участков программного кода, на которые имеются явные ссылки. При этом IDA старается извлечь из кода максимум информации, не делая никаких излишних предположений. После завершения предварительного анализа программы, когда все обнаруженные явные ссылки исчерпаны, IDA останавливается и ждет вмешательства пользователя; просмотрев готовые участки текста, можно подсказать ей, что нужно делать дальше. После каждого вмешательства снова запускается автоматический анализатор IDA, который на основе полученных сведений пытается продолжить дизассемблирование. Таким образом, происходит работа вместе с IDA - она выполняет для пользователя всю рутинную работу, а он подсказываете ей, как поступить, когда существующей информации ей уже не хватает.

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

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

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

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

Управление отладкой. Документы отладки. Инструменты коллективной работы – библиотеки, журналы, хранилища и управление ими.

Основная литература: 5 осн. [ (3) gl 5]

Контрольные вопросы:

1. Что такое отладка?

2. Какие инструменты отладки Вам известны?

3. В каких режимах можно отлаживать ПП?

4. Как документируется отладка при коллективной работе и какие инструменты используются?

5. Чем отличается отладка на этапе компиляции и выполнения программы?

6. Как защитить программу от снятия в run-time?

7. Что позволяют делать отладочные программы- список возможностей?

8. Смысл транзакции?

9. Смысл домена?

10. Понятие целостности данных и вычислений?

11. Что дает журнализация работ?

Лекция 12. Тестирование. Разработка инвариантов и тестовых примеров.

Контроль реализации программ. Разбивка программы на блоки контроля. Определение инвариантов. Определение домена в обработке информации. Инвариант – неизменяемое функциональное значение на определенном участке программы. Определение инвариантов и участков их существования.

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

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

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

Использование исключительных ситуаций.

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

1. Если ситуация возникла внутри блока try..except, то там она и будет обработана. Если ИС "продвинута" дальше при помощи оператора raise, а также если она возникла в блоке try. .finally, обработка продолжается.

2. Если программистом определен обработчик события Application.onException, то он получит управление. Обработчик объявлен следующим образом:

TExceptionEvent = procedure (Sender: TObject; E: Exception) of object;

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

Пункты 2 и 3 реализуются в методе TAppiication.HandieException. Собственно, выглядят они следующим образом:

if not (ExceptObject is EAbort) then

if Assigned(FOnException) then FOnException(Sender, Exception(ExceptObject))

else ShcwExceptior. (Exception(ExceptObject));

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

program Project!;

uses

Forms, SysUtils, //добавлено вручную — там описан класс Exception Dialogs,

Unitl in 'Unitl.pas' {Forml};

{$R *.RES}

type

TExceptClass = class

public

procedure GlobalExceptionHandler(Sender: TObject; E:Exception);

end;

procedure TExceptClass.GlobalExceptionHandler(Sender: TObject;

E:Exception);

begin

ShowMessage('Произошла исключительная ситуация ' + E.ClassName

+ ': ' + E.Message + #13#10'Свяжитесь с разработчиками по тел. 222-33-44');

end;

begin

with TExceptClass.Create do

begin

Application.OnException := GlobalExceptionHandler; Application.Initialize;

Application.CreateFormfTForml, Forml); Application.Run; Free;

end;

end.

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

Примечание Есть и более простой способ присвоить обработчик событию Application.OnException. Для этого поместите на форму компонент типа TApplicationEvents (страница Additional Палитры компонентов), роль которого — предоставление "визуального" доступа к свойствам невизуального объекта TApplication. Среди его событий есть и OnException. Но как "пощупать" переданный при исключительной ситуации объект? Обычная

конструкция on EExceptionType do... указывает на класс объекта, но не на конкретный экземпляр. Если во время обработки требуется доступ к свойствам этого экземпляра, его нужно поименовать внутри on..do, указав перед именем класса некий идентификатор:

on EZD: EZeroDivide do EZD.Message := 'Деление на ноль!'; Здесь возникшее исключение выступает под именем EZD. Можно изменить его свойства и отправить дальше:

var APtr : Pointer;

Forml : TForm;

try

APtr := Forml;

with TObject(APtr) as TBitmap do;

except

on EZD: EInvalidCast do EZD.Message :=. EZD.Message + 'xa-xa!';

Raise;{ теперь обработка будет сделана в другом месте }

end;

Но как поименовать исключительную ситуацию, не попавшую ни в одну из директив on..do? Или, может быть, в вашем обработчике вообще нет on. .do, а поработать с объектом надо? Описанный выше путь здесь не подходит. Для этих случаев есть пара системных функций Exceptobject и ExceptAddr. К сожалению, эти функции инициализируются только внутри конструкции try..except; в try..finally работать с объектом— исключительной ситуацией не представляется возможным… »

Ликвидация коллизий в разработках.

Основная литература: 3 осн. [ (12- 57) ], 5 осн. [ (4)Delphi7-SEH]

Контрольные вопросы:

1. Что такое инвариант?

2. Как использовать инвариант при построении пред и пост условий?

3. Что такое критический участок в программе?

4. Как защищают критические участки?

5. Какие системные инструменты используют для монополизации и распараллеливания

вычислений?

6. Что такое – исключение?

7. Что дает разработчику структурная обработка исключений?

8. Чем отличаются блоки except и finally?

Лекция 13.Оптимизация размеров и времени выполнения разработки

Инструменты и методы. Оптимизация размеров и времени выполнения программ. Определение исполняемых и выделение DLLмодулей в разработке. Различие в построении DLLиEXE. Различие в использовании. . «DLL и EXE (Gordon Smith, ClarionMagazineномер 6 за 1999 г.) Со временем наступает время, когда вам хочется разделить ваш APP (и следовательно EXE) на небольшие, более управляемые части. Это может быть довольно обескураживающей задачей, не потому что она сложная (это всего лишь переключение нескольких параметров в Global Properties на вкладках General и File Control), а потому что это кажется "черной магией" и если сделать не правильно, то кажется ужасно неправильным! В этой статье я набросаю подход к созданиюDLL и разъясню что происходит в действительности. Перед тем как начать, убедитесь что ваши APP и DCT скопированы в легко доступный каталог резервных копий. Вы будете создавать новое APP и потребуется импортировать процедуры из оригинальной копии. Целью является преобразование главного APP в несколько небольших приложений, что дает следующие преимущества:

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

• Многопользовательская разработка: Различные APP легче распределить между разработчиками.

• Упрощение распространения: Небольшие изменения могут потребовать небольшого апгрейда (например, изменения могут касаться только одной DLL).

Каждый APP создает выполняемую программу или библиотеку с процедурами и данными. Есть два основных типа библиотек: 1)Статическая: Все данные и процедуры линкуются в файл библиотеки (.LIB), который может быть включен (целиком) в другие приложения. 2)Динамическая: Все данные и процедуры линкуются в динамическую библиотеку (.DLL), которая является независимой единицей и которую нужно поставлять вместе с EXE-файлом программы. ЗАМЕЧАНИЕ: Файл библиотеки (.LIB) при этом также создается, но он не содержит процедур и данных, а имеет только информацию о DLL (такую как точки входа в процедуры и др.).  Эта статья относится только к динамическим библиотекам (DLL). Предположим, что программа будет состоять из следующих частей (каждая часть соответствует отдельному APP):

• Глобальная DLL (только одна)

• Программные DLL (несколько)

• Главный EXE (только один)

Чтобы сделать разные типы DLL и EXE, нужно предоставить дополнительную информацию:

• Является ли приложение DLL или EXE (параметры проекта)

• Указать какие элементы (данные/классы/процедуры) линкуются в приложение (поведение по умолчанию)

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

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

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

Для упрощения понимания, глобальные данные теперь (Clarion 5) могут быть объявлены в Dictionary-s, что позволяет в каждом APP либо объявить и выделить память для них (в глобальных данных APP), либо просто объявить как external. То же самое относится и к классам. Методы класса должны существовать только в одном экземпляре (думаем о них как о процедурах), а свойства класса должны существовать для каждого экземпляра класса (думаем о них как о данных). Это означает что "код" класса должен быть только в одном APP (глобальном), в то время как экземпляры  класса - в зависимости от использования (экземпляры Window Manager должны быть локальными для процедуры, а единственный экземпляр File Manager должен быть глобальным). Эта DLL будет содержать главную копию всех объявлений фалов, глобальные данные, ABC class library и сгенерированный код поддержки целостности базы данных. В нем не будет доступа к другим DLL (кроме Clarion и Windows runtime). Для создания глобальной DLL выполним следующие шаги: Шаг 1:Чтобы дать возможность шаблонам правильно генерировать глобальные данные, они должны быть перемещены из секции данных (Global Properties) в файл глобальных данных Dictionary. Позднее любой APP, который использует эту Dictionary, будет способен сгенерировать глобальные данные с нужными атрибутами.Шаг 2: Создать новое APP, используя существующий DCT.Шаг 3: В диалоге Proect Editop|Global Options нужно установить Target Type на "DLL". Это сообщает компилятору/линкеру создавать DLL, и определяет какие элементы публиковать (экспортировать) при чтении файла EXP приложения. Будущее обсуждение файла экспорта потребует еще одной статьи!Шаг 4: В диалоге Global Properties на вкладке General установить Generate Templates Globals and ABC's As External в выключенное состояние. При генерации, все глобальные данные шаблонов и объявления классов ABC-библиотеки НЕ БУДУТ иметь атрибутов External или DLL. Это также приводит к тому, что библиотека ABC прилинковывается к этой DLL путем установки _ABCLinkMode_ в TRUE.Шаг 5: В диалоге Global Properties на вкладке File Control  убедитесь что параметр Generate All File Declarations включен. Это обеспечит генерацию всех объявлений файлов Dictionary. Так как глобальное APP не будет иметь браузеров или отчетов, без этого переключателя описания файлов вообще не будут генерироваться. Установите File Attributes/Export files/Export all file declarations в включенное положение. Это подобно Шагу 4 и в результате все сгенерированные описания файлов НЕ БУДУТ иметь атрибутов External или DLL.

Программные DLLsПрограммные DLLs содержат тело программы: браузеры , формы и отчеты. Число этих DLL диктуется размером программы. Из опыта, я обычно помещаю все отчеты в отдельный APP и все что осталось делю на функциональные группы (всю информацию об сотрудниках в один DLL, продажи/счета в другой и т.д.). Другой подход - разделить программу по программистам. Я также стараюсь делать не более 20 процедур в APP, так как это число соответствует моему уровню "терпимости" ожидания завершения генерации/компиляции. Примечание: Причина выделения отчетов в отдельную DLL не производительность, так как более эффективно держать отчеты в их логических DLL, а в практичности. По моему опыту, отчеты изменяются чаще всего, и поэтому держать их в отдельной DLL делает гораздо легче доставку и поддержку. Для создания программных DLLs:Шаг 1: Для каждой DLL, создаем новый APP и импортируем в нее нужные процедуры из оригинального APP и выполняем Шаг 3 из раздела "Глобальный DLL".Шаг 2:  В меню Application выбираем Insert Module и выбираем как тип модуля ExternalDLL. Это вызывает диалог Module Properties. В поле Name нужно ввести имя Lib-файла глобальной DLL.Шаг 3: В диалоге Global Properties на вкладке General установить следующие параметры: 1)Включить Generate Template Globals and ABC's as External. В результате при генерации все глобальные данные шаблонов и объявления классов ABC-библиотеки будут иметь атрибутов External и DLL.Это также приводит к тому, что библиотека ABC не прилинковывается к этой DLL так как _ABCLinkMode_  устанавливается в FALSE.2)Установить External Globals and ABC's Source Module в положение  Dinamic Link Library.  Это сообщает линковщику, что все глобальные объявления данных и библиотека классов ABC находится в другой DLL путем установки _ABCDllMode_ в TRUE. Это необходимо только для 32-разрядных DLLs так как компилятор нуждается в добавлении дополнительных "разименований" для выбора между статическими и динамическими библиотеками.Шаг 4: В диалоге Global Properties на вкладке File Control установите следующие параметры: 1) Выключите переключатель Generate All File Declarations, Нет необходимости генерировать ненужные объявления файлов. 2)УстановитеFileAttributes/Externalв положениеAllExternal. Это подобно Шагу 3 и обеспечивает что все сгенерированные объявления файлов будут иметь атрибуты External и DLL. 3)Включите переключательFileAttributes/Externalfiles/Allfilesaredeclaredinanotherapp. Это используется шаблонами Legacy для опциональной генерации атрибута EXTERNAL для флага File:Open.Шаг 5: Решите какие процедуры нужно экспортировать. Обычно это любые процедуры, которые вызываются из главного меню (браузеры и отчеты, но не формы так как они редко нужны где-либо кроме данной DLL). В диалоге Procedure Properties включите переключатель Export Procedure. Это говорит генератору о том что он должен создать соответствующую строку в файле экспорта.Примечание: При выполнении этих шагов могут возникнуть ссылки на процедуры, которые находятся не в этом DLL и появляются как ToDo. Они находятся в других DLLs и освещаются в следующем разделе. Пока они должны оставаться ка ToDo до тех пор пока не будут созданы соответствующие DLLs; может потребоваться несколько итераций для разрешения этих ссылок. Шаг 6: Компиляция.

Главный EXE. Главный EXE обычно содержит Application Frame и процедуры Splash и About. Являясь exe-файлом, он не может экспортировать процедуру и вызывает процедуры из Процедурных DLLs.Шаг 1: Создайте новое APP и импортируйте нужные процедуры из оригинального APP (Frame, Splash и т.д.).Шаг2: Повторите Шаги 2, 3 и 4 разделаПрограммные DLLs.Шаг 3: Имеются несколько ToDo процедур, каждая из которых относится к пункту меню, который вызывает данную процедуру. Чтобы вызвать эти процедуры, соответствующие им DLL/Lib файлы должны быть сначала добавлены в список модулей (это разрешит вызовы внешних процедур для линковщика).  Для каждой DLL выполняемШаг 2разделаПрограммные DLLs.Шаг 4: Для каждой ToDo процедуры выбираем процедурный шаблон External и убеждаемся что в поле Module Name выбрана правильная  библиотека (Lib-файл). Это добавляет объявления процедур в глобальный Map, в правильный модуль.Шаг 5: Компилируем главный EXE.

Если что-то не так, то появляется множество сообщений об ошибках. Не бойтесь этих сообщений; главные из них вот эти три сообщения: Unresolved External XXX in YYY.obj: Это означает что некоторые элементы объявлены как External, но линковщик не смог их найти ни в одной из подключенных библиотек.XXX Is unresolved for export: Некоторый элемент перечислен в EXP-файле, но линковщик не нашел его в APP.XXX is duplicated (dll): Это происходит если XXX экспортирован более чем в одной подключенной библиотеке или объявлен в текущем APP и одном (или более) подключенных библиотек»

Построение модульных диаграмм. Шаблоны представления модулей- нотация. Модули и компоненты. Пакеты. Определение деталей компонент. Зависимости между компонентами Представление размещения – диаграмма. Средства управления периода исполнения и их использование. Библиотеки периода выполнения программ.

Основная литература: 5 осн. [(3,4)Delphi7,C++Builder]

Контрольные вопросы:

1. Какие классы или компоненты необходимо выделять в отдельный модуль?

2. Как определить размещение классов (компонент) по модулям?

3. Как разделить модули на exeиdll?

4. Как разделить переполненный ехе модуль?

5. Какие инструменты построят диаграмму модулей?

6. Зачем нужна библиотека run-time?

7. Как отличается работа модулей построенных в чисто инструментальной среде и в среде

совмещающей среду исполнения с инструментом создания?