Не могли бы вы сделать диаграмму состояний для хотя бы для одного ВИ, чтобы я хотябы примерно понял как мне строить для моей модели? До этого вроде все диаграммы получались, а вот с этой что-то застрял.

А зачем ДС делать для ВИ? Для ВИ обычно делают диаграмму деятельности, диаграмму последовательности.

Сейчас не могу, времени у меня сегодня нет, может получиться на выходных?

В качестве примера (взят из книги Якобсона Унифицированный процесс)

Пример. Пути варианта использования Оплатить Счет. Заметьте, пожалуйста, как изменился этот текст по сравнению с предварительным вариантом, приведенным ранее в этой главе, когда у нас был только набросок описания варианта
использования (см. подраздел «Краткое описание каждого варианта использования »). Это изменение показывает, как мы детализируем варианты использования посредством моделирования. Реальные полные описания вариантов использования
имеют больший размер и содержат описание большего количества путей.

Предусловие: покупатель получил заказанные товары или услуги и по крайней мере один счет. Теперь он планирует пометить счет(а) к оплате.
Поток событий.
1. Основной путь.
1. Покупатель запускает вариант использования, начиная просматривать счета, полученные от системы. Система проверяет, что содержимое счетов соответствует подтверждениям заказов, полученным ранее (как часть варианта
использования Подтвердить Заказ), и указывает на это покупателю. Подтверждение заказа описывает, что будет поставлено, когда, куда и по какой цене.
2. Покупатель решает пометить счет к оплате, и система генерирует запрос на платеж, чтобы банк мог перечислить деньги на счет продавца. Заметьте, что покупатель не может пометить один и тот же счет к оплате дважды.
3. Позже, а именно в намеченную дату, если на счете покупателя имеется достаточное количество денег, происходит оплата. При оплате деньги перечисляются со счета покупателя на счет продавца, как описано в абстрактном
варианте использования Совершить Перечисление (который используется в Оплатить Счет). Покупатель и продавец уведомляются о результате операции. Банк получает плату за перечисление, которая снимается системой
со счета покупателя.
4. Экземпляр варианта использования прекращает свое существование.

2. Альтернативные пути.
1. На шаге 2 покупатель может потребовать, чтобы система отослала продавцу сообщение о том, что счет отклонен.
2. На шаге 3, если на счете недостаточно денег, вариант использования отменит оплату и сообщит об этом покупателю.

Постусловие: образец варианта использования прекращает свое существование после того, как счет оплачен, или если оплата отменена и деньги не перечислены.

Использование диаграмм состояний для описания вариантов использования. Рисунок 7.16 — диаграмма состояний варианта использования Оплатить Счет. Черная точка в верхней части графика обозначает начало варианта использования. Это место, из которого начинает выполняться конечный автомат, когда зарождается экземпляр варианта использования. Стрелка, выходящая из черной точки, показывает, в какое состояние немедленно после зарождения переходит конечный автомат, в данном случае — в первое состояние Просмотр. Состояния изображаются прямоугольниками со скругленными углами. Изменения состояний изображаются стрелками, направленными из одного состояния в другое.

Диаграмма состояний схематически показывает, как экземпляр варианта использования Оплатить Счет проходит отдельные состояния (скругленные прямоугольники) в ходе последовательных переходов (стрелки). Сначала пользователь
просматривает счет (см. шаг 1 в предшествующем примере Оплатить Счет) и решает, пометить его к оплате (см. шаг 2) или отклонить (см. шаг 5). Вариант использования выходит из состояния Счета, Помеченного к Оплате, когда помеченный счет оплачивается в срок, указанный для платежа (см. шаг 3). Вариант использования прекращает существовать (круг с черной точкой в нем) сразу же после того, как перейдет в состояния Счет Оплачен или Счет Отклонен.

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

А зачем ДС делать для ВИ? Для ВИ обычно делают диаграмму деятельности, диаграмму последовательности.

Сейчас не могу, времени у меня сегодня нет, может получиться на выходных?

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

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

Я бы не ставил на мою быструю помощь, отрецензировать можно, делать - тут ведь думать надо:) Вы в теме, я уже нет.
Что такое диаграмма состояний? Она отображает некий конечный автомат. Демонстрирует поведение такого автомата. Любая программа есть по сути конечный автомат, любой объект аналогично, поскольку является программой.

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

Переход из состояния в состояние меняет параметры рассматриваемого объекта, набор таких параметров и есть состояние.

Для чего строить диаграмму? На уровне аналитической модели - это может быть некий жизненный цикл документа, объекта предметной области, автоматный алгоритм ВИ. На уровне проектной модели - вероятно жизненный цикл управляющих объектов, возможно изменение состояний формы.

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

Что такое диаграмма состояний? Она отображает некий конечный автомат. Демонстрирует поведение такого автомата. Любая программа есть по сути конечный автомат, любой объект аналогично, поскольку является программой.

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

Переход из состояния в состояние меняет параметры рассматриваемого объекта, набор таких параметров и есть состояние.

С какого состояния по вашему лучше будет начать? У меня из программ в модели только БД( и то это и программой то назвать нельзя) которая посылает запрос о месте нахождения книги, посылает менеджеру сообщение о том что книги нет в наличии наличии книги, с помощью неё узнаётся стоимость и которая может пополняться новыми книгами. Она в каждом из вариантов использования выполняет разные функции. Как раз в связи с этим и не пойму как строить, либо для каждого  ВИ либо общую.
Понимаю что туплю, но что-то сообразить никак не могу
 Если интересно, то посмотрите диаграммы коопераций которые я выложил выше.

Диаграмма состояний описывается для ОДНОГО объекта. Если объект - агрегат, то можно описать диаграммы состояний и для его частей.

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

Ну не знаю как донести до вас свою мысль

Взял за основу вариант поставка книг в магазин.

На самом деле - это скорее бизнес ВИ, который требует разделения на несколько вариантов.

За объект изменяющий свое состояние (набор параметров) я взял заявку на поставку книг.

Это только нулевое приближение, с которым ты можешь поработать.Можно добавит действия внутри состояний, можно добавит предусловия состояния, можно добавить точки принятия решений

Спасибо вам большое, теперь буду пытаться ещё две штуки составить !

Дело прошлое, но можно заметить недочёты диаграммы состояний:
Вешать сторожевое условие на переход из начального псевдосостояния запрещает стандарт.
Переходы по завершению со сторожевыми условиями использованы ошибочно. Если заменить их на переходы по событию завершения (с теми же условиями), диаграмма выиграет.

Дело прошлое, но можно заметить недочёты диаграммы состояний:
Вешать сторожевое условие на переход из начального псевдосостояния запрещает стандарт.
Переходы по завершению со сторожевыми условиями использованы ошибочно. Если заменить их на переходы по событию завершения (с теми же условиями), диаграмма выиграет.

Согласен. Ошибки присутствуют. Но коли уж обратили на них внимание, может быть представите вариант лишенный недостатков? Ну помните, картинка лучше 1024 слов

Описка. Событие изменения имелось в виду. Порисую-запосчу.

А зачем ДС делать для ВИ? Для ВИ обычно делают диаграмму деятельности, диаграмму последовательности.

Очень даже стоит строить для варианта использования диаграмму состояний, если сущность/сущности во время действия ВИ меняют своё состояние (возможно, по довольно сложному алгоритму). + ко всему, возможность изменения состояний одной сущности может определяться текущим состоянием других сущностей, с нею связанных. Например, могут быть такие условия:
- "нельзя изменить срок поставки на более ранний менее, чем за 5 дней до действующего (указанного ранее) срока поставки"
- "счёт должен быть оплачен не позднее, чем за 12 часов до срока поставки"
Это может потребовать введения ещё одного состояния "Счёт готов к полате" для сущности "Счёт", и ещё одной ветки "Помеченный счёт" --- назначить дату оплаты счёта --->"Счёт готов к полате"--- оплатить в назначенный день --->"Счёт оплачен". И ещё могла бы быть ветка для коррекции сроков оплаты/поставки.

Сейчас курсовая на такую же тему, ответы в теме очень помогли, спасибо!

Не совсем в тему. В этом году перевели книгу Хорхе Карриона "Книжные магазины". Библиофилам, читающим с бумаги, может быть интересна.
Расширяет перечень ВИ книжных, добавляя такие как: "Выпить чашечку кофе", "Навербовать новых членов в партию", "Улучшить жизнь в сельской местности", "Спереть книгу, а потом продать обратно" и проч. столь же невообразимые.

Не совсем в тему. В этом году перевели книгу Хорхе Карриона "Книжные магазины". Библиофилам, читающим с бумаги, может быть интересна.
Расширяет перечень ВИ книжных, добавляя такие как: "Выпить чашечку кофе", "Навербовать новых членов в партию", "Улучшить жизнь в сельской местности", "Спереть книгу, а потом продать обратно" и проч. столь же невообразимые.

+1