106

UML SysML и пр. / Re: Характерные ошибки use case диаграммы

« : 30 Сентября 2014, 17:20:52 »

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

Ну,  если бы надо было описать такое ВИ в спецификации,  это выглядело бы примерно так:

1. Требуется реализовать функционал управления расписанием занятий.
  1.1 Требования к функционалу менеджера расписаний.
    1.1.1 Контроль прав доступа к функционалу менеджера расписаний.
    1.1.2 Макет менеджера расписаний.
  1.2. Требования к созданию расписания.
    1.2.1 Правила заполнения формы расписания.
    1.2.2 Контроль ввода значений в форме расписания.
    1.2.3 Сохранение нового расписания.
  1.3. Требования к редактированию расписания.
    1.2.1 Правила редактирования формы расписания.
    1.2.2 Контроль ввода значений в форме расписания.
  1.4 Требования к удалению расписания.
  1.5 Требования к печати расписания.
    1.5.1 Макет печатной формы расписания.
  1.6 Требования к логированию добавления/изменения расписания.
  1.7 Требования к оповещению участников нового/измененного расписания.

Описание пошаговое потоков делать не буду, долго:)

107

UML SysML и пр. / Re: Характерные ошибки use case диаграммы

« : 30 Сентября 2014, 14:32:49 »

Ага, спасибо.

А как на Ваш взгляд (ну технически) будет выглядеть ВИ "управление расписанием", например?

Смотря что подразумевать под "технически"
Помимо описания основных и альтернативных потоков ВИ, я бы еще добавил прототип интерфейса работы с ВИ. Т.к. ценю наглядность, а прототип как раз и указывает на очевидно необходимый функционал.

Например как-то так:

108

UML SysML и пр. / Re: Характерные ошибки use case диаграммы

« : 30 Сентября 2014, 13:11:29 »

На самом деле никаких явных рекомендаций по использованию/не использованию CRUD я не давал. Предполагается по правилам игры, что знания у них есть (3 и 4 курсы), и сейчас они эти знания должны применять.

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

Могу ошибиться, но тут возможно студенты пошли по пути "чем больше - тем лучше", наделать кучу ВИ в надежде что какие-то окажутся верными.

Лично я, компоновал бы CRUD действия в один ВИ по типу "управление пользователями", "управление расписанием" - если эти ВИ доступны/ не доступны всем акторам одинаково.
Если же, например, кому-то доступно выставление оценок, а кому-то только просмотр, то разделял бы в разные ВИ

Но должен оговориться: если я чего-то не понимаю, это не означает, что это что-то неправильно. Если у кого-то include и extend эффективно используются, то это прекрасно.

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


PS: Простите что вернулся к теме банкомата:)

109

UML SysML и пр. / Re: Характерные ошибки use case диаграммы

« : 29 Сентября 2014, 12:49:38 »

Что скажет почтенная публика?

А все действия типа выставить/изменить/удалить они показывают как CRUD или каждое отдельным ВИ?

110

Примеры / Re: use case и диаграмма последовательноси работы парикмахерской

« : 29 Сентября 2014, 11:01:16 »

Уважаемые знатоки, покритикуйте пожалуйста. Заранее благодарю.

Добрый день!

А на UML вы сами решили делать или вас заставил кто?

111

Примеры / Re: Здравствуйте помогите пожалуйста !!

« : 24 Сентября 2014, 09:24:28 »

Судя по времени поста, набросить не удалось:)

112

IDEF ARIS BPMN и пр. / Re: Считать ли электроэнергию и пар - механизмом

« : 23 Сентября 2014, 09:03:38 »

Я ставлю эксперимент. Может он будет не удачен, но конечно, технологический процесс нужно забыть и перейти к информационным.

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

113

Примеры / Re: Use case диаграмма снятия денег в банкомате

« : 18 Сентября 2014, 09:31:54 »

Во втором сообщении этой темы Дима привёл пример диаграммы ВИ, в котором общее поведение выделено в два ВИ. Сообщение davvol я воспринял как критику такого решения

Мое сообщение относилось к исходной диаграмме, т.к. там реально один вариант использования (снять деньги) растянут на диаграмму бесполезных действий.
О чем я, собственно, и написал в том сообщении:)

К диаграмме во втором сообщении оно не имело отношения.

114

IDEF ARIS BPMN и пр. / Re: Считать ли электроэнергию и пар - механизмом

« : 16 Сентября 2014, 10:13:11 »

Доброе утро!
Насколько я знаю IDEF0, в центре всегда должен быть процесс. А на мой взгляд, "термофиксационная камера" это не процесс, а механизм.

Я бы представил это так:

Процесс:
  Термофиксация краски

Вход:
 Ткань
 Краска
 Пар

Выход:
 Окрашенная ткань

Управление:
 Технологическая схема процесса

Механизмы процесса:
 Термофиксационная камера

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

115

Примеры / Re: Use case диаграмма снятия денег в банкомате

« : 16 Сентября 2014, 10:00:08 »

Имхо "снятие денег в банкомате" - уже вариант использования сам по себе.
Не надо делать из него диаграмму бесполезных действий.
Так что тут или расписывать теперь основной и альтернативные потоки или уточнять другими диаграммами.

116

Примеры / Re: UML диаграммы по BPMN

« : 12 Сентября 2014, 09:05:10 »

А вот что получилось с Диаграммой последовательности!

Вижу что с предложением использовать диаграмму последовательности я поторопился:)
Но тут, пожалуй, моя вина. Для всей предполагаемой системы, диаграмма последовательности будет выглядеть слишком громоздкой. Обычно такую диаграмму делают для каждого варианта использования отдельно.

Но тем не менее, обратите внимание на компоненты этой диаграммы. У вас получается что система состоит из кучи интерфейсов (кружок с палкой слева), которые сами себя заполняют и оплачивают. При этом нет ни одного класса-контролера, который управлял бы событиями и ни одной сущности, которая хранила бы внутренние данные.
Здесь на сайте есть небольшая библиотека, используйте ее как справочный материал по нотации.
http://www.uml2.ru/books/5.-%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5/UML/

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

117

Примеры / Re: Программа архиватор. Описание требований. Правильно ли я делаю?

« : 11 Сентября 2014, 17:34:59 »

Необходимо разработать архиватор для работы с ZIP архивами. Постановщик требований, аналитик, архитектор, программист - это все я.
 

Хорошо, делайте, а мы посмотрим:)

118

Примеры / Re: UML диаграммы по BPMN

« : 11 Сентября 2014, 17:19:48 »

В начале я пробовал использовать IDEF. Вот что из этого получилось...

Понятно:)

119

Примеры / Re: UML диаграммы по BPMN

« : 11 Сентября 2014, 09:07:53 »

Приходный кассовый орден – служит для учета зачислений наличных денежных средств. То есть оплата от поставщика.
Расходный кассовый ордер – назначен для учета выплаты наличных денежных средств из операционной кассы компании. То есть для оплаты поставщику.
Или не стоит их использовать?

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

Вообще, для описания реальной бизнес-деятельности "как есть", если не брать уже упомянутый BPMN, я бы использовал IDEF0. Но это, конечно, только мое предпочтение. Раз вам дали задачу делать в UML - делайте в UML:)

Если цель стоит описать (а создавать его будут разработчики) АРМ менеджера по продажам средствами UML, я бы рекомендовал вам пойти следующим путем:
1. Перенесите имеющиеся BPMN схемы в диаграмму последовательности.
2. По этой схеме определите все активности в которых участвует менеджер.
3. Из кучи активностей выберете те, которые можно автоматизировать (например, окажется что с "выполнением поставленной задачи" все неоднозначно, а доставка вообще в пролете)
4. Постройте диаграмму ВИ с описаниями основных и альтернативных потоков
5. На основании ДВИ можно уже сделать диаграмму классов. Хотя это и не обязательно.

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

Полностью согласен:)

120

Примеры / Re: UML диаграммы по BPMN

« : 10 Сентября 2014, 15:19:26 »

Можно и так, в принципе.
Теперь, давайте подумаем о пользе. ВИ - это что-то приносящее пользу актору.
Разве приносит пользу выбор заказа покупателя сам по себе?
Разве есть польза в оформлении накладной?
Да и вообще, разве менеджер выбирает товар? Ведь покупатель уже сделал это.
Везде фигурирует счет на оплату, а сама оплата нет. Раз мы моделируем жизнь нашего менеджера, то где же деньги?
По BPMN - счет на оплату делает поставщик. Почему внезапно на ДВИ эта деятельность отнесена к менеджеру?

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

Покупатель:
1. Делает заказ
2. Платит за заказ
3. Получает заказ

Менеджер:
1. Оформляет заказ поставщику на основе заказа покупателя
2. Оплачивает заказ поставщику
3. Получает товар от поставщика
4. Выставляет счет покупателю
5. Выдает товар

Поставщик: Он явно пассивный актор, никих ВИ он не инициирует.

Если бы я по этим вводным делал ВИ, то получилось бы примерно вот как во вложении. Здесь конечно много условностей, но надеюсь ход мыслей, как использовать диаграмму вариантов использования, будет понятен:)