106

Задачи студентов / Re: Диаграммы UML для Библиотеки

« : 24 Декабря 2013, 22:39:14 »

Возможно вы уже ознакомились с этим разделом форума. Тогда вы должны знать что бесплатно делать за Вас вашу работу, без каких либо усилий с Вашей стороны, вряд ли кто-то будет. Давайте для начала разберемся какие именно две диаграммы уже готовы. Обнародуйте.

107

Проектирование / Re: Archimate: примеры использования

« : 12 Декабря 2013, 18:50:15 »

Друзья.

Я начинаю проект по разработке курса Архитектура информационных систем. Узнал о языке архитектурных описаний Archimate.
Примерно как мы делаем это с использованием UML и иных нотаций.

Что скажите?

Эдуард, добрый вечер! Тема интересная. А по каким критериям был выбран именно Archimate, а не упомянутый UML или что-то другое? Чем он лучше для обучения студентов?

108

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

« : 23 Ноября 2013, 12:57:57 »

Прошу не путать активити и ДВИ.

Прошу извинить. Неверно понял о чём речь.

А вообще я больше верю своим глазам, чем авторам, какими бы именитыми они не были.

Есть замечательная книжка Uml 2 and unified process, в котором описано применение UML на всех стадиях разработки ПО, а не только при анализе, надеюсь ее прочтение расширит кругозор.

Значит Джиму Арлоу и Айле Нейштадт вы доверяете больше? Несомненно книга очень полезная, но в чём они не соглашаются с создателями UML и RUP?

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

Исходя из данной цели, предлагаю пройтись по заданию:Для именно этого кейса, исходя из цели моделирования, правильно будет определить 4 действующих лица:

• Субъект, пытающийся получить доступ
• Карт ридер
• Система
• Дверь (турникет и т.п.)

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

109

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

« : 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"
То есть по определению сама система не является эктором.

110

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

« : 19 Ноября 2013, 10:14:35 »

Для именно этого кейса, исходя из цели моделирования, правильно будет определить 4 действующих лица:

• Субъект, пытающийся получить доступ
• Карт ридер
• Система
• Дверь (турникет и т.п.)

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

111

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

« : 19 Ноября 2013, 09:43:56 »

Для именно этого кейса, исходя из цели моделирования, правильно будет определить 4 действующих лица:

• Субъект, пытающийся получить доступ
• Карт ридер
• Система
• Дверь (турникет и т.п.)

Tinner,

• Считыватель карт это не эктор, т.е. не элемент требований, а компонент реализации (часть системы), который должен образоваться по результатам проектирования системы или как ограничение на реализацию.
• Система не является эктором. Эктор по определению это тот, кто находится за пределами Системы и взаимодействует с ней
• Дверь (турникет и т.п.) это тоже не эктор. Дверь это не унаследованная система, с которой наша Система может обмениваться информацией.

Тут могу посоветовать выписать все сущности из задания и довести до минимализма (в буквальном смысле перечитать задание и подчеркнуть все существительные) и исходить из этого.

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

112

Задачи студентов / Re: Вариант использования Создать меню

« : 15 Ноября 2013, 00:03:10 »

2. Если меню на указанную дату уже существует, то
2.1 Система сообщает менеджеру, что меню на указанную дату уже существует
2.2 Возврат к шагу 1 основного потока
3. Иначе

Если основной поток занимает больше 7-10 строк, я предпочитаю выносить даже мелкие ветвления в альтернативные потоки. Здесь можно было бы так сделать.
И ещё мне нравится стиль описания ветвлений, когда в точке ветвления (2) пишется что-то типа:
"1. Менеджер меню делает запрос на создание меню на определенную дату.
2. Система проверяет существование меню на указанную дату.
3. Система выводит новое меню с входящим в него списком стандартных блюд."
, а остальная часть ветвления выносится в альтернативный поток.

3.7 Система выводит блюда, относящиеся к данной категории.
3.8 Менеджер меню выбирает блюда из выбранной категории и при желании меняет цену.

Небольшое дополнение... В конце пункта 3.7 я бы дописал что-то типа ", в том числе их цену, заданную при формировании меню ранее", а в конце 3.8 ", а система сохраняет цену блюда". Иначе непонятно что за цену можно изменить, откуда она изначально берётся и появится ли изменённая цена при формировании меню в следующий раз?

3.9 Система отображает изменения.

Разве если менеджер изменит цену на экране, то это изменение может на нём не отобразиться? Или имеется ввиду что-то другое и нужно уточнить пункт?

4 Если менеджер меню желает сменить категорию блюда то система сохраняет выбранные блюда и возврат к шагу 3.6

Я бы написал после 3.5:
Пока Менеджер меню не инициировал сохранение меню, он имеет возможность:
- Инициировать смену категории блюд и выбрать одну из предложенных (возврат к 3.5). Если Менеджер меню выбирает категорию блюда, то Система выводит блюда, относящиеся к данной категории, в том числе их цену, заданную при формировании меню ранее.
- Выбрать блюда из заданной категории, при желании изменить их цену и добавить в меню.

И возврат не к 3.6, а к 3.5.

5 Если Менеджер меню хочет сменить тип меню то система сохраняет выбранные блюда и возврат к шагу 3.4

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

Альтернативные потоки:
...
Предусловия: Дата превышает текущую дату более чем на 14 дней.

Нужно указать где именно производится проверка на выполнение условия. На каком шаге и какого потока.

Альтернативные потоки:
...
Постусловия: возврат к вводу даты.

Это не постусловие, а описание поведения системы. Нужно указать с какого шага какого потока продолжается выполнение. А постусловие может отражать описание какого-то состояния некоего объекта, которое можно проверить.

- 1 по типу меню (который есть свойство блюда)

Как я понял прямой связи с блюдом не должно быть. Будет связь между типами меню и категориями многие-ко-многим и между категориями и блюдами (один-ко-многим или многие-ко-многим). Я не прав?

- 2 по категории (с учетом заданного порядка - от первых к напиткам) категория тоже свойство блюда.

Кем задан этот порядок и в каком порядке должны располагаться категории между первыми и напитками? Сначала салаты, а потом вторые или наоборот?

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

То есть в основном потоке написать что система не даёт задать дату, не соответствующую таким-то требованиям?

113

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

« : 12 Ноября 2013, 08:06:00 »

Да но были указаны ошибки в виду того что вы смотрели на систему, а не сценарий в целом и поэтому я не исправил.

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

Сервер. С этим пока еще думаю, просто в голову пока не пришло как назвать но смысл эктора ясен.

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

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

Вариант использования должен отражать одну услугу системы, которую пользователь от нее получает. Таких понятий как закрытый или открытый доступ на диаграмме быть не должно. Include и extend нужно использовать правильно и в ограниченном объеме.

114

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

« : 11 Ноября 2013, 23:58:04 »

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

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

115

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

« : 11 Ноября 2013, 23:48:04 »

Спасибо за советы, но меня смущает что препод просит описывать сценарий а не систему в use case diagram.

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

116

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

« : 11 Ноября 2013, 17:58:45 »

Того эктора, который осуществляет рассылку. Т.е. систему которая это делает.

Рассылку осуществляет наша система, но она не является эктором

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

Авторы книг расходятся во мнениях. Некоторые говорят что можно использовать эктора время (таймер), другие говорят что в качестве эктора надо применять того на ком будет лежать ответственность за инициацию ВИ. К примеру админ, который должен следить за тем чтобы отчёты сформировались и разослались правильно и вовремя. Такой подход используется, к примеру, в модели классического кейса "Payroll System" фирмы Rational.

Приведу ещё одну ссылку:)

5. если запуск по расписанию -> автоматически, т.е. по событию времени, таким образом это будет актор Время или Таймер.

117

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

« : 10 Ноября 2013, 16:23:33 »

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

Само поступление никак не будет автоматизироваться системой. В описании могло быть написано что перед получением карты студент заходит в школьную столовую выпить компот. Мы ведь не будем это автоматизировать?

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

В описании сказано что отчет отправляется для анализа, но не указано что система должна как-то помогать проанализировать отчет. Поэтому ВИ не нужен.

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

Почему так сильно хочется разбить? Какую пользу это принесет?

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

Не должно быть такого эктора. Это часть самой системы. Когда аналитик сформирует требования архитектор предложит как реализовать хранение информации о проходах. Не нужно залезать в область решения.

118

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

« : 10 Ноября 2013, 01:28:55 »

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

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

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

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

Ещё комментарии по диаграмме:
1. Из описания я понял что наша система не будет никак автоматизировать процесс анализа отчёта, поэтому ВИ "Анализ отчёта" не нужен. Или я ошибаюсь?
2. Имя ВИ обязательно должно начинаться с глагола (Swipe card reader).
3. На диаграмме не может присутствовать ВИ, который не связан ни с одним эктором (Swipe card reader).
4. Include наиболее полезно использовать когда один и тот же ВИ должен включаться в несколько других ВИ или должен повторяться в одном и том же ВИ несколько раз. В других случаях include я стараюсь не использовать.
5. Лучше уточнить название "Server".

Коллеги, выскажете своё мнение, следует ли выделять роли грузчик, уборщик? Если нет, в каком случае вы бы выделили такие роли?

119

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

« : 09 Ноября 2013, 02:19:03 »

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

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

2. swipe card я отобразил на диаграмме

будет не только создание, но и удаление, изменение прав доступа, просмотр информаци,  печать карт при создании. Предлагаю погуглить "CRUD Use Case". И еще что такое Join the NU и для чего оно? В ведении карт будет участвовать только администратор. Ученик/сотрудник в, это время будет стоять рядом и курить.

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

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

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

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

120

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

« : 09 Ноября 2013, 01:37:51 »

А выделил я старые и новые сотрудники/ученики, так как опять же мы так делаем на практике.

Сотрудник/ученик будет участвовать только в одном системном ВИ. Чем будет отличаться выполнение этого ВИ для старого и нового? Если ничем, то не нужно разделять роли.

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

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