226
IDEF ARIS BPMN и пр. / Re: Помогите начинающему аналитику с моделированием бизнес-процессов
« : 02 Февраля 2011, 18:54:42 »
Если это единственный вопрос, то ДА!
Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
227
Управление Проектом / Шпаргалка руководителю проекта
« : 02 Февраля 2011, 17:49:08 »
Вчера пришлось знакомиться с проектом плана разработки ПО с одной из компаний, которая хочет внедрять процесс RUP.
Разбирать этот план, я, естественно не буду. Но впечатление сложилось не очень. И я решил нарисовать для них шпаргалку для планирования разработки одной возможности (feature RUP).
По ходу рисования я немножко поменял цель. Получился не шаблон плана, а диаграмма бизнес-процесса разработки возможности.
Учитывались рекомендации итерационности и инкрементности.
Конечно, процесс имеет дополнительные связи с другими частями плана (и процесса) разработки. Я от них абстрагировался.
На основе диаграммы сделан шаблон MSProject.
Разбирать этот план, я, естественно не буду. Но впечатление сложилось не очень. И я решил нарисовать для них шпаргалку для планирования разработки одной возможности (feature RUP).
По ходу рисования я немножко поменял цель. Получился не шаблон плана, а диаграмма бизнес-процесса разработки возможности.
Учитывались рекомендации итерационности и инкрементности.
Конечно, процесс имеет дополнительные связи с другими частями плана (и процесса) разработки. Я от них абстрагировался.
На основе диаграммы сделан шаблон MSProject.
228
Примеры / Re: Пример диаграммы для описания функционирования формы
« : 26 Января 2011, 18:03:40 »
Юра Булуй вполне резонно указал, что такое описание на практике никому не нужно.
Для определения требований к интерфейсу с пользователем-человеком вполне достаточно диаграммы деятельности. Из описания к этой диаграмме (поля документирования каждого модельного элемента) должно быть ясно, какие средства управления (поля, кнопки и т.д.) нужны для реализации.
Иногда проектировщик делает диаграмму классов (граничных, по терминологии моделирования анализа). Окна, области, поля и т.д.
Для любого разработчика этого достаточно!
Средства управления, как правило, между собой не взаимодействуют.
Ну, а если форма в процессе заполнения взаимодействует с сущностями или контроллером (подсказки, запуск операций), так это не моделирование формы, а моделирование реализации прецедента (use case realization). См. RUP, там все очень подробно описано.
Для определения требований к интерфейсу с пользователем-человеком вполне достаточно диаграммы деятельности. Из описания к этой диаграмме (поля документирования каждого модельного элемента) должно быть ясно, какие средства управления (поля, кнопки и т.д.) нужны для реализации.
Иногда проектировщик делает диаграмму классов (граничных, по терминологии моделирования анализа). Окна, области, поля и т.д.
Для любого разработчика этого достаточно!
Средства управления, как правило, между собой не взаимодействуют.
Ну, а если форма в процессе заполнения взаимодействует с сущностями или контроллером (подсказки, запуск операций), так это не моделирование формы, а моделирование реализации прецедента (use case realization). См. RUP, там все очень подробно описано.
229
Задачи студентов / Re: Курсовая работа
« : 26 Января 2011, 15:01:46 »
Ох, Эдуард! Вы сделали абсолютно правильные замечания, но не рассказали студенту о последствиях.
Если бы нарисованные связи изменяли только вид картинки!
Когда диаграммы рисуются в инструменте моделирования, каждая ассоциация на диаграмме классов изменяет структуру участников!
Мы начинаем с того, что "хотим" обратить внимание, а фактически создаем новый атрибут класса.
Диаграмма классов показывает наличие статических связей между экземплярами ассоциированных классов.
В качестве примера можно привести "ассоциацию" между между классами контроллера и сущности (из модели анализа RUP). Экземпляр контроллера создается во время выполнения. По завершении своей миссии он "исчезает". Соответственно, в статике класс контроллер не имеет ни одного экземпляра. Соответственно, на диаграмме классов контроллер не может иметь ассоциаций.
Можно посмотреть примеры диаграмм отцов-основателей, да и другие. На диаграмме множество классов не имеют ассоциаций. Но зачем же их нарисовали? Они есть. И они будут иметь динамические связи во время выполнения.
Если бы нарисованные связи изменяли только вид картинки!
Когда диаграммы рисуются в инструменте моделирования, каждая ассоциация на диаграмме классов изменяет структуру участников!
Мы начинаем с того, что "хотим" обратить внимание, а фактически создаем новый атрибут класса.
Диаграмма классов показывает наличие статических связей между экземплярами ассоциированных классов.
В качестве примера можно привести "ассоциацию" между между классами контроллера и сущности (из модели анализа RUP). Экземпляр контроллера создается во время выполнения. По завершении своей миссии он "исчезает". Соответственно, в статике класс контроллер не имеет ни одного экземпляра. Соответственно, на диаграмме классов контроллер не может иметь ассоциаций.
Можно посмотреть примеры диаграмм отцов-основателей, да и другие. На диаграмме множество классов не имеют ассоциаций. Но зачем же их нарисовали? Они есть. И они будут иметь динамические связи во время выполнения.
230
Примеры / Re: Пример диаграммы для описания функционирования формы
« : 26 Января 2011, 14:23:51 »Диаграмма состояний UML контекстна: она описывает состояния владельца. Попробуйте, например, в инструменте перетащить элемент диаграммы к другому владельцу. Фиг!
А теперь попробуйте то же самое сделать с классом. Да запросто!
Извините, я неточно выразился. Следует читать "элементы диаграммы состояний контекстны: они отражают состояния владельца!
Дальше все правильно.
231
Примеры / Re: Пример диаграммы для описания функционирования формы
« : 26 Января 2011, 14:12:06 »Чтобы описать структуру интерфейса, использую диаграмму состояний (пример в приложенином файле).
Думаю, формально ее можно рассматривать как диаграмму состояний фокуса ввода.
Действительно, аналитик и проектировщик могут использовать любые средства для "донесения" своей мысли. Текст, иллюстрации. Но простите, при чем здесь диаграмма состояний UML?
Есть очень простой способ: запустите валидацию в инструменте моделирования. Уверяю Вас, самого большого монитора не хватит, чтобы показать все ошибки!
Диаграмма состояний UML контекстна: она описывает состояния владельца. Попробуйте, например, в инструменте перетащить элемент диаграммы к другому владельцу. Фиг!
А теперь попробуйте то же самое сделать с классом. Да запросто!
232
Примеры / Re: Пример диаграммы для описания функционирования формы
« : 25 Января 2011, 19:51:31 »
Согласен с Юрием, что в ТЗ на систему никакая из таких диаграмм (для отдельной формы), в принципе, не нужна, и никто из аналитиков на практике ее рисовать не будет! Но здесь студент! Может, это главная фишка в работе!
С другой стороны, если он все же хочет это сделать:
Rom меня не понял. Я не советовал "отображать сценарий для отдельных пользователей в виде пулов и дорожек на диаграмме". Я писал, что если нарисовать диаграмму классов, то в виде участников (дорожек) допустимо изобразить экземпляры классов, в виде действий - операции классов, а в виде параметров операций - объекты данных, содержащие атрибуты классов.
Многие скажут, что так не делают, но, смею вас заверить, ни один валидатор UML не увидит здесь ошибки!
Информация в точности соответствует информации диаграммы последовательности, только форма необычная.
Диаграмма последовательности же имеет только один недостаток: сложное описание логики.
Эдуард! А зачем рисовать отдельную диаграмму для каждого сценария? Это в UML 1.x надо было. В UML2 в диаграмму можно включать множество структур управления (если правильно помню, их 12 штук, любой условный переход!). И нарисовать легко. Только прочитать трудно!
Диаграмма состояний, все же, предназначена для описания состояний одного классификатора, большого или маленького, со множеством подсостояний, но одного.
Есть еще одна диаграмма, о которой все забыли, т.к. мало инструментов, которые ее реализуют.
Это диаграмма обзора взаимодействий: основа - диаграмма деятельности, действия представляются диаграммой последовательности. Чтобы изобразить такую диаграмму нужен дисплей размером ... ох!
Я такую диаграмму рисовал "искуственно" так: диаграмма деятельности, где действия - это CallBechavior. Каждое поведение - это взаимодействие, т.е. действие раскрывается отдельной диаграммой последовательности.
Примечание: Диаграмма обзора взаимодействий реализована в Rational Softvare Architect версии 8.0. Версия вышла очень недавно, я рисовать не пробовал: пока не понадобилось!
С другой стороны, если он все же хочет это сделать:
Rom меня не понял. Я не советовал "отображать сценарий для отдельных пользователей в виде пулов и дорожек на диаграмме". Я писал, что если нарисовать диаграмму классов, то в виде участников (дорожек) допустимо изобразить экземпляры классов, в виде действий - операции классов, а в виде параметров операций - объекты данных, содержащие атрибуты классов.
Многие скажут, что так не делают, но, смею вас заверить, ни один валидатор UML не увидит здесь ошибки!
Информация в точности соответствует информации диаграммы последовательности, только форма необычная.
Диаграмма последовательности же имеет только один недостаток: сложное описание логики.
Эдуард! А зачем рисовать отдельную диаграмму для каждого сценария? Это в UML 1.x надо было. В UML2 в диаграмму можно включать множество структур управления (если правильно помню, их 12 штук, любой условный переход!). И нарисовать легко. Только прочитать трудно!
Диаграмма состояний, все же, предназначена для описания состояний одного классификатора, большого или маленького, со множеством подсостояний, но одного.
Есть еще одна диаграмма, о которой все забыли, т.к. мало инструментов, которые ее реализуют.
Это диаграмма обзора взаимодействий: основа - диаграмма деятельности, действия представляются диаграммой последовательности. Чтобы изобразить такую диаграмму нужен дисплей размером ... ох!
Я такую диаграмму рисовал "искуственно" так: диаграмма деятельности, где действия - это CallBechavior. Каждое поведение - это взаимодействие, т.е. действие раскрывается отдельной диаграммой последовательности.
Примечание: Диаграмма обзора взаимодействий реализована в Rational Softvare Architect версии 8.0. Версия вышла очень недавно, я рисовать не пробовал: пока не понадобилось!
233
Примеры / Re: Пример диаграммы для описания функционирования формы
« : 24 Января 2011, 16:46:34 »
Какая-нибудь книжка по UML под руками есть?
Если сейчас начать все описывать "от Адама"...
Опыта больше, чем нужно. По запросу:
1. Совершенно правильно
2. Первый вариант неверный. В UML2 есть "постепенно забываемая" диаграмма коммуникаций. Очень похожа на диаграмму классов, но вместо классов - экземпляры классов, а вместо ассоциаций - сообщения, которые нумеруются в порядке выполнения. Получается очень запутанная паутина, если взаимодействий много.
Диаграммы потоков данных в UML нет.
3. Совершенно неправильно.
Выше предлагались три варианта для UML: Диаграммы деятельности (activity), последовательности (sequence) или состояний (state machine).
С точки зрения теории, правильнее всего (в данной ситуации) рисовать диаграмму последовательности. Но она получается почти необозримой, если много участников и, особенно, много "if-ов". Есть способы "проваливаться" в поддиаграммы, но за один день их точно не освоить.
Можно использовать диаграмму деятельности. Там есть понятие "дорожки" (partition), каждая дорожка - участник. Диаграмма позволяет перекидывать мячик между участниками. Мячиком могут быть данные. А действия - операциями. Все понятно и просто, но не очень корректно.
Для формы м.б. составлена диаграмма состояний, но на ней трудно показать участников. Скорее всего, она не подходит.
В любом случае, книжку посмотреть надо. Там примеры есть.
Если сейчас начать все описывать "от Адама"...
Опыта больше, чем нужно. По запросу:
1. Совершенно правильно
2. Первый вариант неверный. В UML2 есть "постепенно забываемая" диаграмма коммуникаций. Очень похожа на диаграмму классов, но вместо классов - экземпляры классов, а вместо ассоциаций - сообщения, которые нумеруются в порядке выполнения. Получается очень запутанная паутина, если взаимодействий много.
Диаграммы потоков данных в UML нет.
3. Совершенно неправильно.
Выше предлагались три варианта для UML: Диаграммы деятельности (activity), последовательности (sequence) или состояний (state machine).
С точки зрения теории, правильнее всего (в данной ситуации) рисовать диаграмму последовательности. Но она получается почти необозримой, если много участников и, особенно, много "if-ов". Есть способы "проваливаться" в поддиаграммы, но за один день их точно не освоить.
Можно использовать диаграмму деятельности. Там есть понятие "дорожки" (partition), каждая дорожка - участник. Диаграмма позволяет перекидывать мячик между участниками. Мячиком могут быть данные. А действия - операциями. Все понятно и просто, но не очень корректно.
Для формы м.б. составлена диаграмма состояний, но на ней трудно показать участников. Скорее всего, она не подходит.
В любом случае, книжку посмотреть надо. Там примеры есть.
234
Задачи студентов / Re: Курсовая работа
« : 23 Января 2011, 01:14:20 »
Эдуард!
В бизнес-моделировании, в отличие от моделирования системного, полно условностей и "частных соглашений".
Только ленивый не использует пример банкомата.
Если мы моделируем банкомат, прецедент "Получение денег", то клиент - первичный субъект, процессинг - вторичный.
Все то же самое, моделируем систему банкоматов. Соответственно, процессинг включен в систему как некий компонент. Наверное, есть какие-то вторичные субъекты, я их не знаю.
А если мы моделируем бизнес-процессы университета? В отношениях с Министерством все понятно, граница - стена университета. А экзамен - это бизнес-процесс? Без сомнения. Но оба участника так или иначе являются внутренностью университета. Давайте договоримся об условных границах. Границами, по UML, являются субъекты. Если у процесса два субъекта, только один из них м.б. первичным.
Тут пустые размышления могут довести до парадокса "черепахи и олимпийца"!
Договоримся считать системой преподавательский стол, а дальше - нет проблем: пинг-понг!
Если интересно, я могу рассказать, почему использую термин "прецедент". И почему термин RUP "Development Case" я перевел как "Адаптированный процесс". Скажи, где. Не для широкой публики!
В бизнес-моделировании, в отличие от моделирования системного, полно условностей и "частных соглашений".
Только ленивый не использует пример банкомата.
Если мы моделируем банкомат, прецедент "Получение денег", то клиент - первичный субъект, процессинг - вторичный.
Все то же самое, моделируем систему банкоматов. Соответственно, процессинг включен в систему как некий компонент. Наверное, есть какие-то вторичные субъекты, я их не знаю.
А если мы моделируем бизнес-процессы университета? В отношениях с Министерством все понятно, граница - стена университета. А экзамен - это бизнес-процесс? Без сомнения. Но оба участника так или иначе являются внутренностью университета. Давайте договоримся об условных границах. Границами, по UML, являются субъекты. Если у процесса два субъекта, только один из них м.б. первичным.
Тут пустые размышления могут довести до парадокса "черепахи и олимпийца"!
Договоримся считать системой преподавательский стол, а дальше - нет проблем: пинг-понг!
Если интересно, я могу рассказать, почему использую термин "прецедент". И почему термин RUP "Development Case" я перевел как "Адаптированный процесс". Скажи, где. Не для широкой публики!
235
Задачи студентов / Re: Курсовая работа
« : 23 Января 2011, 00:50:04 »
Ээээ..., дорогой!
Да это только вершина! И, может быть, ненужная?
Все равно, сначала сомнения:
1. Бизнес-процесс "Пройти обучение" всегда имеет подпроцессы "Изучить теорию", "Пройти практику" и "Пройти тестирование". Соответственно, я думаю, это включаемые прецеденты: стрелки д.б. наоборот, и д.б. метки <<includ>>.
2. Если УЦ участвует в создании отчета, все правильно. Если же отчет создает инструктор, а потом сдает его в УЦ, линия к УЦ необязательна. А если линию убрать, то и primary на линии "Инструктор - Создать отчет" будет ненужным.
К этой диаграмме больше придраться не могу!
Если курсовая связана с разработкой программной системы, то моделировать нужно программную систему, а модель бизнеса создается (не обязательно) для того, чтобы определить место компьютерной системы в бизнесе. Некоторые из нарисованных эллипсов и близко с компьютерной системой не лежали.
Система, которую Вы, как я понял, уже сделали, решает только часть того, что нарисовано! Что именно? Может быть, эти прецеденты выделить цветом?
Тогда можно будет обсудить, что делать дальше. И поподробнее о системе. Именно это и спросил Galogen (про контекст).
Да это только вершина! И, может быть, ненужная?
Все равно, сначала сомнения:
1. Бизнес-процесс "Пройти обучение" всегда имеет подпроцессы "Изучить теорию", "Пройти практику" и "Пройти тестирование". Соответственно, я думаю, это включаемые прецеденты: стрелки д.б. наоборот, и д.б. метки <<includ>>.
2. Если УЦ участвует в создании отчета, все правильно. Если же отчет создает инструктор, а потом сдает его в УЦ, линия к УЦ необязательна. А если линию убрать, то и primary на линии "Инструктор - Создать отчет" будет ненужным.
К этой диаграмме больше придраться не могу!
Если курсовая связана с разработкой программной системы, то моделировать нужно программную систему, а модель бизнеса создается (не обязательно) для того, чтобы определить место компьютерной системы в бизнесе. Некоторые из нарисованных эллипсов и близко с компьютерной системой не лежали.
Система, которую Вы, как я понял, уже сделали, решает только часть того, что нарисовано! Что именно? Может быть, эти прецеденты выделить цветом?
Тогда можно будет обсудить, что делать дальше. И поподробнее о системе. Именно это и спросил Galogen (про контекст).
236
Задачи студентов / Re: Курсовая работа
« : 22 Января 2011, 23:10:33 »
Эдуард! Я не хочу никого обидеть! Мне просто нужно было привести "зрелищные" примеры, которые были бы понятны "человеку с улицы" (Студента я тоже не хочу обидеть! Он самостоятельно впервые сразу сделал неплохую работу!)
Что касается "первичности" и "вторичности", то в действительности все зависит от контекста.
В данном случае контекст - обучение. Обучающийся реализует свои цели независимо от того, в какой бизнес-системе выполняется тот или иной бизнес-процесс.
Именно студент приходит на экзамен, и именно УЦ просит у Надзора лицензию.
Бизнес-модель вполне реальная, к IT отношения имеет мало, если не будет развиваться в сторону автоматизации.
Если ты не согласен с моими объяснениями первичности и вторичности, сверься с таким авторитетом, как RUP.
Что касается моего опыта, то я всегда был троечником. Но Учителей своих почти всегда уважал и, как ни странно, они меня уважали.
Со студентами общался, когда учился во втором ВУЗе. В первом общался с курсантами.
В настоящее время только с племянниками, которым некогда учиться: они зарабатывают и подучиваются в свободное от работы время. Может быть, мне не повезло с племянниками, а может быть - с госполитикой поддержки образования.
Но последнее лучше обсуждать не на этом сайте!
Что касается "первичности" и "вторичности", то в действительности все зависит от контекста.
В данном случае контекст - обучение. Обучающийся реализует свои цели независимо от того, в какой бизнес-системе выполняется тот или иной бизнес-процесс.
Именно студент приходит на экзамен, и именно УЦ просит у Надзора лицензию.
Бизнес-модель вполне реальная, к IT отношения имеет мало, если не будет развиваться в сторону автоматизации.
Если ты не согласен с моими объяснениями первичности и вторичности, сверься с таким авторитетом, как RUP.
Что касается моего опыта, то я всегда был троечником. Но Учителей своих почти всегда уважал и, как ни странно, они меня уважали.
Со студентами общался, когда учился во втором ВУЗе. В первом общался с курсантами.
В настоящее время только с племянниками, которым некогда учиться: они зарабатывают и подучиваются в свободное от работы время. Может быть, мне не повезло с племянниками, а может быть - с госполитикой поддержки образования.
Но последнее лучше обсуждать не на этом сайте!
237
Задачи студентов / Re: Курсовая работа
« : 22 Января 2011, 21:53:33 »
Если Вы использовали инструмент моделирования, то м.б. обратили внимание, что у модельных элементов есть свойства. Одно из свойств - это текстовое описание. Его очень полезно заполнять, чтобы потом использовать при описании моделей (диаграмм).
Среди параметров есть такие, как стереотип и ключевые слова. Для нужных ассоциаций там нужно написать слово primary.
Если это инструмент рисования, то вместо ваших меток нужно написать <<pimary>>. В угловых скобках помещаются текстовые обозначения стереотипов и ключевых слов.
Ключевое слово primary у ассоциации означает, что ассоциированный субъект для этого прецедента является первичным; остальные связанные субъекты - вторичные, они помогают выполнить цель первичного субъекта.
Студент пришел на экзамен с целью "спихнуть". Его ассоциация первичная. Профессор сидит за столом и по мере сил "помогает" студенту сдать экзамен. Без его участия прецедент невыполним. Но он вторичный: у него нет цели принять экзамен.
Учебный центр обращается за лицензией (первичный), надзорный орган дает лицензию (за плату!) - вторичный.
Абстрактные прецеденты (включаемые и расширяющие) соединяются с основным прецедентом пунктирной линией с открытой стрелкой. Связь с включаемым прецедентом (общая часть многих прецедентов) от основного прецедента к включаемому имеет стереотип includ (если пользуетесь "рисовальщиком", пишите метку <<includ>>. Связь с расширяющим прецедентом - от расширяющего к основному, стереотип extend.
Среди параметров есть такие, как стереотип и ключевые слова. Для нужных ассоциаций там нужно написать слово primary.
Если это инструмент рисования, то вместо ваших меток нужно написать <<pimary>>. В угловых скобках помещаются текстовые обозначения стереотипов и ключевых слов.
Ключевое слово primary у ассоциации означает, что ассоциированный субъект для этого прецедента является первичным; остальные связанные субъекты - вторичные, они помогают выполнить цель первичного субъекта.
Студент пришел на экзамен с целью "спихнуть". Его ассоциация первичная. Профессор сидит за столом и по мере сил "помогает" студенту сдать экзамен. Без его участия прецедент невыполним. Но он вторичный: у него нет цели принять экзамен.
Учебный центр обращается за лицензией (первичный), надзорный орган дает лицензию (за плату!) - вторичный.
Абстрактные прецеденты (включаемые и расширяющие) соединяются с основным прецедентом пунктирной линией с открытой стрелкой. Связь с включаемым прецедентом (общая часть многих прецедентов) от основного прецедента к включаемому имеет стереотип includ (если пользуетесь "рисовальщиком", пишите метку <<includ>>. Связь с расширяющим прецедентом - от расширяющего к основному, стереотип extend.
238
Задачи студентов / Re: Курсовая работа
« : 22 Января 2011, 20:47:48 »
Интересно, кто мне прислал сообщение об этой работе? Вроде, я не подписывался?
Тем не менее, по сути.
Вы знаете, для первого раза диаграмма меня порадовала, с учетом того, что, как Вы написали, раньше этим не занимались!
Складывается впечатление, что Вы понимаете, что рисуете.
Первые замечания (не все, чтобы перегрузки не было):
1. Каким инструментом моделирования Вы пользовались? Если MS Visio, то это инструмент рисования картинок, а не моделирования. Но этот инструмент явно не контролировал Ваши действия. В UML стили изображения отношений между элементами имеют смысл. Отношения между субъектами и прецедентами - это ассоциации. Они показываются сплошными стрелками с открытой стрелкой, или вообще без стрелок (чаще всего, ведь в данном случае они обозначают последовательности взаимодействий между субъектом и прецедентом для достижения цели субъекта, а не одностороннюю передаче информации). То, что нарисовали Вы, означает, что, например, элемент "Госгортехнадзор", очень уважаемый (в прошлом) орган, является потомком элемента "Выдать лицензию".
Если бы Вы пользовались инструментом моделирования, он не позволил бы создать такую связь.
2. То, что Вы нарисовали, называется "Диаграмма бизнес-прецедентов". (Термин use case на русском по разному обозначают, я пользуюсь словом "прецедент"). На диаграмме Вы показали бизнес-процессы, которые выполняются при обучении и допуска к работе.
Диаграмма прецедентов сродни каталогу, который перечисляет процессы и их участников, ничего не говоря об их очередности. У Вас в одном месте очередность указана ограничением {если...}. Вряд ли это можно считать ошибкой, но UML этого не предусматривает. Предусловия перечисляются в текстовом описании прецедента.
Очень часто бизнес-модель разделяют в несколько уровней (Не подумайте. что на одной диаграмме, имеются ввиду уровни моделирования!).
Верхний уровень - общий бизнес процесс, например "Подготовка специалиста". Этот процесс описывается в виде текста и/или с помощью диаграммы деятельности. Действия в этой диаграмме - бизнес-прецеденты более низкого уровня, те, которые Вы нарисовали. (См. RUP, Моделирование больших систем при бизнес-моделировании, или книжку Коберна). Вот в диаграмме деятельности верхнего уровня и показывается очередность, если Вам важно это показать.
3. На диаграммах прецедентов не принято определять метки для ассоциаций. Т.к. правилами языка установлено, что взаимодействие с прецедентом должно реализовать цель субъекта. Но, если с прецедентом взаимодействуют два или больше субъектов, то реализуется цель только одного из них. Другие помогают! Ассоциация с субъектом, цель которого выполняется, должна быть помечена ключевым словом <<primary>>. Тогда другие метки будут просто не нужны. И так все понятно.
4. Название прецедента должно отражать цель первичного субъекта. У студента есть желание "столкнуть", наконец, экзамен. Соответствующий прецедент должен называться "Сдать экзамен" или "Сдача экзамена". Это зависит от языковых традиций. В англоязычных странах принята неопределенная форма глагола, в русскоязычных - отглагольное существительное в именительном падеже. Но это неважно, главное одинаково.
На первый случай и так много информации.
Желаю успехов.
Тем не менее, по сути.
Вы знаете, для первого раза диаграмма меня порадовала, с учетом того, что, как Вы написали, раньше этим не занимались!
Складывается впечатление, что Вы понимаете, что рисуете.
Первые замечания (не все, чтобы перегрузки не было):
1. Каким инструментом моделирования Вы пользовались? Если MS Visio, то это инструмент рисования картинок, а не моделирования. Но этот инструмент явно не контролировал Ваши действия. В UML стили изображения отношений между элементами имеют смысл. Отношения между субъектами и прецедентами - это ассоциации. Они показываются сплошными стрелками с открытой стрелкой, или вообще без стрелок (чаще всего, ведь в данном случае они обозначают последовательности взаимодействий между субъектом и прецедентом для достижения цели субъекта, а не одностороннюю передаче информации). То, что нарисовали Вы, означает, что, например, элемент "Госгортехнадзор", очень уважаемый (в прошлом) орган, является потомком элемента "Выдать лицензию".
Если бы Вы пользовались инструментом моделирования, он не позволил бы создать такую связь.
2. То, что Вы нарисовали, называется "Диаграмма бизнес-прецедентов". (Термин use case на русском по разному обозначают, я пользуюсь словом "прецедент"). На диаграмме Вы показали бизнес-процессы, которые выполняются при обучении и допуска к работе.
Диаграмма прецедентов сродни каталогу, который перечисляет процессы и их участников, ничего не говоря об их очередности. У Вас в одном месте очередность указана ограничением {если...}. Вряд ли это можно считать ошибкой, но UML этого не предусматривает. Предусловия перечисляются в текстовом описании прецедента.
Очень часто бизнес-модель разделяют в несколько уровней (Не подумайте. что на одной диаграмме, имеются ввиду уровни моделирования!).
Верхний уровень - общий бизнес процесс, например "Подготовка специалиста". Этот процесс описывается в виде текста и/или с помощью диаграммы деятельности. Действия в этой диаграмме - бизнес-прецеденты более низкого уровня, те, которые Вы нарисовали. (См. RUP, Моделирование больших систем при бизнес-моделировании, или книжку Коберна). Вот в диаграмме деятельности верхнего уровня и показывается очередность, если Вам важно это показать.
3. На диаграммах прецедентов не принято определять метки для ассоциаций. Т.к. правилами языка установлено, что взаимодействие с прецедентом должно реализовать цель субъекта. Но, если с прецедентом взаимодействуют два или больше субъектов, то реализуется цель только одного из них. Другие помогают! Ассоциация с субъектом, цель которого выполняется, должна быть помечена ключевым словом <<primary>>. Тогда другие метки будут просто не нужны. И так все понятно.
4. Название прецедента должно отражать цель первичного субъекта. У студента есть желание "столкнуть", наконец, экзамен. Соответствующий прецедент должен называться "Сдать экзамен" или "Сдача экзамена". Это зависит от языковых традиций. В англоязычных странах принята неопределенная форма глагола, в русскоязычных - отглагольное существительное в именительном падеже. Но это неважно, главное одинаково.
На первый случай и так много информации.
Желаю успехов.
239
Примеры / Re: Пример диаграммы для описания функционирования формы
« : 21 Января 2011, 16:45:46 »
Ну, все зависит от используемой технологии.
Давно тому назад описание формы включали прямо в текст большой программы, и внутри делалось все. Потом граничные классы придумали, которые только принимают и передают на обработку контроллеру. Потом этого показалось мало, и стали обработчики в форму включать. Потом еще чего-нибудь будет!
У меня возражений нет.
Что касается субъекта на диаграмме, то замена его на дисплей вряд ли сделает ее корректнее. Дисплей, скорее всего, не сумеет принять решение в ответ на сообщение формы. К тому же, нужно в нем (в классе, например, который представляет этот дисплей, создать операцию, выполняющую запрос (сообщение).
Но из моей практики, то ограничение, о котором я написал, действительно не является ужасным: субъект реагирует на возвратные сообщения, среди которых м.б. и диагностика о неправильных действиях.
Но все эти рассуждения в пользу бедных. Те, кто регулярно занимаются разработкой, постоянно решают вопросы, как передать ту или иную мысль, и, как правило, успешно, не нарушая синтаксиса и семантики.
Давно тому назад описание формы включали прямо в текст большой программы, и внутри делалось все. Потом граничные классы придумали, которые только принимают и передают на обработку контроллеру. Потом этого показалось мало, и стали обработчики в форму включать. Потом еще чего-нибудь будет!
У меня возражений нет.
Что касается субъекта на диаграмме, то замена его на дисплей вряд ли сделает ее корректнее. Дисплей, скорее всего, не сумеет принять решение в ответ на сообщение формы. К тому же, нужно в нем (в классе, например, который представляет этот дисплей, создать операцию, выполняющую запрос (сообщение).
Но из моей практики, то ограничение, о котором я написал, действительно не является ужасным: субъект реагирует на возвратные сообщения, среди которых м.б. и диагностика о неправильных действиях.
Но все эти рассуждения в пользу бедных. Те, кто регулярно занимаются разработкой, постоянно решают вопросы, как передать ту или иную мысль, и, как правило, успешно, не нарушая синтаксиса и семантики.
240
Примеры / Re: Пример диаграммы для описания функционирования формы
« : 21 Января 2011, 15:19:05 »
На мой взгляд, форма сама поведения не имеет. Поведение "рождается" при взаимодействии с кем-то.
Т.к. этот "кто-то" - внешний, ближе - диаграмма деятельности.
Если нужно очень детально, структура формы м.б. представлена диаграммой классов. Тогда диаграмма деятельности может содержать нужных участников (потоки).
У диаграммы последовательности есть маленькое ограничение по использованию элемента аctor: actor не может иметь операций, а значит не может принимать сообщений, кроме возвратных.
Диаграмма состояний, на мой взгляд, плоха (в этой ситуации) тем, что форма, в отличие от контроллера, не генерирует событий, она их только принимает. Т.е., нарисовать-то можно, наверное, будет понятно, но не шибко корректно.
Т.к. этот "кто-то" - внешний, ближе - диаграмма деятельности.
Если нужно очень детально, структура формы м.б. представлена диаграммой классов. Тогда диаграмма деятельности может содержать нужных участников (потоки).
У диаграммы последовательности есть маленькое ограничение по использованию элемента аctor: actor не может иметь операций, а значит не может принимать сообщений, кроме возвратных.
Диаграмма состояний, на мой взгляд, плоха (в этой ситуации) тем, что форма, в отличие от контроллера, не генерирует событий, она их только принимает. Т.е., нарисовать-то можно, наверное, будет понятно, но не шибко корректно.