facebook

Reabstracting the diagram

  1. MyEclipse Archived
  2.  > 
  3. UML Development
Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • #265445 Reply

    Paul Cahill
    Member

    Hello All,

    One aspect of UML modelling that is important is the ability to re-abstract a design by shifitng methods and or attributes from one class to another. I should be able to open any class attribute and operation window and hock an attribute or operation then drag from one class to another. This should also be the case in the navigation tool. The only way to do this at present is to open the properties panel and copy the text of an attribute and paste in in the property sheet of a blank new attribute on a different class.

    Regards,

    Paul Cahill

    #265486 Reply

    Riyad Kalla
    Member

    Paul,
    Never having done this, what are the advantages to this… does it help “eyeball” the design of a system faster?

    #265511 Reply

    Paul Cahill
    Member

    @support-rkalla wrote:

    Paul,
    Never having done this, what are the advantages to this… does it help “eyeball” the design of a system faster?

    I hope you know the door you have opened….javascript:emoticon(‘:wink:’)
    Wink

    An important part of Object Oriented Analysis and Design is that it is an iterative process of:

    Analysis -> Design -> Implement -> Test -> Evaluate ->|
    ^
    | ………………………………………………………………….<-

    After the first time around the loop you may need to re-abstract the design by moving behaviour and common attributes to where they should be as this is only seen through experience of the current design. This is one of the most significant advantages of modelling a system as opposed to coding a system.

    The more times you are able to go around this loop and the faster you loop, the more your model will start to reflect the reality of the domain you are modelling. The more experienced you are at OOA/D, the less you need to actually implement. Testing can be done by running your Use Case Scenarios through the design.

    Over time, the Analysis and Design provide less fruitful change and the real job of implementation and testing commences and artefacts of the completed system can be delivered. On projects I’ve managed, we generally tried to drop off artefacts every fortnight so that the users (customers) can evaluate its usability and give feedback to the team. They also provide valuable systems testing.

    The point is, it is far more efficient to modify a design by re-abstracting it than later when you need to refactor an implementation. Some people confuse re-abstraction with refactoring, however when I was trained (in the early 90s), we referred to the process of re-abstracting as generally moving the behaviour to the more abstract end of the model which is quite often actually into Abstract classes that form the base classes of derived concrete classes that have specialised additional attributes and behaviour. We may also need to move properties from some classes into appropriate specialised utility classes.

    I prefer to use Abstract classes as opposed to Interfaces as you can achieve the same thing using an Abstract class as an interface, however you can also group the common attributes.

    Interfaces only allow behavioural abstraction and don’t allow for the common attributes that may also play a part, they are quite often used as a poor mans multiple inheritance. Most C++ developers run into problems with multiple inheritance due to canonical forms that create multiple object instances in the base classes when this form occurs in a design.

    I always thought Bjarne Stroustrup made a mistake when he designed the language as he should have made inheritance Virtual by default as this would have prevented this from becoming an issue. The bugs caused by these problems tends to make the hair on most senior engineers rise as it creates unpredictable bugs that are really hard to find. Virtual by default would have declared that only one object in the base was needed by default which is the case in 99% of systems. I believe this is why multiple inheritance is shied away from as it has provided some real pain for the inexperienced. What a shame though, if you’ve used multiple inheritance in anger, it fantastic.

    I always associate refactoring as reworking the model that results from a reverse engineered model.

    So yes if you’re developing a new UML modelling tool, re-abstration is very important. Most of the leading tools like TogetherJ and Rational do this quite naturally.

    Regards,

    Paul Cahill
    0414 888 141

Viewing 3 posts - 1 through 3 (of 3 total)
Reply To: Reabstracting the diagram

You must be logged in to post in the forum log in