Добавлен: 25.10.2018
Просмотров: 4564
Скачиваний: 12
21
лов». C целью планирования процедуры тестирования необходимо составить проект плана тестиро-
вания, примерная форма которого может быть представлена в виде таблицы (см. табл. 7).
Таблица 7
Тестовые данные для проверки D-требования №nnn
№
п/п
Входные тестовые данные
Ожидаемый результат
1
Иванов Иван Иванович
Иванов Иван Иванович
2 length()<10
Сообщение с вопросом о коррект-
ности вводимых данных
3 length()>256
4 …
…
Создание тестовых планов в процессе проектирования системы лежит в основе отдельно-
го направления разработки информационных систем, получившего название Test-Drive-
Development (TDD) – разработка, основанная на тестировании. Указанному направлению
посвящено множество работ, наиболее известными из которых являются [36, 52].
Результаты анализа требований к проектируемой системе помещаются в спецификацию,
оформленную согласно стандарту IEEE 830-1993. Поскольку D-требования предназначены, прежде
всего, для разработчиков, то диаграммы, которые составляются для документирования D-требований,
должны быть максимально детализированы с использованием возможностей той или иной нотации.
Пример составления спецификации см. в [55]. Оглавление спецификации требований к про-
граммному обеспечению приведено в приложении К и включает в качестве примера типовое описа-
ние некоторых разделов, которое необходимо адаптировать в соответствии с содержанием выпол-
няемого проекта. Примечание к тому или иному разделу приведено в квадратных скобках курсивным
шрифтом.
4.7.2.3. Управление требованиями
Без возможности четкого контроля каждого требования от проекта до программного кода,
реализующего это требование, было бы сложно убедиться в том, что программа разработана в соот-
ветствии с установленными требованиями. Когда требования меняются (чего следует ожидать), это
становится еще сложнее.
Возможность отображать каждое требование на соответствующие части проекта и
программы называется прослеживанием.
Один из способов, помогающих обеспечить прослеживание, заключается в отображении каж-
дого функционального D-требования на конкретную функцию целевого языка. На рис. 2 демонстри-
руется обеспечение принципа прослеживания для некоторого требования №NNN «Поиск учебно-
методических материалов (УММ)»: (i) С-требования, сформулированные заказчиком при проведении
анкетирования (или интервью), отображаются на диаграмме вариантов использования; (ii) на этапе
проработки D-требований, каждое С-требование представляется комплектом из трех диаграмм: дея-
тельности, классов и последовательностей; (iii) при проектировании архитектуры системы для удов-
летворения требования №NNN в некотором классе слоя предметной области предусматривается со-
ответствующий метод(ы) (например, «findByAuthor» и «findByTitle)»; (iv) на стадии детального про-
ектирования прорабатывается алгоритм метода, отвечающего за выполнение требования №NNN, а
также создается ER-диаграмма БД и конструируется SQL-запрос(ы), выполнение которого обеспечит
удовлетворение данного требования; (v) на стадии реализации для выполнения требования №NNN
разрабатываются листинги соответствующих методов и, наконец, на стадии тестирования выполне-
ние требования №NNN проверяется с использованием составленного плана тестирования.
При формировании требований к АСОИУ необходимо обеспечить достижение ряда показате-
лей, среди которых наиболее значимыми являются: прослеживание, полнота и согласованность. На-
бор D-требований согласован, если между требованиями нет противоречий. По мере увеличения чис-
ла D-требований согласованность может стать труднодостижимой, но объектно-ориентированная ор-
ганизация требований помогает избежать несогласованности благодаря классификации D-требований
по классам и с помощью разложения их на простейшие составляющие.
22
Формирование требований
2. …
3. …
4. …
С-требования
1. Поиск учебно-
методических материалов
Проектирование
архитектуры
Диаграмма компонентов
Тестирование
План тестирования
Реализация
function findByAuthor(str as
string, id as integer,…)
…
function findByTitle(str as
string, id as integer,…)
Диаграмма вариантов
использования
Поиск УММ
Диаграмма деятельности
Диаграмма последовательностей
D-требования
Диаграмма классов
Детальное
проектирование
Начало
Инициали-
зация
А.1
Нет
Да
t
j
< T
end
Определение
k
a
(t
j
), k
b
(t
j
), k
c
(t
j
)
А.2
А.3
Конец
SQL-запрос:
select * from Book where title = %матем%
Блок-схема
метода
«поиск
УММ»
Методы поиска
УММ класса
домена
Рис. 2. Пояснение принципа прослеживания требований
При выполнении КП необходимо особое внимание уделить вопросам прослежи-
вания требований. С этой целью в тексте и на диаграммах ПЗ делают отметки,
позволяющие локализовать положение каждого С-требования в проектируемой
системе.
С целью проверки указанных характеристик составляют таблицу, форма которой приведена
на рис. 3.
Во втором столбце таблицы приводится идентификатор D-требования. В столбце 3 приводит-
ся идентификатор С-требования, в состав которого входит данное D-требование. В столбце 4 приво-
дятся идентификаторы D-требований, выполнение которых необходимо и достаточно для реализации
данного D-требования. В столбце 5 делают отметку, если данное D-требование не противоречит ни-
какому другому D-требованию из перечисленных в таблице. В столбце 6 делают отметку, если дан-
ное D-требование может быть реализовано с учетом ограничений, накладываемых другими С- или D-
требованиями, средой разработки, аппаратной платформой и т.д.
23
№
п/п
Треб
ование
Пр
ослеживан
ие
назад
Полн
ота
С
оглас
ован
но
сть
Выпо
лнимо
сть
Одно
значно
сть
Ясно
сть
Точн
ость
М
одифицир
уе
мо
сть
Тестируемост
ь
Пр
ослеживан
ие
впе
-
ред
1
2 3 4 5 6 7 8 9 10 11
12
Рис. 3. Шаблон таблицы для проверки D-требований
В столбце 7 делают отметку, если данное D-требование не может быть истолковано двояко. В
столбце 8 делают отметку, если данное D-требование сформулировано предельно просто. В случае
отсутствия отметки необходимо привести дополнительные разъяснения по содержанию такого тре-
бования. В столбце 9 делают отметку, если в данном требовании указаны допустимые отклонения от
необходимого результата. В столбце 10 делают отметку, если формулировка данного D-требования
не претерпит существенных изменений при возникновении в будущем необходимости наращивания
функциональных возможностей системы. В столбце 11 делают отметку, если для данного требования
составлен план тестирования. В столбце 12 делают отметку по окончании реализации данного D-
требования в виде программного кода.
В заключение раздела, посвященного вопросам управления требованиями, необходимо еще
раз подчеркнуть сущность принципа документирования артефактов
1
, принятого в настоящих МУ.
Большинство артефактов, которые создаются на протяжении выполнения проекта, проходят две ста-
дии детализации: при первом упоминании на
страницах ПЗ приводится черновой эскиз (или
сжатое предварительное описание), а затем
прорабатывается итоговый вариант (рис. 4).
Этот принцип, прежде всего, относится к диа-
граммам, которые создаются при формирова-
нии требований во 2-ой главе ПЗ: черновые эс-
кизы диаграмм и их описания приводятся на
страницах ПЗ, итоговые (полные) версии поме-
щаются в приложение (SRS). Необходимо отме-
тить, что именно приложения к ПЗ представля-
ют собой тот комплект конструкторско-
технологической документации, который и со-
ответствует понятию «проект», поскольку в
приложения помещают, представляя в лаконич-
ной, законченной форме результаты, получен-
ные на страницах ПЗ.
Как будет показано в следующем разде-
ле, эскиз графического пользовательского ин-
терфейса также прорабатывается в два этапа.
4.7.2.4. Проектирование пользовательского интерфейса
Проектирование графического пользовательского интерфейса (ГПИ) в настоящий момент
представляет собой междисциплинарное направление, включающее в свой состав аспекты дизайна,
анализа требований, системного проектирования, программирования, эргономики, социальной пси-
хологии и многие другие вопросы. Переход от традиционного ГПИ к объектно-ориентированному
пользовательскому интерфейсу, развитие концепций социализированных пользовательских интер-
фейсов, адаптивных интерфейсов с мультиагентной поддержкой, интерфейсов, построенных с ис-
пользованием элементов искусственного интеллекта, требует особых усилий при проектировании
1
Под артефактами (в терминологии USDP) подразумеваются определения, требования, диаграммы, листинги
кодов, планы и т.д., т.е. все то, что является продуктом той или иной стадии создания ИС. Как правило, эволю-
цию артефактов необходимо отслеживать с помощью системы управления конфигурациями.
расширение описания, уточнение,
детализация, выводы; результаты
анализа, расчетов и т.д.
программно-технологические
решения
(§введение)
программно-технологические
решения
(§сбор и анализ данных о
зарубежных и отечественных аналогах)
План управления конфигурациями
План контроля качества ПО
План управления программным проектом
ПРИЛОЖЕНИЯ ПЗ
UML-диаграммы, графический
пользовательский интерфейс
ПРИЛОЖЕНИЕ ПЗ (SRS)
Разработка концепции АСОИУ
Эскизный проект
ПРИЛОЖЕНИЕ ПЗ (SDD)
…
Рис. 4. Пояснение принципа документирования арте-
фактов ПЗ
24
пользовательского интерфейса, отвечающего современному уровню развития человеко-машинного
взаимодействия.
Ввиду ограниченного объема времени, выделенного на курсовое проектирование, проработку
ГПИ следует выполнять в два этапа: (i) подготовка чернового эскиза пользовательского интерфейса,
представляющего собой перечень интерфейсных элементов, необходимых для обеспечения требуе-
мой функциональности; (ii) подготовка итогового эскиза путем переработки чернового варианта ГПИ
в соответствии с описанной на страницах ПЗ концепцией.
Концепция ГПИ, представленная на страницах ПЗ, должна основываться на классических и
современных подходах к разработке и дизайну ГПИ [35, 39, 45, 85] и устанавливать требования к:
• цветовым схемам, геометрическим формам, визуальным закономерностям, пропорциям, кон-
трасту расположения элементов, принятых во всем интерфейсе в целом;
• подсказкам, пояснениям, сообщениям об ошибках, справочной информации в соответствии с
особенностями пользователей системы, составляющих наиболее многочисленную группу;
• отдельным элементам, используемым при построении ГПИ (кнопки, чекбоксы и радиокнопки,
списки, поля ввода, счетчики и ползунки, меню и т.д.), в соответствии с их каноническим на-
значением и порядком применения;
• защите системы от ошибок пользователей через проработку блокировок потенциально опас-
ных действий, проверку всех действий пользователя перед их принятием, обеспечение воз-
можности отмены пользователем своих предыдущих действий, без ограничения количества
уровней отмены и типа отменяемых действий и проч.
Известны несколько фундаментальных принципов, относящихся ко многим элементам ин-
терфейса:
1. Правило, сформулированное в 1954 году Полем Фитсом: «Время достижения цели прямо про-
порционально дистанции до цели и обратно пропорционально размеру цели». Откуда, в частно-
сти, следует, что, например, повысить скорость работы можно посредством увеличения площади
активного элемента, что бы пользователь меньше времени тратил на позиционирование курсора
мыши.
2. Принцип «релевантное – вперед»: чаще всего используемые элементы должны быть расположе-
ны в левой верхней части экрана, реже используемые – в правой нижней части.
3. При группировке элементов меню или, например, списков необходимо помнить ограничение,
накладываемое кратковременной памятью человека: запоминаются 7±2 пункта.
4. При размещении графических элементов пользовательского интерфейса на формах (или страни-
цах) настоятельно рекомендуется использовать модульную сетку.
5. Все размеры и координаты (как минимум пропорции диалоговых окон) необходимо привязывать
к золотому сечению (0.618 х 0.382).
В главе 2 на страницах ПЗ формулируется концепция ГПИ в объеме, достаточ-
ном для проработки чернового эскиза интерфейса. И черновой и итоговый эски-
зы ГПИ помещаются в разделы SRS 2.1.2 и 3.1.1 соответственно.
Необходимо обратить внимание на то, чтобы каждый шаг преобразования чернового эскиза в
итоговый был обоснован и снабжался ссылкой на соответствующий пункт концепции.
4.8. РАЗРАБОТКА КОНЦЕПЦИИ АСОИУ (ИМС)
Раздел, посвященный разработке концепции АСОИУ, играет ключевую роль в курсовом про-
екте, поскольку посвящен созданию архитектуры системы.
Описанию различных архитектур программного обеспечения посвящен широкий спектр ли-
тературы [10, 14, 15, 34] и в настоящее время принципы построения эффективных архитектурных
решений ИС составляют отдельное бурно развивающееся направление информационных технологий.
В настоящих методических указаниях используется классификация, предложенная Шоу и
Гарланом [55], согласно которой ИС можно разделить на следующие классы:
1. Потоки данных – архитектура, в которой независимо спроектированные и функционирующие
модули обрабатывают потоки данных, перемещающиеся от одного модуля к другом. Представле-
ние архитектуры информационной системы в виде диаграмм потоков данных является универ-
сальным методом описания подавляющего большинства приложений, однако при отображении
диаграмм на программный код может возникнуть неопределенность.
2. Архитектура независимых компонентов состоит из компонентов, функционирующих параллель-
но во времени.
25
2.1. Наиболее ярким примером такого типа архитектуры является клиент-серверная. Существуют
многочисленные модификации клиент-серверной архитектуры, в частности, широкое рас-
пространение получили трехуровневые системы, в которых помимо традиционных клиента и
сервера выделен промежуточный уровень, отвечающий за преобразование данных и их пере-
направление (например, CORBA, COM).
2.2. Архитектура параллельно взаимодействующих процессов характеризуется тем, что в ней од-
новременно запускается несколько процессов (в различных потоках).
2.3. Приложение, построенное по архитектуре событийно-управляемых систем, представляет со-
бой набор компонентов, каждый из которых находится в состоянии ожидания, пока не про-
изойдет воздействующее на него событие.
3. Архитектура виртуальных машин рассматривает приложение как программу, написанную на спе-
циальном языке. При этом, поскольку должен быть реализован интерпретатор этого языка, ис-
пользование такой архитектуры окупится, если будут реализованы несколько программ.
4. Большинство систем, построенных в соответствии с репозиторной архитектурой предназначены
для обработки транзакций по отношению к БД. Примеры архитектур подобного класса можно
найти в области итеративных сред разработки, которые позволяют редактировать и компилиро-
вать в БД коды и объектные файлы.
Для конкретного проекта ИС может быть найдено несколько подходящих архитектур, из ко-
торых необходимо выбрать лучшую.
Для выбора архитектуры ИС необходимо на страницах ПЗ провести анализ су-
ществующих типов архитектур [10, 14, 15, 34], ввести систему критериев и осу-
ществить выбор архитектуры, воспользовавшись методикой, описанной в п.
4.7.1.3.
Проектирование архитектуры тесно связано с понятием модуля (подсистемы), представляю-
щего собой фрагмент программного кода, и состоящего из интерфейсной части и части реализации.
Модульность – свойство системы, при которой система может подвергаться декомпозиции на
ряд внутренне связанных и слабо зависящих друг от друга частей.
Целями декомпозиции на подсистемы являются:
• повышение уровня абстракции системы;
• декомпозиция системы на части, которые могут независимо конфигурироваться или поставлять-
ся, разрабатываться (при условии стабильности интерфейсов), размещаться в распределенной
среде, изменяться без воздействия на остальные части системы;
• разделение системы на части из соображений ограничения доступа к основным ресурсам;
• представление существующих продуктов или внешних систем (компонентов), которые не подле-
жат изменениям.
Ключевая задача проектирования архитектуры системы состоит в соблюдении двух принци-
пов [62, 80, 89, 98]:
• принцип «слабой вешней связанности» (Low Coupling) – количество связей между отдельными
подсистемами должно быть минимальным;
• принцип «сильного внутреннего сцепления» (High Cohesion) – связность отдельных частей внут-
ри каждой подсистемы должна быть максимальной.
Вопросам проектирования и реализации корпоративных информационных систем в настоящее
время посвящено значительное количество работ [16, 48, 49] и, более того, активно внедряются и ис-
пользуются различного рода платформы (ERP-системы, инструментальные среды разработки (IDE),
системы управления содержимым (CMS) и т.д.), которые позволяют в рамках единой программно-
алгоритмической среды реализовать специфические для заданной предметной области требования. В
этой связи, в большинстве случаев, задача состоит не в создании информационной системы в целом
или ее части с «чистого листа», а в отыскании и адаптации готовых решений, эффективность которых
неоднократно проверена на практике. Такие программно-алгоритмические решения, получив назва-
ние шаблонов (паттернов) проектирования, широко применяются на практике при проектировании
архитектуры ИС [62, 80, 98].
На первом этапе проектирование архитектуры выполняется на уровне классов системы и пре-
имущественно состоит в распределении обязанностей между классами с использованием паттернов
GRASP (General Responsibility Assignment Software Patterns). Из числа GRASP-паттернов наибольшее
распространение получили [80]:
• информационный эксперт (Information Expert) – правило, позволяющее выбрать класс (из
нескольких кандидатур) для назначения тех или иных функциональных обязанностей;