Форум Сообщества Аналитиков

×


СКУД в школе(Прочитано 61501 раз)
Re: СКУД в школе Ответ #75 : 14 Ноября 2013, 14:39:08
Это я так хотел отразить, если студент потерял карту или проблемы с картой. Но видимо это не нужно здесь
Да, потеря карты происходит за рамками рассматриваемой системы

Цитировать
В итоге, вот что получилось. Но из выбранных мною main use cases, я потерял using swipe card reader. Или это не нужно отображать?
Вариант использования - это некое минимальное действие которое пользователь выполняет с целью получить пользу. Т.е. человек прикладывает карту к датчику не для того, чтобы послушать как он круто пикает и моргает зеленым глазом, а чтобы пройти куда ему надо. По этому "Доступ в кабинет" - это вариант использования, а "использование карт ридера" - уже нет.



Re: СКУД в школе Ответ #76 : 14 Ноября 2013, 14:53:29
По этому "Доступ в кабинет" - это вариант использования, а "использование карт ридера" - уже нет.
Тогда что мне еще нужно добавить в use case diagram? Мне она кажется какой то незаконченной



Re: СКУД в школе Ответ #77 : 14 Ноября 2013, 15:02:59
Теперь, когда мы убрали лишнее, можно вернуть отправку отчетов (которая инициируется тем самым "временем"), т.к. это полноценная часть системы.
И получится на мой взгляд полная ДВИ со всеми участниками.
Т.е. диаграмма будет включать 4 варианта использования:
1. Доступ в кабинет (эктор - пользователь)
2. Сохранение данных о доступе (включается в ВИ "доступ в кабинет")
3. Управление картами (эктор - менеджер)
4. Отправка ежемесячного отчета (эктор -  "время")



Re: СКУД в школе Ответ #78 : 16 Ноября 2013, 15:42:31
Теперь, когда мы убрали лишнее, можно вернуть отправку отчетов (которая инициируется тем самым "временем"), т.к. это полноценная часть системы.
И получится на мой взгляд полная ДВИ со всеми участниками.
Т.е. диаграмма будет включать 4 варианта использования:
1. Доступ в кабинет (эктор - пользователь)
2. Сохранение данных о доступе (включается в ВИ "доступ в кабинет")
3. Управление картами (эктор - менеджер)
4. Отправка ежемесячного отчета (эктор -  "время")

Выходит так (решил все таки добавить экторов для ясности)



Re: СКУД в школе Ответ #79 : 18 Ноября 2013, 02:06:31
кстати, пока занимаюсь use case specification, хотелось услышать мнение о class diagram



Re: СКУД в школе Ответ #80 : 19 Ноября 2013, 01:14:46
Народ, опомнитесь! Что ж вы делаете с бедным студентом!? =)

Итак, начну с общего - модель всегда должна соответствовать цели ее создания. Цель, если я правильно ее понимаю, продемонстрировать знание нотации UML и понимание ее роли при проектировании ПО.


Исходя из данной цели, предлагаю пройтись по заданию:
Цитировать
1. Создать activity diagram для описания что произойдет когда кто нибудь попробует получить доступ к одной из зон школы, которая оснащена свайп карт ридером.
Для именно этого кейса, исходя из цели моделирования, правильно будет определить 4 действующих лица:
  • Субъект, пытающийся получить доступ
  • Карт ридер
  • Система
  • Дверь (турникет и т.п.)

Соответственно необходимо создать 4 дорожки, в которой описать действия каждого из акторов данного кейса в четком следовании нотации UML.

Начало Activity диаграммы во вложении. Можно дополнить дополнительными проверками, например если у нас турникет а не дверь - можно зафиксировать факт прохода, и дополнить проверку доступа нашим знанием о местоположении субхекта (осуществлял он ранее проход или нет - например по своей карте пытается провести в закрытую зону еще несколько человек, а регистрация более 3 входов и выходов в течении 5 минут может быть поводом об оперативном информировании службы безопасности) - тут уже можно фантазировать, поскольку данные моменты не оговорены в задании.

Цитировать
2. Предоставить use case model для NSAC системы описываемой сценарии из 1 сообщения.
  а. Определить main use cases
  b. Предоставить use case diagram. Она должна включать систему, actors, use cases а так же внутренние и внешние связи (include, extend), так же как и use case and/or actor generalisation в вашей диаграмме.
  с. Разработать use case спецификации описывающий процесс когда свайп карта была создана для нового сотрудника, который устроился в школу. Если ваша диаграмма содержит больше чем 1 use case для достижения требуемого, тогда опишите для всех их. Это означает, что вы должны описать внешние и внутренние use cases.

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

Тут необходимо подчеркнуть, что UML - язык очень формальный. Если чего-то не указано на диаграмме, то в контексте диаграммы этого просто не существует.

Цитировать
3. Разработайте class diagram для вашей системы. Включая атрибуты, операторы, ассоциации, множественность (miltiplicities).
Тут могу посоветовать выписать все сущности из задания и довести до минимализма (в буквальном смысле перечитать задание и подчеркнуть все существительные) и исходить из этого. Задание действительно сложное, лучше уточнить у преподавателя, будет ли здесь оцениваться полнота покрытия задания, или правильность использования UML

По текущей диаграмме очень много замечаний. Советую вслух проговорить все что описано на диаграмме, с учетом формальности языка. Например 2 класса сверху слева: У каждой персоны может быть 1 карта. У каждой карты есть от 1 до бесконечности владельцев (бред!).

Не забудь о том, что записи можно изменять, а не только создавать и удалять. Добавь CRUD для карт. Точка доступа это сама дверь или карт ридер?? Где логи? Слишком мудришь с сотрудниками и студентами (пытаешься сразу объять необъятное), лучше оставить только класс Persona, и перенести в нее атрибут privilege level - сотрудник, школьник и т.п.
« Последнее редактирование: 19 Ноября 2013, 01:17:37 от Tinner »



Re: СКУД в школе Ответ #81 : 19 Ноября 2013, 09:43:56
Для именно этого кейса, исходя из цели моделирования, правильно будет определить 4 действующих лица:
  • Субъект, пытающийся получить доступ
  • Карт ридер
  • Система
  • Дверь (турникет и т.п.)
Tinner,
  • Считыватель карт это не эктор, т.е. не элемент требований, а компонент реализации (часть системы), который должен образоваться по результатам проектирования системы или как ограничение на реализацию.
  • Система не является эктором. Эктор по определению это тот, кто находится за пределами Системы и взаимодействует с ней
  • Дверь (турникет и т.п.) это тоже не эктор. Дверь это не унаследованная система, с которой наша Система может обмениваться информацией.

Тут могу посоветовать выписать все сущности из задания и довести до минимализма (в буквальном смысле перечитать задание и подчеркнуть все существительные) и исходить из этого.
Подчёркнутые сущности не обязательно покроют все потребности задачи, а некоторые подчёркнутые сущности могут оказаться лишними. Нужно исходить из того какие события мы хотим фиксировать, а уже потом какие сущности будут связаны с этими событиями.



Re: СКУД в школе Ответ #82 : 19 Ноября 2013, 10:14:35
Для именно этого кейса, исходя из цели моделирования, правильно будет определить 4 действующих лица:
  • Субъект, пытающийся получить доступ
  • Карт ридер
  • Система
  • Дверь (турникет и т.п.)
Если довериться Коберну, то можно назвать Систему "действующим лицом". Главное не запутать человека чтобы он не изобразил человечка с именем "Система" на диаграмме ВИ.



Re: СКУД в школе Ответ #83 : 19 Ноября 2013, 13:59:10
  • Считыватель карт это не эктор, т.е. не элемент требований, а компонент реализации (часть системы), который должен образоваться по результатам проектирования системы или как ограничение на реализацию.
  • Система не является эктором. Эктор по определению это тот, кто находится за пределами Системы и взаимодействует с ней
  • Дверь (турникет и т.п.) это тоже не эктор. Дверь это не унаследованная система, с которой наша Система может обмениваться информацией.

В задании четко поставлена задача - описать процесс получения доступа в виде активити диаграммы. У приведенных мной сущностей есть состояния действий, которые можно отобразить на диаграмме. Тогда почему, в данном контексте нельзя на диаграмме отобразить их на отдельных дорожках?
Напоминаю:
 - Конечная цель - не создать модель всей системы в целом (кроме определения main use cases), а выполнить конкретные задания курсового.
 - Детализация может быть разной в разных диаграммах, в зависимости от цели создания конкретной модели.
 - UML - не язык сбора и фиксирования требований, а язык моделирования, а модель может отражать часть требований к системе, но никак не наоброт.
 - Главная цель UML (то, во что она со временем вылилась, и единственная реальная, которую я встречал в жизни) - это обеспечение одинакового понимания задачи всей командой проекта. Соответственно, отойдя от Коберна и компании, которые используют лишь малую часть UML в очень ускоспециализированном контексте, прошу указать мне, чем мое предложение по реализации Активити диаграммы плохо?
Прошу поправить меня, если я не прав, заранее спасибо.



Re: СКУД в школе Ответ #84 : 19 Ноября 2013, 17:38:02
По текущей диаграмме очень много замечаний. Советую вслух проговорить все что описано на диаграмме, с учетом формальности языка. Например 2 класса сверху слева: У каждой персоны может быть 1 карта. У каждой карты есть от 1 до бесконечности владельцев (бред!).
Не забудь о том, что записи можно изменять, а не только создавать и удалять. Добавь CRUD для карт. Точка доступа это сама дверь или карт ридер?? Где логи? Слишком мудришь с сотрудниками и студентами (пытаешься сразу объять необъятное), лучше оставить только класс Persona, и перенести в нее атрибут privilege level - сотрудник, школьник и т.п.
Я хотел написать что у каждой персоны есть 0 или 1 карта, видимо не правильно отобразил.
AccessPoint это сама дверь, т.е это parent class и из него уже идут sub classes door and gates
Опять же, мудрю с классом Person потому что препод хочет увидеть как мы используем parent class и дочерние классы, поэтому его так и отобразил.
Да, сейчас тогда карт ридер добавлю и запись событий
CRUD как я понял нужно просто добавить в operations класса Card?
Цитировать
Начало Activity диаграммы во вложении
Немного не понял что делает ромб слева, под Прикладыванием карты. Обычно же либо объединение либо decision mode, а у вас как то 2 в 1.
В принципе все доп действия можно оставить за рамками системы, как я у препода узнавал про изменение прав доступа к зона в use cases и она сказала не делать это, считать это все установлено за пределами нашей системы. В этом случае и ваша и моя activity diagram должны подходить под задание



Re: СКУД в школе Ответ #85 : 19 Ноября 2013, 18:12:26
Вопрос на засыпку: я правильно понимаю из диаграммы, что HR и Security не являются сотрудниками школы, и доступ им никуда не нужен?
Тут я немного напутал, HR и Student Service Center - actors, они скорее всего являются сотрудниками школы и доступ им нужен, но это не описывается в сценарии. Я думаю в моем случае это просто место, где получают карты



Re: СКУД в школе Ответ #86 : 19 Ноября 2013, 18:50:06
Сейчас опять наверное скажете, что зря я добавил Эктора Аналитика=) Но при написании specification понял что он мне нужен, чтобы был весь процесс куда идет отчет и для чего.


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



Re: СКУД в школе Ответ #87 : 20 Ноября 2013, 09:58:58
Сейчас опять наверное скажете, что зря я добавил Эктора Аналитика=) Но при написании specification понял что он мне нужен, чтобы был весь процесс куда идет отчет и для чего.
Конечно зря:)
Судя по постановке задания, отчеты отправляются в какие-то там другие отделы. Их анализ не происходит в рассматриваемой системе, так что и юз кейс "Analyze report data" и эктор "Analyst" лишние.
Как я понимаю есть желание упомянуть систему в которую уходят отчеты. В таком случае надо во вторичных экторах добавить эту систему, назвать можно как угодно, но это будет именно система (а не прямо в мозг аналитику отправляешь:)) и связать ее с юз кейсом "Send Report to departments"



Re: СКУД в школе Ответ #88 : 20 Ноября 2013, 14:56:10
Как я понимаю есть желание упомянуть систему в которую уходят отчеты. В таком случае надо во вторичных экторах добавить эту систему, назвать можно как угодно, но это будет именно система (а не прямо в мозг аналитику отправляешь:)) и связать ее с юз кейсом "Send Report to departments"
Да, просто при use case specification получается не полная картина без того куда и зачем отправляется отчет. Хорошо, подумаю как систему назвать. В голове только 2 вещи вертятся, это почтовый эктор(Если считать что отправка отчета идет по почте) или так и назвать Система анализа данных.

Что думаете по поводу class diagram? правильно ли я связал cardReader и AccessPoint? или нужно еще с чем то связать?
Спасибо за помощь!



Re: СКУД в школе Ответ #89 : 21 Ноября 2013, 16:45:13
-
« Последнее редактирование: 21 Ноября 2013, 17:55:58 от DEEPshadow »




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19