Abstract classes in Umple (Issue 76)

[Jordan Johns]

I've began work on implementing support for abstract classes in Umple.  Commiting initial groundwork as a basis to work off of to fully implement the feature.

Classes can be recognized as abstract now, however they do not follow the rules and conventions of abstract classes because the behaviour is not enforced (that is coming).

You can do this as follows:

class Student

{

     abstract;

}

Much like the convention that was followed with Singleton and Immutable.

See r1591

- Jordan

[Timothy Lethbridge]

Hi,

This is good.

Tim

> --
> You received this message because you are subscribed to the Google Groups
> "Umple-Dev" group.
> To view this discussion on the web, visit
> https://groups.google.com/d/msg/umple-dev/-/vuZEy4SupOwJ.
> To post to this group, send an email to umpl...@googlegroups.com.
> To unsubscribe from this group, send email to
> umple-dev+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/umple-dev?hl=en-GB.
>
>

Timothy C. Lethbridge, PhD, P.Eng., I.S.P., CSDP
Professor of Software Engineering and Computer Science
/ Professeur Titulaire de g�nie logiciel et d'informatique
Facult� de genie / Faculty of Engineering
University of Ottawa / Universit� d'Ottawa
Tel: 613-562-5800x6685 Fax: 613-562-5664 Mobile: 613-252-1850
http://www.eecs.uottawa.ca/~tcl

[Jordan Johns]

Abstract classes are now implemented such that an Umple class with the "abstract" keyword present causes the generated java code to contain the associated abstract class.  See r1619.

I've been thinking about enforcing abstract class constraints, such as the primary concern around enforcing that it cannot be instantiated and I was wondering if I should proceed on this as there is a potential huge refactoring that will have to happen in the parser.  Assuming I were to proceed, I would rework the parser such that when things are parsed into tokens I would check each and every single one against currently known abstract classes that have been parsed thus far.  This problem is two fold, both quite obvious:

1)  The parser would essentially have to be torn appart since this code has to be heavily interweaved.

2)  Massive performance overhead.  If everything that is parsed has to go through a search to ensure that an abstract class was not instantiated then we effectively add an O(n) time complexity on top of everything (where n is the number of abstract classes).  I'm wondering if this is worth it, or if there is a better way (I think there is, but I'm wondering about the complexity).

Should I proceed with this, or should the stance be taken that the programmer is responsible and won't attempt to instantiate an abstract class anywhere in the code?

Side note:  I was wondering if there are any other constraints that should be taken into consideration, as the only one that seems to come to mind is that abstract classes must be subclassed before being used.

Thanks!

- Jordan

On Friday, March 16, 2012 5:53:38 AM UTC-6, Timothy Lethbridge wrote:

Hi,

This is good.

Tim

On Thu, 15 Mar 2012, Jordan Johns wrote:

> I've began work on implementing support for abstract classes in Umple.

> �Commiting initial groundwork as a basis to work off of to fully implement

> the feature.
> Classes can be recognized as abstract now, however they do not follow the
> rules and conventions of abstract classes because the behaviour is not
> enforced (that is coming).
>
> You can do this as follows:
>
> class Student
> {

> � � �abstract;

> }
>
> Much like the convention that was followed with Singleton and Immutable.
>
> See r1591
>
> - Jordan
>
> --
> You received this message because you are subscribed to the Google Groups
> "Umple-Dev" group.
> To view this discussion on the web, visit
> https://groups.google.com/d/​msg/umple-dev/-/vuZEy4SupOwJ.
> To post to this group, send an email to umpl...@googlegroups.com.
> To unsubscribe from this group, send email to

> umple-dev+unsubscribe@​googlegroups.com.

> For more options, visit this group at
> http://groups.google.com/​group/umple-dev?hl=en-GB.
>
>

Timothy C. Lethbridge, PhD, P.Eng., I.S.P., CSDP
Professor of Software Engineering and Computer Science

/ Professeur Titulaire de g�nie logiciel et d'informatique
Facult� de genie / Faculty of Engineering
University of Ottawa / Universit� d'Ottawa

[Andrew Forward]

I would leave it. 

At is point we don't "know" enough about all the possible code that people could write (ie we don't parse all of the extra code).

I think it is a more worthwhile effort to have compile time errors from the underlying target language bubble up nicely into umple (and once that gets working well we get the check for abstract instantiations for free).

On 2012-03-23, at 6:38 PM, Jordan Johns <jordan...@gmail.com> wrote:

Abstract classes are tnow implemented such that an Umple class with the "abstract" keyword present causes the generated java code to contain the associated abstract class.  See r1619.

To view this discussion on the web, visit https://groups.google.com/d/msg/umple-dev/-/tbf7AV5pqcYJ.

To post to this group, send an email to umpl...@googlegroups.com.

To unsubscribe from this group, send email to umple-dev+...@googlegroups.com.

[Timothy Lethbridge]

This is excellent Jordan. Thanks.

I agree with Andrew's comments, that leaving the detection of breaking of
abstract class rules to the base language compiler would likely be the
best approach for now.

> > https://groups.google.com/d/?msg/umple-dev/-/vuZEy4SupOwJ.

> > To post to this group, send an email to
> umpl...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > umple-dev+unsubscribe@?googlegroups.com.

> > For more options, visit this group at

> > http://groups.google.com/?group/umple-dev?hl=en-GB.

> >
> >
>
>
> Timothy C. Lethbridge, PhD, P.Eng., I.S.P., CSDP
> Professor of Software Engineering and Computer Science
> / Professeur Titulaire de g�nie logiciel et d'informatique
> Facult� de genie / Faculty of Engineering
> University of Ottawa / Universit� d'Ottawa
> Tel: 613-562-5800x6685   Fax: 613-562-5664    Mobile:
> 613-252-1850

> http://www.eecs.uottawa.ca/~?tcl

>
> --
> You received this message because you are subscribed to the Google Groups
> "Umple-Dev" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/umple-dev/-/tbf7AV5pqcYJ.

> To post to this group, send an email to umpl...@googlegroups.com.
> To unsubscribe from this group, send email to

> umple-dev+...@googlegroups.com.

> For more options, visit this group at
> http://groups.google.com/group/umple-dev?hl=en-GB.
>
>

Timothy C. Lethbridge, PhD, P.Eng., I.S.P., CSDP
Professor of Software Engineering and Computer Science

/ Professeur Titulaire de génie logiciel et d'informatique
Faculté de genie / Faculty of Engineering
University of Ottawa / Université d'Ottawa

[david talagrand]

Hi there,

I know it's an old subject, but is it possible to implement the support of abstract class in PHP classes ? 

I use Umple on each project start and prefer it to Dia.

Best regards.

[Timothy Lethbridge]

Hi David

Glad to hear you are using Umple, and thanks for pointing out 'dia'. It is
nice to see that Umple does a whole lot more than Dia.

Implementing 'abstract' in PhP, as you say, is longstanding issue 76
http://code.google.com/p/umple/issues/detail?id=76

I have increased the priority of it and marked it as 'not owned' by
anyone. Hopefully one of the developers could pick do it since it is a
relaively quick task.

Tim

On Tue, 18 Jun 2013, david talagrand wrote:

> Hi there,
> I know it's an old subject, but is it possible to implement the support of
> abstract class in PHP classes ?
> I use Umple on each project start and prefer it to Dia.
>
> Best regards.
>

> Le vendredi 16 mars 2012 05:05:35 UTC+1, Jordan Johns a ￜcritￜ:

> I've began work on implementing support for abstract classes in

> Umple. ï¿œCommiting initial groundwork as a basis to work off of

> to fully implement the feature.
> Classes can be recognized as abstract now, however they do not follow
> the rules and conventions of abstract classes because the behaviour
> is not enforced (that is coming).
>
> You can do this as follows:
>
> class Student
> {

> ￜ ￜ ￜabstract;

> }
>
> Much like the convention that was followed with Singleton and
> Immutable.
>
> See r1591
>
> - Jordan
>

> --
> You received this message because you are subscribed to the Google Groups
> "Umple-Dev" group.

> To unsubscribe from this group and stop receiving emails from it, send an
> email to umple-dev+...@googlegroups.com.

> To post to this group, send an email to umpl...@googlegroups.com.

> Visit this group at http://groups.google.com/group/umple-dev.
> For more options, visit https://groups.google.com/groups/opt_out.

>
>
>
>


Timothy C. Lethbridge, PhD, P.Eng., I.S.P., CSDP
Professor of Software Engineering and Computer Science

/ Professeur Titulaire de gï¿œnie logiciel et d'informatique
Facultￜ de genie / Faculty of Engineering
University of Ottawa / Universitￜ d'Ottawa