Задания. Методические рекомендации по выполнению практических
 Скачать 2.15 Mb.
|
|
Задание 2. Анализ Delphi проекта, добавление визуальных объектов, реинжениринг в Rose 1) Запустите на выполнение программу Delphi и загрузите сгенерированный проект (Proect1.dpr). Проверьте, что проект содержит все модули и присмотрите их содержимое через редактор Delphi. 2) Создайте в проекте Delphi новую форму с Name Form1. Поместите на форму компонент MainMenu (главное меню) 3) С помощью Menu Disigner введите две позиции горизонтального меню с названиями (полями Caption) Oder и OderItem. 4) Для Oder введите две строки вертикального меню с Caption Create и SubmitInfo. Для OderItem введите одну строку вертикального меню с названием GetInfo. 5) Сохраните проект в Delphi. Реинжениринг Delphi проекта в модель Rose 1) Вернитесь в проект Rose и откройте окно проектов Rose Delphi Link. Проверьте, что открыт именно тот проект, для которого выполнялась кодогенерация. 2) Курсором мыши нажмите клавишу Update ALL со стрелкой влево (обновление модели Rose на основе изменений проекта Delphi). В результате в моделе Rose должны произойти определенные изменения (рис. 16): Рис. 16. Окно Rose Delphi Link после кодогенерации - в представление Logic View создался новый пакет Unit1 и External References (Внешние ссылки). Внутри второго пакета созданы три класса TForm, TMainMenu и TMenuItem, которые использовались при развитии проекта Delphi. Отметим, что эта папка не создалась бы, если бы мы при первоначальном создании проекта включили в него пакет классов Delphi FreimWork. - в этом же представлении в пакете Unit1 создан класс TForm1 и Unit1 оба соотнесенные с вновь созданным компонентом Unit1. Кроме того, в этом же пакете создалась диаграмма классов Overview, содержимое которой показано на рис.17 Рис. 17. Результаты реинжениринга проекта Delphi в Rose Задание 3. Построение диаграммы размещения В этом задании создается диаграмма Размещения для системы обработки заказов. OrderclientExe ATMClientExe Рис. 18 Диаграмма размещения для модельной задачи Этапы выполнения OrderServer Exe Клиентская рабочая станция "Сервер базы данных" Клиентская рабочая станция №2 Серв ер прило ж... Прин тер Добавление узлов к диаграмме Размещения 1. Дважды щелкнув мышью на представлении Размещения в браузере, откройте диаграмму Размещения. 2. Нажмите кнопку Processor (Процессор) панели инструментов. 3. Щелкнув мышью на диаграмме, поместите туда процессор. 4. Введите имя процессора "Сервер базы данных". 5. Повторив шаги 2—4, добавьте следующие процессоры: -Сервер приложения - Клиентская рабочая станция №1 - Клиентская рабочая станция №2 6. На панели инструментов нажмите кнопку Devices (Устройство). 7. Щелкнув мышью на диаграмме, поместите туда устройство. 8. Назовите его "Принтер". Добавление связей 1. Нажмите кнопку Connection (Связь) панели инструментов. 2. Щелкните мышью на процессоре "Сервер базы данных". 3. Проведите линию связи к процессору "Сервер приложения". 4. Повторив шаги 1 — 3, добавьте следующие связи; - От процессора "Сервер приложения" к процессору "Клиентская рабочая станция №1" - От процессора "Сервер приложения" к процессору "Клиентская рабочая станция №2" - От процессора "Сервер приложения" к устройству "Принтер" Добавление процессов 1. Щелкните правой кнопкой мыши на процессоре "Сервер приложения" в браузере. 2. В открывшемся меню выберите пункт New > Process (Создать > Процесс), 3. Введите имя процесса — OrderServerExe. 4. Повторив шаги 1 —- 3, добавьте процессы: - Процесс OrderclientExe на процессоре "Клиентская рабочая станция №1" - Процесс ATMClientExe на процессоре "Клиентская рабочая станция №2" Показ процессов на диаграмме 1. Щелкните правой кнопкой мыши на процессоре "Сервер приложения". 2. В открывшемся меню выберите пункт Show Process (Показать процессы). 3. Повторив шаги 1 и 2, покажите процессы на следующих процессорах: - Клиентская рабочая станция №1 - Клиентская рабочая станция №2 Лабораторная работа №6 «Разработка тестового сценария» Цели: усвоить знание о видах тестирования; освоить способы обнаружения и фиксирования ошибок. Теоретические сведения Общепринятая практика состоит в том, что после завершения продукта и до передачи его заказчику независимой группой тестировщиков проводится тестирование ПО. Уровни тестирования: Модульное тестирование. Тестируется минимально возможный для тестирования компонент, например отдельный класс или функция; Интеграционное тестирование. Проверяется, есть ли какие-либо проблемы в интерфейсах и взаимодействии между интегрируемыми компонентами, например, не передается информация, передается некорректная информация; Системное тестирование. Тестируется интегрированная система на ее соответствие исходным требованиям. Таблица 1. Виды некоторых ошибок и способы их обнаружения Виды программных ошибок Способы их обнаружения Ошибки выполнения, выявляемые Динамический контроль: автоматически: аппаратурой процессора; а) переполнение, защита памяти; run-time системы программирования; б) несоответствие типов; операционной системой – по превышению лимита в) зацикливание времени Тест – это набор контрольных входных данных совместно с ожидаемыми результатами. Тесты должны обладать определенными свойствами. Детективность: тест должен с большой вероятностью обнаруживать возможные ошибки. Покрывающая способность: один тест должен выявлять как можно больше ошибок. Воспроизводимость: ошибка должна выявляться независимо от изменяющихся условий. С помощью тестирования разных видов обнаруживаются ошибки в разрабатываемом программном обеспечении. После обнаружения ошибок проводится их устранение. Задание Создать приложение Простой калькулятор, в котором реализовать выполнение простых операций с вводимыми двумя операндами. Выполнить тестирование приложения на различных данных, отличающихся по типу и значению. Программа работы 1. Разработать интерфейс приложения и написать программные коды для событий кнопок. 2. Сохранить проект в отдельной папке, скопировать исполняемый файл на рабочий стол. 3. Составить тесты для проверки работы приложения. 4. Провести тестирование исполняемого файла Составить отчет по итогам тестирования и рекомендации по устранению выявленных ошибок Лабораторная работа №7«Оценка необходимого количества тестов» Цель: получить навыки разработки тестовых сценариев. Теоретические вопросы − Оценка стоимости и причины ошибок в программном обеспечении. − Виды и методы тестирования. − Понятие теста. − Требования к разработке тестовых сценариев. − Правила разработки тестовых сценариев. Задание № 1 Написать программу решения квадратного уравнения ах2 + bх + с = 0. Задание № 2 Найти минимальный набор тестов для программы нахождения веще-ственных корней квадратного уравнения ах2 + bх + с = 0. Решение представлено в таблице. Таким образом, для этой программы предлагается минимальный набор функциональных тестов, исходя из 7 классов выходных данных. Заповеди по отладки программного средства, предложенные Г. Майерсом. Заповедь 1. Считайте тестирование ключевой задачей разработки ПС, поручайте его самым квалифицированным и одаренным программистам, нежелательно тестировать свою собственную программу. Заповедь 2. Хорош тот тест, для которого высока вероятность обнаружить ошибку, а не тот, который демонстрирует правильную работу программы. Заповедь 3. Готовьте тесты как для правильных, так и для неправильных данных. Заповедь 4. Документируйте пропуск тестов через компьютер, детально изучайте результаты каждого теста, избегайте тестов, пропуск которых нельзя повторить. Заповедь 5. Каждый модуль подключайте к программе только один раз, никогда не изменяйте программу, чтобы облегчить ее тестирование. Заповедь 6. Пропускайте заново все тесты, связанные с проверкой работы какой-либо программы ПС или ее взаимодействия с другими программами, если в нее были внесены изменения (например, в результате устранения ошибки). Задание № 3 Разработайте набор тестовых сценариев (как позитивных, так и негативных) для следующей программы: Имеется консольное приложение (разработайте самостоятельно). Ему на вход подается 2 строки. На выходе приложение выдает число вхождений второй строки в первую. Например: Набор тестовых сценариев запишите в виде таблицы, приведенной выше. Задание № 4 Оформить отчет. Лабораторные работы №8 «Разработка тестовых пакетов» Цель: получить навыки разработки тестовых пакетов. Теоретические вопросы − Системные основы разработки требований к сложным комплексам программ. − Формализация эталонов требований и характеристик комплекса программ. − Формирование требований компонентов и модулей путем декомпозиции функций комплексов программ. − Тестирование по принципу «белого ящика». Задание № 1 В Древней Греции (II в. до н.э.) был известен шифр, называемый "квадрат Полибия". Шифровальная таблица представляла собой квадрат с пятью столбцами и пятью строками, которые нумеровались цифрами от 1 до 5. В каждую клетку такого квадрата записывалась одна буква. В результате каждой букве соответствовала пара чисел, и шифрование сводилось к замене буквы парой чисел. Для латинского алфавита квадрат Полибия имеет вид: Пользуясь изложенным способом создать программу, которая: а) зашифрует введенный текст и сохранит его в файл; б) считает зашифрованный текст из файла и расшифрует данный текст. Задание № 2 Спроектировать тесты по принципу «белого ящика» для программы, разработанной в задании № 1. Выбрать несколько алгоритмов для тестирования и обозначить буквами или цифрами ветви этих алгоритмов. Выписать пути алгоритма, которые должны быть проверены тестами для выбранного метода тестирования. Записать тесты, которые позволят пройти по путям алгоритма. Протестировать разработанную вами программу. Результаты оформить в виде таблиц: Тест Ожидаемый результат Фактический результат Результат тестирования … … … … Задание № 3 Проверить все виды тестов и сделать выводы об их эффективности Задание № 4 Оформить отчет. Лабораторные работы №9 «Оценка программных средств с помощью метрик» Цель: знакомство с ГОСТ 28.195-89 «Оценка качества программных средств. Общие положения»; определить способы получения информации о ПС; формирование информационно - правовых компетенции обучающихся. Теоретические сведения Необходимая документация: ГОСТ 28.195-89 Одной из важнейших проблем обеспечения качества программных средств является формализация характеристик качества и методология их оценки. Для определения адекватности качества функционирования, наличия технических возможностей программных средств к взаимодействию, совершенствованию и развитию необходимо использовать стандарты в области оценки характеристик их качества. Показатели качества программного обеспечения устанавливают ГОСТ 28.195-89 «Оценка качества программных средств. Общие положения» и ГОСТ Р ИСО/МЭК 9126 «Информационная технология. Оценка программной продукции. Характеристика качества и руководства по их применению». Одновременное существование двух действующих стандартов, нормирующих одни и те же показатели, ставит вопрос об их гармонизации. Ниже рассмотрим каждый из перечисленных стандартов. ГОСТ 28.195-89 «Оценка качества программных средств. Общие положения» устанавливает общие положения по оценке качества программных средств, номенклатуру и применяемость показателей качества. Оценка качества ПС представляет собой совокупность операций, включающих выбор номенклатуры показателей качества оцениваемого ПС, определение значений этих показателей и сравнение их с базовыми значениями. Методы определения показателей качества ПС различаются: по способам получения информации о ПС – измерительный, регистрационный, органолептический, расчетный; по источникам получения информации – экспертный, социологический. Измерительный метод основан на получении информации о свойствах и характеристиках ПС с использованием инструментальных средств. Например, с использованием этого метода определяется объем ПС - число строк исходного текста программ и число строк - комментариев, число операторов и операндов, число исполненных операторов, число ветвей в программе, число точек входа (выхода), время выполнения ветви программы, время реакции и другие показатели. Регистрационный метод основан на получении информации во время испытаний или функционирования ПС, когда регистрируются и подсчитываются определенные события, например, время и число сбоев и отказов, время передачи управления другим модулям, время начала и окончания работы. Органолептический метод основан на использовании информации, получаемой в результате анализа восприятия органов чувств (зрения, слуха), и применяется для определения таких показателей как удобство применения, эффективность и т. п. Расчетный метод основан на использовании теоретических и эмпирических зависимостей (на ранних этапах разработки), статистических данных, накапливаемых при испытаниях, эксплуатации и сопровождении ПС. При помощи расчетного метода определяются длительность и точность вычислений, время реакции, необходимые ресурсы. Определение значений показателей качества ПС экспертным методом осуществляется группой экспертов-специалистов, компетентных в решении данной задачи, на базе их опыта и интуиции. Экспертный метод применяется в случаях, когда задача не может быть решена никаким другим из существующих способов или другие способы являются значительно более трудоемкими. Экспертный метод рекомендуется применять при определении показателей наглядности, полноты и доступности программной документации, легкости освоения, структурности. Социологические методы основаны на обработке специальных анкет-вопросников. Рис. 1 – Уровни системы показателей качества Показатели качества объединены в систему из четырех уровней. Каждый вышестоящий уровень содержит в качестве составляющих показатели нижестоящих уровней (рисунок 1). Стандарт ИСО 9126 (ГОСТ Р ИСО/МЭК 9126) «Информационная технология. Оценка программной продукции. Характеристика качества и руководства по их применению». Определенные настоящим стандартом характеристики дополнены рядом требований по выбору метрик и их измерению для различных проектов ПС. Они применимы к любому типу ПС, включая компьютерные программы и данные, содержащиеся в программируемом оборудовании. Эти характеристики обеспечивают согласованную терминологию для анализа качества ПС. Кроме того, они определяют схему для выбора и специфицирования требований к качеству ПС, а также для сопоставления возможностей различных программных продуктов, таких как функциональные возможности, надежность, практичность и эффективность. Все множество атрибутов качества ПС может быть классифицировано в структуру иерархического дерева характеристик и субхарактеристик. Самый высший уровень этой структуры состоит из характеристик качества, а самый нижний уровень – из их атрибутов. Эта иерархия не строгая, поскольку некоторые атрибуты могут быть связаны с более чем одной субхарактеристикой. Таким же образом, внешние свойства (такие, как пригодность, корректность, устойчивость к ошибкам или временная эффективность) влияют на наблюдаемое качество. Недостаток качества в использовании (например, пользователь не может закончить задачу) может быть прослежен к внешнему качеству (например, функциональная пригодность или простота использования) и связанным с ним внутренним атрибутам, которые необходимо изменить. Внутренние метрики могут применяться в ходе проектирования и программирования к неисполняемым компонентам ПС (таким, как спецификация или исходный программный текст). При разработке ПС промежуточные продукты следует оценивать с использованием внутренних метрик, которые измеряют свойства программ, и могут быть выведены из моделируемого поведения. Основная цель внутренних метрик – обеспечивать, чтобы было достигнуто требуемое внешнее качество. Внутренние метрики дают возможность пользователям, испытателям и разработчикам оценивать качество ЖЦ программ и заниматься вопросами технологического обеспечения качества задолго до того, как ПС становится готовым исполняемым продуктом. Внутренние метрики позволяют измерять внутренние атрибуты или формировать признаки внешних атрибутов путем анализа статических свойств промежуточных или поставляемых программных компонентов. Измерения внутренних метрик используют категории, числа или характеристики элементов из состава ПС, которые, например, имеются в процедурах исходного программного текста, в графе потока управления, в потоке данных и в представлениях изменения состояний памяти. Документация также может оцениваться с использованием внутренних метрик. Внешние метрики используют меры ПС, выведенные из поведения системы, частью которых они являются, путем испытаний, эксплуатации или наблюдения исполняемого ПС или системы. Перед приобретением или использованием ПС его следует оценить с использованием метрик, основанных на деловых и профессиональных целях, связанных с использованием, эксплуатацией и управлением продуктом в определенной организационной и технической среде. Внешние метрики обеспечивают заказчикам, пользователям, испытателям и разработчикам возможность определять качество ПС в ходе испытаний или эксплуатации. Когда требования к качеству ПС определены, в них должны быть перечислены характеристики и субхарактеристики, которые составляют полный набор показателей качества. Затем определяются подходящие внешние метрики и их приемлемые диапазоны значений, устанавливающие количественные и качественные критерии, которые подтверждают, что ПС удовлетворяет потребностям заказчика и пользователя. Далее определяются и специфицируются внутренние атрибуты качества, чтобы спланировать удовлетворение требуемых внешних характеристик качества в конечном продукте и обеспечивать их в промежуточных продуктах в ходе разработки. Подходящие внутренние метрики и приемлемые диапазоны специфицируются для получения числовых значений или категорий внутренних характеристик качества, чтобы их можно было использовать для проверки того, что промежуточные продукты в процессе разработки удовлетворяют внутренним спецификациям качества. Рекомендуется использовать внутренние метрики, которые имеют наиболее сильные связи с целевыми внешними метриками, чтобы они могли помогать при прогнозировании значений внешних метрик. Метрики качества в использовании измеряют, в какой степени продукт удовлетворяет потребности конкретных пользователей в достижении заданных целей с результативностью, продуктивностью и удовлетворением в заданном контексте использования. При этом результативность подразумевает точность и полноту достижения определенных целей пользователями при применении ПС; продуктивность соответствует соотношению израсходованных ресурсов и результативности при эксплуатации ПС, а удовлетворенность – психологическое отношение к качеству использования продукта. Эта метрика не входит в число шести базовых характеристик ПС, регламентируемых стандартом ИСО 9126, однако рекомендуется для интегральной оценки результатов функционирования комплексов программ. Оценивание качества в использовании должно подтверждать его для определенных сценариев и задач, оно составляет полный объединенный эффект характеристик качества ПС для пользователя. Качество в использовании – это восприятие пользователем качества системы, содержащей ПС, и оно измеряется скорее в терминах результатов использования комплекса программ, чем собственных внутренних свойств ПС. Связь качества в использовании с другими характеристиками качества ПС зависит от типа пользователя, так, например, для конечного пользователя качество в использовании обусловливают, в основном, характеристики функциональных возможностей, надежности, практичности и эффективности, а для персонала сопровождения ПС качество в использовании определяет сопровождаемость. На качество в использовании могут влиять любые характеристики качества, и это понятие шире, чем практичность, которая связана с простотой использования и привлекательностью. Качество в использовании, в той или иной степени, характеризуется сложностью применения комплекса программ, которую можно описать трудоемкостью использования с требуемой результативностью. Многие характеристики и субхарактеристики ПС обобщенно отражаются неявными технико- экономическими показателями, которые поддерживают функциональную пригодность конкретного ПС. Однако их измерение и оценка влияния на показатели качества, представляет сложную проблему. |