How to reduce the gap between OOA&D

[Francis Siu]

As I had listen some concept in OO analysis and design, there exist a gap between analysis and design.
However I do not know how to reduce the gap,
and another question is
How to create a domain model for the Unreal world. :roll:
Do you have some idea or suggestion on it?
thanks

[Ilja Preuss]

Originally posted by siu chung man:
As I had listen some concept in OO analysis and design, there exist a gap between analysis and design.
However I do not know how to reduce the gap,

How do you reduce the gap between earth and moon?

You don't - if you need to go to the moon, you need to learn a whole bunch of skills and techniques, and you probably need to be somewhat creative every time you try to reach the moon again.

The very most effective way to learn those skills and techniques is to work together with someone experienced.

How to create a domain model for the Unreal world. :roll:

I don't think I understand the question.

[Francis Siu]

Um....an unclear question

We know how to construct the real world object to become a domain model, however some software system are for domains that find very little analogy in natural or business domains; software for telcommunications is an example. It is still possible to create a domain in these domains. So are there any methods or idea to create some candidate conceptual classes related to a telecommunication(Unreal world)?

[Lasse Koskela]

Siu, even telecommunications have their own domain concepts based on which the domain model can be built. They might be more abstract than the concepts of retail business, for example, but they're still there.

Would you happen to have some specific examples in mind that we could discuss here at the 'ranch?

[Sathya Srinivasan]

Based on an article by Jack Reeves - Code is Design, I have come to think that analysis model happens before the code while the design model happens after the code.

Let me explain my statement.

1. Analysis model is needed to get an understanding of the domain and how the problem relates to the domain. It is generally free of implementation details and concentrates more on capturing the business relations in the domain.

Such a diagram (crude or formal) is needed to get an idea on how to proceed with the implementation and hence, must be done before coding. Also, this model must be shared with the clients and get their view on whether it correctly represents the business needs.

2. Design model explains how the business needs are going to be implemented using some software language/technique. Such a model is typically useful for the programmers who write it, and more importantly, to serve as a documentation for those who would succeed the programmers who wrote the software in the first place.

As a result, this model should reflect how the project has been implemented exactly (or as close as possible).

2a. There are ALWAYS issues that come up during the code which could not potentially be conceived before writing the code. This may include performance issues if the code is written in a specific manner, constraints on the machines that were not thought of earlier, difficulties in implementing something that was assumed to be easy earlier, etc.

Hence, a detailed design thought of BEFORE the code is written always becomes out of sync with the code very fast. The programmer then has to keep changing the design in order to reflect the realities of the implementation.

Solution: Don't bother creating a detailed design diagram. Create a very good analysis diagram, get the buy in from the client about its viability (and the project lead), write the code, and finally, create the detailed design model from the code to serve as a documentation reference.

Comments?

[Lasse Koskela]

Originally posted by Sathya Srinivasan:
Solution: Don't bother creating a detailed design diagram. Create a very good analysis diagram, get the buy in from the client about its viability (and the project lead), write the code, and finally, create the detailed design model from the code to serve as a documentation reference.

Comments?

I'll sign off this one. It's an urban myth that it would be more efficient to produce a set of detailed design diagrams from which a trained monkey could generate a working application than to let a bunch of smart developers develop the software in direct communication with the customer using tools like a domain model or analysis model.

[Marlene Miller]

Thank you Sathya for the link and your view. That's an interesting article.

[Ilja Preuss]

Originally posted by Sathya Srinivasan:
Based on an article by Jack Reeves - Code is Design

Very thought provoking article.

I have come to think that analysis model happens before the code while the design model happens after the code.

I disagree - they need to be done concurrently. Trying to do them sequentially will lead to suffering, because you are missing vital feedback.

1. Analysis model is needed to get an understanding of the domain and how the problem relates to the domain. It is generally free of implementation details and concentrates more on capturing the business relations in the domain.

That's true. For any but the most trivial system, it's illusory to think that you can fully understand the domain before starting to design or code. While designing and coding - and even after having the users work with a running system - your understanding of the domain *will* change, regardless of the amount of upfront effort to understand it.

Such a diagram (crude or formal) is needed to get an idea on how to proceed with the implementation and hence, must be done before coding.

First, domain knowledge doesn't necessarily be captured in diagrams. What is important is that the knowledge is in the heads of the people - diagrams are only one tool to help doing that. The most important tool, though, is face to face conversation.

Another important tool is showing the customers/users a running system with the most valuable features implemented. You can do this via prototyping, for example. Agile projects take this one step further by evolving a production system over weeks to months.

Also, this model must be shared with the clients and get their view on whether it correctly represents the business needs.

That's certainly important! Therefore we must make sure that they understand the model well. Diagrams aren't always the best choice here. Another good idea is to let them state the requirements in the form of an executable specification (Acceptance Tests).

The final test for wether the system meets their needs is to let them use it, though. Everything else is just (more or less well informed) speculation.

2. Design model explains how the business needs are going to be implemented using some software language/technique. Such a model is typically useful for the programmers who write it, and more importantly, to serve as a documentation for those who would succeed the programmers who wrote the software in the first place.

As a result, this model should reflect how the project has been implemented exactly (or as close as possible).

Well, I'd say that the point of the article you linked to is that the code
*is* that model. Of course additional models are valuable, too, but those should be much higher level than the code. If you want to know the exact details, look at the code.

[Sathya Srinivasan]

Some clarifications:

Originally posted by Ilja Preuss:

I disagree - they need to be done concurrently. Trying to do them sequentially will lead to suffering, because you are missing vital feedback.

True. When I say that the detailed design comes after the code, the emphasis is that it it not done before the code. For example, the model can be built after an iteration is performed on a specific module. In such cases, the model would indeed be developed concurrently with the code. An advantage of doing such peice-meal models would be to share them then and there with others in the team to enhance communication.

If the statement comes across as a waterfall-like approach, that was not the intention.

Originally posted by Ilja Preuss:

First, domain knowledge doesn't necessarily be captured in diagrams. What is important is that the knowledge is in the heads of the people - diagrams are only one tool to help doing that. The most important tool, though, is face to face conversation.

Yes. They don't have to be. I just took diagrams as one form of representation, more in context to the question posed. Certainly there are other ways in which a model can be expressed. Bottom line is, any method that is agreeable and can be understood by the user should be used.

I have seen cases where the user has been force-fed UML diagrams to no avail.

Originally posted by Ilja Preuss:

Well, I'd say that the point of the article you linked to is that the code
*is* that model.

Yes. However, the design diagram (or the model) that I am talking about is one of the auxilliary document mentioned in the article. The point I try to make is that the design model is mainly used as a reference material for the developers who tend to maintain or extend a program and hence should accurately reflect the code developed. Such an accurate model can be developed only after the code is developed (or after an iteration). As a result, it should always be done after the code is developed (or after an iteration).

[Ilja Preuss]

Originally posted by Sathya Srinivasan:
If the statement comes across as a waterfall-like approach, that was not the intention.

It came, and I'm relieved to hear that it wasn't meant that way.

The working style I personally prefer puts analysis, coding and design much more together, though. More like a bit of everything done every day, or even every hour.

The point I try to make is that the design model is mainly used as a reference material for the developers who tend to maintain or extend a program and hence should accurately reflect the code developed. Such an accurate model can be developed only after the code is developed (or after an iteration). As a result, it should always be done after the code is developed (or after an iteration).

Well, OK. I'd go even further - the best way to transfer design knowledge is by collaboration - design sessions on the white board, peer reviews, pair programming, you get the idea.

You might not be able to do that to transfer knowledge to the maintenance team, though. In that case, produce some high level design documentation for them, *but only short before the hand-off*, at the end of the project.


There is another reason to produce design artifacts outside of code: to explore possible designs for the implementation of the next feature. In my opinion, you shouldn't invest too much time into those, and they certainly don't need to be of high quality, let alone be persistent (say, some sketches on the white board, produced in a discussion that didn't last longer than half an hour).

[Scott Ambler]

I do a very simple experiment when I give my Agile Modeling overview talk at conferences. I ask the audience to think of how they would go about addressing a simple problem, perhaps developing the "gather address page" at Amazon.com. I spend about twenty seconds describing the problem then ask them to think about it for thirty seconds.

Once the time elapses I ask for a show of hands for simple questions like:
1. Who started by thinking about a use case.
2. Who started by thinking about writing code?
3. ... developing a UI prototype?
4. ... writing up some business rules?
5. ... with the UI, then thought about building objects to support it, then thought about the database in behind everything?
6. ...

I always get people raising their hands to each question.

I then make several observations:
1. People start at different points, and that's ok.
2. Sometimes people start at code, sometimes with a requirements model, sometimes elsewhere.
3. Some people focus on one task (e.g. writing use cases).
4. Some people go from requirements, to analysis to design to code in seconds.
5. There are many different ways to work, choose the right one(s) for your situation.

As for all these wonderful articles online that tell you that you HAVE to work a certain way in a certain order, the only thing that you should read from them is that the author prefers to work in that way. The secret is to keep an open mind and find various ways to get the job done effectively.

- Scott

[Stan James]

Great story, Scott! Very revealing question!

[Sathya Srinivasan]

Nice questions, Scott! Very interesting.

[Sunder Ganapathy]

Excellent way to kindle the thoughts, Scott. Too Good.

[Francis Siu]

As for all these wonderful articles online that tell you that you HAVE to work a certain way in a certain order, the only thing that you should read from them is that the author prefers to work in that way. The secret is to keep an open mind and find various ways to get the job done effectively.
OOo...... satisfy all conditions.
hi Scott
Could you tell me which way you prefer to use(Or suggest in the book)?
thanks

[Scott Ambler]

I really don't have a preference any more, other than perhaps to find the most appropriate way to work given the current situation.

- Scott

[Jeff Langr]

Scott,

To the OP's question, do you see robustness analysis as helping to bridge the gap between analysis and design? I personally found little value in this technique, and I've not seen anyone else use it with great effectiveness. But I recall that you wrote an article on it that suggested it could be useful.

-Jeff-

[Francis Siu]

hi Jeff
I personally found little value in this technique, and I've not seen anyone else use it with great effectiveness.

Could you share your opinion on it, I want to know more about it that how to bridge the gap between analysis and design effectiveness.
thanks for your time

[Jeff Langr]

This article is by two of the heavy promoters of the technique: http://www.sdmagazine.com/documents/s=733/sdm0103c/0103c.htm
They promote it as part of their ICONIX process. My personal experience has shown it to be largely a waste of time, but that's me; I'm an arrogant SOB and I think I've surpassed the need for it.

However, I suggest you give it a try and see if it adds any value. In either case, the robustness diagram is not something you're going to want to keep around. As with much of UML, it's instead best used as a tool in problem solving, something you put on the whiteboard and then erase once it has gotten you to the next step.

Here's someone that talks about their negative experiences with ICONIX itself:
http://c2.com/cgi/wiki?IconixProcess
The most relevant quote from this link:
"I really don't want to detail the true horror of implementing a large design done the ICONIX way. Briefly, despite 4 months worth of beautifully designed, perfect use cases, domain models, robustnesses and sequence diagrams, most of this analysis was turned upside down in the first few days of coding. The analysts thought the job had been virtually done, that their 4 months of analysis would take around 6 months to implement. It actually took around 18 months, several rewrites and the architecture is still flaky as hell! No change from your typical BigDesignUpFront project there, then."

-j-
[ November 04, 2004: Message edited by: Jeff Langr ]

[Scott Ambler]

I use Robustness diagrams, http://www.agilemodeling.com/artifacts/robustnessDiagram.htm , when I'm working with people who are having problems identifying potential objects from use cases, ... What usually happens is that after drawing a couple of the diagrams they quickly learn how to do so and we find that we can go straight to sequence diagrams, or something else, instead.

The usefullness of a technique always depends on the situation, including both the people that you're working with and the goal(s) that you're trying to accomplish.

- Scott

[Stan James]

When we did Robustness Analysis one goal was to notice that some class is used in four use cases and see if the usage is consistent. Did the author of this use case think Customer was the same thing as the author of that other use case? Or did they use two different names for the same thing and not realize it?

Of course I'm perfectly willing to be told "That's not robustness, that's some other thing!"

Edit: Slowing down to READ a little better, I see that Scott's article has these elements.
[ November 05, 2004: Message edited by: Stan James ]

[Scott Ambler]

You can also achieve the same sort of goal by maintaining a common glossary ( http://www.agilemodeling.com/artifacts/glossary.htm ) or domain model ( http://www.agiledata.org/essays/agileDataModeling.html#InitialDomainModel ).

You can often acheive a goal by several different means. This is one of the reasons why I'm so adamant about concepts such as the AM principle of Multiple Models as well as simply becoming a generalizing specialist with a wide range of knowledge. The more techniques you know about the greater the chance that you can choose the best one for your current situation.

- Scott