16

Примеры / Re: СКУД в школе

« : 12 Ноября 2013, 01:34:32 »

Упомянутые ранее ошибки не исправлены и появились новые.

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

отношения между use case, вот в них не уверен. Особено в той части где идет проверка. Как отобразить закрытый доступ или открытый?
Вроде теперь все мои мысли должны быть вам понятны.

17

Примеры / Re: СКУД в школе

« : 11 Ноября 2013, 22:39:19 »

вот таким образом я изобразил сценарий через use case diagram а так же параллельно начал делать class diagram (use case specification пока пропустил, до того момента как с use case diagram разберусь)
В class diagram пока думаю как отразить время работы или может как то по другому это все надо отобразить?

18

Примеры / Re: СКУД в школе

« : 11 Ноября 2013, 21:34:52 »

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

19

Примеры / Re: СКУД в школе

« : 10 Ноября 2013, 03:38:04 »

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

Как раз в сценарии упоминается что карты генерируется при поступлении студента/сотрудника в школу. И препод сказал что нужно описывать все из сценария, включая студента.

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

Это уточню

Ещё комментарии по диаграмме:
1. Из описания я понял что наша система не будет никак автоматизировать процесс анализа отчёта, поэтому ВИ "Анализ отчёта" не нужен. Или я ошибаюсь?

Опять же, нужно описать все из сценария, поэтому он нужен

2. Имя ВИ обязательно должно начинаться с глагола (Swipe card reader).
3. На диаграмме не может присутствовать ВИ, который не связан ни с одним эктором (Swipe card reader).

Мой косяк, просто не знаю куда и с чем его связать

4. Include наиболее полезно использовать когда один и тот же ВИ должен включаться в несколько других ВИ или должен повторяться в одном и том же ВИ несколько раз. В других случаях include я стараюсь не использовать.

пока оставлю так, если смогу понять как их можно разбить без include то конечно попробую

5. Лучше уточнить название "Server".

Думаю назвать тогда Access Control Server, все таки инфа хранится в БД

20

Примеры / Re: СКУД в школе

« : 09 Ноября 2013, 03:39:13 »

Насколько ВИ должны быть "основными" чтобы заслужить право отображаться на диаграмме?

Такой ответ чтобы не подсказывать, если выбрал не все основные ВИ то и получу меньшее количество баллов)

будет не только создание, но и удаление, изменение прав доступа, просмотр информаци,  печать карт при создании. Предлагаю погуглить "CRUD Use Case".

Хорошо, спасибо учту.

И еще что такое Join the NU и для чего оно?

Это я взял из сценария, описание того что студент/сотрудник поступили на учебу/работу.

Первичным эктором будет время, а вторичным либо почтовый сервер, либо роль пользователя. По тому же принципу что я описал выше. Делать include ВИ стоит делать только если это упрощает модель. Здесь, по моему include неуместен.В ходе эксплуатации системы необходимо будет задавать атрибуты помещения, связанные с правами доступа, указанными в описании? Возможно нужно будет подключать/отключать контроль доступа в определенные зоны типа дня открытых дверей и прочего. Тогда нужен соответствующий ВИ.

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

21

Примеры / Re: СКУД в школе

« : 09 Ноября 2013, 01:28:11 »

Я бы выделил следующие ВИ:
1. Открыть проход
2. Ведение свайп-карт (CRUD)
3. Ведение считывателей (CRUD)
4. Рассылка отчёта

По поводу the main use cases это нужно перечислить основные, по моему мнению, ВИ которые должны быть отражены в диаграмме. Такой вот ответ от препода)

Теперь опять по вашим пунктам,
2. swipe card я отобразил на диаграмме
4. Рассылка отчета тоже добавил, но! какого actor мне надо использовать? Поэтому я вновь использовал время как эктора
3 пункт немного не ясен, я попробовал его отразить но получилась ерунда на мой взгляд

22

Примеры / Re: СКУД в школе

« : 08 Ноября 2013, 18:46:52 »

Тогда, если я всех студентов и работников отнесу в actors Member и департаменты по выдачи под Administrator то получу такую диаграмму.
Только теперь с вашими замечаниями я не могу понять как построить для прохода. Получается так же member будет участвовать в этом и мы используем просто ВИ открыть доступ?

23

Примеры / Re: СКУД в школе

« : 08 Ноября 2013, 18:32:30 »

DEEPshadow, начать можно с определения границ системы (экторов), а потом уже для каждого эктора определить какие услуги они будут получать от системы. Но в общем случае позже может найтись новый ВИ, который сложно будет отнести к существующим экторам. Тогда придётся вводить нового эктора.
Под main use cases видимо подразумеваются наиболее часто используемые. Возможно есть какие-то более чёткие критерии отделения "main" от "не main". Я бы уточнил у преподавателя.

Но если посмотреть на подпунк b, мы увидим что нужно описать все из сценария.
А выделил я старые и новые сотрудники/ученики, так как опять же мы так делаем на практике. Приведу пример use case для тренажерного зала. где actor может быть и почтовый сервер, время и тп. От этого я и отталкиваюсь

24

Примеры / Re: СКУД в школе

« : 08 Ноября 2013, 05:13:53 »

А какой смысл в actors без вариантов использования?
А те предложения, которые вы записали возможных main use cases, почему вы считаете, что это ВИ? Что вы понимаете под ВИ?

Ну я думал что сначала нужно продумать кто взаимодействует с системой, а потом уже как они взаимодействуют друг с другом.

Я понимаю под main use cases, те "варианты использования" которые бы описывали сценарий и без которых выполнение сценария не возможна. То есть в моем случае это выдача карты, механизм контроля доступа и отправка отчета для анализа. Если я как то понял не правильно поправьте меня.

Сейчас попробую накидать диаграмму

25

Примеры / Re: СКУД в школе

« : 07 Ноября 2013, 20:40:42 »

Я все таки решил оставить мою диаграмму, вск таки она более подходит для меня.
Сейчас я перешел ко 2 заданию, use case diagram. И под пунктом этого задания определить main use cases
Как я понял в моем случае это:
1. Получение карты студенту/сотруднику
2. Использование карты для доступа
3. Запись и отправка отчета для анализа

Ниже я привел actors для этой диаграммы. Как вы считаете, я что то упустил?

26

Примеры / Re: СКУД в школе

« : 07 Ноября 2013, 04:49:09 »

Пожалуй, будет достаточно первую активность назвать не "Use..." а "Read...". Тогда можно будет сказать: мы при чтении определили ее тип, и вип-уборщиков пропускаем без дальнейших проверок.

Что если просто добавить действие чтение после использования?
Вот так:

27

Примеры / Re: СКУД в школе

« : 06 Ноября 2013, 16:56:17 »

2. Эстетика. Ромб под проверкой прав опустить на уровень двух следующих и сменить точки входа стрелок в левый ромб.

Сделано.

Что такое "Save data"? Почему недостаточно "Record"?

Согласен, можно отнести все под запись действия. Просто разбил процесс, тем самым усложнив.

1. Отправка отчета Вам не нужна, это другой процесс.

хм, видимо вы правы. не понял задания, сейчас перечитал и отправка же 1 раз в месяц соответственно нам он не нужен по заданию. Спасибо.

Вот такой сейчас вариант

28

Примеры / Re: СКУД в школе

« : 06 Ноября 2013, 16:25:10 »

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

29

Примеры / Re: СКУД в школе

« : 06 Ноября 2013, 16:01:49 »

Постарайтесь обойтись вообще без ромбов. Они загромождают диаграмму, все необходимое можно отразить на дугах.

Дело в том что мы еще не прошли дуги, лекции построены на базе книжки System analyst and Design with UML (Alan Dennis) 4 издание. И в книге кучу примеров с огромным количеством ромбов, поэтому и на практике делали эти задания с таким же количеством)

Второе замечание по стилю. Не обязательно писать у "ромба" условие, а затем выводить лишь два потока

Хорошо, переделаю с вашими замечаниями.

Просто в книге описывается, как и вы говорите, с построения use case specification. Но у нас все как то наоборот, сначала мы строим диаграмму, по ней создаем use case diagram,  далее идет use case specification и в конце уже class diagram. В виду этого я поэтому так и делаю) Даже если вы посмотрите на задания, в каком порядке они идут то заметите что я начал по задачам курсовой.
Спасибо за время, сегодня сделаю тогда диаграмму только получения доступа. Отправку отчета и запись тогда отложу на попозже.

30

Примеры / Re: СКУД в школе

« : 06 Ноября 2013, 01:56:04 »

описание сценария как последовательность шагов.

хм, что то типо
При поступлении получить свайп карту в своем центре выдачи
Получить доступ к помещению? что то не очень понимаю как из такого текста последовательность сделать. Еще более менее понятно с use cases specifications, там уже сами действия описываешь. Но тут другая ситуация