Любая сложная система состоит из простых компонентов. В объектно-ориентированном программировании такими компонентами являются классы, а в функциональном – функции. Таким образом, наряду с классами, функции позволяют программисту описать абстракции. Абстракция — мысленное отвлечение от ряда свойств предметов и отношений между ними [1].
Для объектно-ориентированных систем выработаны принципы хорошего кода – SOLID-принципы [2], часть из них применима и к функциональной парадигме. Так, например принцип единой обязанности можно свести к тому, что функция должна иметь как можно более узкую зону ответственности, а значит – и причину для изменений. Хорошая абстракция в программирования должна скрывать детали реализации и предоставлять простой и удобный интерфейс.
2 Функционалы в LISP
Функционалы — это функции, которые используют в качестве аргументов или результатов другие функции [3]. Из этого определения следует, что функционалы являются инструментом построения более глубоких абстракций, чем обычные функции.
Функционал программы для-кафе.рф
2.1 Функционалы как абстракции
В чистых функциональных языках нет циклов, так как, например, цикл типа for требует наличия счетчика, изменяющего свое значение. Изменение значения переменной является побочными эффектом, поэтому такая операция в функциональных языках нередко отсутствует или ее рекомендуется избегать. Однако императивные циклические конструкции являются очень удобным способом представления повторяющихся вычислений — на них можно смотреть как на программную абстракцию, так:
— они имеют простой и удобный интерфейс — ими легко пользоваться;
— программист может не задумываться о деталях реализации этих конструкций – создании и уничтожении переменных внутри циклов, методах оптимизации, применяемых компиляторами автоматически и т.д. В функциональных языках вместо циклов применяется рекурсия.
Рекурсивный вызов функции сопряжен с использованием стека, в который помещаются аргументы вызываемой функции, адрес возврата, содержимое регистров процессора. При большой глубине рекурсии стек переполняется, исключением является «хвостовая рекурсия», которую компилятор/интерпретатор автоматически транслирует в традиционный цикл [5]. Таким образом, отображающие функционалы типа map можно в полной мере считать абстракциями, заменяющими традиционные циклические конструкции для отдельных случаев. MAP-функции отображают исходный список в новый список или порождают побочный эффект, связанный с исходным списком [6]. Это абстракции потому что предоставляется простой и безопасный интерфейс (сложно случайно организовать «вечную рекурсию»), программист не задумывается о реализации – в частности хвостовой рекурсии.
2.2 Функционалы как средство повышения качества кода
Функционалы соответствуют принципу единой обязанности, так как каждый из них решает только свою задачу. Так, например, map-функции организуют перебор элементов списка, вся дополнительная работа делегируется функции-аргументу. Функционалы содержат в себе некоторый хорошо реализованный код, которым легче воспользоваться, чем реализовать аналог.
Основной функционал программы Xmaind
Однако, это такие фрагменты кода, которые часто встречаются в программах, при отсутствии таких конструкций программисту пришлось бы часто руками реализовывать один и тот же код – нарушался бы принцип DRY – Don’t repeat yourself и KISS — keep it simple stupid [7]. Сами по себе функционалы обязательно что-либо делегируют функции-аргументу. Делегирование является элементарным шаблоном проектирования, повышающим гибкость системы [8]. Паттерны представляют собой некоторые удачные и широко известные (описанные в литературе) программные конструкции. Разобраться в таких конструкциях проще, чем в никому не известных конструкциях – поэтому делегирование – это хорошо, так как даже любой пользовательский (не описанный в стандартной библиотеке) функционал – реализует шаблон делегирования.
Выводы
В результате применения функционалов:
1. программист пишет меньше кода, а значит:
◦ делает меньше ошибок;
◦ стоимость поддержки проекта падает;
2. программный код становится более стандартным, снижается порог вхождения, а значит – упрощается процедура найма и стоимость новых программистов.
Источник: pro-prof.com
1. Функциональность программного средства (functionality)
Совокупность свойств ПС, определяемая наличием и конкретными особенностями набора функций, способных удовлетворять заданные или подразумеваемые потребности качества наряду с ее надежностью как технической системы.
2. Удобство использования программного средства (usability)
Совокупность свойств ПС, характеризующая усилия, необходимые для его использования, и оценку результатов его использования заданным кругом пользователей ПС.
3. Эффективность программного средства (efficiency)
Совокупность свойств ПС, характеризующая аспекты его уровня пригодности, которые связаны с характером и временем использования ресурсов, необходимых при заданных условиях функционирования.
Примечание: правильнее эту характеристику называть производительностью (performance); тогда как эффективность дожна также зависеть от затрат на создание и внедрение ПС.
4. Сопровождаемость программного средства(maintainability)
Совокупность свойств ПС, характеризующая усилия, которые необходимы для его модифи-кации. Модификация, может осуществляться для устранения дефектов, усовершенствования ПС или его адаптации к изменениям в условиях функционирования, a также в составе и особенностях требуемых функций.
5. Мобильность программного средства (portability)
Совокупность свойств ПС, характеризующая приспособленность для переноса из одной среды функционирования в другие.
6. Надежность программного средства (reliability)
Совокупность свойств, характеризующая способность программного средства сохранять заданный уровень пригодности в заданных условиях в течение заданного интервала времени.
Помимо перечисленных используются и другие характеристики качества ПС:
- Корректность или правильность подразумевает соответствие проверяемого объекта некоторому эталонному объекту или совокупности формализованных эталонных характеристик и правил. Корректность программы наиболее полно определяется степенью ее соответствия предъявляемым к ней формализованным требованиям — программной спецификации.
Если надежность программы — свойство, заложенное при ее изготовлении и проявляющееся при эксплуатации программы во времени (поэтому без длительного наблюдения нельзя сделать заключения о надежности программы), то корректность может быть проверена в статике на этапе разработки программы.
- Сложность программ. Рассматривается в трех аспектах:
- сложность процесса разработки программ;
- сложность программы как объекта разработки (статическая);
- сложность выполнения программы (динамическая) – учитывает ресурсы, необходимые для ее выполнения.
- Трудоемкость — совокупные затраты труда на создание или использование программы.
Различают трудоемкость на этапе проектирования программ и трудоемкость изучения и модификации программ при их сопровождении. На этапе проектирования основные затраты составляет трудоемкость создания программ заданной сложности и корректности. Трудоемкость зависит от квалификации специалистов, технологии проектирования, степени автоматизации разработки, испытаний и т.д. Трудоемкость изучения и модификации программ при сопровождении определяется степенью документированности программ, уровнем языка программирования, структурностью их построения и другими факторами, связанными с удобством анализа ПС и внесения изменений. Этот критерий влияет на длительность жизни программ. Целесообразность и длительность использования, модернизации и переноса программ сохраняются до тех пор, пока не станет рентабельной новая разработка.
- Этапы жизненного цикла программ и обеспечение качества программ на различных этапах. Характеристика статических и динамических составляющих качества программ.
Конструктивные критерии зависят не от области применения, а от этапа жизненного цикла программы (ЖЦП). На различных этапах ЖЦП рекомендуется использовать разные критерии: Критерии этапа разработки
- Трудоемкость ( статическая сложность )
- Корректность ( правильность ) программы
Критерии этапа эксплуатации ПП
- Функциональность
- Производительность ( ресурсоемкость )
- Надежность
Критерии этапа сопровождения
- Трудоемкость
- Понимаемость программы
- Производительность программы
- Надежность
В заключение рассмотрим основные компоненты, влияющие в целом на обеспечение заданного качества программных продуктов, состав которых показан на рис.1. На рисунке для трех основных составляющих качества ПП приведены метрики, определяющие качество ПП на уровне этой компоненты, и способ их использования для обеспечения высокого качества ПП. 
- Классификация видов сложности программных продуктов и их краткая характеристика.
Большое многообразие способов оценивания и видов сложности программных продуктов можно разделить на группы, представленные на рис 
Как видно из рисунка, прежде всего можно выделить статические составляющие сложности, характерные для этапов разработки ПП и определяющие их трудоемкость, и динамические составляющие сложности ПП, проявляющиеся в процессе выполнения программы. Трудоемкость разработки ПП может оцениваться двумя способами:
- по интегральным характеристикам сложности, которые определяются по внешним параметрам программы, не учитывающим ее внутреннюю структуру (подход «черного ящика»);
- по структурным характеристикам сложности, учитывающим внутреннюю структуру программы и зависящим от сложности маршрутов (потоков) управления, сложности потоков данных или специальных свойств графа управления (подход «белого ящика»).
Динамическая (или вычислительная) сложность характеризует процесс выполнения программы и имеет три взаимосвязанных составляющих:
- временную – определяется временем выполнения программы или временем ее реакции на запрос пользователя;
- программную – определяется составом и способом взаимодействия процедур или модулей, образующих программу, а также возможностью их размещения в кеш-памяти, основной памяти или на диске; а в случае распределенных приложений — размещением программ в компьютерах сети.
- информационную – определяется сложностью организации данных и доступа к ним, а также особенностями их размещения в кеш-памяти, основной памяти, на диске или на сетевом сервере.
Следует заметить, что для получения достаточно полного представления о сложности программного продукта как статические, так и динамические характеристики сложности следует рассматривать не по отдельности, а в совокупности.
- Система метрик Холстеда для оценивания характеристик программ. Измеримые параметры программ. Оценки длины и объема программы. Потенциальный объем программы. Причины несоответствия оценоктеоретическим значениям.
Одной из интересных интегральных систем оценивания не только сложности, но и качества программ в целом является система метрик, предложенная Холстедом.
Источник: studfile.net
Как использовать термин «функционал программы»?
Возникло недопонимание с начальством по-поводу термина «функционал». Поискав по открытым словарям, действительно не нашел данное слово в контексте программного обеспечения. С другой стороны, «возможности программы» или «алгоритм программы» не передают весь драматизм «функционала программы», да и на хабре это одно из самых частых слов. Как считает сообщество, насколько коректно использование данного термина?
- Вопрос задан более трёх лет назад
- 7053 просмотра
Комментировать
Решения вопроса 0
Ответы на вопрос 1
Программирую немного )
Функционал — математический термин. Меня подёргивает когда его употребляют не по назначению. Функциональность — вот подходящее слово.
Ответ написан более трёх лет назад
я хоть и пережил 3 семестра ФАНа в свое время, но меня не передергивает, а в жизни почти никто не говорит функциональность вместо функционала
Ваш ответ на вопрос
Войдите, чтобы написать ответ
- IT-терминология
Существует ли единый глоссарий для айти?
- нет подписчиков
- 31 мар.
- 157 просмотров
- IT-терминология
Аутентификация. Отсебятина или единообразие?
- 1 подписчик
- 13 дек. 2022
- 148 просмотров
- Бизнес-информатика
- +1 ещё
В чём отличие атрибута от критерия (принятие решений)?
- 1 подписчик
- 09 дек. 2022
- 136 просмотров
Источник: qna.habr.com