diff options
Diffstat (limited to 'umbrello/umbrello/umlrole.cpp')
| -rw-r--r-- | umbrello/umbrello/umlrole.cpp | 24 |
1 files changed, 12 insertions, 12 deletions
diff --git a/umbrello/umbrello/umlrole.cpp b/umbrello/umbrello/umlrole.cpp index 939b7167..ca33dffb 100644 --- a/umbrello/umbrello/umlrole.cpp +++ b/umbrello/umbrello/umlrole.cpp @@ -23,10 +23,10 @@ // constructor -UMLRole::UMLRole(UMLAssociation * tqparent, UMLObject * parentObj, Uml::Role_Type role) - : UMLObject(const_cast<UMLAssociation*>(tqparent)) +UMLRole::UMLRole(UMLAssociation * parent, UMLObject * parentObj, Uml::Role_Type role) + : UMLObject(const_cast<UMLAssociation*>(parent)) { - init(tqparent, parentObj, role); + init(parent, parentObj, role); } UMLRole::~UMLRole() { } @@ -59,9 +59,9 @@ TQString UMLRole::getMultiplicity() const { } void UMLRole::setObject (UMLObject *obj) { - // because we will get the id of this role from the tqparent + // because we will get the id of this role from the parent // object, we CANT allow UMLRoles to take other UMLRoles as - // tqparent objects. In fact, there is probably good reason + // parent objects. In fact, there is probably good reason // to only take UMLClassifiers here, but I'll leave it more open // for the time being. -b.t. if (obj && dynamic_cast<UMLRole*>(obj)) { @@ -88,17 +88,17 @@ Uml::Role_Type UMLRole::getRole() { return m_role; } -void UMLRole::init(UMLAssociation * tqparent, UMLObject * parentObj, Uml::Role_Type r) { +void UMLRole::init(UMLAssociation * parent, UMLObject * parentObj, Uml::Role_Type r) { m_BaseType = Uml::ot_Role; m_role = r; - m_pAssoc = tqparent; + m_pAssoc = parent; m_pSecondary = parentObj; m_Multi = ""; m_Name = ""; m_Changeability = Uml::chg_Changeable; - // connect this up to tqparent - connect(this,TQT_SIGNAL(modified()),tqparent,TQT_SIGNAL(modified())); + // connect this up to parent + connect(this,TQT_SIGNAL(modified()),parent,TQT_SIGNAL(modified())); } void UMLRole::saveToXMI( TQDomDocument & qDoc, TQDomElement & qElement ) { @@ -110,7 +110,7 @@ void UMLRole::saveToXMI( TQDomDocument & qDoc, TQDomElement & qElement ) { << "): m_pSecondary is NULL" << endl; if (!m_Multi.isEmpty()) roleElement.setAttribute("multiplicity", m_Multi); - if (m_role == Uml::A) { // role aggregation based on tqparent type + if (m_role == Uml::A) { // role aggregation based on parent type // role A switch (m_pAssoc->getAssocType()) { case Uml::at_Composition: @@ -268,8 +268,8 @@ bool UMLRole::load( TQDomElement & element ) { // Here comes the handling of the association type. // This is open for discussion - I'm pretty sure there are better ways.. - // Yeah, for one, setting the *tqparent* object parameters from here is sucky - // as hell. Why are we using roleA to store what is essentially a tqparent (association) + // Yeah, for one, setting the *parent* object parameters from here is sucky + // as hell. Why are we using roleA to store what is essentially a parent (association) // parameter, eh? The UML13.dtd is pretty silly, but since that is what // is driving us to that point, we have to go with it. Some analysis of // the component roles/linked items needs to be done in order to get things |