The title says it all. I have moved Model Architecture to WordPress and a custom domain to better support my growing needs. There are many sites on how to port from blogger to WordPress, but the long and short of it is that there is a build in importer in the admin site for your wordpress blog so it take about 3 minutes as long as you have a “newer/modern” blogger account. I did so, 3 minutes later it was done.
(Just a screenshot of where it is located)
Martin Fowler and Markus Völter on DSLs – JAOO Conference Somewhat interesting discussion by some DSL leaders. There is a small bias around a specific vendor’s software, but interesting to listen too.
What they talked about, my notes:
DSLs:
Eclipse GMF/EMF/Textual Languages
CASE Tools, COBOL, Fantasy that programmers are not needed.
Levels of DSL/DSM tooling – Documentation/Testing/Execution
Custom Syntax (External DSL) vs Internal Syntax (Internal DSL , Lisp/Ruby)
Method Chaining, Cool!
1 notation or many notations
(Excel, Boxes and Lines, etc) Power in how to combine the notations.
Divergence, Experimentation, and then Convergence.
UML is not a factor, so they think.
Here is the book in progress that Martin Fowler references, it was in draft form at time of my writing this post. Fowler’s DSL book draft
Have questions about UML/Modeling, then go on over to StackOverflow. I monitor the questions there and provide answers for two reasons:
1. UML outreach for people starting out, not the easiest thing.
2. Some questions require research, which I enjoy, and I find that those questions go unanswered.
You can follow the questions I answer with RSS http://stackoverflow.com/feeds/user/30231
Additionally, you can follow items by tag, like UML: http://stackoverflow.com/feeds/tag/uml
Give Stackoverflow a try, you can get answers very quickly and with often very good quality for free, other than the keystrokes and mental effort in describing the question.
A post by lispy entitled “Why UML Fails to Add Value to the Design and Development Process” reminded me of an existing methodology put together by IBM.
Lispy wrote (I cut a lot out) –
“The modeling language must be a first-class citizen of the development process rather than just make-work for architects and project managers… There are two linguistic abstraction barriers that must be implemented in order to make this work: 1) the modeling language between the models and the generated code and 2) the framework between the generated code and the target libraries. You must build up from your core code components to the framework… and you must build down from the models to the generated code. If the code generation process is too complicated, you may need better abstractions at the framework level. If the code generation process is impossible, then the modeling language may not be providing a detailed enough description of the requirements. If there is too much repetition in the models, then the modeling language will need to be extended to cover additional concepts.”
What I was reminded of was “Patterns: Model-Driven Development Using IBM Rational Software Architect”, by the way you don’t have to use IBM’s products. You can go off and the whole thing, but chapter 4 is where the meat is and Figure 4.2 on pg 47 and the related descriptions on the following pages put it all in place. It really lays out a process which in my mind covers some of Lispy’s concerns.
A short post just to share an interesting modeling process I learned about sometime ago.
The “Done, and gets things smart” phrase coined by Steve Yagge and the “Smart and gets things done” phrase and book by Joel Spolsky are great mantras of modes of operation for technology geeks. Modelers should make special note however as the job of modeling is viewed as overhead or just smart people’s diagrams.
The “Done” part for modelers is critical in several ways. One, Modeling never seems to be done, it can always be improved and two, it always need to be done yesterday because the developers, business, PMs, and Stakeholders don’t see direct value in modeling. Ok, modelers done means actually putting a line in the sand of when the model is good enough, and no this should not be based on your comfort level of showing everything or the number of elements and number of diagrams it should be based on the business needs and drivers, the amount of time the developers need to code up your crazy over engineered design, the market demands, whatever! A model of a system or process that never gets implemented is useless other than too add another notch to your diagramming belt. This brings us to the second part of “done” which is not really your, the modeler, problem but managing others perception and demands. You need time to do your work, however, your work must demonstrate value. Real value is finishing, the modeling needs to get done on or ahead of time.
But Ted, what if being done meanings cutting corners or not going to the granularity required to guide the developers in every aspect? How is that smart? Here is the challenge, I contend that a great modeler knows what pieces parts or elements of a model/solution must be in place to ensure success (Success by most concerned parties measures). Many smart people have asked many smart questions or labored over a large document (Tax reform, all laws, etc) and did more harm than good. If someone asks you 20 questions or read 100 pages and only 3 questions and 16 pages mattered is that smart? Didn’t think so. Modelers have qualities which must be managed to be “done, get things smart”. Modelers have strong analytical minds that can shoot out more questions than a room of people can answer and they are detail oriented. Left un-managed nothing would ever get completed and no it is not your boss’s task. Diagrams have audiences other than yourself and other dorks. Target your audience, this requires more smarts than just creating complete models it requires considering other aspects or factors affecting your final product, from developer’s need, project time lines, readability, etc. As a modeler your are more than a drawer of lines and interpreter of facts.
So for Modelers the phrase or mantra should be “Done, and gets things smart enough” for all the reasons mentioned above. This is not easy and it separates the good from the great. Besides perfection should be left to gods and idiots.
The blog name “Model Architecture” is by no means descriptive or clear, however, it does provide sufficient latitude to post on most topics I am interested in. The goal of this blog is to start pulling energy back into modeling. The hype has faded and the subsequent contraction has left practitioners and new modelers in a vacuum. As the technologies and standards change, but the problems remain there is always plenty to discuss. Not that one person can really effect this… ya ya ya. Ok, not everything but this list should prove a fairly close guide.
Who I am is not really important as I am not someone famous or influential. What I do might be, so I am a Project Architect with a financial company and a graduate student at the University of Minnesota. My focus has been on usability, data, and modeling. Although you may not see it as a defining important personal descriptor I do, I am a Lisp/Functional language advocate. Far to fewer people know it or use it.
Well if you have any ideas or thoughts comment away.
