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