17 Основные этапы решения задач на ЭВМ, критерии качества программы, диалоговые программы, дружественность, жизненный цикл программы. Способы записи алгоритма, программа на языке высокого уровня.

1)Программирование-теоретич и практич дея-ть, связанная с созданием прог. Реш-е задач на компе включает в себя след основные этапы, часть из кот осуществляется без участия компа.

1. Постановка задачи: ●сбор инфы о задаче; ●формулировка усл-я задачи; ●опред-е конечных целей реш-я задачи; ●опред-е формы выдачи рез-тов; ●описание данных (их типов, диапазонов величин, структуры и т. п.).

2. Анализ и исследование задачи, модели: ●анализ существующих аналогов; ●анализ технич и программных средств; ●разработка математич модели; ●разработка структур данных.

3. Разработка алгоритма: ●выбор метода проектирования алгоритма; ●выбор формы записи алгоритма (блок-схемы, псевдокод и др.); ●выбор тестов и метода тестирования; ●проектирование алгоритма.

4. Программирование: ●выбор языка программирования; ●уточнение способов организации данных; ●запись алгоритма на выбранном языке программирования.

5. Тестирование и отладка: ●синтаксич отладка; ●отладка семантики и логической структуры; ●тестовые расчеты и анализ рез-тов тестирования; ●совершенствование проги.

6. Анализ рез-тов реш-я задачи и уточнение в случае необход-ти мат модели с повторным выполнением этапов 2-5.

7. Сопровождение проги: ●доработка проги для реш-я конкретных задач; ●оставление док-тации к решенной задаче, к мат модели, к алгоритму, к проге, к набору тестов, к использованию.

Классический ЖЦ:

1.Системный анализ – сбор и первич. формализация инфы о предмет обл-ти

2.Анализ требований – уточняются и детализируются ф-ции, хар-ки и интерфейс ПО

3.Проектирование ●Архитектура ПО ●Модульная структура ●Алгоритмическая структура ●Структуры данных ●Выходные и входные интерфейсы

4.Кодирование

5.Тестирование

6.Сопровождение – внесение изменений в эксплуатационный программный продукт(ПП)

(Док-тация, опис. прогу на кажд этапе)

Также есть спиральная, макетированная модель ЖЦ, использующие эволюционную стратегию разработки ПО.

Все проги м. разбить на 2 класса по хар-ру использования: 1.утилитарные проги — предназначены для удовлетворения нужд их разработчиков, проги «для себя»; 2.программные продукты — предназначены для удовлетворения потребностей пользователей, широкого распространения и продажи.

2)Программный продукт имеет неск-ко качественных хар-к: ●алгоритмическая сложность; ●полнота ф-ций обработки; ●объём файлов программ; ●требования к ОС и технич средствам обработки со стороны программного средства; ●объём дисковой памяти; ●размер оператив памяти.

Показатели кач-ва должны содержать след аспекты: ●насколько хорошо можно use программный продукт (просто, надёжно, эффективно); ●насколько легко эксплуатировать программный продукт; ●можно ли use программный продукт при изменении усл-я его применения.

В усл-ях существования рынка программных продуктов важными хар-ками явл-ся стоимость, кол-во продаж, время нахождения на рынке, известность фирмы-производителя и самой проги, наличие на рынке программных продуктов аналогичного назначения.

Основные критерии оценки кач-ва проги для ЭВМ

1.Прога работает и решает поставленную задачу. Эта хар-ка проги явл-ся самой важной. В связи с этим кажд прога д.б. устроена так, чтобы м. было проверить правильность полученных рез-тов. Такая проверка проводится в процессе отладки проги, на опред наборах входных данных, для кот заранее известен ответ.

2.Min время, затрачиваемое на тестирование и отладку проги– необход этап в процессе реш-я задачи на ЭВМ. Он занимает от трети до половины всего времени разработки проги, поэтому очень важно уменьшить время, затрачиваемое на тестирование и отладку.

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

Понимание и отладка проги облегчается, если она имеет простую и ясную структуру, если ограничено использование операторов передачи управления (GOTO). Перегруженность проги этими операторами приводит к хаотич структуре и затрудняет отладку.

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

4.Гибкость проги. Разработанная прога обычно находится в эксплуатации длит время. За это время м. измениться требования к решаемой задаче, технич задание, требования к проге. Появляется необход-ть внести опред изменения в прогу, что в некотор случаях бывает трудно сделать, т.к. разработчиком не предусмотрена такая возможность. "Хорошая" прога должна допускать модификацию.

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

6.Простота и эффективность. Прога д.б. просто организована. Это м. проявляться и в структуре проги, и в использовании простых и наиб естественных средств языка программирования, и в предпочтении простых структур данных и т.п.

Эффективность проги считается 1 из главных ее хар-к. Поэтому часто в ущерб др кач-вам проги разработчики прибегают к сложным ухищрениям, чтобы уменьшить объем используемой памяти или сократить время выполнения проги. Во многих случаях затрачиваемые на это усилия не оправдывают себя. Разумный подход к повышению эффективности проги состоит в том, чтобы выявить наиболее "узкие" места и постараться их улучшить.

3)Важной хар-кой явл-ся дружественность интерфейса, кот можно определить как меру того, наск-ко интерфейс удобен в работе, наск-ко корректно он м. сообщать о проблемах понимания

4)Способы записи алгоритмов

Useся след способы представления алгоритма

*на естественном языке,

*в виде схемы (блок-схемы) (графич)

«+»: высокая наглядность;

«-»: блок-схема явл-ся двумерной структурой и ее трансляция в одномерный программный код требует дополнит творческих усилий

*алгебраический (предполагает использование формальной грамматики для описания алгоритма)

*табличный

Компактность, но в случае неординарной ситуации и множ-ва условий табл получится разореженной

- Таблично-графический

­- на языке программирования

Язык программирования - это совокупность средств и правил представления алгоритмов в виде, приемлемом для компа.

5)Программа на языке высокого уровня

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

Так, высокоуровневые языки стремятся не только облегчить реш-е сложных программных задач, но и упростить портирование ПО. Использование разнообразных трансляторов и интерпретаторов обеспечивает связь прог, написанных при помощи языков высокого уровня, с различ ОС и оборудованием, в то время как их исходный код остаётся, в идеале, неизменным.

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

Примеры: C++, Visual Basic, Java, Python, Ruby, Perl, Delphi (Pascal), PHP. Языкам высокого уровня свойственно умение работать с комплексными структурами данных. В большинство из них интегрирована поддержка строковых типов, объектов, операций файлового ввода-вывода и т. п.

I языком программирования высокого уровня считается комп язык Plankalkül разработанный немец инженером Конрадом Цузе ещё в период 1942—1946 гг. Широкое применение высокоуровневых языков началось с возникновением Фортрана и созданием компилятора для этого языка (1957).

6)Стандартные типы данных

К стандартным относятся целые, действительные, логические, символьный и адресный типы.

Целые типы определяют константы, переменные и ф-ции, знач-я кот реализуются множ-вом целых чисел, допустимых в данной ЭВМ.

Над целыми операндами можно выполнять след арифметич операции: сложение +, вычитание -, умножение *, деление div, получение остатка от деления mod.

Рез-т арифметич операции над целыми операндами есть величина целого типа. Рез-т выполнения операции деления целых величин есть целая часть частного. Рез-т выполнения операции получения остатка от деления – остаток от деления целых. Например:17 div 2 = 8, 3 div 5 = 0, 17 mod 2 = 1, 3 mod 5 = 3.

Действительные типы определяют те данные, кот реализуются подмнож-вом действительных чисел, допустимых в данной ЭВМ.

Над действительными операндами м. выполнять след арифметич операции, дающие действительный рез-т: сложение +, вычитание -, умножение *, деление /.

Логический тип (Boolean) определяет те данные, кот м. принимать логич знач-я TRUE и FALSE.

К булевским операндам применимы след логич операции: not and or xor.

Символьный тип (Char) определяет упорядоченную совокупность символов, допустимых в данной ЭВМ. Знач-е символьной переменной или константы – это 1 символ из допустимого набора.

К величинам символьного типа применимы все операции отнош-я.

Диалоговые программы

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

Диалоговое окно (англ. dialog box) — в графическом пользовательском интерфейсе специальный элемент интерфейса, окно, предназначенное для вывода информации и (или) получения ответа от пользователя. Получил своё название потому, что осуществляет двустороннее взаимодействие компьютер-пользователь («диалог»): сообщая пользователю что-то и ожидая от него ответа.

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

Простейшим типом диалогового окна является окно сообщения (англ. message box, англ. alert box), которое выводит сообщение и требует от пользователя подтвердить, что сообщение прочитано. Для этого обычно необходимо нажать кнопку OK. Окно сообщения предназначено для подтверждения системой выполнения команды, вывода сообщения об ошибке и тому подобных случаев, не требующих от пользователя какого-либо выбора.

Несмотря на то, что использование окна сообщения является часто применяемым шаблоном проектирования, оно критикуется экспертами по юзабилити как неэффективное решение для поставленной задачи (защита от ошибочных действий пользователя) вдобавок, при наличии лучших альтернатив.

Кнопки
В диалоговых окнах многих программ присутствуют кнопки OK и Отмена (Cancel), нажимая первую из которых пользователь выражает своё согласие с тем, что в этот момент отображает диалоговое окно, и тем самым закрывает его, приводя в действие сделанные в нём изменения, а вторая — закрывает окно без применения. Существуют варианты с единственной кнопкой ОК — в информирующих окнах, не подразумевающих каких-либо изменений, и с кнопками ОК, Применить (Apply) и Закрыть (Close), в окнах, результаты изменений в которых пользователь, по мнению автора программы, может оценить не закрывая окна, и в случае неудовлетворительного результата продолжить внесение изменений.

Так же хорошим тоном считается обеспечить в диалоговых окнах справочную систему — обычно это реализуется либо в виде кнопки Справка (Help), открывающей страницу документации, описывающую работу в этом диалоговом окне, либо (в Windows) с помощью кнопки с знаком вопрос в заголовке окна, нажав на которую пользователь переключает мышь в режим одноразовой контекстной подсказки: нажатие мышью в этом режиме на элемент диалогового окна вызывает отображение описания этого элемента.

Немодальные диалоговые окна
Немодальные (англ. modeless) диалоговые окна используются в случаях, когда выводимая в окне информация не является существенной для дальнейшей работы системы. Поэтому окно может оставаться открытым, в то время как работа пользователя с системой продолжается. Разновидностью немодального окна является панель инструментов или окно-«палитра», если она отсоединена или может быть отсоединена от главного окна приложения, так как элементы управления, расположенные на ней, могут использоваться параллельно с работой приложения. Впрочем, такие окна редко называют «диалоговыми».

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

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

Например, модальными являются диалоговые окна настроек приложения — так как проще реализовать режим, когда все сделанные изменения настроек применяются или отменяются одномоментно, и с момента, когда пользователь решил изменить настройки приложения и открыл диалог настроек, и до момента, когда он новые настройки вводит в силу или отказывается от них, приложение ожидает решения пользователя.

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

Специалисты по юзабилити считают модальные окна запросов подтверждений плохими дизайнерскими решениями, так как они могут приводить пользователя к, так называемым, «ошибкам режима программы». Опасные действия должны иметь возможность отмены везде, где это возможно, а модальные окна запросов подтверждений, пугающие пользователя своим неожиданным появлением, через некоторое время пропускаются им автоматически (так как он привык к ним) и, поэтому, не защищают от опасных действий.

Модальные на уровне окна
Для смягчения недостатков модальных диалоговых окон (блокирование доступа к приложению, или, даже, к системе в целом) была предложена концепция модальности на уровне окна (или документа). Такой тип диалогового окна введён, например, в Mac OS X, где он называется «диалоговое модальное окно для документа» (англ. document modal sheet).

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