Passion * Technology * Ruthless Competence

Monday, February 28, 2005

Modeling vs. Visualization

Javier got me thinking when he left a comment to my square peg model post. I'll get to intended semantics of class diagrams in another post, but I wanted respond to the latter part of the following comment:

I suppose you are assuming that the Class Diagram is intended to be used for design purposes. Then, a class diagram could be considered simply as a code visualizer.

That's a great point that ties into something I've been thinking about lately: the Class Designer in VS2005 is not a modeling tool, it's a visualization tool. For me, the difference comes down to abstraction and transformation. In VS2005, the Class Designer is built on top of the same metamodel as the underlying language. This means there is no transformation and that the diagram and the text of the code itself are at exactly the same level of abstraction. To me, you're not modeling unless you've raised the level of abstraction.

However, while I think VS2005's class diagram is a visualization, I also believe that UML's class diagram is a model. UML is not built on the same metamodel as the underlying language. It's at a slightly higher level of abstraction. That's why you can generate Java, C++, Ruby or C# from a given class model. That transformation step between diagram and code is what makes UML a model. Granted, the class model of UML is intentionally close in abstraction to the code, but it's still an abstraction.

The only reason it matters IMO if a given diagram is a model or a visualization is to be explicit about the need for transformation. And even the need or lack of transformation is only important for usage purposes. Each method has its pros and cons. UML can't model C# code as precisely as VS2005 can visualize it, but VS2005 can't be used to generate code for non .NET languages.

Javier's point cuts right to the idea that modeling classes "for design purposes" isn't particularly valuable as classes are such a low level abstraction. I think that's why so many people use UML's class model as a general purpose "thing" designer. The question is, what was the class diagrams intended use?

Posted By Harry Pierson at 7:44 AM Pacific Standard Time
Comments are closed.

SoCal Code Camp

PDC08

patterns & practices
Summit 2008

Change Congress
Recent Bookmarks
Tags .NET Framework (2) ADO.NET (5) Agile (7) AJAX (3) Architecture (284) Guidance (6) Interop (2) Modelling (61) Patterns (7) Process (4) SOA (93) Web Services (5) ASP.NET (24) Battlestar Galactica (3) BI (2) BizTalk (4) Blogging (115) dasBlog (11) Podcasting (4) BPM (1) C# (10) C++ (4) Capitals (5) CardSpace (3) CLR (2) College Football (10) Comedy Central (1) Community (81) Concurrency (6) Consumer Electronics (1) Database (13) Dependency Injection (2) Development (117) C Plus Plus (1) Embedded (5) Lanugages (37) Media (2) P2P (11) Rotor (1) SharePoint (6) SOP (3) DIY (1) DLR (16) Domain Specific Languages (13) Durable Messaging (5) Dynamic Languages (10) Dynamic Silverlight (1) Education (3) Enterprise 2.0 (1) Entertainment (14) ETech (15) F# (51) Functional Programming (17) Game Development (2) Guidance Automation (3) Hardware (8) HawkEye (3) Hockey (29) Home Electronics (1) Home Network (5) Humor (5) IASA (1) Idempotence (3) infrastructure (5) Instrumentation (4) Integration (2) IronPython (45) IronRuby (12) Java (2) Job (3) LINQ (23) Live Mesh (2) Lost (1) Master Data Management (1) Media 2.0 (6) Microsoft (30) MIX06 (2) Mobile Phone (1) Monads (5) Morning Coffee (172) Object Oriented (4) Office (5) Open Source (5) Open Space (2) Operations (3) Other (135) Art (1) Books (1) Family (31) Games (18) General Geekery (26) Home Theater (1) Movies (23) Music (20) Politics (3) Society (1) Sports (37) Working at MSFT (15) Parallel Programming (3) Parsing Expression Grammar (16) patterns & practices (2) PDC08 (5) Politics (47) PowerPoint (2) PowerShell (34) Presentation (5) Projects (1) HawkWiki (1) Python (4) Quote of the Day (4) Refactoring (1) Research (2) REST (18) Reuse (5) Robotics (2) Rock Band (4) Rome (5) Ruby (23) Ruby on Rails (1) Sci-Fi (2) Scripting (4) Security (3) Service Broker (14) SharePoint (2) Silverlight (18) Social Software (1) Software + Services (2) Software Design (1) Software Factories (11) Software Industry (1) Spark (1) SQL Server (2) Stephen Colbert (1) TechEd (7) TechEd06 (1) TechRec League (1) Television (6) Travel (6) Unified Client (1) Unit Testing (4) USC (1) UX (1) Virtual PC (2) Visual Basic (1) Visual Studio (20) Volta (2) Washington Capitals (34) WCF (31) Web 2.0 (65) Web Services (5) WF (21) Windows Live (23) WPF (7) Xbox (1) Xbox 360 (53) XML (11) XNA (14) Zune (4)
Disclaimer: The information in this weblog is provided "AS IS" with no warranties, and confers no rights. This weblog does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my opinion. Inappropriate comments will be deleted at the authors discretion.