ТРПО-лекции

Скачано с сайта http://ivc.clan.su

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

На стадии анализа по возможности точно определяются:

1.Функции системы и их распределение между аппаратурой и ПС.

2.Пользовательский интерфейс и распределение функций между человеком ПС.

3.Описание кандидатов в программные объекты системы (Глоссарий).

4.Описание кандидатов в информационные объекты системы (Глоссарий).

5.Требования к базе данных (если предполагается еѐ использование).

6.Необходимые аппаратные ресурсы.

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

С этапом анализа тесно связан основной вид деятельности – анализ предметной области. Прежде чем взяться за создание нового ПС, изучают уже существующие.

Результатом сравнительного анализа ПС может быть один из двух выводов:

1.Новый продукт не надо проектировать, а следует повторно использовать или адаптировать существующий.

2.Точно понять, чем новый продукт будет отличаться от существующих продуктов, и насколько он будет конкурентоспособен.

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

5.5.3. Проектирование

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

Проектирование объясняет, как ПС будет удовлетворять предъявленным к нему требованиям.

Цели проектирования:

1.Создание внутренней архитектуры для реализации ПС.

2.Выработка единых приѐмов, которыми должны пользоваться различные элементы ПС.

При создании программной архитектуры учитываются следующие факторы:

−функциональные возможности;

−эффективность и производительность;

−повторное использование;

−понятность;

−экономические и технологические ограничения;

−эстетическое восприятие.

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

При объектно-ориентированном подходе с использованием UML архитектура опи-92 описывается в логическом представлении (Logical View), представлении компонентов (Component View) и развѐртывания (Deployment View) путѐм построения следующих диаграмм:

−пакетов (чтобы показать, как классы группируются в категории);

−классов (чтобы показать статику системы);

−взаимодействия (чтобы показать динамические аспекты системы);

−компонентов (чтобы показать, как представлены логические абстракции системы в реальных программных компонентах);

−развѐртывания (чтобы отобразить, как взаимосвязаны программные и аппаратные части системы).

Выработка общих приѐмов – это документирование механизмов, которые проявляются во всей системе.

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

5.5.3.1. Концептуальное проектирование

Это определение конструктивных принципов ПС.

Концептуальное проектирование фактически является началом определения архитектуры ПС и определяет подход (или альтернативные подходы) к его построению.

Результатом концептуального проектирования является:

1.Уточнение архитектурного стиля (одно-, двухили трѐхзвенная архитектура).

2.Выделение относительно обособленных подсистем (групп функций системы) без детализации их функциональности.

3.Уточнение возможных подходов к созданию (объектно-ориентированный подход, структурный подход).

4.Принятие решений об использовании сетевых технологий и баз данных.

5.Определение критериев эффективности системы (использование ресурсов, временнЫе характеристики, быстродействие и т.п. – производительность).

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

Концептуальное проектирование полезно завершать созданием прототипа, который содержит пользовательский интерфейс и отражает функциональные возможности системы без их реализации.

5.5.3.2. Логическое проектирование

Это описание структуры, синтаксиса и взаимодействия частей ПС.

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

При создании логического проекта все участники сосредоточены на деталях систе-93

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

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

Логическая модель состоит из двух относительно независимых подмоделей – данных и объектов:

1.Логическая модель данных (logical data model) – представляет атрибуты объектов, которыми система управляет, и описывает правила их хранения.

2.Логическая модель объектов (logical object model) – представляет правила, кото-

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

Логическое проектирование заключается в принятии решений относительно организации ПС, структуры данных и внешнего дизайна.

Решения относительно организации системы:

−Каковы составляющие систему структурные элементы и их интерфейсы?

−Каково поведение этих элементов во взаимосвязи?

−Как выбранные элементы объединяются в подсистемы?

−Каков архитектурный стиль (например, Three-tiered Architecture)?

Решения относительно структуры данных

−Каков способ объединения, взаимосвязи и взаиморасположения элементов данных (простые переменные различного типа или огромные массивы, которые организованы в базе данных)?

−Каков доступ к элементам данных (общедоступные или же их чтение и изменение должно строго регулироваться; доступ просто по имени или через специально написанные функции)?

−Каков способ хранения (оперативная память или постоянный носитель)?

Решения относительно внешнего дизайна − Каков эстетический облик программного продукта?

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

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

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

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

Физическое проектирование является завершающей стадией проектирования. Физическое проектирование отвечает на следующие вопросы:

1.Какие программные средства будут использоваться, чтобы можно было создавать, отлаживать, интегрировать и расширять систему?

2.Каковы компоненты ПС (исполняемые файлы, динамические библиотеки, справочные системы, html-страницы)?

3.Как будут использоваться физические ресурсы аппаратуры, СУБД, операционной системы и услуг для размещения компонент?

4.Использование каких ресурсов является более эффективным (например, локальная машина или Internet)?

5.Как могут быть реализованы требования к внешним сбоям (например, к отключению сетевых серверов или ненадѐжное подключение к Internet)?

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

Выявленные на этом этапе системные компоненты дают возможность составить план работ для всего коллектива разработчиков с учѐтом приоритетов компонент (приоритетность выясняется вместе с экспертами предметной области).

5.5.4. Реализация (кодирование) и эволюция

Реализация и эволюция – это создание компонентов и итеративное совершенствование для получения целевого ПС.

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

Этот этап, как правило, включает следующее:

1.Создание исходного кода с постоянным тестированием (самим разработчиком) и обязательным документированием.

2.Уточнение технического задания разработчиком (возможны изменения).

3.Проведение экспериментов и уточнение архитектуры (но не изменение!).

4.Художественное конструирование пользовательского интерфейса дизайнером.

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения

5.Тестирование компонентов с целью проверки их работоспособности и соответ-95 ствия техническим заданиям.

6.Автоматизация процесса установки системы – создание инсталляционной программы при помощи специальных средств (например, InstallShield).

7.Документирование кода и создание всевозможных руководств (программиста, администратора) и инструкций (по установке системы, пользователя).

Процесс реализации неразрывно связан с эволюцией. В процессе эволюции создаѐтся серия исполняемых релизов (версий программной системы).

Эволюция предполагает возможность экспериментов для исследования альтернативных подходов. Для проекта, требующего 12-18 месяцев на разработку от начала до конца, создаѐтся 6-9 релизов, то есть один релиз каждые два месяца.

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

5.5.5. Сопровождение

Сопровождение – это деятельность по управлению эволюцией ПС в ходе его эксплуатации.

Этот этап предусматривает следующие виды деятельности:

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

2.Внесение требуемых изменений. В соответствии со списком изменений разрабатывается эволюционный релиз ПС.

3.Модернизация функций.

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

5.5.6. Тестирование

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

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

Существует три причины, по которым полное тестирование не может быть выполнено никогда:

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения

1.Слишком большое количество всех возможных комбинаций входных данных.96 Следует проверить:

−Все допустимые входные значения.

−Все недопустимые входные значения.

−Все способы редактирования входных данных.

−Реакцию программы на ввод в каждый момент еѐ работы. Например, по-

пробовать ввести данные, когда программа их совсем не ждѐт, пока она обрабатывает предыдущие данные, выводит результат или сообщение.

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

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

Физически невозможно проверить все пути выполнения программы. Для серь-

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

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

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

Всех ошибок всѐ равно не найти. Для чего же тестируют программы?

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

Если тест позволил выявить проблему, значит, он успешный. Главные ответы тестирования:

1.Показать пригодность системы для пользователя.

2.Показать полноту документации к системе.

3.Показать точность полученных результатов.

Тестирование проводится на всех этапах жизненного цикла. Чем раньше будут выявлены проблемы, тем выше вероятность создания качественного ПС в установлен-

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения 97

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

5.5.6.1. Тестирование на этапе определения требований

Проверяется:

−адекватность (действительно такой продукт нужно создавать);

−полнота (не упущены жизненно-необходимые функции, или наоборот можно ослабить какие-либо требования);

−совместимость (логическая несовместимость требований означает противоречивость, психологическая – концептуальные разногласия);

−выполнимость (может быть, необходимо более быстрое аппаратное обеспечение, больший объѐм памяти, более высокая пропускная способность, большее разрешение и т.п.);

−правильная расстановка приоритетов (абсолютная безупречность, требовательность к ресурсам, готовность конкурировать с другими ПС).

5.5.6.2. Тестирование на этапе анализа

Проверяется:

− соответствие модели анализа требованиям; − соответствие спецификаций требованиям (по функциям и по данным);

− простота, гибкость и функциональность пользовательского интерфейса.

5.5.6.3. Тестирование на этапе проектирования

Проверяется:

−добротность проекта (будет ли на его основе создан эффективный, компактный, лѐгкий в сопровождении программный продукт);

−полнота (описаны ли все взаимосвязи между подсистемами и данными);

−реалистичность (сможет ли продукт работать быстро, достаточны ли аппаратные и программные ресурсы, удачно ли выбраны инструментальные средства разработчиков);

−добротность подсистемы обработки ошибок (все возможные условия возникновения ошибок должны быть продуманы и описаны в проекте).

5.5.6.4. Тестирование на этапе реализации

Технология тестирования этапа кодирования называется тестированием стеклянно-

го ящика (glass box).

Различают структурное и функциональное тестирование:

1.Структурное тестирование (тестирование белого ящика – white box) предполагает знание исходного кода и полный доступ к нему. Как правило, тестирует программист, а само тестирование является неотъемлемой частью процесса программирования. При этом учитываются следующие аспекты:

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

− полный охват кода (когда и какие фрагменты кода работают в конкретный момент времени);

− управление потоком (какая функция и когда должна выполняться в программе, какова последовательность выполнения функций);

− отслеживание целостности данных (какая часть программы меняет данные и каким образом);

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

2. Функциональное тестирование (тестирование чѐрного ящика – black box) предполагает, что внутренняя структура программы неизвестна. Тестер ищет интересные с его точки зрения входные данные и условия, которые могут привести к нестандартным результатам. Программа исследуется извне, то есть с точки зрения пользователя. Именно этому типу тестирования посвящается бОльшая часть времени. Оно позволяет выявить проблемы и критические точки, которые были упущены программистом.

5.5.6.5. Тестирование на этапе тестирования

Этот этап жизненного цикла связан с проверкой качества всего проекта в соответствии со спецификацией качества. Для этого существует специальный тип тестирования, который принято называть регрессионным тестированием.

У термина регрессионное тестирование два значения, объединѐнных общей идеей повторного использования разработанных тестов:

1.Тест обнаружил ошибку, и программист еѐ исправил. Снова проводится тот же тест, чтобы убедиться, что ошибки больше нет.

2.После исправления ошибки проводится стандартная серия тестов для проверки целостности всей системы. Цель тестирования уже другая: убедиться, что, исправляя одну часть, программист не испортил другую.

В первом значении этого термина регрессионное тестирование используется на этапе реализации проекта.

5.5.6.6. Тестирование на этапе опытной эксплуатации

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

5.5.6.7. Тестирование на этапе окончательной приѐмки и сертификации

Если ПС разрабатывалось по договору (контракту), для приѐмки клиенты проводят собственные тесты. Для небольших проектов тестирование может быть неформальным. Для больших – следует убедиться, что ПС абсолютно безупречно прошло серию приѐмочных тестов, то есть провести формальное тестирование.

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения 99

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

Международные стандарты – ISO 12207, ISO 9001. Отечественные стандарты:

ГОСТ 19.201-78. Техническое задание. ГОСТ 19.202-78. Спецификация.

ГОСТ 19.301-79. Программа и методика испытаний. ГОСТ 19.503-79. Руководство системного программиста. ГОСТ 19.504-79. Руководство программиста.

ГОСТ 28195-89. Оценка качества программных средств. Общие положения.

РД 50-34.698-90 – Методические указания. Информационная технология. Автоматизированные системы. Требования к содержанию документов.

5.5.6.8. Тестирование на этапе сопровождения

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

Если этап сопровождения предполагает перенос ПС с одной аппаратной или программной платформы на другую, то проводится адаптационное тестирование.

Адаптационное тестирование включает в себя:

−регрессионные тесты;

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

−тестирование обработки ошибок операционной системой (как ПС защищает себя от ошибок и странностей операционной системы);

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

−проверку совместимости (если на исходном компьютере продукт совместим с программой Икс, то при переносе на новый компьютер он также должен быть совместим с ней);

−тестирование пользовательского интерфейса (в различных графических средах (Windows, Mac, Motif) действуют различные соглашения о пользовательском интерфейсе);

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения

−проверку номера версии и идентификация системы (номер версии везде из-100 менѐн; правильность идентификации аппаратуры и операционной системы);

−другие изменения (спросить у программиста, что он изменил в программе для адаптации, и тщательно протестировать все изменения).

6.ДОКУМЕНТАЦИЯ ПРОЦЕССА РАЗРАБОТКИ

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

При разработке ПС создаѐтся большой объѐм разнообразной документации. Она необходима:

−как средство управления разработкой;

−как средство передачи информации между разработчиками;

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

Примерный состав сопровождающей проект документации, рекомендованный стандартом ISO 12207, показан на рис. 6-1.

Рис. 6-1. Состав

документации

Документацию процесса разработки можно разбить на две группы:

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011