Robust Case Studies

[ASP]

Hey, folks.

I'm fairly new to UML and even more so to EA. However, in a short time I've read quite a bit of material on the basics of UML and the reasons to use specific diagrams, models and views.

Now, I would like to really dig into the subject, and I feel the best way for me to do so is to read and analyze several in-depth case studies. Specifically, for now, I'd like to focus on UML case studies on software engineering & software architecture.

I've examined the "Resource" link on the Sparx Systems site, as well as other related links here. While the information is welcome and valuable, I have not found the in-depth UML case studies that I described. Naturally, I've also "Googled" the heck out of this but have not found any satisfactory links.

If anyone would care to contribute some links where I may read and/or download the aforementioned case studies, I would very much appreciate your suggestions. Thank you for your feedback.

[thomaskilian]

Hi ASP,
from time to time this question pops up in this forum. I can summarize what all your predecessors reveived as answer: you won't get it. You might ask Bruce for his model (1 mio AUD) or you can have mine (only 100 kEUR). Robust case studies (if done in reality) contain valuable information which can't be given away.

You might want to look at ICONIX site (referenced on Sparx' site). The have a nice and affordable tutorial.

[ASP]

Thanks for the reply.

That is unusual, particularly since it is generally easy to obtain well-documented, practical examples for a variety of other frameworks. I would have thought that in this day and age, the same would be available for UML case studies, at the very least in the area of software engineering/architecture.

Mind you, I completely understand and respect the reasons for keeping specific models close to the vest. However, in the interest of promoting recommended practices for UML, it is very reasonable to have accessible well-documented case studies for fictional entities. It's done all the time elsewhere. One might argue that I should purchase a book. Well, I have purchased several, and I will purchase more. The problem with books is that their content must be broad enough for a publisher to see a viable profit, and that's fine. Heck, I've purchased books with similar content on various technical subject matter simply because I want to read and understand the various authors' points of view. However, I have also downloaded a myriad of free white papers, tutorials, code, etc. to supplement my existing knowledge, and that is the issue at hand. If one wants to read very specifically targeted information on a subset of a given subject matter, a book is not the best vehicle for this purpose.

Providing UML case studies would have a dramatically positive effect on disseminating UML and its proper usage. Surely, this would benefit the UML community as a whole. I guarantee you there are a multitude of developers/engineers/architects who would more readily adopt UML if given the opportunity to examine accepted practices in the form of case studies without having to shell out a credit card each and every time. Further, I submit that individual and corporate sales of case tools would increase as a result, and this would widen the talent pool. Naturally, some ensconced in this field may be uncomfortable with this prospect, but I am sure those with that mindset are in the minority.

Looking at the big picture, imagine all the unintended positive side effects. For example, if it weren't for Tim Berners-Lee, this forum might have been running as a BBS. We all continue to benefit from his insight and generosity, and a myriad of new opportunities arose for the developer community.

So, I say not having freely available robust UML case studies makes no sense. Personally I would gladly purchase some case studies AFTER I thoroughly examined well-designed freely available case studies; I've done this in the past in other areas.

I challenge those of you "in the know" to create and make freely available UML case studies. You will be well respected for your contributions, and it will provide a means for you to effectively market yourself to individuals and companies alike.

[ocroquette]

Been there, done that

And I didn't find any UML model of respectable size anywhere either

I thought the book "UML in practice" would help to this regard, but while containing useful advice, all the examples are pretty small, at least in comparison with real-world systems.

I agree with you that this lack of reasonable example is really annoying!

[mikewhit]

You could always start an open source model !

But you would surely find quot homines, tot sententiae

[KP]

quot homines, tot sententiae

suus quique mos.

[Paolo F Cantoni]

suus quique mos.

Quis custodiet, ipsos custodes?
Paolo

[thomaskilian]

I better like Bacon with my scrambled eggs.

[ocroquette]

You could always start an open source model !
But you would surely find quot homines, tot sententiae

Well, the same is true for the code itself. Developers have different conventions, design choices and styles.

Now that you talk about OpenSource, it's also interesting to note that the OS project are not really keen to use UML or modeling.

Is it because:

• the developers are their own client
  
• coding is fun, modeling is boring
  
• the free UML tools are limited
  
• other reasons?
  

?

[Paolo F Cantoni]

• coding is fun, modeling is boring

Shame on you!  ;D

Modelling is fun (or at least it aught to be - if the tools were better), Coding is boring!

I really only like to write code that writes code...  8)

Sometimes I daydream about writing code that writes code that writes code..  8) 8)

Paolo

[kimballjohnson]

The answers to this question are more interesting in some ways than the question itself.

For how to use UML in practice, you need to go away from UML books. Here's why:

Since UML is the object oriented abstraction of object oriented code structures, all UML 'explanations' are going to be wrappers around explanations of how the UML object model works and why. This is not useful for the practioner for the most part, although it is helpful when things don't make sense.

That point explains why UML tools do not satisfy most application developer needs. When you count by weight or volume, the strictly object oriented portion of the code we write as developers is minimal: classes and hierarchies are the containers for the tons of procedural code we write inside methods. None of that is available as UML unless you are willing to go to State Models and Timing Diagrams (which are the next revolution). The balance of what we use are Frameworks and Libraries. Although you can disect these using UML (object orientation) you are clearly off the developer's critical path when you do so. Therefore one part or another of your anatomy receives a painful smack and you get back on track.

As a result, the tools needed are not strictly UML (the faded Rational Rose) but are a bundle of tools that meet a variety of day-to-day situations. EA is the broadest cheap tool.

Therefore if you need background orientation and understanding on application development solutions, the theory is in Architecture books; then the tools become useful as you try to put these concepts into play.

Iconix and so forth can help you apply the tool once you have the background.

Here are some pointers:

1. Martin Fowler defines patterns for applications. My contribution is that Patterns are really only valuable for Frameworks. That's good because then developers code procedurally inside the 'hot spots' defined by abstract classes exposed by the Framework. Fowler is the path to laying out your Models, especially your deployments, testing and components.

2. Allister 'coburn' (Cockburn if you're careful about his sensitivity to pronunciation) is the definitive source about Use Cases. Use cases are the central nexus for information in EA or any UML tool because they tie together user functionality, system requirements, procedures and domain language. That makes them the 'Domain Specific Language' of Model Driven Design.

3. Eric Evans provides the conceptual basis for doing what Iconix says Ivar Jacobsen invented: transforming static understandings of needs into dynamic models of code. Therefore read 'Domain Driven Design' to really understand why Activitiy diagrams are the real next step after Use Cases. These diagrams validate that you understand how to implement a Framework that will accomplish what the User expects as the systems functionality.

4. Most people don't go beyond this point because when they have a domain design and a validated activity diagram, they are already behind in development and the get to coding. The only other unavoidable thing is Requirements. Stick these in through your EA Use Case object and then Externalize them to a separate Requirements model so they can be reported in a single report that has a signature line at the end of every package section. Then you have something your Stakeholder can sign off on.

5. How to define tests so that you can print them out for QA is another story, but not quite so interesting.

Thanks,

Kimball Johnson