2015-01-04 3 views
1

Я думал, что на диаграмме классов в UML, в которой вы создаете класс, и указываете его атрибуты, вы определяете только все атрибуты класса, которые могут/должны быть найдены в конструкторе-методе класса , , когда я попытался обратное проектирование моего (python-) кода с визуальной парадигмой, каждый атрибут был показан в сгенерированных классах (объявленных в конструкторе и объявленных в других методах класса).только атрибуты списка, определенные в конструкторе класса?

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

может кто-нибудь скажет мне, если я ошибался в своем предположении или если VP-код-генератор ошибочен. заранее спасибо.

+2

Список атрибутов класса и список аргументов, переданных конструктору класса, являются полностью независимыми понятиями. Например, некоторые языки (C++, TypeScript, ...) автоматически принимают пустой неявный конструктор с 0 аргументами, если программист не говорит об ином. См. Также http://www.uml-diagrams.org/class-diagrams-overview.html. Это то, о чем вы просите? – xmojmr

+1

спасибо, я все еще читаю эту ссылку.но я не имел в виду аргументы, переданные конструктору класса. Я имею в виду атрибуты, которые я создаю «самостоятельно» в методе конструктора. Я думал, что я их пишу только в атрибутах-купе класса в умле. или же купе также должен содержать каждый атрибут класса, который я мог бы создать в разных методах класса. – coffeekid

+1

Добавьте код python к вопросу и скриншоту диаграмм классов, созданных VP, чтобы проиллюстрировать вашу проблему более ощутимо. Все атрибуты, которые класс когда-либо будет использовать/имеют (независимо от того, когда они появляются во время выполнения), должны находиться в отсеке атрибутов. Предполагается, что диаграмма класса UML представляет собой статический неизменный вид структуры класса. Это то, о чем вы просите? – xmojmr

ответ

2

TL; DR Обратный инженерный автомат визуального парадигмы в этом отношении кажется вполне подходящим.


Sparx Systems → UML 2 Tutorial → Class Diagram

Диаграммы классов

Класс диаграмма показывает, строительные блоки любой объектно-ориентированной системе. Диаграммы классов представляют собой статический вид модели или части модели, описывающий, какие атрибуты и поведение они имеют, а не детализируют методы достижения операций. Диаграммы классов наиболее полезны для иллюстрации взаимосвязей между классами и интерфейсами. Обобщения, скопление и ассоциации являются всеми ценными в отражении наследования, композиция или использования, а также соединения соответственно ...

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

The UML Class Diagram должен представлять статический неизменны («время компиляции») вид наибольшей структуры возможно памяти (состоит из блоков, называемых классами) и попадает в категорию UML Structure Diagrams.

Если вы хотите документ (UML -WAY) когда некоторые атрибуты получают определенное значение во время выполнения то вы должны были бы использовать некоторые из диаграмм, входящих в UML Behavior Diagrams категорию.

Модель класса UML может быть превращена в компьютерно-исполняемую модель на некоторых языках (например, JavaScript) очень динамичным и полиморфным способом. Это только проблема, связанная с реализацией, то, что UML не очень заботит слишком много. То, что UML заботится примерно в основном Platform-independent model (PIM).

+0

спасибо за ответ. но вы бы указали только один атрибут в атрибуте-compartement этого класса, если у вас еще нет композиции, составленной между классом и другим классом, который является типом соответствующего атрибута, правильно ?. я имею в виду, что для каждого атрибута вам нужно выбирать между его перечислением в отсеке атрибутов и составлением ассоциации, верно ли это? – coffeekid

+1

@coffeekid вы можете показать его как атрибут или ссылку или и то, и другое. Это похоже на http://stackoverflow.com/a/27216132/2626313. Что действительно важно, так это если в модели UML (невидимая вещь, которую инструмент использует как «бэкэнд»), и ее можно объединить в другой UML-совместимый инструмент в [XML Metadata Interchange (* .xmi)] (http: //en.wikipedia.org/wiki/XML_Metadata_Interchange), ассоциации правильно смоделированы. Иногда я использую функцию генерации кода инструментов, чтобы посмотреть на модель с точки зрения исходного кода. Генераторы кода Java часто довольно близки. – xmojmr

+1

еще раз спасибо. последний намек в вашем комментарии тоже очень помог. :-) просто, чтобы избежать путаницы, я должен добавить к этому, что вы не будете называть его ссылкой. потому что ссылка является экземпляром ассоциации. поэтому ассоциация соединяет два класса, и связь будет соединением между двумя объектами. – coffeekid

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