SlideShare a Scribd company logo
Лекция №11 для дисциплин: «Прикладное программирование» и «Языки
программирования»
1
Лекция 11 (ч.7)
Синтаксис и программные конструкции Visual C
Подготовительный этап
Практическую часть следует начинать с подготовительного этапа.
1. Создать отдельную папку для проекта.
2. Запустить C++ Builder. Сохранить «пустой» проект в подготовленной папке.
3. Расположить на форме (или на формах) выбранные визуальные компоненты.
4. Задать значения свойств визуальных компонентов, влияющие на внешний вид и
функционирование.
Разработка классов
Именно вопросам разработки классов или вопросам создания абстрактных типов данных
(АТД) требуется максимальное время при создании программы. Проекты, использующие
принципы ООП и предназначенные для решения математических задач, рекомендуется
разрабатывать в следующем порядке.
1. Анализ задачи.
На этом этапе выделяются математические объекты, с помощью которых можно описать
решение задачи. Между ними устанавливаются отношения:
Создавая математическую модель для решения задачи, нужно:
- сформулировать предположения, на которых будет основываться математическая
модель;
- определить, что считать исходными данными и результатами;
- записать математические соотношения, связывающие результаты и исходные данные.
2. Программная постановка задачи.
Устанавливает соответствие между возможностями программы и требованиями
пользователя.
3. Разработка интерфейсов класса.
При создании программы, как и при проектировании классов, разработчик должен
изначально исходить из предположения, что предложенная задача со временем может
претерпевать изменения, связанные с возрастанием и изменением запросов пользователя.
Поэтому необходимо предусмотреть механизм, который бы позволял мобильно изменять
интерфейсы классов. Не затрагивая их реализацию. С этой целью имеет смысл сразу
проектировать семейства классов.
В интерфейс вписываются поля и прототипы методов. Для них устанавливаются правила
доступа - public, private, protected. Методы можно разделить на две группы:
· Стандартные методы – конструкторы, в том числе конструктор копирования,
деструкторы, свойства, унарные и бинарные операторы;
· Специфичные методы, которые следуют из логики задачи.
Лекция №11 для дисциплин: «Прикладное программирование» и «Языки
программирования»
2
Особое внимание необходимо уделить конструкторам – методам конструирования
объектов. Конструкторы класса требуют тщательной проработки. Их может быть много – «на все
случаи жизни».
4. Формализация методов класса.
Формализация методов класса – это переход от спецификации метода, представляющего
собой словесное описание назначенного метода, представляющего собой словесное описание
назначения метода, к разработке алгоритма, обеспечивающего выполнение соответствующих
действий.
Этап «формализации методов класса» включает в себя разработку алгоритмов и запись
программной реализации этих алгоритмов. Если эти алгоритмы сложные, то их разработку
следует производить в соответствии с технологией нисходящего проектирования программ:
задача разбивается на новые подзадачи и так далее до тех пор, пока на очередном уровне
решение подзадачи не становиться очевидным. В соответствии с такой технологией интерфейсы
классов дополняются новыми методами со своими правилами доступа. Формализация методов
классов – важнейший элемент программирования.
Разработка алгоритма начинается с его словесного описания. В непростых случаях это
словесное описание в учебнике сопровождается демонстрационным примером. Возможным
шагом может быть написание блок-схемы алгоритма. В простом случае можно ограничиться
комментариями в описании кода метода. Иногда спецификация может быть выражена простой
фразой в контексте интерфейса класса. В сложных случаях в учебнике спецификация выводиться
из контекста интерфейса и более подробно описывается.
Разработка интерфейса приложения и его дизайна
Подразумевается, что соответствие интерфейса задачам пользователя является
неотъемлемым его свойством. Существует четыре основных критерия оценивания качества
любого интерфейса, а именно:
· Скорость работы пользователей;
· Количество человеческих ошибок;
· Скорость обучения; субъективное удовлетворение.
Скорость выполнения работ является важным критерием эффективности интерфейса.
Длительность выполнения работы пользователем состоит из длительности восприятия исходной
информации, длительности интеллектуальной работы (пользователь думает, что он должен
сделать), длительность физических действий пользователя и длительности реакции системы. Как
правило, длительность реакции системы является наименее значимым фактором.
Лекция №11 для дисциплин: «Прикладное программирование» и «Языки
программирования»
3
Согласно Дональду Норману, взаимодействие пользователя с системой (не только
компьютерной) состоит из семи шагов: формирование цели действий; определение общей
направленности действий; определение конкретных действий; выполнение действий; восприятие
нового состояния системы; интерпретация состояния системы; оценка результата.
Согласно этому списку процесс размышления занимает почти все время, в течение
которого пользователь работает с компьютером. Во всяком случае, шесть из семи этапов
полностью заняты умственной деятельностью. Соответственно, повышение скорости этих
размышлений приводит к существенному улучшению скорости работы.
К сожалению, существенно повысить скорость мышления пользователей не возможно. Тем
не менее, уменьшить влияние факторов, усложняющих процесс мышления, вполне возможно.
Пользователь должен знать:
· Что он хочет получить на выходе (решение задачи);
· Как минимум одну последовательность действий, приводящую к
успешному результату;
· Где ему найти все объекты, участвующие в процедуре решения;
· Как определять пригодность объектов для их использования;
· Как управляться с объектами.
Список довольно внушителен. И если с первым пунктом проблем обычно не возникает, то
остальные требуют определенных усилий. А помочь разобраться в этом должен интерфейс со
встроенной системой подсказок действий. Следовательно, должен быть продуман механизм
управления программой через элементы интерфейса.
Обеспечение функциональности приложения
Обеспечение функциональности приложения связано с разработкой кода программы,
предназначенного для:
· Операций с объектами класса, обеспечивающих их взаимодействие и
согласованную работу;
· Управление программой через элементы интерфейса.
Тестирование приложения
Тестирование программного продукта следует начинать с разработки плана тестирования. При
этом следует помнить, что весь процесс тестирования можно разделить на три этапа:
Лекция №11 для дисциплин: «Прикладное программирование» и «Языки
программирования»
4
· Проверка в нормальных условиях. Предполагает тестирование на основе данных, которые
характерны для условий функционирования программы.
· Проверка в экстремальных условиях. Тестовые данные включают граничные значения
области изменения входных переменных, которые должны восприниматься программой
как правильные данные. Типичными параметрами таких значений являются очень малые
или очень большие числа и отсутствие данных. Если один тип экстремальных условий –
это граничные объемы данных, когда массивы состоят из слишком малого или слишком
большого числа элементов.
· Проверка в исключительных ситуациях. Проводится с использованием данных, значения
которых лежат за пределами допустимой области изменений.
Известно, что все программы разрабатываются в расчете на обработку ограниченного
набора данных. Поэтому важно получить ответ на следующие вопросы:
· Что произойдет, если в программе, не рассчитанной на обработку отрицательных и
нулевых значений переменных, в результате какой-либо ошибки придется иметь
дело как раз с такими данными?
· Как будет вести себя программа, работающая с массивами, если количество их
элементов превысит величину, указанную в объявлении массива?
· Что произойдет, если числа будут слишком малыми или слишком большими?
Наихудшая ситуация складывается тогда, когда программа воспринимает не верные
данные как правильные и выдает не верный результат, но правдоподобный результат.
Хорошая программа должна сама отвергать любые данные, которые она не в
состоянии обрабатывать правильно.
Следует попытаться представить возможные типы ошибок, которые пользователь способен
допустить при работе с Вашей программой и которые могут иметь неприятные для нее
последствия. Нужно не забывать, что способ мышления пользователя отличается от способа
мышления программиста. Нужно предусмотреть обработку ошибок типа: отсутствие нудного
файла, неправильные форматы даты и т,д, Список действий, которые могут привести к
неправильному функционированию программы, довольно длинный и зависит от того, что делает
приложение в данный момент времени.
Для тестирования можно изготовить программу, которая будет вызывать выполняемую
процедуру и следить за ходом ее выполнения. Эта подпрограмма должна содержать: подготовку
входных данных, которые должны быть прочитаны из файла для запуска тестируемой
программы; сравнение выходных данных отдельных подпрограмм с контрольными значениями,
которые также извлекаются из файла.

More Related Content

What's hot

Mva stf module 5 - rus
Mva stf module 5 - rusMva stf module 5 - rus
Mva stf module 5 - rus
Maxim Shaptala
 
Unit Testing
Unit TestingUnit Testing
Unit Testing
Dima Denisenko
 
Никита Налютин, Антон Александров - Управление рисками тестирования
Никита Налютин, Антон Александров - Управление рисками тестированияНикита Налютин, Антон Александров - Управление рисками тестирования
Никита Налютин, Антон Александров - Управление рисками тестирования
SQALab
 
JavaTalks.Unit Testing.Part 1
JavaTalks.Unit Testing.Part 1JavaTalks.Unit Testing.Part 1
JavaTalks.Unit Testing.Part 1
sgdread
 
Тестирование параллельных программ
Тестирование параллельных программТестирование параллельных программ
Тестирование параллельных программ
Tatyanazaxarova
 
МАСТЕР-КЛАСС. Риски тестирования
МАСТЕР-КЛАСС. Риски тестированияМАСТЕР-КЛАСС. Риски тестирования
МАСТЕР-КЛАСС. Риски тестирования
SQALab
 
Как принести пользу разработке и упростить себе жизнь?
Как принести пользу разработке и упростить себе жизнь?Как принести пользу разработке и упростить себе жизнь?
Как принести пользу разработке и упростить себе жизнь?
SQALab
 
Идентификация рисков и проблем тестирования
Идентификация рисков и проблем тестированияИдентификация рисков и проблем тестирования
Идентификация рисков и проблем тестирования
SQALab
 
Ptsp презентация
Ptsp презентацияPtsp презентация
Ptsp презентацияakmoldir
 
Все об эстимейтах
Все об эстимейтахВсе об эстимейтах
Все об эстимейтах
Elena Sharovar
 
Варианты использования (use cases) для быстрой оценки проектов
Варианты использования (use cases) для быстрой оценки проектовВарианты использования (use cases) для быстрой оценки проектов
Варианты использования (use cases) для быстрой оценки проектов
SQALab
 
CodeFest 2013. Сурова И. — Аналитик — инструкция по применению для менеджеров...
CodeFest 2013. Сурова И. — Аналитик — инструкция по применению для менеджеров...CodeFest 2013. Сурова И. — Аналитик — инструкция по применению для менеджеров...
CodeFest 2013. Сурова И. — Аналитик — инструкция по применению для менеджеров...CodeFest
 
TPI® Next: оптимизируем процессы тестирования по взрослому
TPI® Next: оптимизируем процессы тестирования по взросломуTPI® Next: оптимизируем процессы тестирования по взрослому
TPI® Next: оптимизируем процессы тестирования по взрослому
QA Dnepropetrovsk Community (Ukraine)
 
Марри Кантор, Управление программными проектами
Марри Кантор, Управление программными проектамиМарри Кантор, Управление программными проектами
Марри Кантор, Управление программными проектамиElena Sharovar
 
Domain-тестирование
Domain-тестированиеDomain-тестирование
Domain-тестирование
SPB SQA Group
 
Техники тест дизайна для черноящичного тестирования
Техники тест дизайна для черноящичного тестированияТехники тест дизайна для черноящичного тестирования
Техники тест дизайна для черноящичного тестирования
Dmytro Protsenko
 
Тестирование как управление рисками продукта
Тестирование как управление рисками продуктаТестирование как управление рисками продукта
Тестирование как управление рисками продукта
SQALab
 
TMPA-2015: Formal Methods in Robotics
TMPA-2015: Formal Methods in RoboticsTMPA-2015: Formal Methods in Robotics
TMPA-2015: Formal Methods in Robotics
Iosif Itkin
 

What's hot (19)

Mva stf module 5 - rus
Mva stf module 5 - rusMva stf module 5 - rus
Mva stf module 5 - rus
 
Unit Testing
Unit TestingUnit Testing
Unit Testing
 
Никита Налютин, Антон Александров - Управление рисками тестирования
Никита Налютин, Антон Александров - Управление рисками тестированияНикита Налютин, Антон Александров - Управление рисками тестирования
Никита Налютин, Антон Александров - Управление рисками тестирования
 
JavaTalks.Unit Testing.Part 1
JavaTalks.Unit Testing.Part 1JavaTalks.Unit Testing.Part 1
JavaTalks.Unit Testing.Part 1
 
Тестирование параллельных программ
Тестирование параллельных программТестирование параллельных программ
Тестирование параллельных программ
 
МАСТЕР-КЛАСС. Риски тестирования
МАСТЕР-КЛАСС. Риски тестированияМАСТЕР-КЛАСС. Риски тестирования
МАСТЕР-КЛАСС. Риски тестирования
 
Как принести пользу разработке и упростить себе жизнь?
Как принести пользу разработке и упростить себе жизнь?Как принести пользу разработке и упростить себе жизнь?
Как принести пользу разработке и упростить себе жизнь?
 
Идентификация рисков и проблем тестирования
Идентификация рисков и проблем тестированияИдентификация рисков и проблем тестирования
Идентификация рисков и проблем тестирования
 
Ptsp презентация
Ptsp презентацияPtsp презентация
Ptsp презентация
 
Все об эстимейтах
Все об эстимейтахВсе об эстимейтах
Все об эстимейтах
 
Варианты использования (use cases) для быстрой оценки проектов
Варианты использования (use cases) для быстрой оценки проектовВарианты использования (use cases) для быстрой оценки проектов
Варианты использования (use cases) для быстрой оценки проектов
 
CodeFest 2013. Сурова И. — Аналитик — инструкция по применению для менеджеров...
CodeFest 2013. Сурова И. — Аналитик — инструкция по применению для менеджеров...CodeFest 2013. Сурова И. — Аналитик — инструкция по применению для менеджеров...
CodeFest 2013. Сурова И. — Аналитик — инструкция по применению для менеджеров...
 
TPI® Next: оптимизируем процессы тестирования по взрослому
TPI® Next: оптимизируем процессы тестирования по взросломуTPI® Next: оптимизируем процессы тестирования по взрослому
TPI® Next: оптимизируем процессы тестирования по взрослому
 
Марри Кантор, Управление программными проектами
Марри Кантор, Управление программными проектамиМарри Кантор, Управление программными проектами
Марри Кантор, Управление программными проектами
 
Domain-тестирование
Domain-тестированиеDomain-тестирование
Domain-тестирование
 
Техники тест дизайна для черноящичного тестирования
Техники тест дизайна для черноящичного тестированияТехники тест дизайна для черноящичного тестирования
Техники тест дизайна для черноящичного тестирования
 
Тестирование как управление рисками продукта
Тестирование как управление рисками продуктаТестирование как управление рисками продукта
Тестирование как управление рисками продукта
 
01ka-nov
01ka-nov01ka-nov
01ka-nov
 
TMPA-2015: Formal Methods in Robotics
TMPA-2015: Formal Methods in RoboticsTMPA-2015: Formal Methods in Robotics
TMPA-2015: Formal Methods in Robotics
 

Similar to лек11 7

прак 15.docx
прак 15.docxпрак 15.docx
прак 15.docx
ssuser6d63bc1
 
пр 15.docx
пр 15.docxпр 15.docx
пр 15.docx
ssuser6d63bc1
 
чмв лекция №7
чмв   лекция №7чмв   лекция №7
чмв лекция №7student_kai
 
Mva stf module 2 - rus
Mva stf module 2 - rusMva stf module 2 - rus
Mva stf module 2 - rus
Maxim Shaptala
 
оп.05 основы программирования
оп.05 основы программированияоп.05 основы программирования
оп.05 основы программирования
Stepan1234
 
Проектирование Программных Систем. Лекция 01
Проектирование Программных Систем. Лекция 01Проектирование Программных Систем. Лекция 01
Проектирование Программных Систем. Лекция 01
Dima Dzuba
 
Lection 3 4_pm
Lection 3 4_pmLection 3 4_pm
Lection 3 4_pm
Yana Brodetski
 
Частые ошибки при разработке фронтенда | Odessa Frontend Meetup #17
Частые ошибки при разработке фронтенда | Odessa Frontend Meetup #17Частые ошибки при разработке фронтенда | Odessa Frontend Meetup #17
Частые ошибки при разработке фронтенда | Odessa Frontend Meetup #17
OdessaFrontend
 
Построение систем автоматического протоколирования Си/Си++ кода
Построение систем автоматического протоколирования Си/Си++ кодаПостроение систем автоматического протоколирования Си/Си++ кода
Построение систем автоматического протоколирования Си/Си++ кода
Tatyanazaxarova
 
Дополнительная общеразвивающая программа «Основы программирования В C/C++»
Дополнительная общеразвивающая программа «Основы программирования В C/C++»Дополнительная общеразвивающая программа «Основы программирования В C/C++»
Дополнительная общеразвивающая программа «Основы программирования В C/C++»
rnmc7
 
Andrey Petrov P D P
Andrey Petrov P D PAndrey Petrov P D P
Andrey Petrov P D Prit2010
 
Модуль 8. Лекция 37-38. Управление качеством проекта
Модуль 8. Лекция 37-38. Управление качеством проектаМодуль 8. Лекция 37-38. Управление качеством проекта
Модуль 8. Лекция 37-38. Управление качеством проекта
Yana Brodetski
 
Mva stf module 1 - rus
Mva stf module 1 - rusMva stf module 1 - rus
Mva stf module 1 - rus
Maxim Shaptala
 
Как сделать наши проекты немного более управляемыми с Agile
Как сделать наши проекты немного более управляемыми с AgileКак сделать наши проекты немного более управляемыми с Agile
Как сделать наши проекты немного более управляемыми с Agile
Alexey Krivitsky
 
методология Rad (46)
методология Rad (46)методология Rad (46)
методология Rad (46)
romachka_pole
 
Статья «Формирование универсальных требований к пользовательским программам п...
Статья «Формирование универсальных требований к пользовательским программам п...Статья «Формирование универсальных требований к пользовательским программам п...
Статья «Формирование универсальных требований к пользовательским программам п...
ph.d. Dmitry Stepanov
 
Andrey Petrov методология P D P, часть 1, цели вместо кейсов
Andrey Petrov методология P D P, часть 1, цели вместо кейсовAndrey Petrov методология P D P, часть 1, цели вместо кейсов
Andrey Petrov методология P D P, часть 1, цели вместо кейсовrit2010
 
SqaВфны8
SqaВфны8SqaВфны8
SqaВфны8
Catherine Tipanova
 
Андрей Солоной "Как людям бизнеса работать с программистами"
Андрей Солоной "Как людям бизнеса работать с программистами"Андрей Солоной "Как людям бизнеса работать с программистами"
Андрей Солоной "Как людям бизнеса работать с программистами"
Startup_Technologies
 
Статья «Проблемы внедрения корпоративных информационных систем: уровень при...
Статья «Проблемы внедрения  корпоративных информационных систем:  уровень при...Статья «Проблемы внедрения  корпоративных информационных систем:  уровень при...
Статья «Проблемы внедрения корпоративных информационных систем: уровень при...
ph.d. Dmitry Stepanov
 

Similar to лек11 7 (20)

прак 15.docx
прак 15.docxпрак 15.docx
прак 15.docx
 
пр 15.docx
пр 15.docxпр 15.docx
пр 15.docx
 
чмв лекция №7
чмв   лекция №7чмв   лекция №7
чмв лекция №7
 
Mva stf module 2 - rus
Mva stf module 2 - rusMva stf module 2 - rus
Mva stf module 2 - rus
 
оп.05 основы программирования
оп.05 основы программированияоп.05 основы программирования
оп.05 основы программирования
 
Проектирование Программных Систем. Лекция 01
Проектирование Программных Систем. Лекция 01Проектирование Программных Систем. Лекция 01
Проектирование Программных Систем. Лекция 01
 
Lection 3 4_pm
Lection 3 4_pmLection 3 4_pm
Lection 3 4_pm
 
Частые ошибки при разработке фронтенда | Odessa Frontend Meetup #17
Частые ошибки при разработке фронтенда | Odessa Frontend Meetup #17Частые ошибки при разработке фронтенда | Odessa Frontend Meetup #17
Частые ошибки при разработке фронтенда | Odessa Frontend Meetup #17
 
Построение систем автоматического протоколирования Си/Си++ кода
Построение систем автоматического протоколирования Си/Си++ кодаПостроение систем автоматического протоколирования Си/Си++ кода
Построение систем автоматического протоколирования Си/Си++ кода
 
Дополнительная общеразвивающая программа «Основы программирования В C/C++»
Дополнительная общеразвивающая программа «Основы программирования В C/C++»Дополнительная общеразвивающая программа «Основы программирования В C/C++»
Дополнительная общеразвивающая программа «Основы программирования В C/C++»
 
Andrey Petrov P D P
Andrey Petrov P D PAndrey Petrov P D P
Andrey Petrov P D P
 
Модуль 8. Лекция 37-38. Управление качеством проекта
Модуль 8. Лекция 37-38. Управление качеством проектаМодуль 8. Лекция 37-38. Управление качеством проекта
Модуль 8. Лекция 37-38. Управление качеством проекта
 
Mva stf module 1 - rus
Mva stf module 1 - rusMva stf module 1 - rus
Mva stf module 1 - rus
 
Как сделать наши проекты немного более управляемыми с Agile
Как сделать наши проекты немного более управляемыми с AgileКак сделать наши проекты немного более управляемыми с Agile
Как сделать наши проекты немного более управляемыми с Agile
 
методология Rad (46)
методология Rad (46)методология Rad (46)
методология Rad (46)
 
Статья «Формирование универсальных требований к пользовательским программам п...
Статья «Формирование универсальных требований к пользовательским программам п...Статья «Формирование универсальных требований к пользовательским программам п...
Статья «Формирование универсальных требований к пользовательским программам п...
 
Andrey Petrov методология P D P, часть 1, цели вместо кейсов
Andrey Petrov методология P D P, часть 1, цели вместо кейсовAndrey Petrov методология P D P, часть 1, цели вместо кейсов
Andrey Petrov методология P D P, часть 1, цели вместо кейсов
 
SqaВфны8
SqaВфны8SqaВфны8
SqaВфны8
 
Андрей Солоной "Как людям бизнеса работать с программистами"
Андрей Солоной "Как людям бизнеса работать с программистами"Андрей Солоной "Как людям бизнеса работать с программистами"
Андрей Солоной "Как людям бизнеса работать с программистами"
 
Статья «Проблемы внедрения корпоративных информационных систем: уровень при...
Статья «Проблемы внедрения  корпоративных информационных систем:  уровень при...Статья «Проблемы внедрения  корпоративных информационных систем:  уровень при...
Статья «Проблемы внедрения корпоративных информационных систем: уровень при...
 

More from Anastasia Snegina

птп по ппп 2013 2014
птп по ппп 2013 2014 птп по ппп 2013 2014
птп по ппп 2013 2014 Anastasia Snegina
 
прикл.прогр птп 13 14
прикл.прогр птп 13 14прикл.прогр птп 13 14
прикл.прогр птп 13 14Anastasia Snegina
 
2012 2013 пм спп провидошина
2012 2013  пм спп провидошина2012 2013  пм спп провидошина
2012 2013 пм спп провидошинаAnastasia Snegina
 
2012 2013 пм спп провидошина
2012 2013  пм спп провидошина2012 2013  пм спп провидошина
2012 2013 пм спп провидошинаAnastasia Snegina
 
рп по у пп практике в
рп по у пп практике врп по у пп практике в
рп по у пп практике вAnastasia Snegina
 
рп по пр практике в
рп по пр практике врп по пр практике в
рп по пр практике вAnastasia Snegina
 
рп по у сп практике в
рп по у сп практике врп по у сп практике в
рп по у сп практике вAnastasia Snegina
 
рп по у пп практике вт
рп по у пп практике втрп по у пп практике вт
рп по у пп практике втAnastasia Snegina
 
рп по пр практике вт
рп по пр практике втрп по пр практике вт
рп по пр практике втAnastasia Snegina
 
рп по у сп практике вт
рп по у сп практике втрп по у сп практике вт
рп по у сп практике втAnastasia Snegina
 
рп по у пп практике вт
рп по у пп практике втрп по у пп практике вт
рп по у пп практике втAnastasia Snegina
 
рп по пр практике вт
рп по пр практике втрп по пр практике вт
рп по пр практике втAnastasia Snegina
 
рп по у сп практике вт
рп по у сп практике втрп по у сп практике вт
рп по у сп практике втAnastasia Snegina
 

More from Anastasia Snegina (20)

птп по ппп 2013 2014
птп по ппп 2013 2014 птп по ппп 2013 2014
птп по ппп 2013 2014
 
прикл.прогр птп 13 14
прикл.прогр птп 13 14прикл.прогр птп 13 14
прикл.прогр птп 13 14
 
я.прогр птп
я.прогр птпя.прогр птп
я.прогр птп
 
пп кос вт
пп кос втпп кос вт
пп кос вт
 
пп кос в
пп кос впп кос в
пп кос в
 
пп кос в
пп кос впп кос в
пп кос в
 
2012 2013 пм спп провидошина
2012 2013  пм спп провидошина2012 2013  пм спп провидошина
2012 2013 пм спп провидошина
 
2012 2013 пм спп провидошина
2012 2013  пм спп провидошина2012 2013  пм спп провидошина
2012 2013 пм спп провидошина
 
пп кос вт
пп кос втпп кос вт
пп кос вт
 
рп по у пп практике в
рп по у пп практике врп по у пп практике в
рп по у пп практике в
 
рп по пр практике в
рп по пр практике врп по пр практике в
рп по пр практике в
 
рп по у сп практике в
рп по у сп практике врп по у сп практике в
рп по у сп практике в
 
рп по у пп практике вт
рп по у пп практике втрп по у пп практике вт
рп по у пп практике вт
 
рп по пр практике вт
рп по пр практике втрп по пр практике вт
рп по пр практике вт
 
рп по у сп практике вт
рп по у сп практике втрп по у сп практике вт
рп по у сп практике вт
 
рп по у пп практике вт
рп по у пп практике втрп по у пп практике вт
рп по у пп практике вт
 
рп по пр практике вт
рп по пр практике втрп по пр практике вт
рп по пр практике вт
 
рп по у сп практике вт
рп по у сп практике втрп по у сп практике вт
рп по у сп практике вт
 
лр18
лр18лр18
лр18
 
лр15
лр15лр15
лр15
 

лек11 7

  • 1. Лекция №11 для дисциплин: «Прикладное программирование» и «Языки программирования» 1 Лекция 11 (ч.7) Синтаксис и программные конструкции Visual C Подготовительный этап Практическую часть следует начинать с подготовительного этапа. 1. Создать отдельную папку для проекта. 2. Запустить C++ Builder. Сохранить «пустой» проект в подготовленной папке. 3. Расположить на форме (или на формах) выбранные визуальные компоненты. 4. Задать значения свойств визуальных компонентов, влияющие на внешний вид и функционирование. Разработка классов Именно вопросам разработки классов или вопросам создания абстрактных типов данных (АТД) требуется максимальное время при создании программы. Проекты, использующие принципы ООП и предназначенные для решения математических задач, рекомендуется разрабатывать в следующем порядке. 1. Анализ задачи. На этом этапе выделяются математические объекты, с помощью которых можно описать решение задачи. Между ними устанавливаются отношения: Создавая математическую модель для решения задачи, нужно: - сформулировать предположения, на которых будет основываться математическая модель; - определить, что считать исходными данными и результатами; - записать математические соотношения, связывающие результаты и исходные данные. 2. Программная постановка задачи. Устанавливает соответствие между возможностями программы и требованиями пользователя. 3. Разработка интерфейсов класса. При создании программы, как и при проектировании классов, разработчик должен изначально исходить из предположения, что предложенная задача со временем может претерпевать изменения, связанные с возрастанием и изменением запросов пользователя. Поэтому необходимо предусмотреть механизм, который бы позволял мобильно изменять интерфейсы классов. Не затрагивая их реализацию. С этой целью имеет смысл сразу проектировать семейства классов. В интерфейс вписываются поля и прототипы методов. Для них устанавливаются правила доступа - public, private, protected. Методы можно разделить на две группы: · Стандартные методы – конструкторы, в том числе конструктор копирования, деструкторы, свойства, унарные и бинарные операторы; · Специфичные методы, которые следуют из логики задачи.
  • 2. Лекция №11 для дисциплин: «Прикладное программирование» и «Языки программирования» 2 Особое внимание необходимо уделить конструкторам – методам конструирования объектов. Конструкторы класса требуют тщательной проработки. Их может быть много – «на все случаи жизни». 4. Формализация методов класса. Формализация методов класса – это переход от спецификации метода, представляющего собой словесное описание назначенного метода, представляющего собой словесное описание назначения метода, к разработке алгоритма, обеспечивающего выполнение соответствующих действий. Этап «формализации методов класса» включает в себя разработку алгоритмов и запись программной реализации этих алгоритмов. Если эти алгоритмы сложные, то их разработку следует производить в соответствии с технологией нисходящего проектирования программ: задача разбивается на новые подзадачи и так далее до тех пор, пока на очередном уровне решение подзадачи не становиться очевидным. В соответствии с такой технологией интерфейсы классов дополняются новыми методами со своими правилами доступа. Формализация методов классов – важнейший элемент программирования. Разработка алгоритма начинается с его словесного описания. В непростых случаях это словесное описание в учебнике сопровождается демонстрационным примером. Возможным шагом может быть написание блок-схемы алгоритма. В простом случае можно ограничиться комментариями в описании кода метода. Иногда спецификация может быть выражена простой фразой в контексте интерфейса класса. В сложных случаях в учебнике спецификация выводиться из контекста интерфейса и более подробно описывается. Разработка интерфейса приложения и его дизайна Подразумевается, что соответствие интерфейса задачам пользователя является неотъемлемым его свойством. Существует четыре основных критерия оценивания качества любого интерфейса, а именно: · Скорость работы пользователей; · Количество человеческих ошибок; · Скорость обучения; субъективное удовлетворение. Скорость выполнения работ является важным критерием эффективности интерфейса. Длительность выполнения работы пользователем состоит из длительности восприятия исходной информации, длительности интеллектуальной работы (пользователь думает, что он должен сделать), длительность физических действий пользователя и длительности реакции системы. Как правило, длительность реакции системы является наименее значимым фактором.
  • 3. Лекция №11 для дисциплин: «Прикладное программирование» и «Языки программирования» 3 Согласно Дональду Норману, взаимодействие пользователя с системой (не только компьютерной) состоит из семи шагов: формирование цели действий; определение общей направленности действий; определение конкретных действий; выполнение действий; восприятие нового состояния системы; интерпретация состояния системы; оценка результата. Согласно этому списку процесс размышления занимает почти все время, в течение которого пользователь работает с компьютером. Во всяком случае, шесть из семи этапов полностью заняты умственной деятельностью. Соответственно, повышение скорости этих размышлений приводит к существенному улучшению скорости работы. К сожалению, существенно повысить скорость мышления пользователей не возможно. Тем не менее, уменьшить влияние факторов, усложняющих процесс мышления, вполне возможно. Пользователь должен знать: · Что он хочет получить на выходе (решение задачи); · Как минимум одну последовательность действий, приводящую к успешному результату; · Где ему найти все объекты, участвующие в процедуре решения; · Как определять пригодность объектов для их использования; · Как управляться с объектами. Список довольно внушителен. И если с первым пунктом проблем обычно не возникает, то остальные требуют определенных усилий. А помочь разобраться в этом должен интерфейс со встроенной системой подсказок действий. Следовательно, должен быть продуман механизм управления программой через элементы интерфейса. Обеспечение функциональности приложения Обеспечение функциональности приложения связано с разработкой кода программы, предназначенного для: · Операций с объектами класса, обеспечивающих их взаимодействие и согласованную работу; · Управление программой через элементы интерфейса. Тестирование приложения Тестирование программного продукта следует начинать с разработки плана тестирования. При этом следует помнить, что весь процесс тестирования можно разделить на три этапа:
  • 4. Лекция №11 для дисциплин: «Прикладное программирование» и «Языки программирования» 4 · Проверка в нормальных условиях. Предполагает тестирование на основе данных, которые характерны для условий функционирования программы. · Проверка в экстремальных условиях. Тестовые данные включают граничные значения области изменения входных переменных, которые должны восприниматься программой как правильные данные. Типичными параметрами таких значений являются очень малые или очень большие числа и отсутствие данных. Если один тип экстремальных условий – это граничные объемы данных, когда массивы состоят из слишком малого или слишком большого числа элементов. · Проверка в исключительных ситуациях. Проводится с использованием данных, значения которых лежат за пределами допустимой области изменений. Известно, что все программы разрабатываются в расчете на обработку ограниченного набора данных. Поэтому важно получить ответ на следующие вопросы: · Что произойдет, если в программе, не рассчитанной на обработку отрицательных и нулевых значений переменных, в результате какой-либо ошибки придется иметь дело как раз с такими данными? · Как будет вести себя программа, работающая с массивами, если количество их элементов превысит величину, указанную в объявлении массива? · Что произойдет, если числа будут слишком малыми или слишком большими? Наихудшая ситуация складывается тогда, когда программа воспринимает не верные данные как правильные и выдает не верный результат, но правдоподобный результат. Хорошая программа должна сама отвергать любые данные, которые она не в состоянии обрабатывать правильно. Следует попытаться представить возможные типы ошибок, которые пользователь способен допустить при работе с Вашей программой и которые могут иметь неприятные для нее последствия. Нужно не забывать, что способ мышления пользователя отличается от способа мышления программиста. Нужно предусмотреть обработку ошибок типа: отсутствие нудного файла, неправильные форматы даты и т,д, Список действий, которые могут привести к неправильному функционированию программы, довольно длинный и зависит от того, что делает приложение в данный момент времени. Для тестирования можно изготовить программу, которая будет вызывать выполняемую процедуру и следить за ходом ее выполнения. Эта подпрограмма должна содержать: подготовку входных данных, которые должны быть прочитаны из файла для запуска тестируемой программы; сравнение выходных данных отдельных подпрограмм с контрольными значениями, которые также извлекаются из файла.