Недостатки объектно-ориентированного программирования

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

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

3. Также, на скорости выполнения программ может неблагоприятно сказаться реализация полиморфизма, которая основана на механизмах позднего связывания вызова метода с конкретной его реализацией в одном из производных классов.

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

Критерии качества программы

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

Качество исходного кода

Качество кода может определяться различными критериями. Некоторые из них имеют значение только с точки зрения человека. Например, то, как отформатирован текст программы, совершенно не важно для компьютера, но может иметь серьёзное значение для последующего сопровождения. Многие из имеющихся стандартов оформления кода, определяющих специфичные для используемого языка соглашения и задающие ряд правил, улучшающих читаемость кода, имеют своей целью облегчить будущее сопровождение ПО, включающее отладку и обновление. Существуют и другие критерии, определяющие, «хорошо» ли написан код, например, такие, как структурированность — степень логического разбиения кода на ряд управляемых блоков.

1. Читаемость кода

2. Лёгкость поддержки, тестирования, отладки, исправления ошибок, изменения

3. Низкая сложность кода

4. Низкое использование ресурсов: памяти и процессорного времени

5. Корректная обработка исключительных ситуаций

6. Малое число предупреждений при компиляции

Факторы качества

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

Некоторые из факторов качества:

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

Полнота - Все необходимые части программы должны быть представлены и полностью реализованы.

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

Портируемость - Лёгкость в адаптации программы к другому окружению: другой архитектуре, платформе, операционной системе или её версии.

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

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

Удобство использования - Простота и удобство использования программы. Это требование относится прежде всего к интерфейсу пользователя.

Надёжность - отсутствие отказов и сбоев в работе программ, а также простота исправления дефектов и ошибок.

Эффективность - Насколько рационально программа относится к ресурсам (память, процессор) при выполнении своих задач.

С точки зрения пользователя

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

1. Является ли пользовательский интерфейс интуитивно понятным?

2. Насколько просто выполнять простые, частые операции?

3. Насколько легко выполняются сложные операции?

4. Выдаёт ли программа понятные сообщения об ошибках?

5. Всегда ли программа ведёт себя так как ожидается?

6. Имеется ли документация и насколько она полна?

7. Является ли интерфейс пользователя само-описательным/само-документирующим?

8. Всегда ли задержки с ответом программы являются приемлемыми?

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

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

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

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

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

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

Кнопки

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

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

Немодальные диалоговые окна

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

Модальные на уровне приложения

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

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

Модальные на уровне окна

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

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

Дружественность

Интерфейс (interface) - комплекс условий, обеспечивающих взаимодействие объектов в окружающем информационном пространстве. Любая интерактивная система или программа нуждается в интерфейсе, обеспечивающем удобство и простоту работы человека (пользователя). "Дружественность" интерфейса к пользователю, обеспечивающая, в конечном итоге, эффективность системы в целом, сегодня обозначается термином usability (его общеупотребительный русскоязычный эквивалент – юзабилити, в свою очередь происходящее от англ. use — использовать и ability — способность).

Дружественный интерфейс должен предотвращать ситуации, которые могут закончиться ошибками, предупреждать пользователя о возможных ошибках и способах их предупреждения, предлагать отмену ошибочных действий. Дружественность интерфейса означает обеспечение простоты работы в сочетании с реализацией доступа к широким функциональным возможностям. Один из возможных путей поддержания простоты работы - представление на экране информации, минимально необходимой для выполнения пользователем очередного шага задания. Другой путь - размещение и представление элементов управления на экране с учетом их смыслового значения и логической взаимосвязи. Этот подход ориентируется на ассоциативное мышление пользователя. Благодаря дружественности интерфейса происходит лёгкость и быстрота работы пользователя:

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

• простой и быстрый способ размещения настраиваемого окна в нужное место экрана

• удобный и функциональный сервис поиска инструмента или группы инструментов.

Постановка задачи и спецификация программы

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

На этапе постановки задачи под спецификацией разрабатываемой программы понимается формализованное описание потребностей решаемой задачи.

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

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

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

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

4. Требования к составу и параметрам технических средств. Здесь указывают необходимый состав технических средств с указанием их основных технических характеристик.

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

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

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

 На стадии подготовки программных документов под спецификацией программы понимается состав программы и документации на нее.

Способы записи алгоритма.

Выделяют три наиболее распространенные на практике способа записи алгоритмов:

• словесный (запись на естественном языке);

• графический (запись с использованием графических символов);

• программный (тексты на языках программирования).