- •Общая характеристика технологии программных средств.
- •Принципиальная схема разработки программных средств. (Технология, процесс создания).
- •Способы описания алгоритмов.
- •Описание алгоритма с помощью таблиц решения.
- •Технология системного проектирования программных средств. Принципиальная схема разработки.
- •Современные методы и средства разработки прикладных программных средств.
- •Характеристики качества программного обеспечения.
- •Языки программирования.
- •Надёжность программного обеспечения.
- •Показатели надёжности.
- •Факторы, определяющие надёжность по.
- •Стандартизация. Дисциплина и творчество программирования.
- •Виды программ и программных документов.
- •Виды программных документов.
- •Эксплуатационные документы.
- •Классификация документов.
- •Работы, выполняемые на стадии «Эскизный проект».
- •Структурное программирование.
- •Терминология и обозначения.
- •Очевидно, что g и h являются простыми программами, иначе f была бы не простой.
- •Число управляющих линий в блоке h удовлетворяет соотношению:
- •Графическая иерархическая документация (гид).
- •Простейшие пути повышения качества программ.
- •Классификация ошибок.
- •Сквозной структурный контроль.
- •Стиль программирования и качества программ.
- •Case – технологии.
- •Моделирование данных.
- •Что дает применение case-средств?
- •Средства реализации case-технологий.
- •Общая характеристика case-средства
- •Особенности рабочего интерфейса
- •Начало работы с проектом в среде
- •Разработка диаграммы вариантов использования в среде Rational Rose.
- •Разработка диаграммы классов в среде
- •Диаграмма классов
- •Разработка диаграммы состояний в среде Rational Rose.
- •Разработка диаграммы последовательности в среде Rational Rose.
- •Разработка диаграммы кооперации в среде Rational Rose.
- •Разработка диаграммы компонентов в среде Rational Rose.
- •Разработка диаграммы развёртывания в среде Rational Rose.
- •Практические примеры диаграмм.
- •Актеры.
- •Диаграмма классов (основы)
- •Ассоциации
- •Заказ от одного клиента
- •Полезные советы по использованию диаграмм классов
- •Диаграмма взаимодействия
- •Диаграмма кооперации
- •Диаграмма кооперации
- •Диаграмма пакетов
- •Диаграмма состояний
- •Верификация программ.
- •Восходящее тестирование, нисходящее тестирование.
- •Методы тестирования компонентов.
- •Структура коллектива программистов.
- •Общая структура коллектива, работающего над крупным проектом.
- •Трудовые затраты по видам работ (человеко/месяц).
Практические примеры диаграмм.
Диаграмма вариантов использования.
Для понимания правил построения диаграмм рассмотрим понятие «сценарий».
Сценарий представляет собой последовательность шагов, описание взаимодействия между пользователем и системой. Рассмотрим реализацию на Web-технологии Internet-магазин. Сценарий покупки товаров в этом магазине следующий:
Покупатель просматривает каталоги и помещает выбранные товары в корзину. При желании оплатить покупку он вводит информацию кредитной карточке и совершает платеж. Система проверяет авторизацию кредитной карточки и подтверждает оплату товара.
Данный сценарий рассматривает только одну ситуацию, поэтому вариант использования представляет собой множество сценариев объединенных вместе общей целью пользователя.
Для данного случая можно построить вариант использования «Покупка товара», который охватывает несколько сценариев.
Текст примера вариантов использования «Покупка товара».
Покупатель просматривает каталог и выбирает товар для покупки.
Оценка стоимости всех товаров.
Покупатель вводит информацию, необходимую для доставки товара (адрес, время).
Система представляет информацию об общей цене товара и времени доставки.
Покупатель вводит информацию о кредитной карточке.
Система осуществляет авторизацию счета покупателя.
Система выполняет необходимую оплату товара.
Система подтверждает оплату товара по электронной почте.
Альтернатива:
1. Неудача авторизации. На шаге 6 система получила отрицательный ответ на запрос о состоянии счета покупателя. Необходимо предоставить покупателю возможность повторно ввести информацию о состоянии кредитной карточки.
2. Постоянный покупатель (скидки).
Существует множество способов записи содержания вариантов использования. Язык UML в этом случае не определяет ни какого стандарта.
При этом можно добавить в вариант использования дополнительные секции. Например, можно ввести дополнительную секцию для предоставления условий, выполнение которых является обязательным для того, чтобы началась реализация отдельного варианта использования.
Диаграмма вариантов использования является частью языка UML, многие аналитики находят такую диаграмму полезной, однако нет необходимости ее рисовать при описании вариантов использования.
Актеры.
Актер представляет собой некоторую роль, которую играет пользователь по отношению к системе. На рисунке 4 актера:
- менеджер по продажам;
- трейдер;
- продавец;
- система счетов клиентов.
Вероятно, в конкретной организации будет много трейдеров, но все они по отношению к системе играют одну и туже роль. Отдельный пользователь может играть более одной роли.
Актеры связаны с вариантами исполнения. Один актер может выполнить много вариантов использования. В свою очередь, у варианта использования может быть несколько актеров, которые его выполняют.
Актеры наиболее полезны при попытке сформулировать варианты использования на практике. В случае большой системы, часто трудно определить список вариантов использования. В такой ситуации бывает проще сначала перечислить всех актеров, после чего из них попытаться разработать вариант использования.
Актеры не обязаны быть людьми, хотя на диаграмме вариантов использования изображены в виде людей. Отдельный актер может быть даже внешней системой, которой необходима некоторая информация от разрабатываемой системы.
Существует несколько вариантов изображения актеров. Некоторые разработчики учитывают каждую внешнюю систему или пользователя как актёра, другие – указывают только инициатора варианта использования.
Хотя система счетов клиентов и получает сервис от разрабатываемой системы, на диаграмме вариантов использования не показывается тот факт, что кто-либо из актёров может получать информацию от самой системы счетов клиентов. Эту ситуацию следует представить при разработке модели собственно системы счетов клиентов.
В процессе работы с актерами и вариантами использования нужно уточнять точность установления отношений между ними. Пока не выявились все варианты использования не интересует детальное описание актёров.
Иногда все же встречаются ситуации, когда, возможно, следует больше внимания уделять актерам:
Для разных видов пользователей может потребоваться переконфигурация системы. Тогда каждый вид пользователей представляет собой актера, а варианты использования укажут, что должен делать каждый из этих актеров.
Акцент на получение желаемого сервиса от вариантов использования может помочь установить приоритеты между различными актёрами.
Некоторые варианты использования могут не иметь очевидных связей с отдельными актерами.
Помимо связи между актерами и вариантами использования на диаграммах могут быть представлены также отношения между вариантами использования.
Отношение включения имеет место, когда имеется какой-либо фрагмент поведения системы, который повторяется более чем в одном варианте использования.
Отношение расширения аналогично обобщению, но имеет дополнительные особенности. Обобщение позволяет выполнять расщепление или декомпозицию вариантов использования. При выборе связей необходимо пользоваться следующими правилами:
использовать отношения включения, когда приходится повторять одно и тоже в двух или более отдельных вариантах использования;
использовать отношение обобщения, когда описывается изменение некоторой нормализации поведения поверхности;
использовать отношение расширения, когда описывается изменение некоторого формального поведения в более детальной форме.