
- •Динамическая память и указатели. Типы указателей. Описание указателей.
- •Операции над указателями. Выделение динамической памяти для типизированных и нетипизированных указателей. Проблема утечки памяти.
- •Стеки и очереди.
- •Модули.
- •Классы, объекты. Объявление класса, принципы ооп.
- •Инкапсуляция и разграничение доступа к членам класса.
- •Методы (виды методов), конструктор и деструктор.
- •Перекрытие методов, перекрытие конструктора, inherited
- •Поля, Свойства. События
- •Полиморфизм is, as.
- •Дерево классов delphi. Класс tObject. Класс tPersistent. Класс tСomponent.
- •Класс tСontrol.
- •Свойства и методы для обеспечения отношения родительский-дочерний
- •Свойства позиционирования и выравнивания
- •Свойства, определяющие внешний вид элементов управления. Property Color Cursor:Tcursor; Enabled:Boolean; Font, Hint, ShowHint
- •События при нажатии мышью на левую кнопку. Общие события, возникающие при манипулировании мышью.
- •События, предназначенные для поддержки перетаскивания.
- •Свойства и методы, поддерживающие связь родительский-дочерний.
- •События клавиатуры TwinControl. События активизации оконного элемента и потери фокуса.
- •Класс tGraphicControl. Метка Tlabel. Компонент Timer.
- •Interval: cardinal; - интервал в милисекундах после которого начинается событие OnTimer.
- •Класс tCustomEdit. Строка ввода Edit.
- •Класс tStrings. Текстовый редактор Memo.
- •Кнопки.Button, BitBtn, SpeedButton
- •Список ListBox.
- •Комбинированная строка ввода ComboBox.
- •Items:tString;-содержит список названий переключателей.
- •Классы и компоненты, предназначенные для создания изображений. Класс tCanvas. Класс tFont. Класс tPen. Класс Tbrush.
- •Компонент Image. Компонент Shape. Компонент PaintBox.
- •Диалоговые окна. OpenDialog SaveDialog
- •Этапы развития технологии программирования.
- •Первый этап - «стихийное» программирование (50-60-е годы).
- •Второй этап - структурный подход к программированию
- •Третий этап -объектный подход к программированию(с середины 80-х до конца 90-х годов XX )
- •Четвертый этап – компонентный подход и case-технологии (с середины 90-х годов до нашего времени).
- •Проблемы разработки сложных программных систем.
- •Блочно-иерархический подход к созданию сложных систем.
- •Жизненный цикл по и этапы его разработки. Гост 19.102-77 «Стадии разработки»
- •Постановка задачи. Анализ требований и определение спецификаций. Проектирование. Реализация. Сопровождение.
- •Эволюция моделей жизненного цикла по.
- •Жизненный цикл по при использовании case-технологий. Технология rad
- •Оценка качества процессов создания по.
- •5. Оптимизирующий уровень (optimizing level)
- •Понятие технологичности программного обеспечения. Нисходящая и восходящая разработка по
- •Последовательность проектирования и реализации (Иерархический , Операционный , Комбинированный)
- •Модульное программирование. Модули и их свойства. Сцепление модулей. Связность модулей.
- •Предпроектные исследования предметной области
- •Разработка технического задания. Последовательность разработки тз.
- •Принципиальные решения начальных этапов проектирования: Выбор архитектуры программного обеспечения. Выбор типа пользовательского интерфейса. Выбор подхода к разработке.
- •Стадии тестирования. Принципы тестирования. Формирование тестовых наборов ст иФн.
- •Ручной контроль по: инспекция исходного текста, сквозные просмотры, проверка за столом.
- •Структурное тестирование.
- •Функциональное тестирование.
- •Тестирования модулей и комплексное тестирование.
- •Критерии завершения тестирования и отладки. Оценочное тестирование
Последовательность проектирования и реализации (Иерархический , Операционный , Комбинированный)
Для определения последовательности проектирования и реализации компонентов в нисходящем подходе применяют методы :
Иерархический – разработка идет строго по уровням. Недостатки: большое количество сложных заглушек, основная масса модулей разрабатывается и реализуется в конце работы над проектом;
Операционный - последовательность разработки модулей совпадает с порядком их выполнения при запуске программы. Недостатки: модули вывода результатов должны разрабатываться первыми, чтобы не проектировать сложную заглушку, при тестировании;
Комбинированный.
Комбинированный метод учитывает следующие факторы, влияющие на последовательность разработки:
достижимость модуля – наличие всех модулей в цепочке вызова данного модуля;
зависимость по данным – модули, формирующие некоторые данные, должны создаваться раньше обрабатывающих, модули вывода результатов должны создаваться раньше обрабатывающих;
готовность вспомогательных модулей – вспомогательные модули должны создаваться раньше обрабатывающих
сложные модули должны разрабатываться прежде простых.
если некоторый компонент нижнего уровня используется многими компонентами более высоких уровней, то его рекомендуют проектировать и разрабатывать раньше, чем вызывающие его компоненты
Модульное программирование. Модули и их свойства. Сцепление модулей. Связность модулей.
При проектировании сложного ПО выполняют декомпозицию компонентов (в соотвеств с подходом) до получения простых элементов. При этом используют два способа декомпозиции: процедурный (структурный), объектный.
Результатом процедурной декомпозиции является иерархия подпрограмм (процедур), в которой верхние уровни - процедуры, связанные с принятием решения, а нижние уровни - процедуры обработки.
Результатом объектной декомпозиции является совокупность объектов, представляющих собой поля и методы, работающие с этими полями.
Таким образом, при любом способе декомпозиции получают набор процедур , которые в процессе реализации организуют в модули.
Модули и их свойства
Термин «модуль» используется в двух смыслах. Первоначально – это подпрограммы (они компилировались отдельно). В настоящее время - это набор программных ресурсов (констант, переменных, описаний типов, классов и подпрограмм) компилируемый автономно.
Чем выше степень независимости модулей, тем:
легче разобраться в модуле, тестировать, отлаживать и модифицировать его;
меньше «волновой» эффект - новые ошибки при исправлении старых
проще организовать разработку ПО группой программистов.
Таким образом, уменьшение зависимости модулей улучшает технологичность проекта.
Степень независимости модулей (как подпрограмм, так и библиотек) оценивают двумя критериями: сцеплением и связностью.
Сцепление модулей
Сцепление - мера взаимозависимости модулей, определяющая, насколько хорошо модули отделены друг от друга. Модули независимы, если каждый из них не содержит о другом никакой информации. Чем больше информации о других модулях хранит модуль, тем больше он с ними сцеплен.
Различают пять типов сцепления модулей:
по данным - модули обмениваются только скалярными данными ;
по образцу - модули обмениваются структурами данных;
по управлению - один модуль посылает другому сигнал (флаг), предназначенный для управления внутренней логикой модуля, что снижает наглядность взаимодействия модулей;
по общей области данных - модули работают с общей областью данных. Этот тип сцепления считается недопустимым, поскольку: программы сложны при сопровождении; есть зависимость от истории вызовов; ошибка одного модуля может проявиться при выполнении другого (усложняется локализация ошибок); используются конкретные имена;
по содержимому - один модуль содержит обращения к внутренним компонентам другого, это противоречит блочно-иерархическому подходу. Отдельный модуль в этом случае уже не является «черным ящиком»: его содержимое должно учитываться в процессе разработки другого модуля. Pascal не поддерживают данного типа сцепления, но в Ассемблере это возможно.
по общей области данных - модули работают с общей областью данных. Этот тип сцепления считается недопустимым, поскольку: программы сложны при сопровождении; есть зависимость от истории вызовов; ошибка одного модуля может проявиться при выполнении другого (усложняется локализация ошибок); используются конкретные имена;
по содержимому - один модуль содержит обращения к внутренним компонентам другого, это противоречит блочно-иерархическому подходу. Отдельный модуль в этом случае уже не является «черным ящиком»: его содержимое должно учитываться в процессе разработки другого модуля. Pascal не поддерживают данного типа сцепления, но в Ассемблере это возможно.
Как правило, модули сцепляются между собой несколькими способами. Качество ПО принято определяется по типу сцепления с худшими характеристиками.
Так, если использовано сцепление по данным и сцепление по управлению, то определяющим считают сцепление по управлению.
Связность модулей
Связность – степень взаимосвязи элементов, реализуемых одним модулем.
Размещение сильно связанных элементов в одном модуле уменьшает межмодульные связи и взаимное влияние модулей.
Размещение же сильно связанных элементов в разные модули усиливает межмодульные связи и усложняет понимание их взаимодействия.
Объединение слабо связанных элементов также уменьшает технологичность модулей, так как ими сложнее мысленно манипулировать.
Различают следующие виды связности (в порядке убывания уровня):
• функциональную - все объекты модуля предназначены для выполнения одной функции ;
• последовательную - выход одной функции служит исходными данными для другой функции ;
• информационную - связанными считают функции, обрабатывающие одни и те же данные ;
• процедурную - функции или данные, которые являются частями одного процесса. Обычно модули с процедурной связностью функций получают, если в модуле объединены функции альтернативных частей программы.
• временную - функций подразумевает, что эти функции выполняются параллельно или в течение некоторого периода времени;
• логическую - объединении данных или функций в одну логическую группу;
• случайную - если связь между элементами мала или отсутствует.
Структурное программирование. Стиль оформления программы. Правила именования объектов программы. Правила оформления модулей. Стиль оформления текстов модулей. Сквозной структурный контроль. Эффективность и технологичность.
Структурное программирование
Любой линейный алгоритм может быть реализован в виде комбинаций трех типовых структур алгоритмов: линейной, ветвящейся и циклической.
Слово «структурное» в данном названии подчеркивает тот факт, что при программировании использованы только перечисленные конструкции (структуры). Отсюда и понятие «программирование без go to».
Способы описания алгоритмов
Стиль оформления программы
Технологичным считают стиль оформления программы, облегчающий ее восприятие самим автором и другими программистами.
Хороший стиль оформления программы включает:
правила именования объектов программы (переменных, функций, типов, и т.п.);
правила оформления модулей;
стиль оформления текстов модулей
Правила именования объектов программы
Имя объекта должно соответствовать его содержанию. Например: Maxltem - максимальный элемент.
Если позволяет язык программирования, можно использовать символ «_» для визуального разделения имен, состоящих из нескольких слов Max_ltem, Next_Item.
Необходимо избегать близких по написанию имен, например: Index и InDec.
Правила оформления модулей
Каждый модуль должен предваряться комментарием, который, содержит: - название модуля; - краткое описание его назначения; - краткое описание входных и выходных параметров; - краткое описание алгоритма (метода) и ограничений; - ФИО автора программы, идентифицирующую информацию (номер версии и/или дату последней корректировки). Например:
{*****************************************************}
{* Функция: Length_Path(n:word; L: array of real):real *}
{* Цель: определение суммарной длины отрезков *}
{* Исходные данные: *}
{* L - массив длин отрезков (в метрах) *}
{* Результат: длина (в метрах) *}
{* Вызываемые модули: нет *}
{* Описание алгоритма: *}
{* отрезки суммируются методом накопления, n > О *}
{* Дата: 25.12.2001 Версия 1.01. ' *}
{* Автор: Иванов И.И. *}
{* Исправления: нет *}
{*********************************}
Стиль оформления текстов модулей
Стиль оформления текстов модулей определяет использование комментариев, пропусков строк и отступов, облегчающих понимание программы.
Пропуски строк и комментарии используют для визуального разделения частей модуля.
Комментарии должны содержать цели выполнения тех или иных действий и некоторую дополнительную (неочевидную) информацию.
Использование отступов позволяет прояснить структуру программы - дополнительный отступ обозначает вложение операторов.
Сквозной структурный контроль
Сквозной структурный контроль представляет собой совокупность технологических операций контроля, позволяющих обеспечить как можно более раннее обнаружение ошибок в процессе разработки.
Термин «сквозной» в названии отражает выполнение контроля на всех этапах разработки. Термин «структурный» означает наличие четких рекомендаций по выполнению контролирующих операций на каждом этапе.
Сквозной структурный контроль должен выполняться на специальных контрольных сессиях, в которых, помимо разработчиков, могут участвовать специально приглашенные эксперты.
Для всех этапов целесообразно иметь списки наиболее часто встречающихся ошибок, которые формируют по литературным источникам и исходя из опыта предыдущих разработок.
Эффективность и технологичность
Традиционно эффективными считают программы, требующие минимального времени выполнения и/или минимального объема оперативной памяти.
Иногда способы снижения временных затрат приводят к увеличению емкостных и, наоборот. Не следует «платить» за увеличение эффективности снижением технологичности. Частично проблему эффективности программ решают за программиста компиляторы.
Способы экономии памяти. Следует выбирать алгоритмы обработки, не требующие дублирования исходных данных структурных типов в процессе обработки в динамической памяти и удалять при завершении обработки. «по значению»
Способы уменьшения времени выполнения. необходимо анализировать циклические участки программы с большим количеством повторений выносить вычисление не зависящих от параметров цикла, выражений из циклов, минимизировать преобразования типов в выражениях и т.д.