The Artima Developer Community
Sponsored Link

Weblogs Forum
Object Design

37 replies on 3 pages. Most recent reply: Feb 18, 2016 8:46 AM by kadirvelu sundaram

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 37 replies on 3 pages [ « | 1 2 3 ]

Posts: 63
Nickname: piglet
Registered: Dec, 2005

UML sucks. Posted: Dec 6, 2005 6:45 AM
Reply to this message Reply
Are there still people who take UML seriously? When I first learnt about UML, I was disappointed. After all, it's not a "language" at all. Soon I realized that it was one of those hypes: Almost nobody actually uses it, except for rather trivial sketches (boxes connected by arrows, that's the "useful" part of UML, nobody bothers about semantic subtleties that allegedly give UML its "power") and to satisfy management. Management usually like it because it has been sold as a "methodology". They don't know that no living software developer ever found a method in that chaos. Of course you can't say this loud if you want to keep your job. Fortunately we can have some fun with UML:

Bertrand Meyer:

UML, a modern dinosaur? A Critical Analysis of the Unified Modelling Language

Chris Date:

The emperor really has no clothes ;-)

Pablo Mirones

Posts: 1
Nickname: aeronautic
Registered: Mar, 2006

Re: Object Design Posted: Mar 18, 2006 2:24 AM
Reply to this message Reply
I'm eager to see the evolution of flow diagrams. This is what engineering industry demands, something similar to the previous procedural methods.

Aeronautical engineers need to calculate with variables and functions, whatever is the class they belong to. This way we can debug the data flow, and where is the wrong calculation.

UML tools came as a tsunami over CASE tools (Computer Aided Software Engineering), but the procedural approach is not obsolete at all. I agree with this lack of flow data information regarding UML. There should be another point of view of the model called for example "flow diagram". The compiler elaborates this database, able to answer questions such as these:

- what is the domain of propagation of a variable through the data flow (which functions call the Get() or Set() function).

- which calculations depend on the value of this variable

- ...

In fact, the OO compilators do that job of rearranging in memory the human OO design to a machine procedural design, with an only entry point, variables instantiated of only int-double-char type, and calling functions of hierarchical structure.

A variable is a procedural-like variable, and a function is a procedural-like function, even if they are member of a class. Also virtual functions appear in memory as procedural-like functions, once an object is instantiated.

ibrahim ALShehri

Posts: 6
Nickname: ibh3000
Registered: Oct, 2005

Re: Object Design Posted: Mar 19, 2006 6:27 AM
Reply to this message Reply
Thank u Bruce for this nice post

There are people that will argue with this, saying that it's generally a good idea but that because of this or that special case we must add these extra steps or that complexity (a big argument is: "so that the method will scale" -- this produces a method that promises to scale but that doesn't get used because it's too complex). In my experience this falls into the same trap as premature optimization or any other form of mixing abstraction levels that we, as programmers, are prone to.

i totaly agree with this !

The structure chart only expresses the relationships between classes, not how they interact

to show how they interact , u can use "Sequence Diagram" it shows objects interactions !

From experience, you know that you'll move forward a lot faster by moving on, into a design pass, or even by pseudocoding your design (in a couple of instances we used Python to try out a design; this worked remarkably well in producing new insights about that design). In addition, you can "backfill" user stories and design details as you uncover new factors, so you don't need to feel like an incomplete design must hold you back. The experience I had was very rapid and liberating; we could often punch through into designs and insights that had been holding people back for

i think this is applied in XP = Extreme Programming

by the way , (as some fan of XP told me) there is no use of UML and modiling in XP :)

in not that great !? :D

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Object Design Posted: Mar 20, 2006 2:54 AM
Reply to this message Reply
Object-orientation is way too overestimated as a design methodology. What solves problems is functions. Object-oriented programming is nothing more than pattern matching (i.e. function selection) based on type.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Object Design Posted: Mar 20, 2006 3:05 AM
Reply to this message Reply
I would also like to point out to a really simple design technique that is not too technical, not too mathematical and does not require much work. Here is a sort description:

1) scan the requirements for verbs and nouns.
2) make the nouns classes/fields, and the verbs methods.
3) "normalize" the design by placing common fields/methods to base classes/interfaces.
4) done!

shreshtha kumar

Posts: 1
Nickname: shreshtha
Registered: May, 2007

Re: Object Design Posted: May 30, 2007 12:04 AM
Reply to this message Reply
Great post.

Being in small embedded design domain, I never worked on UML. But OO always fascinated me as every IC here acts as object which interact with other objects.

2nd 3rd and 4th para says a lot about how to keep separated abstraction and complexity.
But I am not able to understand completely what exactly he mean to say or express.

I feel that OO concepts really help while coding in C atleast in modular design and design which lives long in terms of it up-gradation etc.(here comes the theory of making design simple).

Can any one plese refer me any doc which explains what things to keep in mind while designing a software system like what level of abstractions I create, how and where memeory management should be kept.
(If you are not getting the context of above - think of Linux, its design. I create any framework with this arch as role model apart from all the domain my framework should cater)

Hope any one got what i want to say!!!
Bringing/using modeling concepts in C.


Rob Casper

Posts: 1
Nickname: casperr0
Registered: Aug, 2007

Re: Object Design Posted: Aug 17, 2007 2:05 PM
Reply to this message Reply
Enjoyed the comments Bruce and others - made me chuckle.

In my experience the real crux of the matter is getting to grips with Business Process. Unfortunately time and again I have discovered that often, some or even all stakeholders do not understand their own and colleagues' business process. Process is frequently driven by company/shop floor culture or tradition, often unnecessary or redundant or with glaring holes.

End users of a software solutions will create a process of their own to get work done in a way that suits the "real process", adding their own process to the software solution rather than how the analysts/developers and other facilitators think it is being done - enter the bolt-on.

Getting to the bottom of this if stuff is crucial in my experience; this holds true for me whether it be a new solution or a proposed improvement. Developers can use what method they like - you will deliver only what you think or are even convinced is required if you do not discover how well the various stakeholders know their own processes.

I have used several "soft" methodologies, none of which capture the whole picture but combinig parts has got me close - horses for courses. Further I find them invariably too large and cumbersome.

Useful things I have used: CUSTOM - a stakeholder analysis method Developed between The university of Huddersfield and Hull University.

Another I mix is IDEF03 which is a Business process methodology - this is great for trapping business logic (only when it is discovered what is really required/expected beforehand) - needs a little effort to grasp but once done, well worth it in my view.

The other mix I like is FDD ( Feature Driven development ), I wrote a prototype tracking tool based on this which I am experimenting with currently.

By taking out a subset from each of these I combined them without initially realizing it; interestingly each subset is a seven + or - 2 as commented by Bruce - easy to keep in the head. The other thing to note is that these combined subsets are Implementation-Independent in terms of platform, language, persistence and general architechture.

Regarding Bruce's comments on complete capture, I find that it is possible to capture a general expectation governed by mutual sign-off between the various stakeholders; as an agreed rule anything more than this is acknowledged additional, requiring additional agreement if added to the process and requirements. Hence the methodologies can be viewed as dynamic - Agile if you like, but crucially - still implementation independent, and naturally scalable.

Rob C.

kadirvelu sundaram

Posts: 1
Nickname: seeker16
Registered: Feb, 2016

Re: Object Design Posted: Feb 18, 2016 8:46 AM
Reply to this message Reply
I am also guilty of seeking completeness.
your comments about accepting incompleteness keep moving forward is inspiring.

Flat View: This topic has 37 replies on 3 pages [ « | 1  2  3 ]
Topic: What is "The Best" Arduino kit? Previous Topic   Next Topic Topic: ScalaTest 3.0 Preview

Sponsored Links


Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use