220905_3_Lekts_UP_ch_1_V1

1. Б1.В.15 ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА ИНФОРМАЦИОННЫХ СИСТЕМ (4408-022, 09.03.02 ИСиТ, 7 семестр - экзамен)

160711-160715

2.

144 – 4 ЗЕТ
18 ч. лекций
36 ч. лаб.
3 теста
экзамен
54 СР
4 ЗЕТ
2

3. Литература:

1. Вендров
А.М.
Проектирование
программного
обеспечения экономических информационных систем.
Учебник. М.: Финансы и статистика, 2003, 352 с.
2. Вендров
А.М.
Практикум
по
проектированию
программного обеспечения экономических информационных
систем. М.: Финансы и статистика, 2002,192 с.
3. Леоненков А. UML 2-е издание, Санкт-Петербург: БХВПетербург, 2004,432 с.
.
3

4. Термины процесса проектирования ИC

4

5. Федеральный закон Российской Федерации от 27 июля 2006 г. N 149-ФЗ Об информации, информационных технологиях и о защите

информации
Информация — сведения (сообщения, данные)
независимо от формы их представления.
Информационные технологии (ИТ) - процессы, методы
поиска, сбора, хранения, обработки, предоставления,
распространения информации и способы осуществления
таких процессов и методов.
Информационная система (ИС) - совокупность
содержащейся
в
базах
данных
информации
и
обеспечивающих
ее
обработку
информационных
технологий и технических средств.
Информационно-телекоммуникационная
сеть
технологическая система, предназначенная для передачи по
линиям связи информации, доступ к которой осуществляется
с использованием средств вычислительной техники.
5

6. Термины процесса проектирования ИТ

Модель (model) — абстракция физической системы,
рассматриваемая с определенной точки зрения и
представленная на некотором языке или в графической
форме.
Проекти́рование — процесс определения архитектуры,
компонентов, интерфейсов и других характеристик
системы или её части (ISO 24765).
6

7.

Результатом проектирования является прое́кт —
целостная
совокупность
моделей,
свойств
или
характеристик, описанных в форме, пригодной для
реализации системы. Проектирование, наряду с анализом
требований, является частью большой стадии жизненного
цикла системы, называемой проектирование, системы
(англ. system definition). Результаты этой стадии являются
входной информацией для стадии реализации (воплощения)
системы (англ. system realization).
Жизненный цикл ИС можно представить как ряд
событий, происходящих с системой в процессе ее создания и
использования.
7

8.

Информационная система (ИС) - совокупность
содержащейся
в
базах
данных
информации
и
обеспечивающих
ее
обработку
информационных
технологий и технических средств;
Продолжительность жизненного цикла современных ИС
составляет около 10 лет, что значительно превышает сроки
морального и физического старения технических и
системных программных средств, используемых при
построении системы. Поэтому в течение жизненного цикла
ИС проводится модернизация ее технико-программной базы.
При этом прикладное программное обеспечение системы
должно быть сохранено и перенесено на обновляемые
аппаратно-программные платформы.
8

9.

Реализацию крупных проектов принято разбивать на
стадии
анализа,
проектирования,
непосредственного
кодирования, тестирования и сопровождения. Известно, что
исправление
ошибок, допущенных на предыдущей
стадии, обходится примерно в 10 раз дороже, чем на
текущей, откуда следует, что наиболее критичными
являются первые стадии проекта. В связи с этим крайне
важно иметь эффективные средства автоматизации ранних
этапов реализации проекта. Крупный проект невозможно
реализовать
в
одиночку.
Коллективная
работа
существенно отличается от индивидуальной, поэтому
при реализации крупных проектов необходимо иметь
средства координации и
управления коллективом
разработчиков.
9

10. ЖЦ каскадной модели проектирования ИС

10

11.

ЖЦ предусматривает последовательное выполнение всех
этапов проекта в строго фиксированном порядке. Переход на
следующий этап означает полное завершение работ на
предыдущем этапе и каждый этап завершается передачей
заказчику полного комплекта проектной документации по
ГОСТ серии 34. (с эта модель с 70 г.).
11

12.

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

13. Поэтапная модель ЖЦ ИС с промежуточным контролем

13

14. Особенности каскадной (водопадной) модели ЖЦ

1. Каждый этап начинается с заключения договора.
2. Предоплата.
3. Разработчик разрабатывает соответствующий этап в
соответствии с требования к данному этапу по ГОСТ
19. и 34.
4. Данная документация передается на согласование
заказчику.
5. Защита этапа. Заказчик привлекает сторонние
организации для выявления ошибок и полноты.
6. Если найдены ошибки проекта, то проектировщик
обязан устранить за свой счет.
7. Этап закрывается. Заказчику передается весь комплект
проектной документации этапа (несколько кубометров
книг). Заказчик оплачивает разработчику этап.
14

15. Особенности поэтапной модели ЖЦ. Продолжение.

Для систем реального времени возможны аварийные
ситуации. Авария может возникнуть по вине системы
управления. Документация в этом случае позволяет
выявить виновность проектной организации.
8. Заказчик заключает новый договор на следующий этап
проекта. Не факт, что проектирование продолжит та же
компания, которая разрабатывала предыдущий этап.
15

16. Достоинства и недостатки каскадной модели

Достоинства:
1. на каждом этапе формируется законченный набор
проектной документации, отвечающий критериям полноты и
согласованности (непротиворечивости);
2. выполняемые в логической последовательности этапы
работ позволяют планировать сроки завершения всех работ и
соответствующие затраты.
Недостаток:
1. Велика длительность проектирования.
2. Необходимо
разрабатывать
огромный
комплект
проектной документации по стандартам.
3. Сложность включения новых требований.
16

17. Спиральная модель ЖЦ

Спиральная модель ЖЦ
была предложена для
преодоления выше перечисленных проблем. На этапах
анализа и проектирования реализуемость технических
решений и степень удовлетворения потребностей заказчика
проверяется путем создания прототипов. Каждый виток
спирали
соответствует
созданию
работоспособного
фрагмента или версии системы. Это позволяет уточнить
требования, цели и характеристики проекта, определить
качество разработки, спланировать работы следующего витка
спирали. Таким образом углубляются и последовательно
конкретизируются детали проекта и в результате выбирается
обоснованный
вариант,
который
удовлетворяет
действительным требованиям заказчика и доводится до
реализации.
17

18.

Спиральная модель ЖЦ
была предложена для
преодоления перечисленных проблем. На этапах анализа и
проектирования реализуемость технических решений и
степень удовлетворения потребностей заказчика проверяется
путем создания прототипов. Каждый виток спирали
соответствует созданию работоспособного фрагмента или
версии системы. Это позволяет уточнить требования, цели и
характеристики проекта, определить качество разработки,
спланировать работы следующего витка спирали. Таким
образом углубляются и последовательно конкретизируются
детали проекта и в результате выбирается обоснованный
вариант,
который
удовлетворяет
действительным
требованиям заказчика и доводится до реализации.
18

19. Спиральная модель ЖЦ ИС

19

20.

На каждом витке спирали выполняется создание
очередной версии продукта, уточняются требования проекта,
определяется его качество и планируются работы
следующего витка. Особое внимание уделяется начальным
этапам разработки - анализу и проектированию, где
реализуемость тех или иных технических решений
проверяется и обосновывается посредством создания
прототипов (макетирования).
Заказчику
передается
только
эксплуатационная
документация.
СПИРАЛЬНУЮ
МОДЕЛЬ
НЕЛЬЗЯ
ИСПОЛЬЗОВАТЬ ПРИ ПРОЕКТИРОВАНИИ СИСТЕМ
РЕАЛЬНОГО ВРЕМЕНИ!!!
20

21. ПАРАДИГМА СОВРЕМЕННОГО ПРОИЗВОДСТВА

Отныне нужно не “что-то производить и стараться
потом продать”, а “стараться производить, то, что
продается”.
21

22.

Прогресс в области компьютерных систем обработки
данных, сетевых технологий, разработка
стандартов и
интерфейсов
интеграции
данных
и
приложений
обеспечивают реализацию и экономическую эффективность
ИТ управления.
Под корпоративной информационной системой
(КИС)
понимается
система,
реализующая
информационные
технологии для
применения
эффективных
методов
управления
предприятием
масштаба корпорации.
22

23. Роль и место информационных технологий в управлении предприятием

В системах управления предприятиями применяются
различные методы управления, основанные на конкретных
алгоритмах подготовки и принятия управленческих решений
с использованием ИТ. Методы управления формализованы
в виде стандартов управления, которые являются основой
разработки функциональной структуры ИС (организационноэкономической подсистемы).
23

24.

Показатели, характеризующие тенденции развития
экономики предприятий
24

25.

MPS- главный календарный план производства (Master
Production Schedule, MPS) или «Главного плана-графика
производства».
MRP — Material Requirements Planning (планирование
потребности).
Электронная торговля.
2525
25

26. Задачи предприятий:

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

27. Требования со стороны рынка к КИС

- открытая архитектура построения;
- распределенная система обработки данных;
- развитая коммуникационная подсеть (интрасеть);
- многоплатформенность приложений и баз данных.
Создание КИС обусловлено потребностью системы
управления
предприятием
в
реализации
новых
информационных технологий управления.
Под корпоративной информационной системой (КИС)
понимается система, реализующая информационные
технологии для
применения эффективных методов
управления предприятием масштаба корпорации.
27

28. ПОНЯТИЕ ИНТЕГРИРОВАННОЙ ИС

Эффективной информационная система становится,
когда она позволяет обмениваться информацией различным
системам и пользователям. Именно в этом случае наступает
то, что называется «синергетическим эффектом» — т.е.
совместное использование различных систем и совместная
работа пользователей позволяет достичь того эффекта,
который был недоступен без такой интеграции. Пример:
пусть поступил запрос от клиента в отдел сбыта о состоянии
выполнения заказа (разработка строительного проекта,
производственной линии и т.д.). В интегрированной системе
управления путем нескольких щелчков мыши можно
получить отчет о состоянии выполнения заказа (в
нормальных фирмах западного уровня клиентам сотрудник
отправляются такие отчеты периодически, без напоминания).
28

29. Причины низкой эффективности управления компаниями в России 

Причины низкой эффективности управления
компаниями в России
Согласно исследованиям консалтинговой компании
McKinsey, основной причиной низкой производительности труда
(на уровне 19% от западной), низкой конкурентоспособности и
прибыльности отечественных компаний является низкое
качество управления. Причина низкой эффективности
управления во многих случаях достаточно проста — это
отсутствие целостной корпоративной системы управления,
объединяющей все информационные ресурсы компании.
Руководители в любой момент времени должны знать, какими
ресурсами
они
располагают,
насколько
эффективно
используются эти ресурсы, какую прибыль они приносят. Для
успешной работы компании всегда необходимо иметь самую
свежую, достоверную и полную информацию, анализ которой
позволяет оперативно реагировать на изменения рынка.
29

30. Специфика «кусочной» автоматизации

При «кусочной» автоматизации
на предприятии
раpабатываются не связанные между собой подсистемы
(например,
бухучет,
склады,
сбыт,
автотранспорт,
производственные подсистемы и т.д.), т.е. нет единой
информационной базы. В случае «кусочной» автоматизации
сотрудник отдела сбыта формирует служебную записку в
производственный отдел о ходе выполнения заказа клиента.
Подписывает служебную записку у начальника своего отдела.
30

31.

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

32.

"Инвестиции в бардак этот бардак
только увеличивают" - это следствие из IIго закона термодинамики для общества.
32

33. Базовые принципы построения ИС

Рассмотрим базовые принципы построения ИС,
которые сформировались на современном этапе:
- масштабируемость;
- надежность;
- управляемость;
- опора на стандарты.
33
33

34. Масштабируемость

Масштабируемость
подразумевает
возможность
увеличить необходимую производительность системы, как
по количеству операций, так и по числу пользователей.
Может
сложиться
впечатление,
что
обеспечить
масштабируемость достаточно просто: необходимо просто
купить более мощное и производительное оборудование, и
проблема решена. Это верно лишь отчасти —
масштабирование наращиванием мощности работает только
до определенного уровня или, точнее, до момента «разрыва
непрерывности».
34

35.

Невозможно масштабировать прикладную программу,
написанную в незапамятные времена «на коленке»,
принципиально не понимающую распараллеливания или
многопроцессорности. Но это масштабы, до которых еще
нужно дожить. А вот для нашего малого и среднего бизнеса
очень характерна другая ситуация. Не секрет, что большая
часть расчетов и планов строится сотрудниками в
электронных таблицах — Excel. До определенного этапа
развития это нормально и экономически оправдано.
35

36. Надежность

Основное значение этого параметра: оценивать
устойчивость системы к сбоям, включая такие экстремальные
ситуации, как катастрофы. Современные технологии позволяют
создавать исключительно эффективные системы, устойчивые
практически к любым внешним воздействиям, вплоть до уровня
трансконтинентальных кластеров (локальная и глобальные
отказоустойчивости).
Уровень
надежности
определяется
процентом времени, которое система находится в рабочем
состоянии. Скажем, 0,99999 или, в просторечье, «пять девяток»,
обеспечивает такой уровень надежности, что в течение года
система будет в простое состоянии всего 5 минут в год!!! Такой
нижний уровень надежности предъявляется для банковских
систем. Сервера в банке Ак Барс имеют четырехкратное
резервирование!!!
В понятие «надежность» входит и защищенность от
внешних воздействий и кражи информации.
36

37. Управляемость

ИС не должна отнимать слишком много ресурсов на
свое обслуживание. В небольших и средних организациях
обычно пренебрегают эти фактором, считая, что он
проявляется только при сотнях и тысячах пользователей, но
это не всегда правильно, особенно на «кусочно»
автоматизированных предприятиях (до 30% затрат ИТ
отделов связано на интеграцию подсистем).
37

38. Опора на стандарты. При разработку ИС использовать самые современные инструментальные средства разработки!!!

Информационные технологии меняются еще быстрее,
чем окружающий мир, — им ведь нужно не просто
поменяться, а попробовать несколько вариантов и наконец
выбрать тот, который наилучшим образом соответствует
переменам в реальном мире бизнеса и отношений. Каким
образом я могу быть уверен, что все деньги, которые я
вложил в ИТ, не пропадут и я смогу хоть как-то использовать
мои наработки в будущем? Единственный метод, который
может с определенной степенью вероятности гарантировать
такую «совместимость с будущим», это опора на стандарты.
Если ваша система использует сегодняшние стандарты
информационных технологий, то вероятность ее
интеграции и применения в будущем очень серьезно
возрастает.
38

39. Особенности управлению программными проектами

39

40. Отличия программной инженерии от других отраслей

Standish Group, проанализировав работу сотен
американских корпораций и итоги выполнения нескольких
десятков тысяч проектов, связанных с разработкой ПО, в
своем докладе с красноречивым названием «Хаос» пришла к
следующим неутешительным выводам.
40

41. Успешность программных проектов

41

42. Кто виноват?

Кто виноват? Никто. Cамого-то «хаоса» не было, и нет, а
есть лишь Богом данная (для атеистов — объективная)
реальность, которая заключена в особой специфике
производства программ, по сравнению с любой другой
производственной деятельностью, потому что то, что
производят программисты — нематериально, это
коллективные ментальные модели, записанные на языке
программирования.
То, что производят программисты нематериально — это
коллективные мысли и идеи, выраженные на языке
программирования.
42

43. Причины неудачных проектов

Главной причиной такого положения является то,
уровень
технологии
анализа
и
проектирования ИС, методов и средств управления
что
проектами не соответствует сложности создаваемых
систем, которая постоянно возрастает в связи с
усложнением и быстрыми изменениями бизнеса.
Наиболее совершенной моделью кота является такой
же кот, а лучше - он сам (Н. Винер).
43

44. Причины неудачных проектов

1. Недостаточно адекватное управление требованиями.
2. Несогласованность требований, проектных решений и
реализации.
3. Жесткая архитектура ПО.
4. Нарастающая сложность ПО.
5. Неточная и противоречивая коммуникация.
6. Недостаточное тестирование.
7. Субъективное отношение к приоритетам отдельных
артефактов проекта.
8. Игнорирование рисков и отсутствие процедур
управления рисками.
9. Бесконтрольное внесение изменений в артефакты
проекта.
10. Недостаточное использование CASE-средств и
средств поддержки отдельных этапов проекта.
44

45. Отсутствие моделей при разработке ПО

Не позволяет справиться с растущей сложностью
разрабатываемых программных систем.
Не позволяет эффективно управлять разработкой в
условиях изменяющихся требований.
Создает барьеры непонимания: аналитик не понимает
руководителя проекта, разработчик – аналитика,
тестировщик – разработчика и пр.
Не позволяет обеспечить контроль изменений в
процессе выполнения работ.
Не позволяет избежать субъективности в оценке
качества разрабатываемых продуктов.
Модель (model) — абстракция физической системы,
рассматриваемая с определенной точки зрения и
представленная на некотором языке или в графической
форме.
45

46. Термин «Инструментальные средства информационных систем»

Инструментальные средства ИС — комплекс
программно-технических средств предназначенных для
автоматизации разработки ИС.
46

47. Лучшие практики разработки ПО

- использование визуальных моделей при разработке
ПО;
- итеративная разработка ПО;
- управление требованиями;
- управление изменениями и конфигурацией артефактов ПО;
- использование компонентных архитектур;
- непрерывное тестирование и верификация качества ПО;
- использование паттернов проектирования (шаблоны);
- использование CASE-средств.
Управление рисками:
- технологическими рисками;
- связанными с требованиями;
- связанными с квалификацией персонала проекта;
- политическими рисками.
47

48. МОДЕЛЬ ЗРЕЛОСТИ ПРОЦЕССОВ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Наилучшее решение проблемы надёжности – с
самого начала не допускать ошибок в программе.
48

49.

Производственный процесс может быть определен как
набор операций, методов, практик и преобразований,
используемых
разработчиками
для
создания
и
сопровождения ПО и связанных с ним продуктов (например,
планов проекта, проектных документов, кодов, сценариев
тестирования и руководств пользователя). По мере того, как
организация становится более зрелой, ее производственный
процесс становится все более четко определенным и
последовательно применяемым в рамках всей организации.
Существует международный стандарт классификации
производственного процесса разработки ИС - CMM.
Независимый сертификационный центр сертифицирует
проектные организации. Сертификат CMM 5-го уровня
позволяет организации участвовать в тендерах для
Пентагона.
49

50. Организация CMM по пяти уровням зрелости определяет приоритеты работ по развитию производственного процесса.

50

51.

1)
Начальный.
Производственный
процесс
характеризуется как создаваемый каждый раз под
конкретный проект, а иногда даже как хаотический.
Определены лишь некоторые процессы и успех проекта
зависит от усилий индивидуумов.
2) Повторяемый. Установлены основные процессы
управления проектом, позволяющие отслеживать затраты,
следить за графиком работ и функциональностью
создаваемого
программного
решения.
Установлена
дисциплина процесса, необходимая для повторения
достигнутых ранее успехов в проектах разработки
подобных приложений.
51

52.

3)
Определенный.
Производственный
процесс
документирован и стандартизован как для управленческих
работ, так и для проектирования. Этот процесс интегрирован
в стандартный производственный процесс организации. Во
всех
проектах
используется
утвержденная
адаптированная версия стандартного производственного
процесса организации.
4) Управляемый. Собираются подробные количественные показатели производственного процесса и
качества создаваемого продукта. Как производственный
процесс, так и продукты оцениваются и контролируются
с количественной точки зрения.
52

53.

5)
Оптимизирующий.
Постоянное
совершенствование
процесса
достигается
благодаря количественной обратной связи с
процессом и реализации передовых идей и
технологий.
75% программного кода переходит в
новые проекты!!! Практически 100% гарантия
уложиться в срок и бюджет!!!
53

54. Объектно-ориентированный анализ и проектирование (ООАП) – основные понятия

Объектно-ориентированный анализ и проектирование
(Object-Oriented Analysis/Design) — технология разработки
программных систем, в основу которых положена объектноориентированная методология представления предметной
области в виде объектов, являющихся экземплярами
соответствующих классов
Предметная область (domain) – часть реального мира,
которая имеет существенное значение или непосредственное
отношение к процессу функционирования программы
54

55.

Модель (model) — абстракция физической системы,
рассматриваемая с определенной точки зрения и
представленная на некотором языке или в графической
форме.
Диаграмма (diagram) — графическое представление
совокупности элементов модели в форме связного графа,
вершинам и ребрам (дугам) которого приписывается
определенная семантика,
Нотация канонических диаграмм является основным
средством разработки моделей на языке UML.
55

56. ОСНОВНЫЕ КОНЦИИ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПРОЕКТИРОВАНИЯ (ООП)

ОСНОВНЫЕ КОНЦИИ ОБЪЕКТНООРИЕНТИРОВАННОГО ПРОЕКТИРОВАНИЯ (ООП)
Мир состоит из систем.
Системы состоят из объектов.
Объекты некоторым образом взаимодействуют между
собой.
Каждый объект характеризуется своим состоянием и
поведением.
56

57. Принципы ООП

Инкапсуляция.
Наследование.
Полиморфизм.
57

58. Инкапсуляция

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

59. Наследование

1. Возможность порождать один класс от другого с
сохранением всех свойств и методов класса – предка (иногда
его называют суперклассом или родительским классом)
добавляя при необходимости новые свойства и методы.
2. Призвано отобразить такое свойство реального мира, как
иерархичность.
59

60. Полиморфизм

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

61. Канонические диаграммы языка UML 2.х

Диаграмма
Диаграмма
структуры
Диаграмма
классов
Диаграмма
компонентов
Диаграмма
развертывания
Диаграмма
поведения
Диаграмма
объектов
Диаграмма
композитной
структуры
Диаграмма
деятельности
Диаграмма
пакетов
Диаграмма
конечного
автомата
Диаграмма
взаимодействия
Диаграмма
последовательности
Диаграмма
вариантов
использования
Диаграмма
обзора
взаимодействия
Диаграмма
коммуникации
Временная
диаграмма
61

62. Использование языка UML в проектах по отраслевой принадлежности

- банки и инвестиционные фонды;
- связь и телекоммуникации;
- нефтегазовая промышленность;
- страховые фонды;
- энергетика;
- машиностроение;
- торговля;
- фармацевтическая промышленность;
- оборонная промышленность;
- федеральная таможенная служба;
- учебные заведения.
62

63. Средний проект по разработке ПО:

- 5-10 человек;
- 10-15 месяцев;
- 10-15 задач;
- незначительная неопределенность и риски.
63

64. Диаграмма вариантов использования (use case diagram)

65. Диаграмма вариантов использования (ВИ) (use case diagram)

Диаграмма, на которой изображаются ВИ проектируемой
системы, заключенные в границу системы, и внешние актеры, а
также определенные отношения между актерами и вариантами
использования.
<<extend>>
Клиент Банка
Пополнить счет
Открыть счет
варианты использования
актеры
Кассир
<<extend>>
Операционист
ассоциации
Снять деньги со счета
Закрыть счет
зависимость с текстовым
стереотипом
65

66. Назначение диаграммы вариантов использования

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

67. Проектируемая система и ее окружение

Предоставляемые
сервисы
Предоставляемые
сервисы
ПРОЕКТИРУЕМАЯ
СИСТЕМА
Пользователи
системы
Заинтересованные
лица
Субъект (subject) – любой элемент модели,
который обладает функциональным поведением
67

68. Основные обозначения на диаграмме вариантов использования

68

69. Вариант использования (use case)

Вариант использования (use case)
– представляет собой общую спецификацию совокупности
выполняемых системой действий с целью предоставления
некоторого наблюдаемого результата, который имеет значение
для одного или нескольких актеров
Отвечает на вопрос «Что должна выполнять система?», не
отвечая на вопрос «Как она должна выполнять это?»
Имена – отглагольное существительное или глагол в
неопределенной форме.
<<use case>>
Формирование отчета по
выполненным заказам
Проверка состояния
текущего счета клиента
Формирование отчета по
выполненным заказам
69

70. Актер (actor)

– любая внешняя по отношению к проектируемой системе
сущность, которая взаимодействует с системой и использует ее
функциональные возможности для достижения определенных
целей или решения частных задач
Примеры актеров: кассир, клиент банка, банковский
служащий, президент, продавец магазина, менеджер отдела
продаж,
пассажир
авиарейса,
водитель
автомобиля,
администратор гостиницы, сотовый телефон
Клиент банка
<<actor>>
Посетитель
Интернет-магазина
Удаленный
пользователь
70

71. Вопросы для идентификации актеров в системе

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

72. Отношения на диаграмме вариантов использования

72

73. Отношение ассоциации

Ассоциация
(association)
является
одним
из
фундаментальных понятий в языке UML 2.х и может
использоваться на различных канонических диаграммах при
построении визуальных моделей
Применительно к диаграммам вариантов использования
отношение ассоциации может служить только для обозначения
взаимодействия актера с вариантом использования.
Просмотр списка
представленных товаров
Посетитель
Интернет-магазина
73

74. Отношение включения

Отношение зависимости (dependency) определяется как
форма взаимосвязи между двумя элементами модели,
предназначенная для спецификации того обстоятельства, что
изменение одного элемента модели приводит к изменению
некоторого другого элемента.
Отношение включения (include) специфицирует тот факт,
что некоторый вариант использования содержит поведение,
определенное в другом варианте использования
Оформление Заказа в
Интернет-магазине
вариант использования А
<<include>>
Регистрация
покупателя
вариант использования Б
74

75. Отношение расширения

Отношение расширения (extend) определяет взаимосвязь
одного варианта использования с некоторым другим
вариантом использования, функциональность или поведение
которого задействуется первым не всегда, а только при
выполнении некоторых дополнительных условий.
Оформление Заказа в
Интернет-магазине
вариант использования А
<<extend>>
Предоставление бонусной
скидки постоянному
покупателю
вариант использования Б
75

76. Изображение отношения расширения с условием выполнения

Условие: {клиент имеет бонусную карточку}
extention point:Скидка
Оформление Заказа в
Интернет-магазине
extention point
Скидка
<<extend>>
Предоставление бонусной
скидки постоянному
покупателю
76

77. Отношение обобщения

Отношение обобщения (generalization relationship)
предназначено для спецификации того факта, что один
элемент модели является специальным или частным случаем
другого элемента модели
Оплата выбранного в
Интернет-магазине товара
Оплата товара по
кредитной карточке
вариант использования А
вариант использования Б
Посетитель
Интернет-магазина
Покупатель
(актер А)
(актер Б)
77

78. Пример диаграммы ВИ для системы продажи товаров в Интернет-магазине

Система продажи товаров в Интернет-магазине
Просмотр списка
товаров
Изменение списка
товаров
Посетитель
Интернетмагазина
Изменение содержания
корзины
Оформление Заказа
на покупку товаров
<<include>>
<<extend>>
Менеджер
Регистрация
покупателя
Предоставление
бонусной скидки
Покупатель
Оплата выбранного
товара
Бухгалтер
Оплата товара
наличными
Оплата товара по
кредитной карточке
78

79. Формализация функциональных требований с помощью диаграммы ВИ

Требование (requirement) – желательное свойство,
характеристика или условие, которым должна удовлетворять
система в процессе своей эксплуатации.
Требование к ПО – некоторое свойство ПО, которым
должна обладать система или ее компонент, чтобы
удовлетворять условиям контракта, положениям стандартов,
формальной спецификации или технической документации.
Управление требованиями – это систематический подход
к выявлению, организации и документированию требований к
системе, а также процесс, в ходе которого вырабатывается и
обеспечивается соглашение между заказчиком и разработчиком
по поводу меняющихся требований к системе.
79

80. Классификация требований – модель FURPS+

Functionality
– функциональные требования
Usability (требования практичности)
Reliability (требования надежности)
Performance (требования производительности)
Supportability (требования обслуживания и
сопровождения)
Дополнительно + IEEE 610.12.1990
– Проектные ограничения
– Требования выполнения
– Требования к GUI
– Физические требования
80

81. Functionality – функциональные требования

Функциональные
требования
определяют
действия, которые должна быть способна выполнить
система, без рассмотрения физических особенностей их
реализации
Тем самым функциональные требования определяют
внешнее поведение системы
Лучше всего они описываются в форме модели
вариантов использования.
Каждому функциональному требованию в этом
случае будет соответствовать отдельный вариант
использования
81

82. Спецификация ВИ с помощью текстовых сценариев

Сценарий (scenario) – специально написанный текст, который
описывает поведение моделируемой системы в форме
последовательности выполняемых действий актеров и самой
системы.
82

83. Показатели качества для модели вариантов использования

Все ли функциональные требования описываются
вариантами использования?
Не содержит ли модель вариантов использования
ненужное поведение, которое отсутствует в требованиях?
Действительно ли в модели необходимы все выявленные
связи включения, расширения и обобщения?
Правильно ли произведено деление модели на пакеты
вариантов использования?
Стала ли модель в результате деление на пакеты проще и
удобнее для восприятия и сопровождения?
Можно ли на основе модели вариантов использования
составить четкое представление о функционировании системы
в контексте ее пользователей?
83

84. Последовательность разработки вариантов использования

Определить главных (первичных) актеров и определить их
цели по отношению к системе.
Специфицировать все базовые (основные) варианты
использования.
Выделить цели базовых ВИ, интересы актеров в
контексте этих ВИ, предусловия и постусловия ВИ.
Написать успешный сценарий выполнения базовых ВИ
Определить исключения (неуспех) в сценариях ВИ и
написать сценарии для всех исключений.
Выделить ВИ исключений и изобразить их со стереотипом
«extend».
Выделить общие фрагменты функциональности ВИ и
изобразить их отдельными ВИ со стереотипом «include».
84

85. Типичные ошибки при разработке диаграмм вариантов использования

1. Превращение диаграммы вариантов использования в
диаграмму деятельности за счет желания отразить все
функциональные действия.
2. Инициатором действий является разрабатываемая
система
Спецификация атрибутов и операций классов до того, как
сформулированы все варианты использования.
3.
Задание
слишком
кратких
имен
вариантам
использования.
4. Описание вариантов использования в терминологии,
непонятной пользователям системы или заказчику.
5.
Отсутствие
описаний
альтернативных
последовательностей действий.
6. Тратится слишком много времени на решение вопросов о
том, какие стереотипы и ассоциации использовать на
диаграмме.
85

86. Шаблон ВИ. Пример№1

Сценарий №1 выполнения варианта использования
"Снятие наличных по кредитной карточке"
Главный раздел
Вариант использования:
Снятие
наличных
по
кредитной
карточке
Актеры:
Клиент Банкомата, Банк
Цель:
Получение
требуемой
суммы
наличными
Краткое описание:
Клиент использует свою карточку для
снятия наличных. Клиент запрашивает требуемую сумму.
Банкомат обеспечивает доступ к счету клиента. Банкомат выдает
клиенту наличные.
Тип:
Базовый
Ссылки на другие варианты использования: Включает в себя
ВИ:
– Проверка ПИН-кода кредитной карточки
86

87. Раздел Типичный ход событий

1. Клиент вставляет кредитную карточку в устройство чтения
банкомата
2. Банкомат передает информацию о кредитной карточке в Банк
3. Банк проверяет информацию о кредитной карточке
Исключение №1: Кредитная карточка недействительна (утрачена)
Исключение №2: Кредитная карточка просрочена
4. Банкомат предлагает ввести ПИН-код
5. Клиент вводит PIN-код
6. Банкомат проверяет ПИН-код
Исключение №3: Введенный ПИН-код неверный
Исключение №4: Клиент ввел неверный ПИН-код 3 раза
7. Банкомат отображает опции меню
8. Клиент выбирает снятие наличных со своего счета
9. Банкомат предлагает ввести требуемую сумму

88. Раздел Типичный ход событий

10. Клиент вводит требуемую сумму
11. Банкомат делает соответствующий запрос в Банк
12. Банк проверяет введенную сумму
Исключение №5: Требуемая сумма превышает сумму на счете
клиента
13. Банк изменяет состояние счета клиента
15. Клиент получает свою кредитную карточку
Исключение №6: Клиент выбрал печать чека
14. Банкомат предлагает клиенту забрать его кредитную карточку
16. Банкомат выдает наличные и предлагает забрать их клиенту
17. Клиент получает наличные
18. Банкомат отображает сообщение о готовности к дальнейшей
работе
88

89. Раздел Исключений

Исключение №1. Кредитная карточка недействительна
(утрачена)
4. Банкомат блокирует кредитную карточку
18. Банкомат отображает сообщение о готовности к дальнейшей
работе
Исключение №2: Кредитная карточка просрочена
4. Банкомат предлагает клиенту забрать его кредитную карточку
15. Клиент получает свою кредитную карточку
18. Банкомат отображает сообщение о готовности к дальнейшей
работе
Исключение №3. Введенный ПИН-код неверный
4. Банкомат предлагает ввести ПИН-код
5. Клиент вводит ПИН-код
89

90. Сценарий №2 "Получение справки о состоянии счета"

Сценарий №2 "Получение справки о состоянии счета"
Главный раздел
Вариант использования:
Получение
справки
о
состоянии счета
Актеры: Клиент Банкомата, Банк
Цель:
Получение информации о балансе
Краткое описание:
Клиент использует свою карточку
для получения справки о состоянии счета. Банкомат
обеспечивает доступ к счету клиента. Банкомат выдает клиенту
справку в форме чека.
Тип:
Базовый
Ссылки на другие варианты использования:
Включает в себя ВИ:
– Проверка ПИН-кода кредитной карточки
90

91. Типичный ход событий

1. Клиент вставляет кредитную карточку в устройство
чтения банкомата
2. Банкомат передает информацию о кредитной карточке
в Банк
3. Банк проверяет информацию о кредитной карточке
Исключение №1: Кредитная карточка недействительна
(утрачена)
Исключение №2: Кредитная карточка просрочена
4. Банкомат предлагает ввести ПИН-код
5. Клиент вводит PIN-код
6. Банкомат проверяет ПИН-код
Исключение №3: Введенный ПИН-код неверный
Исключение №4: Клиент ввел неверный ПИН-код 3 раза
91

92. Типичный ход событий

7. Банкомат отображает опции меню
8. Клиент выбирает получение справки о состоянии счета
9. Банкомат делает соответствующий запрос в Банк
10. Банкомат предлагает клиенту забрать его кредитную
карточку
11. Клиент получает свою кредитную карточку
12. Банкомат выдает справку о состоянии счета и
предлагает забрать ее клиенту
13. Клиент получает справку о состоянии своего счета
14. Банкомат отображает сообщение о готовности к
дальнейшей работе
92

93. Раздел Исключений

Исключение №1. Кредитная карточка недействительна
(утрачена).
4. Банкомат блокирует кредитную карточку.
14. Банкомат отображает сообщение о готовности к
дальнейшей работе.
Исключение №2: Кредитная карточка просрочена.
4. Банкомат предлагает клиенту забрать его кредитную
карточку.
11. Клиент получает свою кредитную карточку.
14. Банкомат отображает сообщение о готовности к
дальнейшей работе.
Исключение №3. Введенный ПИН-код неверный.
4. Банкомат предлагает ввести ПИН-код.
5. Клиент вводит ПИН-код.
Исключение №4: Клиент вводит неверный ПИН-код 3 раза.
4. Банкомат блокирует кредитную карточку.
18. Банкомат отображает сообщение о готовности к
дальнейшей работе
93

94. Раздел Исключений

Исключение №4: Клиент вводит неверный ПИН-код 3 раза
4. Банкомат блокирует кредитную карточку.
18. Банкомат отображает сообщение о готовности к дальнейшей
работе.
Исключение №5. Требуемая сумма превышает сумму на счете
клиента.
9. Банкомат предлагает ввести новую сумму.
10. Клиент вводит новую требуемую сумму.
Исключение №6: Клиент выбрал печать чека.
16.1. Банкомат предлагает клиенту забрать чек.
Примечание. Клиент может отказаться от выполнения
транзакции "Снятие наличных по кредитной карточке" при введении
ПИН-кода, при выборе типа транзакции и при вводе суммы.
94

95. КОНЕЦ РАЗДЕЛА

95

96.

96

97.

97