Замена UML для контекстной диаграммы
по данным UML контекстная диаграмма контекстная диаграмма не существует.
Поэтому мой вопрос в том, какой из UML-схемы хорошо показать что-то вроде этого и как это нарисовать?
6 ответов
Я нашел следующее определение: http://en.wikipedia.org/wiki/System_context_diagram Это, наверное, то, что тебе нужно. :)
A контекстная диаграмма определяет границу между системой или частью системы и ее среда, показывающая сущности, которые взаимодействуют с ней.
в UML нет ни одной диаграммы, которая соответствовала бы этому определению, но у меня есть хорошие новости - есть несколько диаграмм (out всего 14), которые могут показать границу между системой и окружающим ее миром с разных точек зрения. Это гораздо более гибко, чем просто контекстная диаграмма.
прежде всего, я бы упомянул специальный элемент UML-a граница. Его можно использовать в любом типе диаграммы для того чтобы показать некоторый вид размежевания. Возможно, вы захотите использовать его для визуального разграничения между системой и ее средой, особенно в ситуациях, когда это не является явным.
следующие диаграммы могут показать границу между системой и ее средой:
- диаграмма вариантов использования (ваш пример) поддержка контекста explicitelly на функциональном уровне. Варианты использования элементов системы, в то время как актеры Экстерн extities (систем или пользователей). Ранее упомянутая граница часто используется для визуального разграничения между системой и ее окружением.
- компонент схемы используется для моделирования некоторых программных модулей (приложений, DBs, внешних систем, библиотек и т. д.). Вы можете ise его, чтобы показать как внутренние, так и внешние компоненты и способ их взаимодействия. Границу можно использовать для четкого проведения линии разделения.
- диаграмма деятельности смогите показать ваши процессы системы / дела / использования. Некоторые действия могут быть выполнены внутри, другие-снаружи. Здесь вам не нужна граница, но так называемая роли изобразить, кто что делает.
- схемы последовательности / совместной работы другой вариант. Они показывают последовательности связи между несколькими объектами. Если вы разделите эти объекты на внутренние и внешние и обернете их границами, появится другая контекстная диаграмма. :)
UML является гибким, есть, вероятно, дополнительные варианты, но я думаю, что этого достаточно, чтобы получить идею.
имена вашей ассоциации-это Службы. UseCase в центре диаграммы-это контекст определения служб. См. диаграмму usecase:
Это можно сделать с помощью прецедента
http://en.wikipedia.org/wiki/Use_case
EDIT:
пересмотрев его, диаграмма прецедентов должна быть следующим шагом после определения операций, поэтому сначала вы должны сделать диаграмму последовательности систем.
Я склонен использовать диаграммы совместной работы для этого. Поэтому для каждого основного сценария каждого варианта использования нарисуйте диаграмму сотрудничества, показывающую акторов, с приложением как единым объектом посередине, и сообщения, путешествующие вокруг, которые показывают, как приложение взаимодействует с акторами, чтобы выполнить сценарий.
(Я не кладу слишком много деталей в сообщениях-я лишь хочу показать, что есть делегирование ответственности и какое-то взаимодействие, но я не забота о деталях фактического сообщения, мнения, сведения и т. д.)
Я считаю, что контекстная диаграмма имеет особую привлекательность. Он хорошо сочетается с бизнес-пользователями, показывая им область и стороны системы очень простым способом. Таким образом, я склонен создавать контекстную диаграмму, даже в контекстах, где преобладает UML.
Если вы довольны переходом в не полный суперсет UML, который является SysML, у вас могут быть правильные контекстные диаграммы.
однако контекстные диаграммы в SysML-это просто блок-схемы, показывающие системный контекст... и блок-схемы совпадают с диаграммой классов UML2, где классы имеют стереотип "SysML:: Block".
таким образом, вы можете определить свою контекстную диаграмму с точки зрения агрегации блоков в вашей системе с соответствующим стереотипы, основанные на диаграммах классов UML2.