--- title: "Q&A: Microsoft, UML and Software Factories" url: "https://osherove.com/blog/2006/5/16/qampa-microsoft-uml-and-software-factories.md" canonical: "https://osherove.com/blog/2006/5/16/qampa-microsoft-uml-and-software-factories.html" published: "2006-05-16T10:42:00" updated: "2006-05-16T10:42:00" tags: [] author: "Roy Osherove" description: "Q: Software Factories and UML Has Microsoft Abandoned UML? Is the Domain Specific Language path so different than UML? Can they be combined? From what I’ve seen so far, and from talks I had with various people (…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Q&A: Microsoft, UML and Software Factories By Roy Osherove May 16, 2006 **Historical article** · Originally published May 16, 2006; technical details may be outdated. Q: [Software Factories and UML](http://weblogs.asp.net/rosherove/archive/2006/05/15/ArchPanelQuestions.aspx) Has Microsoft Abandoned UML? Is the Domain Specific Language path so different than UML? Can they be combined? From what I’ve seen so far, and from talks I had with various people _(_[_including Steve Cook_](http://www.teamagile.com/mainpages/Interviews.html)_, from the original UML Team, now at Microsoft_), Microsoft have sort of “adapted” an easy to use and understand version of the UML. They took the basic idea of shapes and arrows and made it work on the level of a specific domain which is in turn used in a [Software Factory](http://www.softwarefactories.com/Links.html). Most people I know have done \*some\* UML, but most only know how to use maybe 3 or 4 types of UML Diagrams, let alone using UML Protoypes and such stuff. The main problem people face with UML is that using it to draw shapes, it then makes you give \*specific meaning\* to those shapes in your own domain using prototypes. Instead of using proptypes on the UML (which are very time consuming) Microsoft has taken some of the simplest ideas and made them part of the tooling strategy. So when you draw a shape, you’re actually drawing some sort of \*real\* entity in your domain. You can then manipulate it and use it to build real code, and it (should) reflects changes in the real code. The notion of a software factory is, to me, taking the UML shapes and giving them real meaning inside the tools. Not only that, to be able to create meaningful shapes for specific projects easily. I still use UML to a degree – whenever I draw shapes on the whiteboard I draw UML. Whenever I want to make some interaction clear I draw some sort of interaction diagram. But that’s basically it. IN projects where you are forced to write so much documentation and use cases using UML it usually turns out to be a very complicated set of design docs that developers have trouble reading. When they finally get to reading the whole thing its usually way out of date anyway and one has to talk to the man who actually wrote the thing. See? \*Communication\* always wins. Instead, what I try to do is have less documentation (butt enough to get things going) which can help start good conversations with the designer/architect in that project. In an XP project that’s could be the team lead. So, in short – UML is too complicated, most people don’t know even half of it. Microsoft tries to make it simpler and more usable in the real world of its tools. Cross Posted from [Blogs.Microsoft.Co.Il/Blogs/Royo](http://blogs.microsoft.co.il/blogs/Royo) --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/