Форум Сообщества Аналитиков
Общий раздел => Примеры => Тема начата: DEEPshadow от 05 Ноября 2013, 01:18:54
-
Добрый день!
Делаю курсовую по UML и нужно чтобы кто то указал на ошибки, т.к показать не кому.
Итак сам сценарий: Школа (NS) хочет внедрить систему контроля доступа в некоторые зоны. Хотят использовать свайп карты для контроля доступа к определенным зонам(на дверях).
Как я написал, некоторые входы будут оснащены свайп карт ридером, и если имеется карта то можно получить доступ в эту зону к которой пользователь имеет доступ и соответственно получить доступ в помещение. Иначе двери закрыты и доступа не будет.
NS предоставляет карты с фотографией и уникальным номером для множества людей которым требуется доступ к определенным зонам. Этими людьми могут быть ученики, преподаватели, администрация, охрана, грузчики. Эти карты выдаются тогда, когда ученик/работник поступает/устраивается в школу. Карта имеет срок истечения. Если карта была утеряна, она заменяется новой. Карты для учеников выдают в Student Service Сentre. Все другие карты выдаются в отделе HR.
Школа открыта по будням с 8 до 22. Все зоны должны быть доступны для грузчиков, уборщиков и охранникам в любое время. Тем не менее, другие держатели карт имеют доступ только с 8-22.
Некоторые из входов должны предоставлять доступ всем без исключения в течении рабочих часов. Примером такого доступа может быть главный вход или вход в библиотеку. Другие входа, с конфиденциальной информацией например, должны иметь ограничения для тех лиц кому дозволено заходить.
Использование свайп карт при входе в различные зоны записываются и на регулярной основе отправляются раз в месяц в отдел безопасности и в отдел обслуживания для различного анализа.
Итак пока вот сделал вот такую Activity Diagram (вложение)
-
Это диаграмма какого процесса?
Судя по вопросам, больше похоже на шуточную инфографику из интернета.
Чтобы указывать на ошибки, надо видеть задание.
Задание «попытайтесь изобразить нечто, имеющее отношение к тексту с использованием нотации UML, да так, чтобы было весело»?
-
Добрый день!
Делаю курсовую по UML и нужно чтобы кто то указал на ошибки, т.к показать не кому.
...
Итак пока вот сделал вот такую Activity Diagram (вложение)
Добрый день!
Во-первых, раз вы назвали свою работу "диаграммой деятельности", то нужно для начала определиться, какую деятельность надо моделировать, а не пихать все что можно в одну кучу.
Я предлагаю вам сделать так:
Исходя из выбранной деятельности, сначала продумать позитивный сценарий деятельности, а затем проработать все исключения, которые могут предотвратить позитивный сценарий. Ну и в конце добавить обработку исключений, чтобы участник этой деятельности не оказался в логическом тупике, при выполнении сценария.
А пока данный рисунок выглядит как попытка впихнуть невпихуемое:)
-
...нужно чтобы кто то указал на ошибки, т.к показать не кому.
Ошибки в UML в данном случае несущественны. Проблема на уровне моделирования.
Как уже порекомендовали, нужно "пересчитать" процессы и отрисовать для них отдельные диаграммы.
На глаз, там как минимум:
- выдача новой карты;
- замена утерянной;
- авторизация и учет проходов;
- отчетность в отдел кадров.
При разбивке на процессы, скорее всего, пропадет необходимость применения "ромбиков" проверки условий. Достаточно будет правильно названных дуг переходов от одной активности к другой.
Параллелить процессы, судя по сделанной попытке, вообще незачем. Например, регистрировать проход желательно по факту его предоставления, а не одновременно с. А ну как турникет не провернется?
-
А слона то и не приметил) Спасибо, как до софта доберусь - переделать попробую!
Задания следующие:
1. Создать activity diagram для описания что произойдет когда кто нибудь попробует получить доступ к одной из зон школы, которая оснащена свайп карт ридером.
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.
3. Разработайте class diagram для вашей системы. Включая атрибуты, операторы, ассоциации, множественность (miltiplicities).
-
А ну как турникет не провернется?
Простите, вопроса не понял. Можете перефразировать?
-
Простите, вопроса не понял. Можете перефразировать?
Что будет при параллельном выполнении задач "пропустить" и "отметить", если одна из них по каким-то причинам завершится неудачно? Отмечен, но не прошел? Прошел, но не отмечен?
-
Синхронизировать потоки после узла логического разветвления (верхняя линейка синхронизации) вряд ли удастся.
Концовка в правой части страдает симметричным недугом. Параллельные потоки объединяются логически перед финальным узлом. Это означает, что когда курсор управления минует левый поток, где Access, всё закончится, независимо от того, успели ли выполнить Record и Send a report.
Все мои замечания формального плана, т. к. неясно, что за сценарий Вы моделируете этой диаграммой.
-
Все мои замечания формального плана, т. к. неясно, что за сценарий Вы моделируете этой диаграммой.
Спасибо, сценарий описан в 1 сообщении.
Тогда попробую седня переделать все со всеми замечаниями.
-
Мне привычнее видеть описание сценария как последовательность шагов. Подобный текст бывает полезно составить перед тем как создавать диаграмму.
-
Итак, рассмотрев вновь задание сделал следующую диаграмму.
PS 1. Создать activity diagram для описания что произойдет когда кто нибудь попробует получить доступ к одной из зон школы, которая оснащена свайп карт ридером.
-
описание сценария как последовательность шагов.
хм, что то типо
При поступлении получить свайп карту в своем центре выдачи
Получить доступ к помещению? что то не очень понимаю как из такого текста последовательность сделать. Еще более менее понятно с use cases specifications, там уже сами действия описываешь. Но тут другая ситуация ???
-
хм, что то типо
При поступлении получить свайп карту в своем центре выдачи
Получить доступ к помещению? что то не очень понимаю как из такого текста последовательность сделать. Еще более менее понятно с use cases specifications, там уже сами действия описываешь. Но тут другая ситуация ???
DEEPshadow, я считаю было бы правильно если бы вы временно забыли о существовании диаграмм и последовали совету коллег. Сценарий использования описывается в виде последовательности шагов. Сценарий описывает получение эктором какого-то одного полезного результата (услуги). Каждый шаг описывает либо воздействие эктора на систему, либо реакцию системы на это воздействие. Такая последовательность шагов описывается в документе, который называется use-case specification. В принципе не важно как документ будет называться. Можете назвать его по своему вкусу если название будет соответствовать содержимому документа.
-
Прошел, но не отмечен?
Выбор профессионала!:)
Итак, рассмотрев вновь задание сделал следующую диаграмму.
PS 1. Создать activity diagram для описания что произойдет когда кто нибудь попробует получить доступ к одной из зон школы, которая оснащена свайп карт ридером.
На мой взгляд уже лучше, однако по прежнему много лишних элементов для одной активности.
Опять смешали две активности. Вход по карте и сохранение информации и отправку отчетов.
От этого, как упоминали коллеги ранее, синхронность некоторых процессов вызывает сомнения. Например, если новый месяц то получается, данные отправляем, но не сохраняем?
Или если новый месяц, то отправляем отчет в департамент после каждого прикладывания карточки?
PS: И да, как уже многие говорили, составьте последовательность шагов по пунктам на бумажке. Сразу станет яснее что за чем следует и как работает.
-
Итак, рассмотрев вновь задание сделал следующую диаграмму.
PS 1. Создать activity diagram для описания что произойдет когда кто нибудь попробует получить доступ к одной из зон школы, которая оснащена свайп карт ридером.
В дополнение к уже данным советам. Постарайтесь обойтись вообще без ромбов. Они загромождают диаграмму, все необходимое можно отразить на дугах.
Например, возьмем узел с проверкой прав доступа. Из этой активности мы переходим либо к пропуску, либо к запрету. Вот и попробуйте нарисовать три активности, соединив их дугами с названиями примерно "прав достаточно" и "прав недостаточно". И никаких ромбов. С остальными - аналогично.
-
Итак, рассмотрев вновь задание сделал следующую диаграмму.
Формальный недочёт -- если следовать стандарту UML2 узел Access Deny будет пытаться синхронизировать свои входящие потоки. Т. е. он сработает лишь тогда, когда курсор управления сверху и курсор управления слева дождутся друг друга. Что, наверно, никогда не наступит. Входящие потоки следует логически объединить перед этим узлом.
Второе замечание по стилю. Не обязательно писать у "ромба" условие, а затем выводить лишь два потока: "да"-поток и "нет"-поток. Из узла логического разветвления Вы можете вывести сколько угодно потоков и приписать им сторожевые условия.
Пример: (http://yuml.me/03dc5341.png)
-
Постарайтесь обойтись вообще без ромбов. Они загромождают диаграмму, все необходимое можно отразить на дугах.
Дело в том что мы еще не прошли дуги, лекции построены на базе книжки System analyst and Design with UML (Alan Dennis) 4 издание. И в книге кучу примеров с огромным количеством ромбов, поэтому и на практике делали эти задания с таким же количеством)
Второе замечание по стилю. Не обязательно писать у "ромба" условие, а затем выводить лишь два потока
Хорошо, переделаю с вашими замечаниями.
Просто в книге описывается, как и вы говорите, с построения use case specification. Но у нас все как то наоборот, сначала мы строим диаграмму, по ней создаем use case diagram, далее идет use case specification и в конце уже class diagram. В виду этого я поэтому так и делаю) Даже если вы посмотрите на задания, в каком порядке они идут то заметите что я начал по задачам курсовой.
Спасибо за время, сегодня сделаю тогда диаграмму только получения доступа. Отправку отчета и запись тогда отложу на попозже.
-
Дело в том что мы еще не прошли дуги, лекции построены на базе книжки System analyst and Design with UML (Alan Dennis) 4 издание.
Дугами я назвал обычные стрелки от одной активности к другой. Это не какие-то особые элементы.
И в книге кучу примеров с огромным количеством ромбов, поэтому и на практике делали эти задания с таким же количеством)
Раз в книге приведено с ромбами - рисуйте с ромбами (и пусть будет похоже на блок-схему). При приемке результата преподаватель тоже наверняка будет ориентироваться на эту книгу, так что подстраивайтесь под эстетические ожидания "заказчика".
Если когда-нибудь придется рисовать "боевые" модели-иллюстрации, имейте ввиду - чем меньшим количеством элементов удастся донести нужную информацию без потерь, тем лучше.
Отправку отчета и запись тогда отложу на попозже.
Запись результата попытки прохода должна быть.
-
Вот переделал диаграмму по последним замечаниям и по предоставленному примеру.
-
Вот переделал диаграмму по последним замечаниям и по предоставленному примеру.
если уже похоже на правду, нужно отдельно диаграмму для записи данных и отправки отчета сделать и потом их объединить?
1. Отправка отчета Вам не нужна, это другой процесс.
2. Эстетика. Ромб под проверкой прав опустить на уровень двух следующих и сменить точки входа стрелок в левый ромб. Модель получится симметричной.
Что такое "Save data"? Почему недостаточно "Record"?
-
2. Эстетика. Ромб под проверкой прав опустить на уровень двух следующих и сменить точки входа стрелок в левый ромб.
Сделано.
Что такое "Save data"? Почему недостаточно "Record"?
Согласен, можно отнести все под запись действия. Просто разбил процесс, тем самым усложнив.
1. Отправка отчета Вам не нужна, это другой процесс.
хм, видимо вы правы. не понял задания, сейчас перечитал и отправка же 1 раз в месяц соответственно нам он не нужен по заданию. Спасибо.
Вот такой сейчас вариант
-
Вот такой сейчас вариант
Осталось уязвимое место. Ветка "полного доступа" отрабатывает до проверки прав. Это не есть хорошо. Пожалуй, будет достаточно первую активность назвать не "Use..." а "Read...". Тогда можно будет сказать: мы при чтении определили ее тип, и вип-уборщиков пропускаем без дальнейших проверок.
-
лекции построены на базе книжки Systems analysis and Design with UML (Alan Dennis) 4 издание
Благодарю за ссылку, полистал. Действительно, авторы предлагают свою методику, в которой рисование диаграмм вариантов использования и описание ВИ относят к анализу. До этого я знал, что есть анжеро-судженский ООАП, теперь буду знать, что и в Индиане прогресс не стоит на месте.)
-
авторы предлагают свою методику, в которой рисование диаграмм вариантов использования и описание ВИ относят к анализу. До этого я знал, что есть анжеро-судженский ООАП, теперь буду знать, что и в Индиане прогресс не стоит на месте.)
Виктор, простите, может я такой же идиот из Индианы, но в чем проблема отнесении ВИ и ДВИ к стадии анализа?
-
Если когда-нибудь придется рисовать "боевые" модели-иллюстрации, имейте ввиду - чем меньшим количеством элементов удастся донести нужную информацию без потерь, тем лучше.
Наверное, Вы правы, но если я не ошибаюсь эстетика и прагматика спецификации UML2 предполагает использование decision и merge node для разделения и слияния потоков управления, типа в одну activity или action две стрелки входить не должны. Прагматика насколько я понимаю проистекает из того, что теперь понимается под диаграммой деятельности, а именно сеть Петри, а не вырожденная диаграмма состояний.
Но, могу заблуждаться.
-
Просто в книге описывается, как и вы говорите, с построения use case specification. Но у нас все как то наоборот, сначала мы строим диаграмму, по ней создаем use case diagram, далее идет use case specification и в конце уже class diagram. В виду этого я поэтому так и делаю) Даже если вы посмотрите на задания, в каком порядке они идут то заметите что я начал по задачам курсовой.
Спасибо за время, сегодня сделаю тогда диаграмму только получения доступа. Отправку отчета и запись тогда отложу на попозже.
Конечно, я не знаю, что Вам преподают и как, но есть такой довольно распространенный подход.
1. Изучив предметную область, построить диаграмму деятельности для описания бизнес-процесса (типично используют диаграммы BPMN)
2. Этапы такого бизнес-процесса выделяются и определяются как варианты использований
3. Совокупность вариантов использований и акторов, им соответствующих, образуют диаграммы ВИ
4. Каждый ВИ специфицируется до основного и альтернативных потоков
5. Для каждого ВИ возможно строится диаграмма классов, участников данного ВИ (обычно такие классы делать на сущностные, граничные и управляющие)
6. Частные диаграммы классов объединяются и образуют общую диаграмму классов
и т.п.
Может что-то подобное и в вашем случае?
-
Виктор, простите, может я такой же идиот из Индианы, но в чем проблема отнесении ВИ и ДВИ к стадии анализа?
Я никого не считаю идиотами, без шуток. Книга Коберна "Writing Effective Use Cases" на русский переведена как " Современные методы описания функциональных требований к системам". В рамках RUP и Open UP написание сценариев ВИ и составление диаграммы ВИ отнесены к процессу определения требований. В рамках Agile UP сценарии ВИ и диаграммы ВИ являются частью модели требований. Поэтому я привык соотносить ВИ и их диаграммы, и диаграммы деятельности, моделирующие ВИ, с требованиями, а не с анализом. В ходе анализа привычно выполнять реализацию ВИ, уточнять их описания. Сценарии и диаграмма ВИ + диаграммы деятельности для ВИ (в некотором, возможно не финальном своём состоянии) являются входными рабочими продуктами для процесса анализа.
Понятно, что ВИ, точнее бизнес-ВИ (бизнес-процессы) относятся к бизнес-моделированию. И Вы, конечно, правы, что сначала может быть составлена диаграмма деятельности, моделирующая бизнес-процесс, а затем диаграмма ВИ системы и их описания.
По привычке я счёл, что в задании требуется составить диаграмму деятельности для ВИ системы, а не для предприятия. Книгу просматривал бегло и, возможно, поторопился с выводами.
-
Пожалуй, будет достаточно первую активность назвать не "Use..." а "Read...". Тогда можно будет сказать: мы при чтении определили ее тип, и вип-уборщиков пропускаем без дальнейших проверок.
Что если просто добавить действие чтение после использования?
Вот так:
-
Что если просто добавить действие чтение после использования?
Вот так:
Если выделять отдельное действие, то тогда возникает вопрос, почему бы не сделать "классически"? То есть, сначала считать карту, а затем авторизовать ее по правилу "Тип карты" ИЛИ ("Время прохода" И "Локация").
В этом случае активность "Cheking" переместится на место "Read" и назовется "Authorize", а на выходе будет один ромб с тремя исходящими стрелками, две из которых уйдут в "Пропустить". Две - только если мы хотим для чего-то выделить карты с ограниченным доступом (например, если вскоре собираемся добавить туда какой-то специфический процесс). Иначе хватило бы и одной.
Наверное, Вы правы, но если я не ошибаюсь эстетика и прагматика спецификации UML2 предполагает использование decision и merge node для разделения и слияния потоков управления, типа в одну activity или action две стрелки входить не должны. Прагматика насколько я понимаю проистекает из того, что теперь понимается под диаграммой деятельности, а именно сеть Петри, а не вырожденная диаграмма состояний.
Но, могу заблуждаться.
Полагаю, что в контексте эстетики и прагматики UML правы именно Вы. Я практик, для меня UML - еще один хорошо проработанный комплекс нотаций, которыми я не пользуюсь ввиду их довольно ограниченной практической полезности. А вот модели рисовать доводится. И с точки зрения их восприятия человеком, чем меньше элементов задействовано для передачи нужной информации, тем быстрее и легче понимается модель.
-
Я никого не считаю идиотами, без шуток.
Виктор, простите мой моветон. Конечно, это просто оборот речи, некая эмоциональная краска.
Книга Коберна "Writing Effective Use Cases" на русский переведена как " Современные методы описания функциональных требований к системам". В рамках RUP и Open UP написание сценариев ВИ и составление диаграммы ВИ отнесены к процессу определения требований. В рамках Agile UP сценарии ВИ и диаграммы ВИ являются частью модели требований. Поэтому я привык соотносить ВИ и их диаграммы, и диаграммы деятельности, моделирующие ВИ, с требованиями, а не с анализом. В ходе анализа привычно выполнять реализацию ВИ, уточнять их описания. Сценарии и диаграмма ВИ + диаграммы деятельности для ВИ (в некотором, возможно не финальном своём состоянии) являются входными рабочими продуктами для процесса анализа.
Опять же, может я не прав (да и обсуждение темы оффтоп для данного треда), но разве сбор и описание требований не являются частью анализа - аналитической деятельности? Или Вы здесь вкладываете совершенно определенный смысл - создание аналитической модели и именно в контексте ООАД?
Понятно, что ВИ, точнее бизнес-ВИ (бизнес-процессы) относятся к бизнес-моделированию. И Вы, конечно, правы, что сначала может быть составлена диаграмма деятельности, моделирующая бизнес-процесс, а затем диаграмма ВИ системы и их описания.
На самом деле не утверждаю, что это обычный путь. Хотя некоторые так делают, я бы остановился на уровне просто БП, без перехода на бизнес-ВИ.
По привычке я счёл, что в задании требуется составить диаграмму деятельности для ВИ системы, а не для предприятия. Книгу просматривал бегло и, возможно, поторопился с выводами.
Насчет книги. Она не случайно называется системный анализ и проектирование с припиской с помощью UML. Т.е. тут описаны процессы системной инженерии, а UML лишь приложение. Может потому у Вас возник определенный диссонанс?
-
Поэтому я привык соотносить ВИ и их диаграммы, и диаграммы деятельности, моделирующие ВИ, с требованиями, а не с анализом. В ходе анализа привычно выполнять реализацию ВИ, уточнять их описания. Сценарии и диаграмма ВИ + диаграммы деятельности для ВИ (в некотором, возможно не финальном своём состоянии) являются входными рабочими продуктами для процесса анализа.
Довольно интересная точка зрения.
Тут все зависит от того что считать "анализом".
Ведь на входе у аналитика ни требования, ни ВИ и не диаграммы деятельности.
На входе у аналитика или какой-то бизнес-процесс, который надо исследовать, разложив на части, т.е. провести тот самый "анализ". Или же набор пожеланий клиента, который надо так же исследовать, чтобы разработать требования.
Как ни крути и ВИ и диаграммы - это результат анализа входных данных аналитиком.
А потом он продолжает с ними работать и разрабатывает требования.
Т.е. сначала аналитик анализирует входные данные для разработки понимаемой модели системы, а затем анализирует эту модель для разработки требований, необходимых для реализации данной модели.
-
Довольно интересная точка зрения.
Тут все зависит от того что считать "анализом".
Ведь на входе у аналитика ни требования, ни ВИ и не диаграммы деятельности.
Это не точка зрения. Это использование терминологии, связанной с некоторыми технологиями.
Аналитик не является участником анализа ни в RUP, ни в Open UP. Аналитик занимается работой с требованиями.
То, что Вы называете анализом в рамках указанных технологий называют работой с требованиями. Анализом там является моделирование эскизной архитектуры. Только и всего.
-
Насчет книги. Она не случайно называется системный анализ и проектирование с припиской с помощью UML. Т.е. тут описаны процессы системной инженерии, а UML лишь приложение. Может потому у Вас возник определенный диссонанс?
Эдуард, выше в ответе davvol я указал, анализ RUP -- это не анализ требований, а архитектурный анализ и эскизная реализация ВИ.
Если вернуться к книге, то, как я теперь вижу, анализом, а точнее аналитическим моделированием там назван не процесс, а фаза жизненного цикла.
-
Постарайтесь обойтись вообще без ромбов. Они загромождают диаграмму, все необходимое можно отразить на дугах.
Если позволите... С точки зрения практики, это разумный, дельный совет.
С формальной точки зрения можно указать пример, когда два фрагмента будут неэквивалентны.
Фрагмент1:
(http://yuml.me/9844b4c8)
Фрагмент2:
(http://yuml.me/cb2e3fae)
В случае не исключающих друг друга сторожевых условий guard1 и guard2 в 1-м фрагменте можем получить два параллельных потока, если условия истинны одновременно. Во втором фрагменте в тех же условиях будет единственный поток -- либо верхний, либо нижний, выбранный случайным образом.
Первому фрагменту полностью эквивалентен 3-й:
(http://yuml.me/ca6f8092)
-
Эдуард, выше в ответе davvol я указал, анализ RUP -- это не анализ требований, а архитектурный анализ и эскизная реализация ВИ.
Что же является предметом анализа в «архитектурном анализе»?
-
Что же является предметом анализа в «архитектурном анализе»?
RUP есть в онлайне: http://students.mimuw.edu.pl/~zbyszek/posi/ibm/RUP_Eval/process/activity/ac_arcan.htm
-
Виктор, вы не ответили на мой вопрос, жаль.
По приведённой ссылке — не фаза ЖЦ проекта и не процесс проекта, а деятельность — понятие меньшего масштаба, чем первые 2.
Вне зависимости от RUP/неRUP анализ встречается в следующих работах:
Анализ собранной информации на предмет выявления требований
Анализ разработанных требований на предмет их качества
Анализ разработанных требований с целью проектирования
Анализ архитектуры на предмет её качества
Анализ разработанных требований с целью разработки тестов
Анализ разработанных требований с целью оценки трудоёмкости
Анализ тестов на предмет их качества.
и т.д. и т.п.
Таким образом, анализ — крайне неудачный термин для обозначения фазы или сквозного процесса без уточнения объекта и цели анализа, т.к. аналитическую деятельность выполняют разные проектные роли с разной целью и над разными объектами. Даже сам аналитик делает как минимум 2 разных вида анализа — входной информации и своих артефактов. «Системный анализ» — тоже ещё тот термин — какую систему анализировать, если никакой системы ещё нет?
Но вы конечно можете продолжать спорить о том, сколько чертей уместится на острие иглы, то бишь что и как называется в RUPe. Если кому-то это позволит сдать зачёт, потому что он ответит именно то, что от него ожидает препод — ну и слава богу.
-
Виктор, вы не ответили на мой вопрос, жаль.
По приведённой ссылке — не фаза ЖЦ проекта и не процесс проекта, а деятельность — понятие меньшего масштаба, чем первые 2.
Вне зависимости от RUP/неRUP анализ встречается в следующих работах:
Анализ собранной информации на предмет выявления требований
Анализ разработанных требований на предмет их качества
Анализ разработанных требований с целью проектирования
Анализ архитектуры на предмет её качества
Анализ разработанных требований с целью разработки тестов
Анализ разработанных требований с целью оценки трудоёмкости
Анализ тестов на предмет их качества.
и т.д. и т.п.
Таким образом, анализ — крайне неудачный термин для обозначения фазы или сквозного процесса без уточнения объекта и цели анализа, т.к. аналитическую деятельность выполняют разные проектные роли с разной целью и над разными объектами. Даже сам аналитик делает как минимум 2 разных вида анализа — входной информации и своих артефактов. «Системный анализ» — тоже ещё тот термин — какую систему анализировать, если никакой системы ещё нет?
Но вы конечно можете продолжать спорить о том, сколько чертей уместится на острие иглы, то бишь что и как называется в RUPe. Если кому-то это позволит сдать зачёт, потому что он ответит именно то, что от него ожидает препод — ну и слава богу.
Денис, по моему спор о том что такое "анализ" бессмысленный. Один из плюсов методологии типа RUP, использование общей терминологии. Есть какая-то распространенная методология, которая ближе Вам по душе чем RUP в части использования термина "анализ"?
-
Денис, по моему спор о том что такое "анализ" бессмысленный.
Разговор был не об анализе как таковом, а о названии этапов/процессов/работ. Я утверждаю, что деятельность без заданных входов (объект анализа) и результатов (результат анализа) не является определённой и как раз слово «анализ» в отвязке от них — малополезно.
Один из плюсов методологии типа RUP, использование общей терминологии.
Популярное явление — не значит эффективное. Чего стоит терминология в которой «аналитик не занимается анализом»?
Есть какая-то распространенная методология, которая ближе Вам по душе чем RUP в части использования термина "анализ"?
Стандарт на ЖЦ ПО 12207, CMMI и стандарт инженерии требований 29148-2011 разделяют процессы:
1. Определения (разработки) требований ЗЛ
2. Анализа требований ЗЛ
3. Архитектурного проектирования
Что, как мне кажется, немногим лучше RUP'а. Также меня вполне устраивает терминология ГОСТ 19/34.
-
Я все таки решил оставить мою диаграмму, вск таки она более подходит для меня.
Сейчас я перешел ко 2 заданию, use case diagram. И под пунктом этого задания определить main use cases
Как я понял в моем случае это:
1. Получение карты студенту/сотруднику
2. Использование карты для доступа
3. Запись и отправка отчета для анализа
Ниже я привел actors для этой диаграммы. Как вы считаете, я что то упустил?
-
Ниже я привел actors для этой диаграммы. Как вы считаете, я что то упустил?
А какой смысл в actors без вариантов использования?
А те предложения, которые вы записали возможных main use cases, почему вы считаете, что это ВИ? Что вы понимаете под ВИ?
-
Виктор, вы не ответили на мой вопрос, жаль.
Не, не думаю, что жаль. Найти ответ Вам не составит труда.
По приведённой ссылке — не фаза ЖЦ проекта и не процесс проекта, а деятельность — понятие меньшего масштаба, чем первые 2.
Вас кто-то обманул, утверждая, что архитектурный анализ -- это процесс RUP.
Вне зависимости от RUP/неRUP анализ встречается в следующих работах:
Это как-то связано с моими пояснениями? Я запрещаю кому-либо использовать слово "анализ" в определённых словосочетаниях или смыслах? Вопросы риторические.
Таким образом, анализ — крайне неудачный термин для обозначения фазы или сквозного процесса без уточнения объекта и цели анализа, т.к. аналитическую деятельность выполняют разные проектные роли с разной целью и над разными объектами.
Любая технология определяет процесс или деятельность не только давая ему/ей название. Что фазу так называть не стоит, согласен.
Даже сам аналитик делает как минимум 2 разных вида анализа — входной информации и своих артефактов. «Системный анализ» — тоже ещё тот термин — какую систему анализировать, если никакой системы ещё нет?
Интересная мысль. Правильно ли я понимаю, что Вы полагаете архитектурный анализ в RUP беспредметным, на основании этого умозаключения?
Но вы конечно можете продолжать спорить о том, сколько чертей уместится на острие иглы, то бишь что и как называется в RUPe. Если кому-то это позволит сдать зачёт, потому что он ответит именно то, что от него ожидает препод — ну и слава богу.
Я лишь дал пояснение. Вас не затруднит указать, где и с чем я спорю? Как мне кажется, спор пытаетесь раздуть Вы, оспаривая терминологию установившуюся в рамках определённой технологии сравнительно давно.
-
Я утверждаю, что деятельность без заданных входов (объект анализа) и результатов (результат анализа) не является определённой и как раз слово «анализ» в отвязке от них — малополезно.
Входы и выходы в архитектурном анализе, о котором Вы спрашивали меня, в технологии определены.
-
«аналитик не занимается анализом»
Подмётные цитаты в ход пошли.
-
Подмётные цитаты в ход пошли.
…Аналитик не является участником анализа ни в RUP, ни в Open UP …
Может ли аналитик заниматься анализом, не являясь его участником? Думаю, ответ понятен.
Ок, с человеком, который не отвечает на заданные вопросы и врёт мне общаться не интересно.
-
Вы не общаетесь, Вы извращаете чужое сообщение и показательно опровергаете собственную выдумку. Не в первый раз.
-
А какой смысл в actors без вариантов использования?
А те предложения, которые вы записали возможных main use cases, почему вы считаете, что это ВИ? Что вы понимаете под ВИ?
Ну я думал что сначала нужно продумать кто взаимодействует с системой, а потом уже как они взаимодействуют друг с другом.
Я понимаю под main use cases, те "варианты использования" которые бы описывали сценарий и без которых выполнение сценария не возможна. То есть в моем случае это выдача карты, механизм контроля доступа и отправка отчета для анализа. Если я как то понял не правильно поправьте меня.
Сейчас попробую накидать диаграмму
-
Ну я думал что сначала нужно продумать кто взаимодействует с системой, а потом уже как они взаимодействуют друг с другом.
DEEPshadow, начать можно с определения границ системы (экторов), а потом уже для каждого эктора определить какие услуги они будут получать от системы. Но в общем случае позже может найтись новый ВИ, который сложно будет отнести к существующим экторам. Тогда придётся вводить нового эктора.
Я понимаю под main use cases, те "варианты использования" которые бы описывали сценарий и без которых выполнение сценария не возможна.
Под main use cases видимо подразумеваются наиболее часто используемые. Возможно есть какие-то более чёткие критерии отделения "main" от "не main". Я бы уточнил у преподавателя.
То есть в моем случае это выдача карты, механизм контроля доступа и отправка отчета для анализа. Если я как то понял не правильно поправьте меня.
Я бы выделил следующие ВИ:
1. Открыть проход
2. Ведение свайп-карт (CRUD)
3. Ведение считывателей (CRUD)
4. Рассылка отчёта
Сейчас попробую накидать диаграмму
Возникли следующие комментарии:
1. См. список ВИ выше.
2. Не нужно выделять два разных ВИ с разными именами ("create swipe card")
3. Не нужно выделять Student Service Center и HR. На самом деле это одна и та же роль типа "Администратор". Если правами доступа будет управлять кто-то другой типа начальника охраны, то нужна отдельная роль.
4. Первичных экторов принято указывать слева от ВИ, а вторичны справа.
5. Неверное использование "extend" ("формирование отчёта" не расширяет функционал "получить доступ") и "include" (Нельзя использовать функциональную декомпозицию).
6. CardReader и DataBase это не экторы, а часть системы. Их нужно удалить.
7. Нового и старого сотрудника/ученика выделять не нужно. Они будут отличаться только наличием свайп-карты, а роль одна и та же.
8. Зачем разделять сотрудников и учеников? Они будут как-то по разному взаимодействовать с системой?
9. Сотрудники/ученики не будут взаимодействовать с системой при получении/замене свайп-карты. Они будут взаимодействовать только с администратором.
-
Если позволите... С точки зрения практики, это разумный, дельный совет.
С формальной точки зрения можно указать пример, когда два фрагмента будут неэквивалентны.
...
В случае не исключающих друг друга сторожевых условий guard1 и guard2 в 1-м фрагменте можем получить два параллельных потока, если условия истинны одновременно. Во втором фрагменте в тех же условиях будет единственный поток -- либо верхний, либо нижний, выбранный случайным образом.
Первому фрагменту полностью эквивалентен 3-й:
...
Все верно. Нужно изобразить параллельные потоки - формулируем неисключающие условия. Нужно "один из" - взаимоисключающие.
-
И еще одно замечание в кучу к тому что написал Сергей.
"Время" -это тоже не эктор.
-
DEEPshadow, начать можно с определения границ системы (экторов), а потом уже для каждого эктора определить какие услуги они будут получать от системы. Но в общем случае позже может найтись новый ВИ, который сложно будет отнести к существующим экторам. Тогда придётся вводить нового эктора.
Под main use cases видимо подразумеваются наиболее часто используемые. Возможно есть какие-то более чёткие критерии отделения "main" от "не main". Я бы уточнил у преподавателя.
Но если посмотреть на подпунк b, мы увидим что нужно описать все из сценария.
А выделил я старые и новые сотрудники/ученики, так как опять же мы так делаем на практике. Приведу пример use case для тренажерного зала. где actor может быть и почтовый сервер, время и тп. От этого я и отталкиваюсь
-
Тогда, если я всех студентов и работников отнесу в actors Member и департаменты по выдачи под Administrator то получу такую диаграмму.
Только теперь с вашими замечаниями я не могу понять как построить для прохода. Получается так же member будет участвовать в этом и мы используем просто ВИ открыть доступ?
-
Модератор: Коллеги, просьба перестать ругаться и выражаться по теме, если хотите обсудить термин "анализ", то просьба создать отдельную тему. Дальнейший флуд и отклонения от темы будут удаляться.
-
Я бы выделил следующие ВИ:
1. Открыть проход
2. Ведение свайп-карт (CRUD)
3. Ведение считывателей (CRUD)
4. Рассылка отчёта
По поводу the main use cases это нужно перечислить основные, по моему мнению, ВИ которые должны быть отражены в диаграмме. Такой вот ответ от препода)
Теперь опять по вашим пунктам,
2. swipe card я отобразил на диаграмме
4. Рассылка отчета тоже добавил, но! какого actor мне надо использовать? Поэтому я вновь использовал время как эктора
3 пункт немного не ясен, я попробовал его отразить но получилась ерунда на мой взгляд
-
А выделил я старые и новые сотрудники/ученики, так как опять же мы так делаем на практике.
Сотрудник/ученик будет участвовать только в одном системном ВИ. Чем будет отличаться выполнение этого ВИ для старого и нового? Если ничем, то не нужно разделять роли.
Приведу пример use case для тренажерного зала. где actor может быть и почтовый сервер, время и тп.
Время действительно отображается в виде искуственного первичного эктора там где нужна инициация ВИ по какому-то расписанию. А существующий сервер может быть как частью системы так и эктором. Он будет эктором если мы будем использовать его без доработок через существующий интерфейс. Иначе эктор удаляется, функционал становится частью нашей системы и он как бы растворяется в системе до момента проработки архитектуры.
-
По поводу the main use cases это нужно перечислить основные, по моему мнению, ВИ которые должны быть отражены в диаграмме. Такой вот ответ от препода)
"Основные" - расплывчатое понятие. Насколько ВИ должны быть "основными" чтобы заслужить право отображаться на диаграмме? А про остальные ВИ можно совсем забыть и не реализовывать их в системе?
2. swipe card я отобразил на диаграмме
будет не только создание, но и удаление, изменение прав доступа, просмотр информаци, печать карт при создании. Предлагаю погуглить "CRUD Use Case". И еще что такое Join the NU и для чего оно? В ведении карт будет участвовать только администратор. Ученик/сотрудник в, это время будет стоять рядом и курить.
4. Рассылка отчета тоже добавил, но! какого actor мне надо использовать? Поэтому я вновь использовал время как эктора.
Первичным эктором будет время, а вторичным либо почтовый сервер, либо роль пользователя. По тому же принципу что я описал выше. Делать include ВИ стоит делать только если это упрощает модель. Здесь, по моему include неуместен.
3 пункт немного не ясен, я попробовал его отразить но получилась ерунда на мой взгляд
В ходе эксплуатации системы необходимо будет задавать атрибуты помещения, связанные с правами доступа, указанными в описании? Возможно нужно будет подключать/отключать контроль доступа в определенные зоны типа дня открытых дверей и прочего. Тогда нужен соответствующий ВИ.
-
Насколько ВИ должны быть "основными" чтобы заслужить право отображаться на диаграмме?
Такой ответ чтобы не подсказывать, если выбрал не все основные ВИ то и получу меньшее количество баллов)
будет не только создание, но и удаление, изменение прав доступа, просмотр информаци, печать карт при создании. Предлагаю погуглить "CRUD Use Case".
Хорошо, спасибо учту.
И еще что такое Join the NU и для чего оно?
Это я взял из сценария, описание того что студент/сотрудник поступили на учебу/работу.
Первичным эктором будет время, а вторичным либо почтовый сервер, либо роль пользователя. По тому же принципу что я описал выше. Делать include ВИ стоит делать только если это упрощает модель. Здесь, по моему include неуместен.В ходе эксплуатации системы необходимо будет задавать атрибуты помещения, связанные с правами доступа, указанными в описании? Возможно нужно будет подключать/отключать контроль доступа в определенные зоны типа дня открытых дверей и прочего. Тогда нужен соответствующий ВИ.
Попробую рассмотреть с этой точки, но в сценарии нет информации о подключении или отключении КД в зоны. Сказано только что есть такие зоны, и я думаю, эту зону просто и надо описать.
-
Это я взял из сценария, описание того что студент/сотрудник поступили на учебу/работу.
Судя по описанию нет каких-либо сценариев при поступлении на работу/учёбу, кроме выдачи карты, подлежащих автоматизации.Поэтому такого сценария в системе быть не должно.
Попробую рассмотреть с этой точки, но в сценарии нет информации о подключении или отключении КД в зоны. Сказано только что есть такие зоны, и я думаю, эту зону просто и надо описать.
Можно и не рассматривать такой ВИ, но нужно подумать над тем как заказчик будет добавлять новый зоны и редактировать параметры прав доступа типа "наличие конфиденциальной информации" и "признак публичной зоны" (библиотека и т.п.). То есть нужно понимать что в описании может не быть чего-то, что заказчик на самом деле ожидает от системы. Может быть нужно спросить у преподавателя.
Ещё комментарии по диаграмме:
1. Из описания я понял что наша система не будет никак автоматизировать процесс анализа отчёта, поэтому ВИ "Анализ отчёта" не нужен. Или я ошибаюсь?
2. Имя ВИ обязательно должно начинаться с глагола (Swipe card reader).
3. На диаграмме не может присутствовать ВИ, который не связан ни с одним эктором (Swipe card reader).
4. Include наиболее полезно использовать когда один и тот же ВИ должен включаться в несколько других ВИ или должен повторяться в одном и том же ВИ несколько раз. В других случаях include я стараюсь не использовать.
5. Лучше уточнить название "Server".
Коллеги, выскажете своё мнение, следует ли выделять роли грузчик, уборщик? Если нет, в каком случае вы бы выделили такие роли?
-
Судя по описанию нет каких-либо сценариев при поступлении на работу/учёбу, кроме выдачи карты, подлежащих автоматизации.Поэтому такого сценария в системе быть не должно.
Как раз в сценарии упоминается что карты генерируется при поступлении студента/сотрудника в школу. И препод сказал что нужно описывать все из сценария, включая студента.
Можно и не рассматривать такой ВИ, но нужно подумать над тем как заказчик будет добавлять новый зоны и редактировать параметры прав доступа типа "наличие конфиденциальной информации" и "признак публичной зоны" (библиотека и т.п.). То есть нужно понимать что в описании может не быть чего-то, что заказчик на самом деле ожидает от системы. Может быть нужно спросить у преподавателя.
Это уточню
Ещё комментарии по диаграмме:
1. Из описания я понял что наша система не будет никак автоматизировать процесс анализа отчёта, поэтому ВИ "Анализ отчёта" не нужен. Или я ошибаюсь?
Опять же, нужно описать все из сценария, поэтому он нужен
2. Имя ВИ обязательно должно начинаться с глагола (Swipe card reader).
3. На диаграмме не может присутствовать ВИ, который не связан ни с одним эктором (Swipe card reader).
Мой косяк, просто не знаю куда и с чем его связать
4. Include наиболее полезно использовать когда один и тот же ВИ должен включаться в несколько других ВИ или должен повторяться в одном и том же ВИ несколько раз. В других случаях include я стараюсь не использовать.
пока оставлю так, если смогу понять как их можно разбить без include то конечно попробую
5. Лучше уточнить название "Server".
Думаю назвать тогда Access Control Server, все таки инфа хранится в БД
-
Как раз в сценарии упоминается что карты генерируется при поступлении студента/сотрудника в школу. И препод сказал что нужно описывать все из сценария, включая студента.
Само поступление никак не будет автоматизироваться системой. В описании могло быть написано что перед получением карты студент заходит в школьную столовую выпить компот. Мы ведь не будем это автоматизировать?
Опять же, нужно описать все из сценария, поэтому он нужен
В описании сказано что отчет отправляется для анализа, но не указано что система должна как-то помогать проанализировать отчет. Поэтому ВИ не нужен.
пока оставлю так, если смогу понять как их можно разбить без include то конечно попробую
Почему так сильно хочется разбить? Какую пользу это принесет?
Думаю назвать тогда Access Control Server, все таки инфа хранится в БД
Не должно быть такого эктора. Это часть самой системы. Когда аналитик сформирует требования архитектор предложит как реализовать хранение информации о проходах. Не нужно залезать в область решения.
-
4. Рассылка отчета тоже добавил, но! какого actor мне надо использовать? Поэтому я вновь использовал время как эктора
Того эктора, который осуществляет рассылку. Т.е. систему которая это делает.
Время действительно отображается в виде искуственного первичного эктора там где нужна инициация ВИ по какому-то расписанию.
Мне кажется это недопустимое пренебрежение спецификацией UML. Эктор - конкретная роль или человека или системы, которая взаимодействует с рассматриваемой системой. По этому кто инициирует ВИ по расписанию, тот и является эктором.
ДВИ не место для философских абстракций:)
Коллеги, выскажете своё мнение, следует ли выделять роли грузчик, уборщик? Если нет, в каком случае вы бы выделили такие роли?
Имхо их надо выделять, только если у них есть уникальные ВИ, отличающие их от других. Но т.к. таковых я тут не вижу, то и выделять их не надо.
-
Того эктора, который осуществляет рассылку. Т.е. систему которая это делает.
Рассылку осуществляет наша система, но она не является эктором
Мне кажется это недопустимое пренебрежение спецификацией UML. Эктор - конкретная роль или человека или системы, которая взаимодействует с рассматриваемой системой. По этому кто инициирует ВИ по расписанию, тот и является эктором.
ДВИ не место для философских абстракций:)
Авторы книг расходятся во мнениях. Некоторые говорят что можно использовать эктора время (таймер), другие говорят что в качестве эктора надо применять того на ком будет лежать ответственность за инициацию ВИ. К примеру админ, который должен следить за тем чтобы отчёты сформировались и разослались правильно и вовремя. Такой подход используется, к примеру, в модели классического кейса "Payroll System" фирмы Rational.
Приведу ещё одну ссылку:)
5. если запуск по расписанию -> автоматически, т.е. по событию времени, таким образом это будет актор Время или Таймер.
-
Может это поможет в дискуссии.
Рекомендации по написанию спецификаций вариантов использования (http://www.uml2.ru/faq/use-cases/399-recommendations-for-use-case-specification). Это выжимка из книги, авторы которой весьма известные в западных кругах тренеры.
Управляет процессом не время, а например планировщик. Причем планировщик может быть частью системы, а может быть внешним. По идее мы так и можем написать: Планировщик. Роль, которого запускать задачи по достижению определенных условий (времени). Таким образом Время - как физический процесс, на который мы не можем оказывать влияния, можно считать ДЛ. Кстати и, система, которую мы проектируем, тоже действующее лицо.
В интересах какого заинтересованного лица действует Время, можно показать используя второстепенных ДЛ, например. Впрочем действительно, нет однозначного понимания, потому допустимы обе точки зрения.
-
Спасибо за советы, но меня смущает что препод просит описывать сценарий а не систему в use case diagram. Посмотрел примеры своих одногрупников и они описывают весь сценарий. Включая что студент поступил в школу, и как высказались, если бы было написано что они пили сок то и это бы они отразили. Поэтому я хочу сделать use case diagram по сценарию, а не конкретизировать именно к системе, может пока нам не дают сложное задание чтобы мы не думали где система, а где сценарий. Конечно для вас это будет не правильно, это и меня смущает, но все же я попробую так. а потом можно будет и выделить систему.
-
вот таким образом я изобразил сценарий через use case diagram а так же параллельно начал делать class diagram (use case specification пока пропустил, до того момента как с use case diagram разберусь)
В class diagram пока думаю как отразить время работы или может как то по другому это все надо отобразить?
-
Спасибо за советы, но меня смущает что препод просит описывать сценарий а не систему в use case diagram.
Системные ВИ используются для описания системы, автоматизирующей выполнение части того самого сценария, о котором вы говорите. Неавтоматизируемые части, типа употребления разных напитков и т.п. не описываются в ВИ. Но если препод требует "кушать суп вилкой"...
-
вот таким образом я изобразил сценарий через use case diagram а так же параллельно начал делать class diagram (use case specification пока пропустил, до того момента как с use case diagram разберусь)
В class diagram пока думаю как отразить время работы или может как то по другому это все надо отобразить?
Упомянутые ранее ошибки не исправлены и появились новые.
-
Упомянутые ранее ошибки не исправлены и появились новые.
Да но были указаны ошибки в виду того что вы смотрели на систему, а не сценарий в целом и поэтому я не исправил.
Время. мы используем время в качестве эктора, посмотрел по лекциям.
Сервер. С этим пока еще думаю, просто в голову пока не пришло как назвать но смысл эктора ясен.
То что я разбил экторов, так же по лекциям мы так делали. Например был пример записи к врачу и мы разбивали пациента на Нового и Старого.
отношения между use case, вот в них не уверен. Особено в той части где идет проверка. Как отобразить закрытый доступ или открытый?
Вроде теперь все мои мысли должны быть вам понятны.
-
Да но были указаны ошибки в виду того что вы смотрели на систему, а не сценарий в целом и поэтому я не исправил.
Судя по всему у Вас нет цели использовать правильно методологию. Если цель только сдать работу и преподаватель не выскажет замечаний, то все ок.
Сервер. С этим пока еще думаю, просто в голову пока не пришло как назвать но смысл эктора ясен.
Смысл непонятен. В описании нет информации о том что мы должны использовать какой-то унаследованный сервер. Поэтому такого эктора быть не должно. Это часть самой системы.
отношения между use case, вот в них не уверен. Особено в той части где идет проверка. Как отобразить закрытый доступ или открытый?
Вариант использования должен отражать одну услугу системы, которую пользователь от нее получает. Таких понятий как закрытый или открытый доступ на диаграмме быть не должно. Include и extend нужно использовать правильно и в ограниченном объеме.
-
Управляет процессом не время, а например планировщик.
Планировщик мне нравится гораздо больше. Сразу понятно на кого смотреть при разборе ВИ:)
вот таким образом я изобразил сценарий через use case diagram
Сценарий - это одно действие от начала и до конца, по шагам. Т.е. или проход по карте или получение карты или отправка отчета. Но что-то одно.
А у вас все сразу.
Плюс мне кажется что у вас все поставлено с ног на голову.
Потому что обычно сценарий поясняет диаграмму использования, а не диаграмма использования сценарий.
Обычно на каждый use case пишется сценарий этого use case с основным и альтернативными потоками.
Например если это use case прохода по карте, то у его сценария будет основной поток когда доступ получен и альтернативный когда доступ запрещен.
Но как Сергей написал выше, если преподаватель "так видит", то что поделаешь:)
-
Может и я не понял его) просто эти размышления я получил после примеров что другие делают.
Хорошо, тогда соглашусь с вами и попробую сделать нормальную систему. Единственное что время может быть эктором в моем случае) седня перечитаю еще раз все ваши замечания и попробую сделать use case именно по системе. Спасибо за понимание.
Так же бы хотел услышать замечания по class diagram, сразу скажу что нужно отразить только entity class, т.е я не залезал в стереотипы.
-
Теперь я вроде бы разобрался) use case зависит от того что я выбрал main use cases. Поэтому у всех они не похожи и я подумал о сценарии. Тогда начнем с чистого листа и сначала мне нужно выбрать main use cases. Их выбор ниче не ограничен, можно выбрать что угодно из сценария. В моем случае это access control. Тогда подумаю сейчас что же выбрать из ваших замечаний
Вот что осталось из того что было.
main use cases:
Generate swipe card
Open access to zone
using swipe card reader
Я уже немного запутался, направьте меня на путь истинный)
-
Мне кажется уже лучше:)
Выкинули систему отчетов, схема стала легче.
Однако есть следующие замечания:
1. Теряюсь в догадках, что такое "Swipe card transaction"? И почему каждый раз при его использовании должны выпускать новую карту?
2. Почему вариант использования "Incorrect entry" расширяет неясный "Swipe card transaction"? В то время как сам вход происходит в другом варианте использования.
3. И вообще, что это за вариант использованя "Incorrect entry"? В чем его польза для клиента? Такие вещи как успех/неуспех отображаются в сценарии, а не в ДВИ.
3. Я бы заменил "Manage swipe card" на "swipe card CRUD" без инклюдов. Потому что по текущей схеме, получается, что при управлении картами, нужно будет и обновлять информацию и удалять карту и делать новую одновременно.
ЗЫ: К диаграмме классов тоже можно придраться, но предлагаю сначала разобраться с ДВИ:)
-
1. Теряюсь в догадках, что такое "Swipe card transaction"? И почему каждый раз при его использовании должны выпускать новую карту?
Это я так хотел отразить, если студент потерял карту или проблемы с картой. Но видимо это не нужно здесь
2 вопрос по той же причине, не знал как их объединить и сделал одно и тоже два раза
3 вопрос, логично. Исправлю.
В итоге, вот что получилось. Но из выбранных мною main use cases, я потерял using swipe card reader. Или это не нужно отображать?
-
В диаграмме вариантов использования в посте от 11 Ноября 2013, 21:39:19 неправильно обозначены отношения генерализации между акторами: вместо отношения генерализации обозначено отношение ассоциации.
Для наглядности прикладываю пример обозначения генерализации из документации одного своего реального проекта.
-
Это я так хотел отразить, если студент потерял карту или проблемы с картой. Но видимо это не нужно здесь
Да, потеря карты происходит за рамками рассматриваемой системы
В итоге, вот что получилось. Но из выбранных мною main use cases, я потерял using swipe card reader. Или это не нужно отображать?
Вариант использования - это некое минимальное действие которое пользователь выполняет с целью получить пользу. Т.е. человек прикладывает карту к датчику не для того, чтобы послушать как он круто пикает и моргает зеленым глазом, а чтобы пройти куда ему надо. По этому "Доступ в кабинет" - это вариант использования, а "использование карт ридера" - уже нет.
-
По этому "Доступ в кабинет" - это вариант использования, а "использование карт ридера" - уже нет.
Тогда что мне еще нужно добавить в use case diagram? Мне она кажется какой то незаконченной
-
Теперь, когда мы убрали лишнее, можно вернуть отправку отчетов (которая инициируется тем самым "временем"), т.к. это полноценная часть системы.
И получится на мой взгляд полная ДВИ со всеми участниками.
Т.е. диаграмма будет включать 4 варианта использования:
1. Доступ в кабинет (эктор - пользователь)
2. Сохранение данных о доступе (включается в ВИ "доступ в кабинет")
3. Управление картами (эктор - менеджер)
4. Отправка ежемесячного отчета (эктор - "время")
-
Теперь, когда мы убрали лишнее, можно вернуть отправку отчетов (которая инициируется тем самым "временем"), т.к. это полноценная часть системы.
И получится на мой взгляд полная ДВИ со всеми участниками.
Т.е. диаграмма будет включать 4 варианта использования:
1. Доступ в кабинет (эктор - пользователь)
2. Сохранение данных о доступе (включается в ВИ "доступ в кабинет")
3. Управление картами (эктор - менеджер)
4. Отправка ежемесячного отчета (эктор - "время")
Выходит так (решил все таки добавить экторов для ясности)
-
кстати, пока занимаюсь use case specification, хотелось услышать мнение о class diagram
-
Народ, опомнитесь! Что ж вы делаете с бедным студентом!? =)
Итак, начну с общего - модель всегда должна соответствовать цели ее создания. Цель, если я правильно ее понимаю, продемонстрировать знание нотации 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 - сотрудник, школьник и т.п.
-
Для именно этого кейса, исходя из цели моделирования, правильно будет определить 4 действующих лица:
- Субъект, пытающийся получить доступ
- Карт ридер
- Система
- Дверь (турникет и т.п.)
Tinner,
- Считыватель карт это не эктор, т.е. не элемент требований, а компонент реализации (часть системы), который должен образоваться по результатам проектирования системы или как ограничение на реализацию.
- Система не является эктором. Эктор по определению это тот, кто находится за пределами Системы и взаимодействует с ней
- Дверь (турникет и т.п.) это тоже не эктор. Дверь это не унаследованная система, с которой наша Система может обмениваться информацией.
Тут могу посоветовать выписать все сущности из задания и довести до минимализма (в буквальном смысле перечитать задание и подчеркнуть все существительные) и исходить из этого.
Подчёркнутые сущности не обязательно покроют все потребности задачи, а некоторые подчёркнутые сущности могут оказаться лишними. Нужно исходить из того какие события мы хотим фиксировать, а уже потом какие сущности будут связаны с этими событиями.
-
Для именно этого кейса, исходя из цели моделирования, правильно будет определить 4 действующих лица:
- Субъект, пытающийся получить доступ
- Карт ридер
- Система
- Дверь (турникет и т.п.)
Если довериться Коберну, то можно назвать Систему "действующим лицом". Главное не запутать человека чтобы он не изобразил человечка с именем "Система" на диаграмме ВИ.
-
- Считыватель карт это не эктор, т.е. не элемент требований, а компонент реализации (часть системы), который должен образоваться по результатам проектирования системы или как ограничение на реализацию.
- Система не является эктором. Эктор по определению это тот, кто находится за пределами Системы и взаимодействует с ней
- Дверь (турникет и т.п.) это тоже не эктор. Дверь это не унаследованная система, с которой наша Система может обмениваться информацией.
В задании четко поставлена задача - описать процесс получения доступа в виде активити диаграммы. У приведенных мной сущностей есть состояния действий, которые можно отобразить на диаграмме. Тогда почему, в данном контексте нельзя на диаграмме отобразить их на отдельных дорожках?
Напоминаю:
- Конечная цель - не создать модель всей системы в целом (кроме определения main use cases), а выполнить конкретные задания курсового.
- Детализация может быть разной в разных диаграммах, в зависимости от цели создания конкретной модели.
- UML - не язык сбора и фиксирования требований, а язык моделирования, а модель может отражать часть требований к системе, но никак не наоброт.
- Главная цель UML (то, во что она со временем вылилась, и единственная реальная, которую я встречал в жизни) - это обеспечение одинакового понимания задачи всей командой проекта. Соответственно, отойдя от Коберна и компании, которые используют лишь малую часть UML в очень ускоспециализированном контексте, прошу указать мне, чем мое предложение по реализации Активити диаграммы плохо?
Прошу поправить меня, если я не прав, заранее спасибо.
-
По текущей диаграмме очень много замечаний. Советую вслух проговорить все что описано на диаграмме, с учетом формальности языка. Например 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 должны подходить под задание
-
Вопрос на засыпку: я правильно понимаю из диаграммы, что HR и Security не являются сотрудниками школы, и доступ им никуда не нужен?
Тут я немного напутал, HR и Student Service Center - actors, они скорее всего являются сотрудниками школы и доступ им нужен, но это не описывается в сценарии. Я думаю в моем случае это просто место, где получают карты
-
Сейчас опять наверное скажете, что зря я добавил Эктора Аналитика=) Но при написании specification понял что он мне нужен, чтобы был весь процесс куда идет отчет и для чего.
И вот добавил лог и картридер в диаграмму классов, прочитав еще раз задание больше для себя классов не нашел. Единственное что смущает это рабочее время, и от этого зависит будет ли доступ у определенных лиц. Нужно ли какой то класс создавать, который бы хранил время? или это можно все в класс Привилегии отнести?
-
Сейчас опять наверное скажете, что зря я добавил Эктора Аналитика=) Но при написании specification понял что он мне нужен, чтобы был весь процесс куда идет отчет и для чего.
Конечно зря:)
Судя по постановке задания, отчеты отправляются в какие-то там другие отделы. Их анализ не происходит в рассматриваемой системе, так что и юз кейс "Analyze report data" и эктор "Analyst" лишние.
Как я понимаю есть желание упомянуть систему в которую уходят отчеты. В таком случае надо во вторичных экторах добавить эту систему, назвать можно как угодно, но это будет именно система (а не прямо в мозг аналитику отправляешь:)) и связать ее с юз кейсом "Send Report to departments"
-
Как я понимаю есть желание упомянуть систему в которую уходят отчеты. В таком случае надо во вторичных экторах добавить эту систему, назвать можно как угодно, но это будет именно система (а не прямо в мозг аналитику отправляешь:)) и связать ее с юз кейсом "Send Report to departments"
Да, просто при use case specification получается не полная картина без того куда и зачем отправляется отчет. Хорошо, подумаю как систему назвать. В голове только 2 вещи вертятся, это почтовый эктор(Если считать что отправка отчета идет по почте) или так и назвать Система анализа данных.
Что думаете по поводу class diagram? правильно ли я связал cardReader и AccessPoint? или нужно еще с чем то связать?
Спасибо за помощь!
-
-
-
В задании четко поставлена задача - описать процесс получения доступа в виде активити диаграммы.
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"
То есть по определению сама система не является эктором.
-
Tinner, в задании не менее чётко поставлена и другая задача "Предоставить use case diagram". DeepShadow начал с этого задания, а активити-диаграмму мы пока не обсуждали.
Моя диаграмма на 2 странице, ее самой первой обсуждали. Главная задача отобразить процесс когда кто нибудь пытается получить доступ и думаю моя диаграмма отображает это, с учетом всех нюансов сценария
-
Состояния можно придумать для многих предметов типа провода, который питает считыватель или дверной замок. Проблема в том что диаграмма ВИ даёт общий обзор функциональных требований к системе и подобные предметы на ней не должны упоминаться.
Прошу не путать активити и ДВИ. Использовать разную детализацию в разных диаграммах не преступление. Кроме этого, можно показать на активити диаграмме взаимодействие между компонентами системы, это даст представление о том, что происходит в целом, откуда какие отказы появляются. Например на диаграмме уважаемого 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 на всех стадиях разработки ПО, а не только при анализе, надеюсь ее прочтение расширит кругозор.
-
Например на диаграмме уважаемого DEEPshadow не показан случай, когда карту не удалось считать, кто из вас ни разу не прикладывал не ту карту в метро или не пытался открыть дверь неправильным магнитным ключом?
Это я уже добавил, просто не выложилю После действия прочитать карту, у меня идет decision mode - не удалось прочитать карту и на access deny, else и далее как указано.
Сейчас я решил отобразить еще отправку отчета в этой диаграмме, стоит ли? Использую для этого TimeEvent
Пока думаю отобразить как параллельное событие или лучше в конце, как было, добавить снизу отправку. Или вообще не стоит?
-
Прошу не путать активити и ДВИ.
Прошу извинить. Неверно понял о чём речь.
А вообще я больше верю своим глазам, чем авторам, какими бы именитыми они не были.
Есть замечательная книжка Uml 2 and unified process, в котором описано применение UML на всех стадиях разработки ПО, а не только при анализе, надеюсь ее прочтение расширит кругозор.
Значит Джиму Арлоу и Айле Нейштадт вы доверяете больше? Несомненно книга очень полезная, но в чём они не соглашаются с создателями UML и RUP?
Прошу указать мне место, где я на диаграмме ВИ предлагаю использовать эктора "Система". Я считаю это большой проблемой аналитиков, зашоренность во взглядах: Если UML, то обязательно ДВИ и фиксация и выявление требований. Применяется UML для описания системы в целом. Есть замечательная книжка Uml 2 and unified process, в котором описано применение UML на всех стадиях разработки ПО, а не только при анализе, надеюсь ее прочтение расширит кругозор.
Исходя из данной цели, предлагаю пройтись по заданию:Для именно этого кейса, исходя из цели моделирования, правильно будет определить 4 действующих лица:
- Субъект, пытающийся получить доступ
- Карт ридер
- Система
- Дверь (турникет и т.п.)
Вы предлагаете выделить элементы с разных уровней абстракции и назвать их действующими лицами. Какими деятельностями на диаграмме деятельности будут заниматься дверь с карт ридером?
-
Например на диаграмме уважаемого DEEPshadow не показан случай, когда карту не удалось считать, кто из вас ни разу не прикладывал не ту карту в метро или не пытался открыть дверь неправильным магнитным ключом?
А вот это как раз совершенно не важно, почему доступ не получен.
А вдруг клиент приложил к считывателю ботинок, а не карту? Это совершенно лишняя, мусорная, информация, которая усложнит восприятие.
и отображаться она не должна, т.к. сам ВИ "use swipe card" уже предполагает что клиент приложил нужную карту.
Что клиент прикладывал к ридеру до этого (проездной от метро или ботинок) не имеет значения, т.к. НЕ на карту ридер не сработает.