43.Контроль удобства программного обеспечения.

Наиболее широко для контроля удобства использования ПО применяются различные виды инспектирования.

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

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

Оценка проводится в два этапа. На первом исследуется архитектура интерфейса в целом, на втором — отдельные контексты взаимодействия и элементы интерфейса.

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

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

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

  • Задачи располагаются в порядке убывания частоты их возникновения на практике.

  • Оценивается количество действий пользователя, необходимое для выполнения каждой задачи.

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

  • Итоговая согласованность задач оценивается как процентное отношение индекса согласованности к общему количеству различных пар задач, т.е. к n(n–1)/2, где n — число различных задач.

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

44.Компоненты технологии и разработка распределенного по.

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

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

• На диаграммах компонентов в языке UML часто изображаются компоненты, являющиеся единицами сборки и конфигурационного управления, — файлы с кодом на каком-то языке, бинарные файлы, какие-либо документы, входящие в состав системы. Иногда там же появляются компоненты, представляющие собой единицы развертывания системы, — это компоненты уже в третьем, следующем смысле..

Общие принципы построения распределенных систем

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

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

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

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

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

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

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

Понятие безопасности включает следующие характеристики:

• Сохранность и целостность данных.

• Защищенность данных и коммуникаций.

• Отказоустойчивость и способность к восстановлению после ошибок.

• Связь.

• Именование.

• Процессы.

• Синхронизация.

• Целостность.

• Отказоустойчивость.

• Защита.