Rosario – Import Visio documents in the diagrams.
Had some fun last weekend and past evenings with Rosario, DSL’s and Visio.
When you read the MSDN forums about Visio, Modeling and Tools, Team Architect and Rosario you see that there are often questions about Visio and the need for export functionality… see this search result list and these threads:
This answers, triggered me:
there is no way to export to Visio using the April CTP
David is right with his answer. Visio 2007 doesn’t have an XMI export and the April CTP doesn’t have a XMI import [yet!!??, haven’t heard anything about it but David Starr mentions it in this post Architecture Modeling in Rosario with Peter Provost, still wondering if you can make an general XMI export/ import while every tools uses it’s own version].
But, the Rosario UML diagrams are based on the DSL tools… so everything is possible :-)
So, after some hours of playing… here is the Visio Import Addin. [don’t think an export is prio 1 at this moment]
First create or open an activity diagram, right mouse click and select “Import Visio Diagram”…
Select the diagram you want to import and look at the result…
I know it’s a very simple diagram, but it works, it even tries to take make the same layout (I didn’t do anything with the position of the shapes after the import)..
So, now it’s time to answer that forum post :-)
I think it’s useful. It’s useful for us, we’ve got tons of activity diagrams in Visio...
Anyway, time to prepare myself for a trip to Italia… will show some code after this weekend.
Rosario – Create Custom Team Architect UML Diagram-MenuItems
There are many ways, maybe to many, to extend Visual Studio. Macros, AddIns, VSPackages, [see: Visual Studio Extensibility Demystified] GAT-GAX, et cetera and now with Rosario we get even more ways with new features like the Architecture Explorer [see Create your own Progression Provider post].
So, we’ve got a lot of ways to add our own functionality. While the Architectural Explorer is more for visualizing the architecture of your applications [or binaries] it is also possible to make executable commands, not really the best place to do that. I think users will get lost when I hide my commands in there, they are used to the current structure of commandbars and mouse-menu items. We also could use GAT-GAX [did that with the first ideas around testcase generation] to add commands, works also pretty easy… [note: you can install all the possible powertools, AddIns, gat-gax and factories which work on Orcas also on the Rosario CTP12].
Anyway, because I think commands should be as near as possible at the thing they act on, for the TestCaseGeneration that would be the activity diagram, I wanted the command on the activity diagrams design surface. Not really rocket science because the Team Architects UML are based on the DSL-Tools.
First, create an normal Visual Studio AddIn project [Creating Visual Studio Add-Ins] and add the necessary code for adding an CommandBar. The only thing you need to figure out is the CommandBar you want to add your MenuItem at… for the activity designer this is “Activity Designer Context”, for the use Case diagrams it is “UseCaseModel Context” and so on… you can easily get all the names by iterating to the CommandBar collection.
Next, create the MenuItem handler, grab the current file and load the model [see next code snippet]. From here we can do anything with the UML diagram we want to do. For example for the testcase generation I only iterate trough the diagram [ see: foreach (ModelElement … in allElements) ], do some magic and create the WorkItems. But, you also can add ModelElments at the diagram, remove them or change properties.
Getting the model diagram is also pretty straight forward…
Conclusion: adding MenuItems is an easy way to add functionality to your diagrams... although I have to say that this implementation is based on the Rosario CTP12 bits and I don’t expect they stay the same while the diagrams evolve. Anyway, for now, a nice way to play with the UML diagrams.
Rosario – Project Estimating with Team Architect Diagrams
An idea [and early implementation ] of our “Enable ALM by Automation” vision within Rosario.
While VSTS with TFS is great in measuring, time tracking, project planning and other project management kind of tasks it misses the early phase where the project team needs to estimates the project. With Rosario Team Architect this important missing piece in Application Lifecycle Management can be realized, by making an “connected” viewpoint for business estimation and measurement.
Project Estimation.
I think, I don’t have to talk about why there is a need for project estimation [it would be a very long post], how it’s done and what needs to be in place to do it “right” [is an estimation ever right??] is more interesting.
The classic estimation book 'Software Estimation: Demystifying the Black Art', a must read anybody interested in software estimation, is a good start in capturing the needs for a good enough software estimation implementation. The next “deadly sins” are distilled out of this presentation “10 Deadly Sins of Software Estimation” from the author “Steve McConnell”.
- Confusing targets with estimates
- Saying “yes” when you really mean “no”
- Committing to estimates too early in the cone of uncertainty
- Assuming underestimation has a neutral impact on project results
- Estimating in the “impossible zone”
- Overestimating savings from new tools or methods
- Using only one estimation technique
- Not using estimation software
- Not including risk impacts in estimates
- Providing off-the-cuff estimates
Before we can use this list and look at Rosario Team Architect and what the diagrams can mean for software estimation we have to dive in to the different estimation methodologies. Lucky me somebody already did that in this paper “An Effort Estimation by UML Points in the Early Stage of Software Development”, and the writers also point to the pain point of these methodologies:
Common problems with these approaches are lack of early estimation, over-dependence on expert decision, and subjective measurement of each metric. A new approach is required to overcome these existing difficulties. We move upstream in the software development process to requirement analysis and design.
The missing estimation style in this table is the most interesting one for us, Use Case Points. [it’s the topic of the report, so that’s the reason it’s missing]. Use Case Points is an estimation method based on UML Use Cases. From UML Distilled:
Use Cases are a technique for capturing the functional requirements of a system.
And requirements is exactly what we need as bases for an estimation.
Use-Case-Points [UCP].
So, Use Case Points is based on Use-Cases with al it’s pros and cons. But, the way it works is pretty easy. When you have your Use-Case in place you can start counting “points” the same way as with for example Function Points. Some cases are harder to implement than others so those will have more points… easy going.
To be more precise Use-Case Points exists of:
- the number and complexity of the use cases in the system
- the number and complexity of the actors on the system
- various non-functional requirements (such as portability, performance, maintainability) that are not written as use cases
- the environment in which the project will be developed
and ranking:
- Rank Actors as simple (1 point), average (2 points), or complex (3 points):
- Simple: a machine with a programmable API
- Average: either a human with a command line interface or a machine via some protocol (no API written)
- Complex: a human with a GUI
- Rank use cases as simple (5 points), average (10 points), or complex (15 points):
- Simple: fewer than 4 key scenarios or execution paths in the UC
- Average: 4 or more key scenarios, but fewer than 8
- Complex: 8 or more key scenarios
Readings about Use-Case Points:
Automation.
From a Rosario Team Architect point of view this is an interesting estimation method… because it can be automated! Not that we only should use UCP just because it can be automated, put automation of the estimation process will give us a big benefit in making estimation more mature within the organization.
Looking at Steve McConnell’s deadly sins we can imaging that one of the important capabilities we need from estimation tooling is historical data, “Providing off-the-cuff estimates”. Without historical data estimation is useless, error prone and unpredictable, with automated estimations this can be realized. Another important pro with automation is that we are reproducible, running the estimation again will result in the same numbers, which give the historical data some more value ;-)
TFS is a databasesystem so capturing historical data shouldn’t be a big problem.
[Process Improvement Journey (From level 1 to Level 5) The Boeing Company]
Deadly sins tackled:
- Saying “yes” when you really mean “no”
- Not using estimation software
- Providing off-the-cuff estimates
One other important advantage you get from automation the estimation process with Rosario and UCP is collaboration, collaboration in the early phase of the project lifecycle between business and development. Estimation is important for the business to get budget and for the project lead for the planning, while working together on the Use-Cases business can immediately see what the impacts are in terms of budget, so there will be less unnecessary and incomplete requirements.
Drawbacks and points to look at:
1. Use Case Granularity and Complexity…
There is no standard in writing Use Cases. You can define very high-level cases and very low-level detailed use-cases, nobody will stop you from doing that. This is one major challenge in estimation with Use-Cases. When writing to high level cases you are in the neighbourhood of the deadly sin “Estimating in the “impossible zone” and “Committing to estimates too early in the cone of uncertainty”.
[ The Cone of Uncertainty from http://www.construx.com/Page.aspx?hid=1648]
For sure it’s possible to estimate with use-cases in a more early stage of the project using more higher level use cases, the “initial state”, but keep in mind that the uncertainty will be bigger in this stage. When the project evolves and more information comes available, more detailed use-cases are made, you can tune the estimation and with version control of previous estimations and use-cases you will have an mechanism to assess your previous estimation. With this assessment you can make this process of early estimation in the lifecycle more mature. Actually this learning process must be in place during the whole lifecycle, for estimation and for all the other things. [see the Boeing story]
This problem of differences in granularity and complexity of use-cases is recognized by the industry and many people and organizations have a solution for it. For example Capgemini use Smart Use Cases which are generic use case types.
I really like this approach of a kind of repository of UseCase stereotypes, although you must be aware that a use case is technology independent adding technology in to use cases will make the world more fuzzier.
2. Technology/ platform independence…
Use Case is document which describes “WHAT” our system will do at high-level and from user perspective. Use Case does not capture “HOW” the system will do. It’s impossible to make an “platform independence” estimation. Platforms, technologies, tools and languages all have impact on the speed of development. While Use-Cases, actually UML in its whole, is platform independent, estimation can’t be, so there needs to be a place in the Use-Case-Points methodology for differences in platforms, technologies, tools and languages . With UCP this is minimal done by the identification of actors.
Actor identification need technical details: In order that the actor is classified we need to know technical details like which protocol the actor will use. So estimation can be done by technical guys.
[How to Prepare Software Quotation]
[ almost 4th of July :-) The signing of the Declaration of Independence 4th July 1776 ]
Actually, you don’t want technology in Use Cases, it’s mend to be independent so we need to keep it that way. Another way to put technological knowledge in the estimation is add this information to the complete estimation. For example, most organizations already have chosen their platforms, technologies, tools and languages and Enterprise Architecture will monitor it that every project uses their guidelines. So adding a reference to these guidelines while estimating will bring technology in the estimation. Historical data will need to have this information and projects can base their estimation on this, guideline referenced, data. These Enterprise Architectural guidelines can be measured up-front and will get fine-tuned with every project. With that identifying risks when using new technologies in an early stage.
when capturing this in with automation, you have Deadly sins tackled:
- Committing to estimates too early in the cone of uncertainty
- Estimating in the “impossible zone”
- Overestimating savings from new tools or methods
- Not including risk impacts in estimates
Deadly sins not tackled:
- Confusing targets with estimates [for sure don’t put the estimation in TFs as workitems, maybe something like a workitem where the project lead can upgrade them to workitems. But that’s already very very tricky ]
- Assuming underestimation has a neutral impact on project results [don’t assume that]
- Using only one estimation technique [with one technique automated there is time left for the other…]
Summary.
So, there has to be many capabilities in place before we can make an mature automated estimation process with Rosario Team Architect.
But, we can start small… extend the Use-Case Diagram with additional “complexity” information [also granularity information], add an command which captures the Use-Cases and collect the points. The very near next step would be historical data with the possibility of referencing guidelines. In the future we could make a repository of Use-Case stereotypes like the smart use cases from Capgemini.
[next post an early implementation]
Rosario – Create your own Progression Provider
What Progression Providers?
I mean those commands in the Architecture Explorer. For example the “Insert into Active Diagram” command which generates a sequence diagram from the selected method or the “Save as XPS…”.
And just because Visual Studio is extensible from top to bottom it should be easy to make your own commands.
Why..?
Why would you want to create your own Progression provider? For example, you could make your own “Import from strange format…” or “Export Model to strange format…” commands, XMI for example. I want a command “Generate TestCase…” for this solution Rosario Video - Generate TestCases from ActivityDiagram and I also thinking of changing GAX/GAT actions in progression commands, will save me some installation problems... many possibilities for the progression commands to get useful. Although the user-interface good have some usability improvements.
The Basics…
The providers can be found in the “C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\Providers\” folder and are loaded on runtime. No configuration and no installation is required. Just put your provider-assembly in this directory and the commands will appear in the Architecture Explorer.
This can solve an interesting problem when you work within different teams.
The problem with different teams and extensibility is that Visual Studio extensibility is “developer”machine focused and not project focused. For example, when you want to use an GAT package within a projectteam all of the team-members must install that package. A new team member must start his first day by installing and configuring the packages/ customizations used by that project. When you work on many different projects where each project has his own set of customizations this can be awkward, you have to maintain as many different environments as projects. With the Progression providers “assembly only” approach it will get much easier, just copy past the assemblies or when it’s possible to put them in the same directory as your project [didn’t tried this, maybe some kind of reg-key or config setting which points to the providers]. We could put them in source control [nice wane have] just a get latest will setup your development environment. That will even solve the visioning problem… nice!
The Inspection…
There are already five providers in the “…\PrivateAssemblies\Providers\” folder, let’s examine them with Reflector . A quick look in to the Progression namespace together with the providers tells [see image] that all of them use the Microsoft.VisualStudio.Progression.Common and .Interfaces.
What are the most important classes used by the providers… In Dependency Matrix 2 [below] you can see that the ProviderAttribute and the Transalator is used by all of them and StateMachine classes by 3 out 5. So that are the interesting classes to look at.
The same way you can see that classes prefixed with provider most heavily use [depend on] the ProviderAtrtribute, Translator and StateMachine classes from Microsoft.VisualStudio.Progression.Common.
So, now we know where to look let’s see what these classes do [NDepend right mouse click go to Reflector]. First the DSLProvider, and as expected there is a Provider attribute and an inheritance from Translator. The Translator class has some WPF methods DependencyProperties and some abstractmethods we need to implement.
The Translator method Added runs immediately when the Architecture Explorer starts and the method BecomeActive is called by some kind of interval [still don’t know where it is triggered]. The Tick method is fired by System.Windows.Threading.DispatcherTimer.FireTick and the other methods have logical names.
The only class left to analyse is the StateMachine class and it does exactly what the name say’s. It’s a statemachine, with a little bit of knowledge of the State Pattern is this class easy to understand [you can find in this issie of the MSDN magazine some background, this article “Design Patterns: Solidify Your C# Application Architecture with Design Patterns”].
A state has an enter, exit and update delegate. So, these are methods which are executed at the moment of state change. A statemachine can have different states, you create them with the CreateState method. this method saves the different states in a Dictionary. for example when Enter on the statemachine is processed it fires the StateEnter delegate. You also can add events which helps by the transition between states.
Enough analysing… let’s make our own Progression Provider.
The Implementation…
- Start a new Class Library project.
- Add the Provider attribute and the Translator, IDisposable inheritance.
- Add a constructor where we initialise a new statemachine, create states and events.
This piece of code, initialise a new statemachine, create two states which both have only a StateUpdate delegate. [I have to play with these different kind of delegates, still don’t know what’s the best way…]. The two events both put the statemachine in idle state.
- Implement the added method, we register the action/command so it will be visible in the Architecture Explorer and put the statemachine in Idle state.[You can really do a lot with the RegisterAction method, I think this is the most minimal way to use it]
- BecomeActive is checked constantly with some kind of interval and I had some challenges with this. What resulted in an empty Architecture Explorer and many errors. Anyway, when everything works it enters the ActionHandling state. That one looks in the pendingactions dictionary for the command he wants to execute, mine is called 0xbb6.
After this complete the rest of the methods and do what ever you want…
- Finally, copy past the created assembly to the “…\PrivateAssemblies\Providers\” directory start Visual Studio and have fun with YourFirstProgressionCommand…
This one really does magic… it say’s something like “Hello….” in a windowsform.
Some final words…
This is really a “Hello World” implementation of a progression command, there are many area’s for investigation left… but, it works and I think there will follow many more commands.