2013-08-05 3 views
3

Я пытаюсь создать модель, которая позволит мне захватить владельцев, пользователей & активов в данной организации. Кажется, я попал в камнем преткновения, так как не могу ответить на приведенные ниже вопросы, а также не знаю, правильно ли я смоделировал его.Есть ли лучший способ моделирования в UML?

  1. Как выразить право собственности и пользователя на данный актив?
  2. Как выразить права собственности и использовать значения для объекта, например. серверный объект имеет стоимость поставщика IBM и принадлежит ABC Corp и используется пользователем DEF.
  3. Есть ли способ, которым я могу дополнительно отделить общие атрибуты или свойства, например. имя, местоположение? Есть ли необходимость в дальнейшем отделить это?
  4. Как оценить поведенческие ограничения, например. что произойдет, если пользователь покинет организацию или объект поврежден? Где я могу взять эту информацию, если не в модели?

Пример модели

enter image description here

EDIT

В дополнение к ответам, я обновил свою модель. Не уверен, что он идет по правильному пути.

enter image description here

ответ

2

EDIT: В ответ на замечания OP:

Re. запись информации о собственности и т. д. Вот пример: enter image description here

Главное, что дата, приобретенная/проданная и т. д., является атрибутом отношения между Активом и Организацией/Пользователем. Они не являются атрибутами участвующих классов. В этом примере Asset Use позволяет использовать несколько одновременных пользователей, тогда как Asset Ownership позволяет только одному владельцу в любой точке. Это контролируется множественностью.

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

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

Например, атрибут имени у владельца будет иметь название организации, однако атрибут name под сервером будет иметь имя сервера, а именно FQDN.

ОК: тогда у вас могут быть разные типы данных для двух имен. Возможно, простая строка для организации и определенное полное доменное имя для Asset. Но помните: это означает, что все Активы должны быть названы с использованием полного доменного имени. Если только компьютеры названы с полным доменным именем, тогда поместите атрибут имени на компьютер, а не в Asset. В стороне: для организаций довольно часто иметь схему именования активов, которая не зависит от типа актива. Единственное требование - уникальность. Например, я показал это выше. НТН.

End Edit

Ответ на ваши конкретные вопросы:

Как выразить собственность [..] для данного актива?

Предположительно, это то, что охватывает община Organisation - Asset? Если да, то какая кратность? Предположительно:

  • Каждый объект принадлежит одной организации или может быть актив совместно владеть?
  • У каждой организации есть много (ноль или более) активов?
  • Вам нужно записать любую информацию о собственности - например, когда был приобретен актив, когда он был продан и т. Д. Если это так, вам понадобится класс ассоциации для его захвата.

Как выразить пользователя за данный актив?

Похожие вопросы, как указано выше. Могут ли многие пользователи использовать один и тот же актив? Одновременно или последовательно? Нужно ли записывать даты начала и окончания использования активов?

Как выразить [..] объект сервера имеет значение поставщика в IBM

Вы это смоделированный с атрибутом Asset.vendor - что может быть достаточно. Однако: вам нужно фиксировать какие-либо детали для поставщиков? например контактную информацию, адрес, контракты на поддержку и т. д. Если это вам понадобится, вам придется разделить отдельный класс поставщика.

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

Все 3 подкласса имеют те же атрибуты. Это плохо пахнет - это говорит о том, что они не совсем разные. Не могли бы вы использовать один класс (Asset), который захватывает все атрибуты - и имеет дополнительный «assetType» (или аналогичный) с правовыми значениями «Сервер», «Депоп», «Ноутбук»? Однако: вам нужно отслеживать активы, которые не являются компьютерами какого-либо типа? Если так, один класс Asset недостаточно гибкий.

Как оценить поведенческие ограничения, например. что произойдет, если пользователь покинет организацию или объект поврежден?

В зависимости от требований вашего бизнеса. Что должно произойти, если пользователь уйдет? Если у актива просто нет Пользователей? В этом случае связь должна быть необязательной (0 .. *).

Что означает повреждение актива? Нужно ли записывать убытки? Если так, вам нужен другой класс.

Где я могу взять эту информацию, если нет в модели?

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

Вообще-то я бы порекомендовал вам несколько раз подумать о множественности ассоциаций между именами &. Это, несомненно, вызовет вопросы о требованиях и/или ограничениях домена. Это поможет вам получить модель, которая имеет гораздо больше шансов удовлетворить требования.

hth.

+0

Спасибо за подробный ответ. На данном этапе нет требования о совместном владении активом. Это не значит, что этого никогда не произойдет. Как смоделировать возможность его возникновения? Я не понимаю вашего комментария. «Нужно ли записывать любую информацию о владении - например, когда был приобретен актив, когда он был продан и т. Д. Если это вам понадобится, класс ассоциации для его захвата». I необходимо записать такую ​​информацию. – PeanutsMonkey

+0

Что касается вашего вопроса 'Похожие вопросы выше. Могут ли многие пользователи использовать один и тот же актив? Одновременно или последовательно? 'Да, несколько пользователей могут использовать один и тот же актив, и это может происходить одновременно или последовательно. Например, сервер базы данных будет иметь одновременно работающих пользователей. – PeanutsMonkey

+0

Что касается моего вопроса относительно объектов времени выполнения, я хотел сказать, что есть требование отображать как владельца, так и пользователей. Как бы я показал это, увидев, что этот актив не является подклассом или подтипом владельца или пользовательского класса? – PeanutsMonkey

3

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

На вопрос 3, вы можете использовать общий абстрактный класс, как это:

asset ownership UML Class diagram http://app.genmymodel.com/engine/xaelis/assetOwnership.jpg

Вы можете использовать эту link, если вы хотите, чтобы сделать копию и адаптировать эту модель.

+0

Спасибо Xaelis. Есть ли лучший термин, чем сущность? Я начал с того же подхода, что и вы предложили, однако люди, которых я показал модель, были смущены термином «сущность». Причина, по которой я хочу уловить такие ограничения, как повреждение, заключается в том, что она предоставляет исторический контекст для таких аспектов, как, например, кто был пользователем в то время, что было повреждено и, возможно, заменено, и т. Д. Наконец, как я могу показать объект, отображающие значения времени выполнения для владения, пользователей и т. д., особенно если актив не является специализацией или обобщением пользователя. – PeanutsMonkey

+0

Возможно, лучшим термином, чем объект, может быть NamedElement или LocalizableElement. Если вам нужна история события повреждения, вы облака добавьте класс Damage, который может записывать всю информацию о таком событии (дата, местоположение, пользователь и организация в это время ...). – Xaelis

+1

Использование общей базы только потому, что два класса имеют общее имя и местоположение, очень сомнительны. Эти подклассы должны иметь общую семантику; это не должно быть просто удобством для сохранения ввода текста. Однако хорошо, что ваша модель имеет множественность и определенные роли. Они могут быть или не быть правильными - это будет зависеть от требований. Но хорошо, что это поднимает вопрос. – sfinnie

Смежные вопросы