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

×


СКУД в школе(Прочитано 61405 раз)
Re: СКУД в школе Ответ #90 : 21 Ноября 2013, 23:58:58
В задании четко поставлена задача - описать процесс получения доступа в виде активити диаграммы.
Tinner, в задании не менее чётко поставлена и другая задача "Предоставить use case diagram". DeepShadow начал с этого задания, а активити-диаграмму мы пока не обсуждали.

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

- Детализация может быть разной в разных диаграммах, в зависимости от цели создания конкретной модели.
Это не вопрос детализации, а вопрос замусоривания диаграммы неспецифическими для неё элементами. Use Case модель это способ представления функциональных требований к системе. Зачем на диаграмме нужны лишние экторы или ВИ если они не будут реализованы в системе?

- UML - не язык сбора и фиксирования требований, а язык моделирования
Из книги G. Booch, J. Rumbaugh, and I. Jacobson, 1998. UML User Guide:
"A language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system"
Этим авторам я больше верю.

Соответственно, отойдя от Коберна и компании, которые используют лишь малую часть UML в очень ускоспециализированном контексте
Что по Вашему "Малая часть UML" и "узкоспециализированный контекст"? Я лишь говорил о том, что у Коберна сама система упоминается как действующее лицо, но разрабатывамая система не является эктором и не отображается на диаграмме ВИ.
Цитата из RUP про эктора: "This artifact defines a coherent set of roles that users of the system can play when interacting with it"
То есть по определению сама система не является эктором.



Re: СКУД в школе Ответ #91 : 22 Ноября 2013, 03:29:18
Tinner, в задании не менее чётко поставлена и другая задача "Предоставить use case diagram". DeepShadow начал с этого задания, а активити-диаграмму мы пока не обсуждали.
Моя диаграмма на 2 странице, ее самой первой обсуждали. Главная задача отобразить процесс когда кто нибудь пытается получить доступ и думаю моя диаграмма отображает это, с учетом всех нюансов сценария



Re: СКУД в школе Ответ #92 : 22 Ноября 2013, 17:59:41
Состояния можно придумать для многих предметов типа провода, который питает считыватель или дверной замок. Проблема в том что диаграмма ВИ даёт общий обзор функциональных требований к системе и подобные предметы на ней не должны упоминаться.

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

Это не вопрос детализации, а вопрос замусоривания диаграммы неспецифическими для неё элементами. Use Case модель это способ представления функциональных требований к системе. Зачем на диаграмме нужны лишние экторы или ВИ если они не будут реализованы в системе?
Снова, при чем здесь UC и варианты использования?

Из книги G. Booch, J. Rumbaugh, and I. Jacobson, 1998. UML User Guide:
"A language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system"
Этим авторам я больше верю.

Не вижу противоречия =) Модель, написанная на языке UML для всего этого и предназначена. А вообще я больше верю своим глазам, чем авторам, какими бы именитыми они не были. И какой бы хорошей не была задумка, когда начинали разрабатывать сам язык UML, он сейчас используется иначе.

Что по Вашему "Малая часть UML" и "узкоспециализированный контекст"? Я лишь говорил о том, что у Коберна сама система упоминается как действующее лицо, но разрабатывамая система не является эктором и не отображается на диаграмме ВИ.
Цитата из RUP про эктора: "This artifact defines a coherent set of roles that users of the system can play when interacting with it"
То есть по определению сама система не является эктором.

Прошу указать мне место, где я на диаграмме ВИ предлагаю использовать эктора "Система". Я считаю это большой проблемой аналитиков, зашоренность во взглядах: Если UML, то обязательно ДВИ и фиксация и выявление требований. Применяется UML для описания системы в целом. Есть замечательная книжка Uml 2 and unified process, в котором описано применение UML на всех стадиях разработки ПО, а не только при анализе, надеюсь ее прочтение расширит кругозор.



Re: СКУД в школе Ответ #93 : 22 Ноября 2013, 21:46:32
Например на диаграмме уважаемого DEEPshadow не показан случай, когда карту не удалось считать, кто из вас ни разу не прикладывал не ту карту в метро или не пытался открыть дверь неправильным магнитным ключом?
Это я уже добавил, просто не выложилю После действия прочитать карту, у меня идет decision mode - не удалось прочитать карту и на access deny, else и далее как указано.

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




Re: СКУД в школе Ответ #94 : 23 Ноября 2013, 12:57:57
Прошу не путать активити и ДВИ.
Прошу извинить. Неверно понял о чём речь.

А вообще я больше верю своим глазам, чем авторам, какими бы именитыми они не были.
Есть замечательная книжка Uml 2 and unified process, в котором описано применение UML на всех стадиях разработки ПО, а не только при анализе, надеюсь ее прочтение расширит кругозор.
Значит Джиму Арлоу и Айле Нейштадт вы доверяете больше? Несомненно книга очень полезная, но в чём они не соглашаются с создателями UML и RUP?

Прошу указать мне место, где я на диаграмме ВИ предлагаю использовать эктора "Система". Я считаю это большой проблемой аналитиков, зашоренность во взглядах: Если UML, то обязательно ДВИ и фиксация и выявление требований. Применяется UML для описания системы в целом. Есть замечательная книжка Uml 2 and unified process, в котором описано применение UML на всех стадиях разработки ПО, а не только при анализе, надеюсь ее прочтение расширит кругозор.
Исходя из данной цели, предлагаю пройтись по заданию:Для именно этого кейса, исходя из цели моделирования, правильно будет определить 4 действующих лица:
  • Субъект, пытающийся получить доступ
  • Карт ридер
  • Система
  • Дверь (турникет и т.п.)
Вы предлагаете выделить элементы с разных уровней абстракции и назвать их действующими лицами. Какими деятельностями на диаграмме деятельности будут заниматься дверь с карт ридером?



Re: СКУД в школе Ответ #95 : 25 Ноября 2013, 10:57:42
Например на диаграмме уважаемого DEEPshadow не показан случай, когда карту не удалось считать, кто из вас ни разу не прикладывал не ту карту в метро или не пытался открыть дверь неправильным магнитным ключом?

А вот это как раз совершенно не важно, почему доступ не получен.
А вдруг клиент приложил к считывателю ботинок, а не карту? Это совершенно лишняя, мусорная, информация, которая усложнит восприятие.
и отображаться она не должна, т.к. сам ВИ "use swipe card" уже предполагает что клиент приложил нужную карту.
Что клиент прикладывал к ридеру до этого (проездной от метро или ботинок) не имеет значения, т.к. НЕ на карту ридер не сработает.




 

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