The Artima Developer Community
Sponsored Link

Weblogs Forum
Object Design

36 replies on 3 pages. Most recent reply: Aug 17, 2007 5:05 PM by Rob Casper

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 36 replies on 3 pages [ « | 1 2 3 | » ]
Bruce Eckel

Posts: 874
Nickname: beckel
Registered: Jun, 2003

Re: Object Design Posted: Jun 18, 2005 12:52 PM
Reply to this message Reply
Advertisement
> Interesting post. I'd second the request that I'd *really*
> like to see some of the diagrams you came up with.
>
> UML looks to me like it has the curse of all *diagramming*
> methods. It loses a sense of time in a way that text
> somehow doesn't. Maybe because text still has a temporal
> dimension (or flow down the page) you sense time passing
> as you read it. Looking at diagrams, your eyes wander
> backwards and forwards across a static landscape, trying
> to find the movement.

Exactly what I discovered. Various different types of UML diagrams show different types of "movement" but those tools are too far into the details; you don't get a big picture of what this system is doing. My theory is that most of the time you can figure out the low-level details without the UML activity, sequence, collaboration, or state diagrams. But we really need a more general diagram that, in conjunction with the static structure chart (which is certainly useful), allows us to see "the movement," as you say.

Peter Booth

Posts: 62
Nickname: alohashirt
Registered: Aug, 2004

Re: Object Design Posted: Jun 18, 2005 11:02 PM
Reply to this message Reply
Every 18 months for the past ten years I install a demo of Rational Rose,
TogetherJ or some similar UML tool. Rose is a faecal piece of software, with appalling usability. I am yet to add any value through the use of a UML/Case/MDA tool, which is frustrating. What do Corba, UML, EJB spec all have in common? They were all authored by committe and all belong in the toilet.


I heard someone asked Martin Fowler which UML tool he used in a lecture at JavaOne six years ago and his response was "a whiteboard and colored markers."

There was a half interesting book published five years ago about visualizing software architecture that detailed different diagramming styles and classified them. It was an interesting if academic read but confirmed that diagraming systems is really hard to do or even talk about doing.

In my experience:
1) "Requirements" are best expressed as Use Case text descriptions
2) Object discovery seems to work best with a CRC card, which forces a simple approach
3) UML is great to justify an apporach to management after the fact, but not really for much else
4) Object interaction diagrams are interesting but not worth the time investment to create
6) Runtime structure can often be best viewed by drilling into sdomething akin to Borland OptimizeIt's thread debugger.

Eric Armstrong

Posts: 207
Nickname: cooltools
Registered: Apr, 2003

Re: Object Design Posted: Jun 19, 2005 2:34 PM
Reply to this message Reply
> ...it's really, really important that a design
> method be simple...you need to be able
> to hold the method in your head, which means
> that it must conform to the "seven plus-or-minus two" rule
> ....
> First, when walking through use cases/user stories,
>... we found that a very simple form of structure diagram
> would suffice (showing class names only)
> ....(it captures) the domain model
> ... but it lacks an essential ingredient: mechanism.
> ....
> (leading to) a "flow diagram" (that shows) the flow
> of objects and messages through the system of
> objects. This diagram (shows) the relationship of
> higher-level objects and (how) they accomplish their
> tasks. It also seems to show threading...focus(ing)
> on the way that objects are wired together
> to build a system and the dynamics of that system
> ....
> I don't have a "finished" approach for flow diagrams,
> but the idea continues to reappear and evolve.</p>
>
Too right! The design process must be simple. A simple structure diagram *does* illustrate the domain, and what's needed is some way to see how things *work*.

After identifying objects, the only other UML tool I use is the object-interaction diagram. I like the static diagram, because it's the simplest, but I agree with Alan Holub that the dynamic diagram he recommends compresses more information into a smaller space. (I just haven't gotten as used to reading it as he has.)

Diagramming one per use case is generally sufficient to capture the relevant detail. (The trick is to spot inconsistiencies or overlaps in the detailed structure. That's when it's actually helpful to have a more detailed structure model.)

But as useful as they are, those tools frequently fail to capture the somewhat "incestuous" relationships between objects where, for example, object A creates B and sends itself to B, after which B invokes a method in A, and passes itself! The really interesting patterns are filled with those kinds of difficult-to-visualize relationships, because there doesn't seem to be any *good* way to capture them on a flat page.

Our diagramming tools are great for physical machines, because the parts just sit there. But in software, the parts move around. An object-oriented system moves data around, it also moves functionality around. That's the essence of the complexity. Not only do our diagramming tools break down, but our capacity to visualize the interactions *also* breaks down.

Personally, I've been inclined to think that animation may be necessary to show the relationships. It's only in the last year or two that I really began to sense the potential of incestuous relationships--because it was only after several years of working with objects that I really began to *see* how such things work--for example, in the strategy pattern where I set up a generalized perform(S) method in a domain object, and then send the perform(S) method a Strategy object--an object which, by rights, is not part of the domain at all, but is simply a convenient mechanism that allows code reuse. The perform(S) method then invokes S.execute(me), passing itself as the argument so the Strategy object's ececute can do whatever manipultation it was designed to perorm, but do so on or with the original domain object.

Similarly, in one application I made an inner singleton to report errors so I'd have an object that could record whether or not any errors had ever occurred, and query it find out whether or not the program should proceed--much later in the process, after all of the basic processing had been performed, so that the program would find all errors in the input data, instead of stopping after the first. That too, is an example of a non-domain object that makes coding easier, but which makes the resulting system more difficult to visualize.

If you have a diagramming technique that promises to show those kinds of dynamic interaction, you are truly on to something. Let me know if I can be of help as you develop it further.

shahzad bhatti

Posts: 1
Nickname: sbhatti
Registered: Jun, 2005

Re: Object Design Posted: Jun 20, 2005 10:48 AM
Reply to this message Reply
I agree that UML is too complexed for most people (technical and business folks alike). However, can you describe how your flow diagram is different from the activity diagram as you can show flow and concurrency using forks/swim lanes. In general, I use hand-drawn UML for only high level design (which is less likely to change) and use forward/backward engineering tools like Eclipse-UML for detailed design with all attributes and methods. In the end, the purpose of design is to communicate shared understanding of the system, and if business people or technical folks are not fluent in UML. I don't think we need another formal modeling language, instead any block diagram can work. In this economical crunch time, I would hate to spend time on drawing pretty UML diagrams if they are not directly benefiting the clients, which is also advocated by most agile practices. I also agree is that using UML for MDA is doomed because of its complexity and no business person will understand it.

Shashank D. Jha

Posts: 68
Nickname: shashankd
Registered: May, 2004

Re: Object Design Posted: Jun 20, 2005 11:57 AM
Reply to this message Reply
> <p>There were many side issues surrounding that idea, but
> everything always came back to objects and design. Over
> the years I've studied most of the OO design methods (and
> the procedural methods before the advent of OO) and have
> selected pieces to add to my own slowly-amalgamating
> method. However, this tour produced a number of
> ephiphanies about OO design.</p>
> <p>First, it's really, really important that a design
> method be simple. Any bit of complexity that doesn't
> produce big results in the design process makes the method
> fuzzy and hard to remember. I believe you need to be able
> to hold the method in your head, which means that it must
> conform to the "seven plus-or-minus two" rule,
> regarding the number of things that humans can keep in
> their head at one time.</p>
> <p>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.</p>
> <p>This is the second point: people have a very difficult
> time separating abstraction levels. We are drawn to the
> complexity that we know. Once we conquer a particular bit
> of complexity, I believe we enjoy revisiting it to renew
> the sense of satisfaction. That's why it's so hard to give
> it up in order to step back and say: "but that isn't
> relevant here; we're trying to get the big picture right
> now."</p>
> <p>As a result, attempts to develop the domain model end
> up in arguments about whether to use stored database
> procedures, or how to optimize a particular aspect of the
> system, or invent yet another framework in an attempt to
> create reusable code rather than just solving the problem
> at hand. Much of my coaching during this trip involved
> gentle prodding to help people stay at the right level of
> abstraction. There are a million ways to fall off the
> razor's edge, which is why it's so essential that a design
> method be simple.</p>
> <p>The third big issue was about the UML. Everywhere I
> went, people were struggling with it, and I think the
> repetition of that confusion finally made me take a hard
> look at it. The UML is not only too complex, it seems to
> be incomplete (or at the very least, it takes far too many
> kinds of diagrams to express the design).</p>
> <p>The reason for the complexity of the UML is,
> ironically, inappropriate mixing of abstraction levels.
> I'm certain this happened because, back when Rational was
> a viable company (before too many people asked "if
> Rational is supposed to teach us how to create good
> software, how come Rose is such a bad piece of
> software" and the company imploded, being
> "saved," if you can call it that, only because
> IBM bought them as they were spiraling down the drain),
> and they brought Booch, Jacobsen and Rumbaugh together so
> they would stop fighting and create a "Unified"
> model (the creation of peace was the reason for the
> "U", for those of you new to the story). When
> this happened, agendas inevitably got mixed together, and
> I suspect that Rational had its own agendas which got into
> the mix, design-by-committee style. At the time, C++ was
> king of the OO languages so you see a lot of C++-isms in
> the UML, which introduced innapropriate details. At least
> one player appeared to have grand ideas of taking this
> abstraction tool and giving it enough detail to produce
> code. Of course, we see this in most of the modeling
> tools, which can spit out framework code from the UML, but
> in recent years the spectre of Model-Driven Architecture
> (MDA) has appeared, which was probably inevitable given
> the implied promise that someday UML would be the one ring
> that binds them all. Fortunately, the MDA experiments seem
> to be happening in the open-source world, so we can
> discover (again) that programming-by-drawing-pictures is
> Goedel-incomplete, without having to pay hundreds of
> thousands for tools that don't work hawked by vendors
> selling faith-based solutions, as has been the case for
> every "revolution" that has popped up in the
> past.</p>
> <p>Because of all these misdirections, it's no wonder
> people get confused about what to do with the UML. Is it
> for modeling, or is it for detailed design? My guess is
> that forces within Rational wanted it to be everything to
> everyone, but this goes back to my original point: a
> method must be really, really simple in order for people
> to use it without getting lost.</p>
> <p>Two things became clear about the UML on this trip.
> First, when walking through use cases/user stories, the
> static structure diagram is what appears. This is not a
> revelation; CRC cards or simply hunting for nouns and
> verbs produce the same results. However, we found that a
> very simple form of structure diagram would suffice, and
> this seemed to be very helpful for people because they
> could see that it was only intended to capture the domain
> model, and not express every possible detail about the
> code. Without this guidance, people can waste a lot of
> time filling in all the methods, arguments and fields and
> lose sight of the big picture.</p>
> <p>The second thing that became clear was that a UML
> structure chart is a very helpful step in expressing the
> domain model, but it lacks an essential ingredient:
> mechanism. The structure chart only expresses the
> relationships between classes, not how they interact.
> Sometimes this relationship is enough, along with some
> words and hand-waving, to understand how the system will
> work. But, I began to see, that is only in the case where
> the mechanism is so obvious that everyone can see it. (I
> am aware that the UML has a various number of different
> diagrams that show different aspects of mechanism, but
> none of them are able to sum it up.)</p>
> <p>On the other hand, expressing mechanism down to the
> nuts and bolts is precisely the pitfall we are trying to
> avoid by using a model. What's needed is the
> <em>essence</em> of mechanism, just enough so that we can
> see how something should work without getting lost in
> detail.</p>
> <p>Could this essence be design patterns? Might we be able
> to see the most obvious designs because we have been
> schooled in the most basic of patterns so effectively that
> we don't even consider them patterns, but just fundamental
> ways of doing things, and don't even have names for them?
> But when we have more complex interactions, we need a
> pattern to describe it?</p>
> <p>During one session, I began to see the possibility of
> annotating a structure chart with the mechanisms that
> drove the program, and this seemed to work in some
> situations. However, in the following consulting session
> the idea of a separate diagram began to appear. I started
> calling this a "flow diagram" because it showed
> the flow of objects and messages through the system of
> objects. This diagram does not show composition and
> inheritance, but rather the relationship of higher-level
> objects and the way they accomplish their tasks. It also
> seems to show threading in the system. In general, it
> seems to focus on the way that objects are wired together
> to build a system and the dynamic of that system, rather
> than just examining the inheritance and composition
> relationships (which are certainly important, but are
> clearly only a step in the design process). I don't have a
> "finished" approach for flow diagrams, but the
> idea continues to reappear and evolve.</p>
> <p>Finally, it has become quite clear to me that the
> software design process involves incomplete information at
> every stage. This can be a point of contention, one that
> appears to be rooted in your belief system about the
> world. Suggest that you don't ever really know everything
> about a system to someone who really wants things to be
> deterministic from beginning to end, and you'll get a
> response ranging from "huh?" to downright
> hostile, depending on how threatening the idea is (we
> could probably carry this same argument into the realms of
> the static/dynamic language debate, exceptions, developer
> testing, etc.). But my experience is that, if you insist
> that complete information must be available at every
> stage, you rapidly converge on analysis paralysis on the
> project level, and the waterfall approach on the method
> level.</p>
> <p>On the other hand, accepting that information is
> incomplete allows a project to become remarkably nimble.
> At each stage you know you will only be able to mine some
> of the information about the project, and when a vein
> begins to dry up you move on rather than wasting time
> trying to pry out every possible nugget. 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 significant periods.</p>
> <p>Note: I'll also be discussing these ideas at the
> upcoming <a class="reference"
&gt; href="http://mindview.net/Seminars/ObjectsAndSystems/">Desi
> gning Objects & Systems seminar</a> that I'm giving
> with Bill Venners (the driving force behind Artima).</p>

responding to Eckel
> <p>The third big issue was about the UML. Everywhere I
> went, people were struggling with it, and I think the
> repetition of that confusion finally made me take a hard
> look at it.

I think this has more to do as you have mentioned early:
"Once we conquer a particular bit of complexity, I believe we enjoy revisiting it to renew the sense of satisfaction"

Because they are not versed in UML they struggle and have all tendency to get back to things they are comfortable at, and peers to accept this as they too want to get into their comfortable zone.

> The UML is not only too complex, it seems to
> be incomplete (or at the very least, it takes far too many
> kinds of diagrams to express the design).</p>

I think a software has several aspects/ stake holders and each aspect needs elaborate design and so many diagrams.

> <p>The reason for the complexity of the UML is,
> ironically, inappropriate mixing of abstraction levels.
Can you clearify this a bit. What is "inappropriate mixing of abstraction levels".

> Of course, we see this in most of the modeling
> tools, which can spit out framework code from the UML, but
> in recent years the spectre of Model-Driven Architecture
> (MDA) has appeared, which was probably inevitable given
> the implied promise that someday UML would be the one ring
> that binds them all. Fortunately, the MDA experiments seem
> to be happening in the open-source world, so we can
> discover (again) that programming-by-drawing-pictures is
> Goedel-incomplete, without having to pay hundreds of
> thousands for tools that don't work hawked by vendors
> selling faith-based solutions, as has been the case for
> every "revolution" that has popped up in the
> past.</p>

I think MDA is happening in even commercial tools. And OMG has list of so many vendors list.

> <p>Because of all these misdirections, it's no wonder
> people get confused about what to do with the UML. Is it
> for modeling, or is it for detailed design?

I think modeling and design are too close to each other to justify different concepts, vocabs, and tools?

I think non uses are more confused about the things then the actual users.

> My guess is
> that forces within Rational wanted it to be everything to
> everyone, but this goes back to my original point: a
> method must be really, really simple in order for people
> to use it without getting lost.</p>

I think this has to do more with trying to spend more time in design then coding? To remr properly high level class responsibility and ability to look for certain behaviour in the expeted class, then to rermr actuall method name. Example could be certain JAVA API's wherein class may have so many of methods, but little acquaintence with rols/ behaviour impliitly indicates where to find this method.

> <p>Two things became clear about the UML on this trip.
> First, when walking through use cases/user stories, the
> static structure diagram is what appears. This is not a
> revelation; CRC cards or simply hunting for nouns and
> verbs produce the same results. However, we found that a
> very simple form of structure diagram would suffice, and
> this seemed to be very helpful for people because they
> could see that it was only intended to capture the domain
> model, and not express every possible detail about the
> code. Without this guidance, people can waste a lot of
> time filling in all the methods, arguments and fields and
> lose sight of the big picture.</p>

Exactly. And UML has good notations to visualize and dispay the same.

> <p>The second thing that became clear was that a UML
> structure chart is a very helpful step in expressing the
> domain model, but it lacks an essential ingredient:
> mechanism. The structure chart only expresses the
> relationships between classes, not how they interact.

But you have collaboration, sequence and Activity diaggrams (may be) to depict the same.

And I think it makes sense to separte out concerns of identification of domain class/ objects and their interaction pattern.

> Sometimes this relationship is enough, along with some
> words and hand-waving, to understand how the system will
> work. But, I began to see, that is only in the case where
> the mechanism is so obvious that everyone can see it. (I
> am aware that the UML has a various number of different
> diagrams that show different aspects of mechanism, but
> none of them are able to sum it up.)</p>
> <p>On the other hand, expressing mechanism down to the
> nuts and bolts is precisely the pitfall we are trying to
> avoid by using a model. What's needed is the
> <em>essence</em> of mechanism, just enough so that we can
> see how something should work without getting lost in
> detail.</p>

I think you have a point here. But it is like, telling some codes are really tough to write elegantly, with all constraints and you need expert programmers.

Similarly may be we need some template model element with semantic definition that may be standarized to express complex behaviour.

As far as nitty gritties are concerned, I think yeh currently UML lacks but it is making that up be using action semantic language. And I think its viabililty and feasibility has been demonstrated by xUML and other tools.

> <p>Could this essence be design patterns? Might we be able
> to see the most obvious designs because we have been
> schooled in the most basic of patterns so effectively that
> we don't even consider them patterns, but just fundamental
> ways of doing things, and don't even have names for them?
> But when we have more complex interactions, we need a
> pattern to describe it?</p>

I think patterns representation and usgae in a context needs standarization. But this again can be dong UML syntax and semantics.

> <p>During one session, I began to see the possibility of
> annotating a structure chart with the mechanisms that
> drove the program, and this seemed to work in some
> situations. However, in the following consulting session
> the idea of a separate diagram began to appear. I started
> calling this a "flow diagram" because it showed
> the flow of objects and messages through the system of
> objects. This diagram does not show composition and
> inheritance, but rather the relationship of higher-level
> objects and the way they accomplish their tasks. It also
> seems to show threading in the system. In general, it
> seems to focus on the way that objects are wired together
> to build a system and the dynamic of that system, rather
> than just examining the inheritance and composition
> relationships (which are certainly important, but are
> clearly only a step in the design process). I don't have a
> "finished" approach for flow diagrams, but the
> idea continues to reappear and evolve.</p>

I think this can be captured in Activity diagram.

> <p>Finally, it has become quite clear to me that the
> software design process involves incomplete information at
> every stage.

I think unless someone really goes through all aspects of the software model, he cant really get all the information. But it makes sense. Static structural diagram, is not directly affected by separate deployment or Fault Tolerance requiremnts of each of the class in class model? And so it makes sense to capture that in separete diagram.

But may be you have some point I missed. If you mention some example.

> This can be a point of contention, one that
> appears to be rooted in your belief system about the
> world. Suggest that you don't ever really know everything
> about a system to someone who really wants things to be
> deterministic from beginning to end, and you'll get a
> response ranging from "huh?" to downright
> hostile, depending on how threatening the idea is (we
> could probably carry this same argument into the realms of
> the static/dynamic language debate, exceptions, developer
> testing, etc.). But my experience is that, if you insist
> that complete information must be available at every
> stage, you rapidly converge on analysis paralysis on the
> project level, and the waterfall approach on the method
> level.</p>

I think all the information needs to be modeled as part of analysis or depiction of different kind of diagram. If all the diagrams are being modeled parallely and appropriate links are provided to navigate through differnt aspects this incompleteness may be removed.

> <p>On the other hand, accepting that information is
> incomplete allows a project to become remarkably nimble.
> At each stage you know you will only be able to mine some
> of the information about the project, and when a vein
> begins to dry up you move on rather than wasting time
> trying to pry out every possible nugget. 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 significant periods.</p>

Perfectly valid point. This will always happene if you have not desigend similar kind of system earlier. You need to validate and iterate through the design.

I believe struggling with UML, or UML loop holes has to more to do with its being newer technology and lack of people who practice it.

And any way I agree to a extent that still we find lots of things difficult to capture using UML but they are difficult otehrwise as well, unless you "code it" with understanding of the required behavour?

regards,
Shashank

Shashank D. Jha

Posts: 68
Nickname: shashankd
Registered: May, 2004

Re: Object Design Posted: Jun 20, 2005 11:58 AM
Reply to this message Reply
Sorry for duplicate quoting of original texts.

regards,
Shashank

Mike Dunbar

Posts: 12
Nickname: mikedunbar
Registered: Jun, 2004

"flow" vs. sequence diagram Posted: Jun 21, 2005 8:25 AM
Reply to this message Reply
>...in the following consulting session
> the idea of a separate diagram began to appear. I started
> calling this a "flow diagram" because it showed
> the flow of objects and messages through the system of
> objects. This diagram does not show composition and
> inheritance, but rather the relationship of higher-level
> objects and the way they accomplish their tasks.

How does your "flow" diagram differ from a UML sequence (or interaction) diagram, which shows the communication/message flow between objects? Is it worth a new/proprietary notation?

Agree that UML is huge, and definitely prefer to stay informal and high-level with it myself. I mostly stick to class diagrams (for showing structure) and sequence diagrams (for behavior/flow). I also like "package" diagrams (technically, still a class) for showing layers, sub-systems, and higher-level things like that.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: Object Design Posted: Jun 21, 2005 9:58 AM
Reply to this message Reply
> I also think too many people try to treat various design
> approaches as rules not as guidelines. That and hidden
> complexity prices often make design too complicated. It
> becomes harder than it should be, sometimes resulting in
> poor software quality.

People have agendas. If there is a guideline that supports their agenda in the presence of conflict, they'll try to use that guideline as a rule.

This is the number one reason, for me, that design methods need to be simple. Ideas need to stand on their own, without a methodology driving it.

Nicolas Nombela

Posts: 17
Nickname: nnombela
Registered: Feb, 2005

Re: Object Design Posted: Jun 21, 2005 10:53 AM
Reply to this message Reply
UML is good if you want to explain a high-level description of some aspect of your system. I even found it to be more helpful if you sacrifices correctness and orthodoxy in those UML-like descriptions just to make the message and ideas you want to communicate more clear.

Complexity can not be describe with UML not just because is incomplete (and It is), but because it fails to make a complete description less complex that the system it tries to describe. I think UML, as a general modeling language, should not be used to SOLVE specific problems but just to COMMUNICATE general (high-level) ideas about that problem. I would say 80% of UML is useless, 15% can be helpful and 5% are really worthy, and that is the best I manage to distilled.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Object Design Posted: Jun 25, 2005 10:25 AM
Reply to this message Reply
Maybe diagramming isn't the answer. I learned something from Ron Jeffries that some people have called Naked CRC. I wrote it up in my book, but unfortunately, I don't have it in a form I can post right now. Here's is a blog entry that tries to explain it compactly:

http://blackbox.cs.fit.edu/blog/andy/archives/000063.html

The idea is: if you want to show movement, use movement.

Eric Armstrong

Posts: 207
Nickname: cooltools
Registered: Apr, 2003

Re: Object Design Posted: Jun 26, 2005 6:05 PM
Reply to this message Reply
> Maybe diagramming isn't the answer...
>
> The idea is: if you want to show movement, use movement.
>
Right. Animation could make things easier to visualize.
On the other hand, incestuous relationships where one
object creates another and passes itself to it, which allows that object to call methods in the original object--such things are going to be difficult to represent visually, with or without animation. (I sincerely wish there *were* a way to visualize them, however.)

Scott Ambler

Posts: 1
Nickname: sambler
Registered: Jul, 2005

Re: Object Design Posted: Jul 22, 2005 4:30 PM
Reply to this message Reply
I've been writing about the insufficiency of the UML for several years. Actually, I wrote the first article in Object Magazine about the UML in 1997, and in that I pointed out that the UML was missing some basic things such as a data model, a viable process model, and a UI model. At http://www.agilemodeling.com/essays/realisticUML.htm I explore the idea in a bit more detail.

Anyway, I think a major problem with the UML is that it's being driven by the tool vendors, not by practitioners. At http://www.agilemodeling.com/openUML/ we just started to open source the definition of modeling languages, including the UML. Isn't it about time we took back modeling for ourselves?

- Scott

Steven

Posts: 1
Nickname: steveg
Registered: Sep, 2005

Re: Object Design Posted: Sep 23, 2005 5:35 PM
Reply to this message Reply
The article ends with a very astute observation:

> On the other hand, accepting that information is
> incomplete allows a project to become remarkably
> nimble. At each stage you know you will only be
> able to mine some of the information about the
> project, and when a vein begins to dry up you
> move on rather than wasting time trying to pry
> out every possible nugget.

However:
- how will you ever finish mining that vein later,
- how do you know that mining that vein later will not lead to insights that will invalidate other parts of the design,
- why accumulate a large inventory of incomplete designs based on incomplete information before moving on to the next "stage" (which would be implementation?)?

I believe a good answer to this is to take the following approach:
- Mine just one vein (i.e., design just one part of the system, the single most critical or valuable or best understood part)
- Drive to delivering working software for that one part of the system rather than some diagrams. Do so by obtaining the information you need directly from the customers right then when you need it.
- Get real user feedback on that software (don't rely on SMEs to validate design diagrams).
- Learn from and respond appropriately to feedback.
- Move on to the next vein.
- Continue until the feedback says you are done.

Just-in-time design of vertical functional slices is an approach that reduces complexity quite well, and you never accumulate a large inventory of unimplemented designs to weigh you down. Of course, you have to implement each vertical slice in a simple, flexible, easily refactorable way.

Does this approach sound familiar?

Steven Gordon

Bruce Eckel

Posts: 874
Nickname: beckel
Registered: Jun, 2003

Re: Object Design Posted: Sep 23, 2005 6:54 PM
Reply to this message Reply
My primary concern with this approach is that it's tempting to do the parts we already know how to do. It's important to dive into the hard stuff that we don't know how to do, so that we can get a sense of how hard it might be and how long it might take. Also, by starting on the difficult stuff early, we have more time to recover if it's harder than we think, or to report back and find out what the stakeholders want to do.

Peter Thompson

Posts: 1
Nickname: pthompson
Registered: Oct, 2005

Re: Object Design Posted: Oct 18, 2005 1:41 PM
Reply to this message Reply
For anyone interested doing some background reading, I think that the "half-interesting" book mentioned above by Peter Booth was probably
<a href="http://www.sei.cmu.edu/publications/books/engineering/documenting-sw-arch .html">Documenting Software Architectures: Views and Beyond</a>.

You can find a report that preceeded the book at<a href="http://www.sei.cmu.edu/publications/documents/01.reports/01tn010.html"> ; Documenting Software Architectures: Organization of Documentation Package</a>.

Flat View: This topic has 36 replies on 3 pages [ « | 1  2  3 | » ]
Topic: Object Design Previous Topic   Next Topic Topic: Beautiful Code in the Real World - Part I


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us