Файл: ТРПО-лекции.pdf

Скачано с сайта 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