aspose file tools*
The moose likes OO, Patterns, UML and Refactoring and the fly likes perspectives for UML diagrams Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "perspectives for UML diagrams" Watch "perspectives for UML diagrams" New topic
Author

perspectives for UML diagrams

william kane
Ranch Hand

Joined: Nov 21, 2000
Posts: 260
I am not able to relate the concepts of 'perspective'(specification,implementaion and conceptual) for UML diagrams.Do these perspectives mean that there are seperate class diagrams for same system for the three perspectives or is it the way the same class diagram needs to be interpreted.

Also is the statement 'There is no difference between realization and subtyping in a specification model.' true???

Thanks in advance
William


Help me!Help you!!!
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I happen to have the Larman book you mentioned in another question. (Can't say I liked it; guess it didn't match other sources I was studying at the time.) He says at one point the conceptual model represents real world things in the business domain while a design model (is that specification?) represents software entities. Mapping conceptual entities to design entities is the skilled part of the job.

His definition of implementation seems to be about the development and deployment environment - source files to components, components to processes and processing nodes (computers). Rational's 4+1 views separate those into development, process and physical views.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Scott Ambler
author
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
At Data Modeling 101 I show how to use the UML to data model, and part of that discussion is the differences between the various levels.

At UML Class Diagrams I also have a bit of a discussion.

The real question is why do you care? Shouldn't your real goal be to create models which meet the needs of your project team, not the dictates of some book you've read?

- Scott


<a href="http://www-306.ibm.com/software/rational/bios/ambler.html" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="http://www.ambysoft.com/books/refactoringDatabases.html" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
william kane
Ranch Hand

Joined: Nov 21, 2000
Posts: 260
Originally posted by Stan James:
I happen to have the Larman book you mentioned in another question. (Can't say I liked it; guess it didn't match other sources I was studying at the time.) He says at one point the conceptual model represents real world things in the business domain while a design model (is that specification?) represents software entities. Mapping conceptual entities to design entities is the skilled part of the job.

His definition of implementation seems to be about the development and deployment environment - source files to components, components to processes and processing nodes (computers). Rational's 4+1 views separate those into development, process and physical views.


Thanks Stan,
So am I right in concluding that conceptual,specification and implementation views are expressed in different models???
Regards
William
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I'm going to be real picky about "model" and "diagram" for a sec. One of the neat features of a tool like Rose is that you can have one model with many different diagrams as views into the model. I'd keep the "conceptual" model separate because it models domain concepts, not software artifacts. The other perspectives all model aspects of the software, and could be sets of views into the same model.
Scott Ambler
author
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
You need to decide which views/diagrams/models you wish to invest in. Will you gain value from having conceptual, logical, and physical views? If so, create them. My experience building business applications is that a conceptual view offers value, as does a physical data model, but that a logical view is a waste of time. From an object point of view the conceptual view makes sense as does a detailed design model if you have a tool such as OptimalJ or Together which (re)generates code (without such a tool a detailed model is often a waste of time).

- Scott
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Does anybody have a link to Phillipe Krutchen's original "four plus one" paper? I get some Google hits for Rational, but IBM seems to have moved everything since Google last looked. Any opinion ... are people still talking about the 4+1 or Larman's perspectives?
william kane
Ranch Hand

Joined: Nov 21, 2000
Posts: 260
Originally posted by Scott Ambler:
My experience building business applications is that a conceptual view offers value, as does a physical data model, but that a logical view is a waste of time. From an object point of view the conceptual view makes sense as does a detailed design model if you have a tool such as OptimalJ or Together which (re)generates code (without such a tool a detailed model is often a waste of time).

- Scott

Thanks Scott,
Are you saying that without the aid of a tool that generates code from a detailed design investing time in detailed designing is a waste?If yes,how can i take my conceptual model as an input to write code?I was under the impression that the a detailed design model is necessary as it represents the solutions for many problems that are not addresses in the conceptual modelling phase.
Please clarify
William
william kane
Ranch Hand

Joined: Nov 21, 2000
Posts: 260
Originally posted by Stan James:
Does anybody have a link to Phillipe Krutchen's original "four plus one" paper? I get some Google hits for Rational, but IBM seems to have moved everything since Google last looked. Any opinion ... are people still talking about the 4+1 or Larman's perspectives?


Thanks Stan,
I think this is the link you are refering too
Scott Ambler
author
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
Are you saying that without the aid of a tool that generates code from a detailed design investing time in detailed designing is a waste?

For the most part yes. What usually happens is that a modeler(s) go off, create overly detailed models, hand them off to the developers, who then read them and may or may not follow them. Often the models look good but in practice prove to have so many minor mistakes that the developers soon start to only reference the design for higher-level issues but handle the details themselves. Once you observe this a few times in practice, you start to realize that you had might as well just focus on high-level design.

If yes,how can i take my conceptual model as an input to write code?I was under the impression that the a detailed design model is necessary as it represents the solutions for many problems that are not addresses in the conceptual modelling phase.


Why don't you work closely with the rest of the team and find out what they actually need you to do? The conceptual model will help you to understand the major domain concepts and the relationships between them. A few free form diagrams could easily overview the architecture. Then I would model storm in a JIT manner and create diagrams/models as needed. You'll likely find that sequence diagrams are useful to describe the detailed object logic and that flow charts are useful to explore business logic. I've also found that class diagramming can be useful too, particularly on a whiteboard to explore what needs to be built over the next couple of hours. I suspect that you'll discover that one of the few keeper models will prove to be your physical data model.

- Scott
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
In my eyes, the code itself already is the detailed design model, so why build another one - one that isn't testable and needs to be kept in sync with the code?


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
How detailed should you make a design? Good enough to hand off to the next person in the development process so they can understand what's expected and do the job. If there is only one person or a small team that talks to each other there may be no need for such a design artifact at all. If you're building something like the Saturn V rocket with components from dozens of companies all over the country assembled ONCE on the launch pad with life critical quality requirements, you'd better have pretty detailed design docs. Of course if your software team works like that, and it's not actually programming the shuttle, look for another team.

Back to the original question ... I asked for a link to the 4+1 paper and someone found it for me above. (Thanks!!) This is some seminal work on multiple views into the same model and worth comparing to the Larman book.
[ May 04, 2005: Message edited by: Stan James ]
Scott Ambler
author
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
Another look at multiple views is presented at Extending the RUP with the Zachman Framework.

- Scott
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Stan James:
How detailed should you make a design? Good enough to hand off to the next person in the development process so they can understand what's expected and do the job.


Note that there is a difference between the *design* and a *design document*.

What you need to do, *if* you decide that the person coming up with the preliminary design should not be the person implementing it for whatever reason, is getting the design ideas from the head of the designer into the head of the implementor.

A design *document* is only one communication channel to use for that, and probably quite inefficient if it is the only one. So how detailed that document should be heavily depends on what other channels you can and will use (such as face-to-face communication, video recordings of design sessions on the white board, pair programming etc. pp.).
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Thanks for a strong reminder that any model or conversation or artifact is a tool for communication. Try to communicate as efficiently and cheaply as possible. Look critically at anything somebody asks you to make, be sure you know the audience and what you need to communicate to them. Consider if there is a faster and cheaper way to do the job. In process driven shops it's easy to get the idea you have to make every artifact in the book.

Another purpose for the whole modeling and designing activity is to explore. Draw a picture, decide it doesn't look good, draw another, get a neat idea, draw another. Artifacts you make in this mode may be transient - thrown away at end of day - if they only have to communicate to yourself.

Here's a neat post I found about process over people ... Jim Bullock on his experiences with the DOD-2167 methodology spec ...


Of course the org-bots steeped in 2167 (vs. folks using it as a tool to get work done) noticed that some of the formats changed in 2167a, while ignoring the change in flow, process, and interactions. I suspect that there's no process / prescription or methodology that can't be hijacked by sufficiently motivated martinets. So how much of the abuse of methodologies ties to the methodology, and how much to the people abusing it. Specs don't kill projects. People kill projects. Yet, you don't want a dangerous spec format lyng around for any damaged individual to pick up and bludgeon a co-worker to death with. Nor do you particularly want a wise-acre slogan lying about to feed the righteousness of folks doing development The One True Way (with extra contempt for Everyone Else(tm)).


Org-bots, martinets, damaged individuals ... this guy isn't bitter about something is he?
Scott Ambler
author
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
If you're interested in the communication aspects within software development, you may find Communication to be of interest.

- Scott
william kane
Ranch Hand

Joined: Nov 21, 2000
Posts: 260
Hey thanks everyone for your enthusiastic response.
Here is a sum up of all that I have gathered from this discussion.
1.Design is the actual solution to the problem and models are a way of communcating.
2.Donot invest a lot of time on fine tuning a detailed design document as it is very likely to change anyway when coded.
3.Use simple tools and ways to express design.
4.Conceptual model+High level design document should be good enough to start code.
Correct me if I am wrong on any of the above
-William
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by william kane:
4.Conceptual model+High level design document should be good enough to start code.


That's also a matter of personal preference. Personally, I typically don't do much design documentation outside of code, but prefer do drive my designs by testing (Test Driven Development). Sometimes I scribble some class diagrams on a napkin together with my programming partner for a couple of minutes to get some ideas on where to start.
william kane
Ranch Hand

Joined: Nov 21, 2000
Posts: 260
Originally posted by Ilja Preuss:


That's also a matter of personal preference. Personally, I typically don't do much design documentation outside of code, but prefer do drive my designs by testing (Test Driven Development). Sometimes I scribble some class diagrams on a napkin together with my programming partner for a couple of minutes to get some ideas on where to start.


Thanks Ilja, if that is the case i understand that you donot invest any in preparing class diagrams in UML with an intension to preserve them.Do you ever in the Test Driven Development cycle create UML diagrams using a modelling tool like rose?If no, how do you ensure that the application you have built with the throw away diagrams will be understood and maintained moving forward?

Also, on reading the 4+1 architectural views proposed in the document by Kruchten i have find it talks of different views and artifacts to express arhitecture.I feel that these views co-exist with the 'perspectives' stated in UML distilled as perpectives talk about how a class diagram can be used to convey different information based in different models.
Please post your opinion on this
Thanks
William
william kane
Ranch Hand

Joined: Nov 21, 2000
Posts: 260
In continuation with my previous queries on views and perspectives some more queries on the 4+1 architectural view.
1.How and when are artifacts for these views developed considering that UP is iterative and that it will take the end of elaboration for most of the significant requirements to be analysed?
2.Typically will the domain model and other artifacts created and updated during elaboration be a part of these views or does there need to a seperate effort to 'decide the architecture of the system'?
3.What is the role of an 'Architect' in a UP based project?
Thanks,
William
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
When you read the RUP descriptions of the tasks and deliverables a lot of them say "refine document X". The artifacts live and grow along with your knowlege. To satisfy an external reviewer I maintain an architecture overview document that is revised for every release, even if I just add "nothing new" to the history.

I hadn't thought about domain analysis fitting into the 4+1. I'm first inclined to say it doesn't because the 4+1 is all about software design, not about the business concepts that got you there. But the +1 is use cases and they can have as much business background as you like. My team has suffered from not having enough.

Along with my boss, some very sharp consultants and other architects I struggled mightily to build giant Word docs using the 4+1 as a guideline to the contents of each. I finally gave up and did all my doc on a Wiki with links in all directions. Now you can follow a business feature from end-to-end through the architecture or view many business functions across one layer of the architecture. That was too hard to do on paper.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by william kane:
1.How and when are artifacts for these views developed considering that UP is iterative and that it will take the end of elaboration for most of the significant requirements to be analysed?


Concurrently with all the other effort to get the software done; whenever you feel it will help you prepare to go the next step toward running software, and as long as you need to get enough information to go the next step. With other words, none of the artifacts will be really "finished" before the whole software is finished.

Take a look at www.agilemodeling.com


2.Typically will the domain model and other artifacts created and updated during elaboration be a part of these views or does there need to a seperate effort to 'decide the architecture of the system'?


I don't see how not being part of those views connects to the need of a separate effort. Anyway, I think that *all* efforts in software development need to be interconnected and be done concurrently, basically. Trying to separate them is just likely to lead to reduced communication and wasted effort due to limited feedback from other activities.


3.What is the role of an 'Architect' in a UP based project?


To me, an "Architect" basically is the person most experienced with design matters, and therefore the natural and generally *accepted* role to mentor and assist the other team members regarding the most critical design issues of the system.

Not sure wether that view is compatible with the official RUP stance, though...
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by william kane:
Thanks Ilja, if that is the case i understand that you donot invest any in preparing class diagrams in UML with an intension to preserve them.


Some months ago, we produced a class diagram for a rather complicated part of the system. It's still hanging as a poster on one of the doors, but as far as I can tell, noone is really looking at it for reference. It's already too complicated to provide a good overview, but still typically lacking the details you are currently interested in, so you have to look at the code, anyway.

Do you ever in the Test Driven Development cycle create UML diagrams using a modelling tool like rose?


TDD has a very specific, short working cycle. Write a test for, say, a minute, write a little bit of production code, run the test, refactor. I don't know of any UML tool that wouldn't slow down this cycle to an amount that it would break the flow - let alone that I would know how to effectively write a test in UML.

If no, how do you ensure that the application you have built with the throw away diagrams will be understood and maintained moving forward?


By close collaboration inside the team - design discussions, stand up meetings, pair programming, colocated development ("war room"), osmotic communication.

And by building a strong, team wide language - both domain-specific and technical - kind of light weight, team specific design patterns, or perhaps more like idioms.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I had to run before I could say much about the architect's role. All this heavily depends on individual skills and what your team needs and wants. Many teams work quite happily with nobody with an architect title. In more agile shops the whole team collaborates to cover the responsibilities and most of what I'll say doesn't much apply.

We may have gotten the notion from Rational: the architect is a "peer to the project manager." The PM is responsible for planning, scheduling and tracking work to meet release requirements. The architect is responsible for technical vision and quality. Some possible responsibilities:

Define, prioritize and enforce (how?) quality attributes of the system. I have a list of a hundred or so in a drawer someplace that I pull out for new projects: speed, portability, small memory footprint, small disk footprint, reuse existing components, contribute to reuse, conform to standards, easy to maintain, easy to deploy, scalable, easy to manage and many more. Customers and managers help prioritize and commit to the list.

Code (with a very small team - 2 or 3) the "spike" that proves the architecture works. Code any frameworks needed to make a larger development team productive. That second sentence almost says "so an army of interchangeable coding drones can churn out functionality without thinking too much" which is a really harmful attitude. Be careful there.

Produce or consult on designs at any level: System interactions, major components, internal implementation classes, database models.

Review or police quality.

Liason with external partners. Because we have many partners, this is a big part of my day ... negotiating protocols, defining spikes, documenting findings.

That wound up pretty broad. Maybe some teams just call that "technical lead" or "senior developer".
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Stan James:
That wound up pretty broad. Maybe some teams just call that "technical lead" or "senior developer".


And some just call it "team member".
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Yes, I started with that caveat: In more agile shops the whole team collaborates to cover the responsibilities and most of what I'll say doesn't much apply.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: perspectives for UML diagrams