Ted Johnson on Programming & Architecture

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

Great minds think and do not always think alike. In surfing the web this week around clojure , Stack Overflow , Architecture and DSL (Domain-Specific Language) sites there is just a broad misunderstanding of UML. Really smart people seem to miss that UML is more than a modeling language with everything and the kitchen sink that is to vague to use. Just keep reading...really. UML is meant for extension and restriction as it offers, via the UML Profiles, mechanism which I recently extolled in Profiles - The UML problem solver . I have found others that are in this camp, http://www.dsmforum.org/ . They even wrote a paper UML vs. Domain-Specific Languages, Methods and Tools which if you go by the title seems to pit UML against DSLs, however it is quite the opposite. They seem to understand that UML profiles can be used to create restricted models or DSMs (Domain Specific Modeling); and yes I am using DSM and DSL interchangeably. Call me crazy, but this is also what the OMG - Objec

In reading several posts on stackoverflow.com (and posting ) and through personal interactions it has become clear that people hate UML because they think of UML as a drawing language and not a tool for modeling. Nothing new so far, however, I realized as people search to bring teams together or gain efficiencies in communication UML all together skip UML profiles. People would really benefit from the added rigour that UML profiles can be used to create. UML problem - How a UML profile helps: * UML is to big - Profiles reduce the scope and mature tools only display valid elements and relationships. Only allow drawing that which should be drawn (modeled). * UML is slow - Profiles reduce the problem space and force the modeler to solve only the important pieces for your particular problem space. * UML is complex - Yup it is, but profile can reduce the possibilities and focus on simpler problem spaces. Novel idea, you mean I don't have to diagram the bits and the components. The

Over at Stack Overflow a question was posted " Is UML practical? ". The question itself is fine, but several of the answers were so narrowly focused. I believe that the everyday developer only sees UML as only a common set of shapes drawing a picture. Granted it has a common set of shapes for notation, but UML is first and foremost about modeling. (Big surprise coming from a Modeling Website). Where did this dis-information come from? In my experience the UML for diagrams message comes from schools/universities and popular UML books. Schools will often only teach UML as a way to diagram the solution you and your team of group participants are going to code up. Well of course it seems a little redundant in that contrived learning environment. UML's concepts are to large to teach in the same class as project management 101 or multi-developer projects 101. Most people just don't go any further with it and thus the collective knowledge is that UML is for making d

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, whatev

Not the most relevant first post, but what ya going to do. I just read the book More Joel on Software . Now if you don't know Joel on Software but still some how have arrived at my blog, which I consider VERY unlikely, here is the scoop. Joel on Software is a extremely popular blog with over a million reads on some articles. Joel Spolsky writes is a informal engaging way an takes on all software questions. If you don't know Joel's blog and are still reading this post and have not yet googled it click this Joel on Software , then come back. Ok now that everyone is up to speed I better review it or something. If you are not connected to the internet and are not nerdy enough to cache the entire Joel on software website onto your phone or pda then you might just want to buy this book. The articles were selected to provide some general theme and flow to the book despite the chapters being desperite posts on the webstie. Though I made it through the book I was not wow'

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. UML Modeling Tools OO methods (OOAD, POAD, SOAD, IOAD, etc) Book reviews DSLs - Domain Specific Languages BPEL/BPMN/BPM Software Standards - WS 2.0, Frameworks, patterns Comments on other posts and articles. 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 be