Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
29_Textovyy_redaktor_Memo_ekzamen.docx
Скачиваний:
8
Добавлен:
16.04.2019
Размер:
100.24 Кб
Скачать

Класс tCanvas

Определяет поверхность компонента, используемую для рисования и инструменты для рисования TFont, TPen, Tbrush. Объекты класса TCanvas не являются компонентами, но входят в состав компонентов своими свойствами. Канва состоит из точек – пикселей. В TCanvas определена система координат. На канве имеется невидимый графический курсор, который определяет положение карандаша. Рисование примитивов начинается именно с этого положения в процессе рисования оно изменяется.

Property Pen; - задает карандаш канвы.

Property Brush; - задает кисть канвы.

Property Font; - задает шрифт канвы.

Property Pos; - определяет текущее положение графического курсора.

Property Pixel[X,Y:integer]:TColor; - задает цвет пикселя с координатами X,Y.

События

OnChange – перед тем как на канве должны быть произведены изменения.

ONChangingсразу после изменения

Класс tFont

Property Color;- цвет символов.

Property Height;-высота в пикселях.

Property Name;- имя шрифта.

Property Size;- высота в пунктах.

Property Style;- задает тип шрифта.

TPen

Характеристики карандаша.

Property Color;-цвет линии (черный по умолчанию).

Property Mode;- (перечислимый) стиль цвета, т.е. взаимодействие линии с фоном.

Property Style;- (перечислимый) стиль линии (сплошная, штриховая).

Property Width;- толщина рисуемой линии в пикселях.

Класс Tbrush.

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

Property Bitmap; побитовое отображение изображения, размером 8х8, которое будет использоваться кистью для заполнения замкнутых пространств.

Property Color;- цвет кисти, по умолчанию – белый.

Property Style;- орнамент кисти (сплошная, горизонтальные линии, вертикальные и т.д..)

38 Компонент Image. Компонент Shape. Компонент PaintBox.

Страница палитры Additional. Используется для размещения на форме картинки. Файл изображения может быть битовой картой (расширение bmp), пиктограммой (ico), метафайлом (wmf). Непосредственный потомок класса TGraphicControl.

Canvas: Tcanvas предназначается для формирования изображения на этапе выполнения программы.

Center: Boolean;если true, то изображение центре компонента.

Picture: Tpicture – определяет изображение, помещаемое в компонент.

Stretch: Boolean - если значение true, то картинка увеличивается или уменьшается до размеров компонента. Image обрабатывает все события от мыши

Компонент Shape.

Экземплярами класса являются компоненты фигуры – круги, эллипсы, прямоуг..

Свойства

Brash:tBrashкисть для закрашивания поверхности фигуры.

Pen:Tpen - карандаш для рисования контура фигуры.

Shape:Tshape – определяет фигуру выводимую на экран.

Компонент PaintBox.

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

Свойство

OnPaint: TNotifyEvent; возникает перед тем как компонент должен быть перерисован. Событие по умолчанию OnClick

39 Диалоговые окна. OpenDialog SaveDialog

 Диалоговые окна служат для открытия файлов (OpenDialog), сохранения файлов (SaveDialog), для настройки параметров шрифта (FontDialog)-Property Font:TFont; Задает характеристики шрифта будет использоваться один из шрифтов, зарегистрированных в ОС. Активизируется методом Execute.

Для любого диалогового окна метод Function Execute: Boolean; - размещает это окно в модальном режиме. Возвращает ИСТИНА, если окно закрыто кнопкой Открыть, и ЛОЖЬ если кнопкой Отмена.

OpenDialog SaveDialog

Property FileName: TFileName; - имя выбранного файла.

Property Files: TStrings; - содержит список имен выделенных файлов (только для чтения).

Property Filter:sting; - Содержит описание одного или нескольких файловых фильтров.

property FilterIndex:Integer; - определяет какой элемент фильтра будет показан по умолчанию при открытии диалогового окна.

Property InitialDir:string; - определяет папку, содержимое которой появляется при открытии диалогового окна.

40 Технология программирования

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

ТП представляет собой набор технологических инструкций, включающих:

  • описание проектируемой системы (т.е. модели, используемые на каждом этапе разработки);

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

  • указание условий, при которых выполняются операции;

  • описание самих операций.

Первый этап - «стихийное» программирование (50-60-е годы).

Сформулированные технологии отсутствовали, программиро-вание было искусством.

Первые программы имели простейшую структуру. Они состоя-ли из программы на машинном языке и данных, обрабатываемых ею. Для повышения эффективности программирования в этот период разрабатываются ряд алгоритмических языков:

  • Низкого уровня - ассемблеры;

  • Высокого уровня FORTRAN и ALGOL

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

Причины кризиса:

  • при сборке программного продукта выявлялось большое количество ошибок согласования.

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

  • процесс тестирования и отладки программ занимал более 80 % времени разработки, если вообще заканчивался.

Анализ причин возникновения большинства ошибок позволил сформулировать новый подход к программированию, который был назван «структурным»

Второй этап - структурный подход к программированию

Структурный подход (60-70-е годы) охватывает все этапы разработки ПО. Он требует представления задачи в виде иерархии («часть-целое») подзадач более простой структуры вплоть до небольших подпрограмм (40-50 операторов). Поддержка принципов структурного программирования была заложена в основу процедурных языков программирования PL/1, ALGOL-68, Pascal, С, включающих «структурные» операторы, подпрограммы, локализацию данных.

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

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

Но структурный подход позволяет создавать надежные программы размером до 100.000 операторов. Причины: ошибка в интерфейсе выявляется при выполнении программы. Для разработки ПО большого объема был предложен объектный подход.

Третий этап - объектный подход к программированию (с середины 80-х до конца 90-х годов XX в.).

Программа представляется в виде ряда объектов. Объекты объединяют в себе данные и подпрограммы, обрабатывающие эти данные.

Каждый объект является экземпляром класса (типа), а классы образуют иерархию с наследованием («простое-сложное). Взаимодействие объектов осуществляется путем передачи сообщений.

Основным достоинством (ООП) по сравнению со структурным является «более естественная» декомпозиция задачи, которая существенно облегчает его разработку.

Недостатки реализации ООП в PASCALе и С++.

• компоновка объектов, полученных разными компиляторами затруднена, что приводит к необходимости разработки ПО в рамках одного компилятора и одной ОС;

•   изменение реализации одного объекта, связано с перекомпиляцией всего модуля.

Четвертый этап – компонентный подход и CASE-технологии (с середины 90-х годов до нашего времени).

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

В отличие от обычных объектов объекты-компоненты можно собрать в динамически вызываемые библиотеки или исполняемые файлы (*.dll *.exe), распространять в двоичном виде (без исходных текстов) и использовать в любом языке, поддерживающем соответствующую технологию.

41 Проблемы разработки сложных программных систем.

Современное ПО сложно, потому что решает сложные задачи. Кроме того:

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

  • не существует средств, позволяющих детально описывать поведение сложных систем на высоком уровне;

  • коллективная разработка, чем больше коллектив, тем сложнее организовать процесс работы;

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

42 Блочно-иерархический подход к созданию сложных систем.

Большинство сложных систем имеет иерархическую внутреннюю структуру, что позволяет рассматривать их как некоторую совокупность взаимозависимых подсистем. Внутренние связи элементов таких подсистем сильнее, чем связи между подсистемами.

На свойствах иерархических систем («целое-часть») строится блочно-иерархический подход к исследованию и созданию ПО, предполагающий сначала создавать части объектов (блоки, модули), а затем собирать из них объект.

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

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

Использование блочно-иерархического подхода

  • делает возможным создание сложных систем;

  • упрощает проверку работоспособности системы в целом и отдельных ее блоков;

  • обеспечивает возможность модернизации систем.

43 Жизненный цикл ПО и этапы его разработки

Жизненным циклом (ЖЦ) ПО называют период от момента появления идеи создания ПО до момента завершения его поддержки разработчиком или фирмой, выполнявшей сопровождение. ЖЦ состоит из ряда процессов, состав которых регламентируется стандартом ISO/IEC 12207: 1995.

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

По стандарту процесс разработки включает следующие действия:

•  подготовительную работу выбор модели ЖЦ, стандартов, методов и средств разработки, а также составление плана работ;

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

•  проектирование архитектуры системы определение состава необходимого оборудования, ПО;

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

проектирование архитектуры ПО определение структуры ПО, документирование интерфейсов его компонентов, разработку предварительной версии пользовательской документации, а также требований к тестам и плана интеграции;

детальное проектирование ПОподробное описание компонентов ПО и интерфейсов между ними, обновление пользовательской документации, разработка и документирование требований к тестам и плана тестирования компонентов программного обеспечения, обновление плана интеграции компонентов;

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

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

квалификационное тестирование ПО тестирование ПО в присутствии заказчика для демонстрации его соответствия требованиям и готовности к эксплуатации; при этом проверяется также готовность и полнота технической и пользовательской документации

интеграцию системы сборку всех компонентов системы, включая ПО и оборудование;

квалификационное тестирование системы тестирование системы на соответствие требованиям к ней и проверка оформления и полноты документации;

установку программного обеспечения установку программного обеспечения на оборудовании заказчика и проверку его работоспособности;

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

44 Постановка задачи. Анализ требований и определение спецификаций.

В процессе постановки задачи четко формулируют назначение ПО и определяют основные требования к нему.

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

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]