Лицензии для школ и вузов

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

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

58. Сложность программных средств. Основные виды сложности проектирования и функционирования ПС. Измерение и оценка сложности программных средств.

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

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

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

В простейшем случае сложность системы определяется как сумма мер сложности ее модулей. Сложность модуля может вычисляться различными способами.

При оценке сложности программ, как правило, выделяют три основные группы метрик:

1) метрики размера программ

2) метрики сложности потока управления программ

3) метрики сложности потока данных программ.

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

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

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

Основу метрики Холстеда составляют четыре измеряемые характеристики программы: h1 - число уникальных операторов программы, включая символы-разделители, имена процедур и знаки операций (словарь операторов); h2 – число уникальных операндов программы (словарь операндов); N1 – общее число операторов в программе N2 – общее число операндов в программе.

Опираясь на эти характеристики, получаемые непосредственно при анализе исходных текстов программ, М. Холстед вводит следующие оценки:

h=h1+h2 словарь программы

N=N1+N2 длину программы

V=N∙log2(n) (бит) объем программы

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

Далее М. Холстед вводит h* - теоретический словарь программы, т.е. словарный запас, необходимый для написания программы, с учетом того, что необходимая функция уже реализована в данном языке и, следовательно, программа сводится к вызову этой функции. Например, согласно М. Холстеду, возможное осуществление процедуры выделения простого числа могло бы выглядеть так:

CALL SIMPLE (X,Y),

где Y - массив численных значений, содержащий искомое число X.

Теоретический словарь в этом случае будет состоять из

h1*: {CALL, SIMPLE (...)},

h1*=2; h2*: {X, Y},

h2*=2,

а его длина, определяемая как

h* = h1* + h2*,

будет равняться 4.

Используя n*, Холстед вводит оценку V*:

V* = h* ∙ log2 h*,

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

Вторая наиболее представительная группа оценок сложности программ – метрики сложности потока управления программ. Как правило, с помощью этих оценок оперируют либо плотностью управляющих переходов внутри программ, либо взаимосвязями этих переходов.

И в том и в другом случае стало традиционным представление программ в виде управляющего ориентированного графа G(V,E), где V – вершины, соответствующие операторам, а E – дуги, соответствующие переходам. В дуге (U,V) – вершина V является исходной, а U – конечной. При этом U непосредственно следует V, а V непосредственно предшествует U. Если путь от V до U состоит более чем из одной дуги, тогда U следует за V, а V предшествует U.

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

Для вычисления цикломатического числа Маккейба Z(G) применяется формула

Z(G) = l–v+2p,

где l – число дуг ориентированного графа G; v – число вершин; p- число компонентов связности графа.

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

По сути Z(G) определяет число линейно независимых контуров в Сильно связном графе. Иначе говоря, цикломатическое число Маккейба показывает требуемое количество проходов для покрытия всех контуров сильно связного графа или количество тестовых прогонов программы, необходимых для исчерпывающего тестирования по критерию "работает каждая ветвь".

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

Исходя из этого Г. Майерс предложил расширение этой метрики. Суть подхода Г. Майерса состоит в представлении метрики сложности программ в виде интервала [Z(G), Z(G)+h]. Для простого предиката h=0, а для n-местных предикатов h=n–1. Таким образом, первому оператору соответствует интервал [2,2], а второму - [2,6].

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

В графе программы, где каждому оператору соответствует вершина, т. е. не исключены линейные участки, при передаче управления от вершины a к b номер оператора a равен min(a,b), а номер оператора b - max(a,b). Точка пересечения дуг появляется, если

min(a,b) < min(p,q) < max(a,b) & max(p,q) > max(a,b) |

min(a,b) < max(p,q) < max(a,b) & min(p,q) < min(a,b).

Иными словами, точка пересечения дуг возникает в случае выхода управления за пределы пары вершин (a,b).

Количество точек пересечения дуг графа программы дает характеристику не структурированности программы.

Одной из наиболее простых, но, как показывает практика, достаточно эффективных оценок сложности программ является метрика Т. Джилба, в которой логическая сложность программы определяется как насыщенность программы выражениями типа IF-THEN-ELSE. При этом вводятся две характеристики: CL – абсолютная сложность программы, характеризующаяся количеством операторов условия; cl – относительная сложность программы, характеризующаяся насыщенностью программы операторами условия, т. е. cl определяется как отношение CL к общему числу операторов.

Используя метрику Джилба, можно дополнить ее еще одной составляющей, а именно характеристикой максимального уровня вложенности оператора CLI, что позволило не только уточнить анализ по операторам типа IF-THEN-ELSE, но и успешно применить метрику Джилба к анализу циклических конструкций.

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

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

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

вершины у которых положительная степень <=1;

вершины у которых положительная степень >=2.

Вершины первой группы назовем принимающими вершинами, а вершины второй группы – вершинами отбора.

Для получения оценки по методу граничных значений необходимо разбить граф G на максимальное число подграфов G', удовлетворяющих следующим условиям:

вход в подграф осуществляется только через вершину отбора;

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

Число вершин, образующих такой подграф, равно скорректированной сложности вершины отбора.

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

S0=1– (v–1)/Sa,

где S0 – относительная граничная сложность программы; Sa – абсолютная граничная сложность программы, v – общее число вершин графа программы.

Таким образом, относительная сложность программы равна

S0=1– (11/25)=0,56.

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

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

Пара "модуль-глобальная переменная" обозначается как (p,r), где p - модуль, имеющий доступ к глобальной переменной r. В зависимости от наличия в программе реального обращения к переменной r формируются два типа пар "модуль-глобальная переменная": фактические и возможные. Возможное обращение к r с помощью p показывает, что область существования r включает в себя p.

Характеристика Aup говорит о том, сколько раз модули Up действительно получали доступ к глобальным переменным, а число Pup - сколько раз они могли бы получить доступ.

Отношение числа фактических обращений к возможным определяется

Rup = Aup/Pup.

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

Покажем расчет метрики “модуль – глобальная переменная”. Пусть в программе имеются три глобальные переменные и три подпрограммы. Если предположить, что каждая подпрограмма имеет доступ к каждой из переменных, то мы получим девять возможных пар, то есть Pup=9. Далее пусть первая подпрограмма обращается к одной переменной, вторая – двум, а третья не обращается ни к одной переменной. Тогда Aup=3, Rup=3/9.

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

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

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

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

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

М – модифицируемые или создаваемые внутри программы переменные.

C – переменные, участвующие в управлении работой программного модуля (управляющие переменные).

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

Далее вводится значение метрики Чепина:

Q = a1*P + a2*M + a3*C + a4*T,

где a1, a2, a3, a4 - весовые коэффициенты.

Весовые коэффициенты использованы для отражения различного влияния на сложность программы каждой функциональной группы. По мнению автора метрики, наибольший вес, равный трем, имеет функциональная группа C, так как она влияет на поток управления программы. Весовые коэффициенты остальных групп распределяются следующим образом: a1=1, a2=2, a4=0.5. Весовой коэффициент группы T не равен 0, поскольку "паразитные" переменные не увеличивают сложность потока данных программы, но иногда затрудняют ее понимание. С учетом весовых коэффициентов выражение принимает вид:

Q = P + 2M + 3C + 0.5T

 

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

Наиболее простой метрикой стилистики и понятности является оценка уровня комментированности программы F:

F = Nком/Nстр,

где Nком – количество комментариев в программе;

Nстр – количество строк или операторов исходного текста.

Таким образом, метрика F отражает насыщенность программы комментариями.

Исходя из практического опыта принято считать, что F0.1, т.е. на каждые десять строк программы должен приходиться минимум один комментарий. Как показывают исследования, комментарии распределяются по тексту программы неравномерно: в начале программы их избыток, а в середине или в конце – недостаток. Это объясняется тем, что в начале программы, как правило, расположены операторы описания идентификаторов, требующие более “плотного” комментирования. Кроме того, в начале программы также расположены “шапки”, содержащие общие сведения об исполнителе, характере, функциональном назначении программы и т.п. Такая насыщенность компенсирует недостаток комментариев в теле программы, и поэтому приведенная формула недостаточно точно отражает комментированность функциональной части текста программы.

Более удачен вариант, когда вся программа разбивается на n равных сегментов и для каждого из них определяется Fi:

Fi=sign(Nком/Nстр–0.1), при этом ∑_(i=1)^n▒F_i

Уровень комментированности программы считается нормальным, если выполняется условие: F=n. В противном случае какой либо фрагмент программы дополняется комментариями до нормального уровня.

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

59. Программные средства как объект авторского права. Интеллектуальная собственность и авторское право. Основные понятия. Сфера действия авторского права. Объект авторского права.

В РБ регулируется Законом РБ от 17 мая 2011 г. № 262-З «Об авторском праве и смежных правах»

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