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

Разработка функциональной структуры программной системы.

Диаграммы вариантов использования

План лекции

Введение. 2

1. Структурные модели анализа бизнес-процессов. 2

1.1. Схема Захмана. 2

1.2. Диаграммы потоков данных. 4

2. UML-диаграммы вариантов использования. 6

2.1. Назначение и компоненты UseCase-диаграммы.. 6

2.2. Компонент диаграммы "Актер". 6

2.3. Компонент диаграммы "Вариант использования". 7

2.4. Компонент диаграммы "Интерфейс". 7

2.5. Компонент диаграммы "Связь"("Отношение") 8

2.5.1. Отношение ассоциации. 9

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

2.5.3. Отношение обобщения. 11

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

2.6. Примеры UseCase-диаграмм.. 12

2.7. Обозначения компонентов UseCase-диаграмм.. 14

2.8. Сценарии вариантов использования. 14

2.9. Рекомендации и типичные ошибки при разработке UseCase-диаграмм.. 16

3. Выявление и анализ требований. 17

4. Контрольные вопросы и задания. 20

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

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

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

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

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

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

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

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

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