Visual Studio Team System 2010 – Episode 3: The Lifecycle
Previous episodes:
In the last episode Rob talked about the main challenges of testing, and not only for the acceptance tester but all the roles who are responsible for the quality of the product and that's actually everybody.
No Risk- No Test… what needs to be tested, when there is no business risk there is no reason to test, no reason to make unit tests by the developer, no reason to make regression tests and no reason to do acceptance testing. But when there is a risk every role has the goal of making that risk as small as possible. There is a joined effort in execution of tests to prove that the risk is minimized or solved. The development testers, system integration testers and acceptance testers together have to make a strategy on how to test.
Application Lifecycle Management
When talking about Application Lifecycle Management [ALM] terms like accountability, governance and compliance are used. All of them refer back to “working together”, how do we work together during the application lifecycle. ALM is not about tools, it’s about working together. Working together seamless and flexible while staying in control, being measurable and responsible. All the roles in the application lifecycle have a part in this collaboration effort. Tools can help but isn’t’ the core driver.
There are lots of examples of wrong interpreted business requirements, miss communication between development en test [Rob describes a very real example], applications which won’t run in production, operations who don’t understand the applications. All of them resulting in more work, more faults, more costs or even only costs and no application because the project was unplugged. Most of these projects faults, these extra costs are a slip in communication.
Having a strategy how people have to collaborate within the lifecycle is one important piece of Application Lifecycle Management. Most organizational parts have already some kind of process / methodology in place. Having an approach how to share information and share ideas from their own role point of view through the other roles is a key success factor for lowering the costs and raise the business value of IT investments.
Tools can help with this goal. Having gear in place which supports and stimulates collaboration is a driver for a successful Application Lifecycle Management. But without a plan, how people should collaborate and communicate, tools are useless.
Before ALM…
In the early ages, the waterfall ages, nobody talked about Application Lifecycle Management. Software development was still in his youth, experimenting with proven processes from the industrial age. The era where Taylor educated managers controlled the workforce. Business people writing down what they want [not knowing what they need] and throwing their needs over the wall to the workforce.
There was no communication between the guy who needed the software and the guy who implemented the software, a massive brick wall separated them. All the roles in the Application Lifecycle did their job between walls. People where used to this formal way of working, not arguing, not discussing about the solution, be doing their job as optimal as possible.
It doesn’t need any explanation that this Taylor way of work didn’t work for software development. Some software projects succeeded but many more failed to reach the goal. The main reason why all those projects fail: there was no sharing of ideas, ideas how to achieve business value. Everybody was working in his own domain with their own specific tools, as shown in the picture below, everybody on his own island with his own specific tools, practices and methodologies.
Software development is way different than producing products [Taylor’s theory is about optimizing the work force, something Ford did very well]. Software development needs a shared effort, a shared effort by all the roles in the lifecycle. From the people who have the business ideas and knowledge to the people who have to implement, test and maintain the final solution. Everybody in the lifecycle needs to collaborate with each other. Everybody needs to add their specific knowledge to the solution, that's not the same as adding parts to a car.
It’s interesting to notice that when there are no guidelines / structure in place, and nothing is done to stimulate collaboration. People and groups of same interest starting building their own walls, building their own kingdoms, protecting their environment. So, if we want to change this cubicle way of working, management buy-in needs to be in place, groups aren’t going to collaborate automatically.
Now
Nowadays, everybody understands that communication is king. Roles in the lifecycle need to communicate, need to listen to each other and share ideas about their view on the solution. The Agile methodology gives guidelines and structure , with valuable principles like:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Business people and developers must work together daily throughout the project.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- The best architectures, requirements, and designs emerge from self-organizing teams.
Tooling starts to support these principles [and the other 17] adopting a new way of communicative work around the Application Lifecycle. In 2005 Visual Studio Team System starts to support these principles. The integrated development environment got supported by Team Foundation Server with workitems, process templates and reports, helping to get roles in the lifecycle to communicate in a more efficient manner. Integrated in one tool people can share their workload and workprocesses, giving the project leader and for sure the other roles the ability to have more control over the process of software development, by knowing what the other one is doing.
Telling each other what you are doing is challenging. It’s challenging within a group of people with the same interest, it’s even more challenging between groups of different interests. It’s a culture challenge to get it working. Everybody knows it’s valuable, but most don’t want to give someone else a look in his kitchen. It’s valuable because it give transparency, agreements are known, even if someone is working according to this agreement and people can more easily get in sync. Everybody gets the focus on the business target.
[A dependency diagram of RUP’s process components.]
That people need to work together on a process and workitem level isn’t that strange when we look at the above image. This is a visualization of the degree of coupling between different process elements in the RUP methodology. …A Rational Unified Process (RUP) Plug-in To Support Requirements Quality Assurance [pdf]
The figure shows, that there is a very high coupling for approximately one third of all process components. 21 process components have a coupling less than 25%, 8 process components have a coupling of more than 25% and 3 process components more than 40%.
It’s interesting to notice that the adoption of workitems and processtemplates, although they are valuable, within companies fail. The main reason is the culture of the organization and management which doesn’t fully supports communication. This cultural aspect of communication between different roles, different social groups, should have a main focus while implementing Visual Studio Team System, otherwise success isn’t guaranteed.
This is also recognized by agile gurus like Scott Ambler who is writing in his blog:
Your existing culture and organization can really hinder your ability to scale agile approaches,
In his book “Agile Database techniques” he talks about The Cultural Impedance Mismatch between Data Professionals and Application Developers, discussing the cultural problems according to the communication between database people and code ‘object oriented’ people.
Overcoming the cultural impedance mismatch is much more difficult than overcoming the technical impedance mismatch. [The Cultural Impedance Mismatch Between Data Professionals and Application Developers]
The collaboration starts
While VSTS 2005 and 2008 support communication at a workitem level, the 2010 version of Visual Studio is going to support collaboration at artifact level. Different roles in the lifecycle work together on artifacts. Each of them adds their knowledge, vision and ideas to the solution from their view point. These artifacts are accessible by every role in every phase of the project, adding value throughout the lifecycle.
People are enabled to collaborate, making applications together, and not only by telling what they are doing but most important by working seamless together on the application.
While working together with all the roles and having these ‘ALM’ artifacts accessible for every role, collaboration in the application lifecycle will rise to the next level. People with different social and cultural characters start discussing solutions, trigger each other to improve and being innovative with their view on the application and all within the constraints of their role.
VSTS 2010 enables people to collaborate on artifacts in the Application Lifecycle. While the 2005 and 2008 versions mainly focus on communicating about work [workitems , processes and reports]. With VSTS 2010 the focus moves on to collaboration on artifacts. The main reason this is going to be possible is the investment by Microsoft in the Architecture Edition and Test Edition, widening the scope from developer to more roles in the lifecycle.
Not only development artifacts like source code can be saved to a repository but also test artifacts like test cases and test results. they can also be saved to the same repository, creating the possibility to work together on these artifacts from the same repository.
Testing in the Lifecycle
To figure out how this all works with testing we need a deep dive in the different test roles, what they do, what way they work together with the other team members and what kind of capabilities they need from the tools they use. Rob already talked about the different test roles “developers who are testing, specialist testers during system testing or generalist testers during the final acceptance test”. How do all these test roles work together with for example the business to capture risks of the system?
In the next episodes we will discuss these different test practices what they patterns are and the capabilities the need from tools.
Visual Studio Team System 2010 – Episode 1: A Focus on Testing
An intro from the VSTS 2010 data sheet:
[VSTS 2010 new functionality focuses on the architect, designer and test rolls in the Application Lifecycle]
This series will focus on the test roll; which flavors are there, what do they do, what are their goals, what do they do to reach that goal, how do they collaborate with other rolls and in what way does VSTS 2010 support their activities.
In what way can a collaborative effort in test activities support the business goal? Visual Studio Test Edition offers several new possibilities according to testing in the lifecycle and with the interaction between the tester and the other rolls in the lifecycle.
[Tests in the Lifecycle]
In the early and current edition of Visual Studio Team Test there are already several testing features available, helping the developer with test driven development, performance testing, load testing and several more [see this MSDN page].
While the current version of the Test Edition focuses on the roll of the tester and their activities, Visual Studio Team System 2010 is focused on the collaborative effort between the tester and the other rolls in the application lifecycle.
[Camano, VSTS2010 Acceptance Test Tool]
The most visible feature is Camano, a standalone acceptance test tool. This tool connects with Team Foundation Server and the newly introduced workitemtype ‘test case’. Workitems aren’t the only integration with the rest of the lifecycle, Camano also create automation strips which can be used during the ‘readiness scan’ [the system / integration test phase of the lifecycle]. Both possibilities of Team Test give the tester a stronger connection, a better collaboration with development. Another addition which stimulates the collaboration is Lab Management [see this screencast on Channel9]:
…lab management, which leverages virtualization to enable software development and test teams to build higher quality apps. Lab management accelerates setup/tear down time and eliminates no-repro bugs by creating better integration across dev and test teams throughout the application lifecycle.
[Lab Management]
These new capabilities will help fixing some major challenges in product development, they will save time and improve the quality of the overall product. Analyzing and fixing a bug is, without doubt, a loss of time. And the later the bug is found, the greater are the losses. Finding bugs AEAP (As Early As Possibly) becomes more and more important, especially in the complex systems we make nowadays. The joined knowledge together with integrated tooling of the developer, the tester and the architect/designer can help with this challenge. But, having tooling in place which help the tester to their job more efficient isn’t enough for a good test process. Testers can still just test one button, one screen or even the wrong functionality or do it the monkey way.
[Monkey Testing]
How good is your test process? This seemingly easy question turns out to be very hard to answer in reality. Testing is often experienced as a troublesome and uncontrollable process. Testing takes too much time, costs a lot more than planned, and offers insufficient insight in the quality of the test process and, therefore, the quality of the information system under test and the risks for the business process itself.
The Test Process Improvement (TPI®)-model offers insight in the 'maturity' of test processes within your organization. Based on this understanding the model helps to define gradual and controllable improvement steps.
[TPI® levels mapped on IO model]
Collaborative, efficient tooling together with a mature structured test approach will not only result in better quality software but also gives the Application Lifecycle a way to improve the software delivery process. The responsibility of testers is not only finding bugs, but also to initiate learning cycles. They know where things go wrong.
In the next episode Rob will guide us through the world of testing…
Alternate Image in Diagrams
For communication with higher level audience you can change default images in the VSTA 2010 diagrams.
Some thoughts on Structuring modeling projects in Visual Studio Team Architect.
The success of using models [UML and non-UML] in the application lifecycle dependents deeply on how you’ve organized them, and with that also the success of the solution you are going to deliver.
Models [mainly the UML ones] are used for communication. Communication with different shareholders how the solution looks like and to discuss how the different concerns and needs find their way in the solution. But also to communicate with developers, testers, operations, designers and many more.
[A like this picture of different types of stakeholders, from the change management toolbox ]
Communication, Keep it simple.
The most important thing you have to think of when you want to communicate something with someone is to be clear..! With models this means; clear in language use, so people understand the models. Avoid jargon and overuse of big words.
As the poet William Butler Yeats once said:
Not only be understandable in language but also be clear and self explaining in the organization of the models, so people can find their way in the solution. Just as the basic rules used when writing and article or book.
Organization Maintain a logical order or sequence. Paragraphs should deal with one subject. Logical transitions should be made within sentences and from paragraph to paragraph. Make sure introductions and conclusions are evident. Make it easy on the reader to see your point of view by guiding them logically down a path.
With this in mind, lets organize some thoughts how to structure the modeling effort.
I almost forgot one thing many people, organizations trying to accomplish with the use of models traceability. Traceability of requirements top–down and traceable from bottom-up. Traceability is an interesting goal, a hard to reach goal but we can keep it in mind will organizing our model structure.
The Default Modeling Structure
Lets call it default, because the most common way to group diagrams is in levels of abstraction [Business, Analysis, System and Implementation, see image below]. And within this grouping models are often divided in scenarios, userstories and components, subsystems, sometimes grouped by iteration [see analyses and system model]. 
Having the models structured in this way makes it easy to understand at what kind, what level, you are looking. for example when you want to know the overall
meaning of the system under development, look in the Business Model folder. When you find the piece what’s interesting for you step one folder lower and look at a more detailed level in the analysis model. You can walk down till implementation level, the code and corresponding class diagrams. [with VSTA’s designer bus this should be even more easy]
You also see structures where the analysis model and system-design model are divided in scenarios grouped by iteration [I call it system-design model because the other part of the system model is the high level architecture/ software architecture, see image]. Grouping these two models together gives an easy way to find the meaning, requirements and the corresponding design of components, useful when you have a lot of components and subsystems with many functionality [also called vertical grouping].
Possible artifacts.
Possible, because every project is different and with every project we must think about the structure modeling method, what models are needed and even more important which models are useless.
The Business Model, meant to get business-driven requirements and set boundaries, is not always necessary. Within big companies with mature enterprise architecture skills this is often already defined and is the input for the project. [The Enterprise Architect and the Application ]. But, it’s still very useful to have this information in the solution and not somewhere on a portal, teammembers will have easy access to the “business / why this project” information. And the business models are input for the analysis models. Often used models are: Business Use Cases [Capturing business requirements using use cases], Business Activity Diagram [and-or state chart], and Business Object Model [Class diagram]. When the Business model is in place [and additional information like a glossary], you can define the key usages scenarios for the project.
The Analysis Model, captures more detailed requirements, user stories and/ or usages scenarios [depends on what methodology your team uses]. From the key scenarios found during business modeling, capture the more detailed use cases, activity diagrams and domain model. Just enough information to get an understanding how the high level architecture should be modeled in the System Model. Traceability between the business model and analysis model is easy. the same kind of diagrams are used and the information is just a bit more details in the system model than in the business model.
From the, kind of, requirements gathering models we get at the level of defining our system. The Application Architecture Guidance from the Patterns and Practices group gives a nice overview of this process [see image]. A must see is the video they made. Within the System Model there are two different models [or more] the first is the high level architecture which gives an overview of the system. Component diagrams are often used at this level and also the layer diagram [ the deployment diagram isn't available in VSTA but should also be used at this level]. This high level architecture sets the technical boundaries of the system from where the other parts are designed. I call it the System Design Model, this is where scenarios, requirements who need more designing because they are hard to understand, difficult to implement or some other reason are modeled. Also by using component diagrams, layer diagrams, class, sequence… you name it. so that’s the reason why I divided this system model in two parts.
The thick red line between Analysis model and System model is there because traceability between these two artifacts is hard, two different things get modeled [requirements versus system] and with different diagrams. A thing often done to validate the system design is replaying the key scenarios with a sequence diagram at component level. The Implementation Model is actually the code and the diagrams who live very near the code like class diagrams. As you can see in the Solution Explorer image I called this folder ‘Source’, because that's what we used to do. Also between System Model and Implementation Model a red line and hard to organize traceability for the same reasons. Although the layer diagram with the architecture validation capability makes it easier to get a connection between these two.
4+1 View
The 4+1 View is something everybody learns on school as a way to describe an architecture of a system. This view model designed by Philippe Kruchten defines it’s views based on the viewpoint of different involved stakeholders.
http://en.wikipedia.org/wiki/4%2B1
The scenarios [use case view] are the reason for the system and all the other describe the system, that's way the +1. You can structure your models based on this viewpoint model. Mapped on the ‘default’ structure described in the previous paragraph, it would look something like this; The business model and analysis model are the scenario’s. The system model can be mapped to the logical view, although i do think the logical view as described in the different books has a bit lower abstraction level than the system model as described in the previous paragraph. The logical view can be structured in a horizontal way and a vertical way.
Vertical and horizontal divisions
The application can be vertically divided into significant functional areas (i.e., order capture subsystems, order processing subsystems).
Or, it can be horizontally divided into a layered architecture distributing responsibilities among these layers (i.e., presentation layers, services layers, business logic layers, and data access layers).
[whitepaper [the pdf ] from Sparx]
In the example structure I divided it in functional areas. The process view together with the Logical view are at a conceptual level while the other two [development and deployment [physical]] are at a physical level. In the ‘default’ and in the example structure, the process and logical view are grouped in functional areas, you also can divide them in separate folders. The other two ‘physical’ views is the implementation model, although Visual Studio Team Architect 2010 CTP doesn't have a Deployment diagram [yet..? ]. The development view is the source folder in the example structure, because the class diagrams in team architect are coupled in someway [actually there are two different class diagrams within VSTA, the very tied coupled which is actually a visual representation of the code and the loose coupled logical class diagram from where you can promote classes to the physical level] with the sources. You could make a separate folder for the implementation model / development view and use that one for the logical class diagrams and put the physical class diagrams near the sources. Not a very clear structure, in that way you put the same information two different places.
Actually we made the ‘default’ structure in a 4+1 way. So, when the environment/ customer wants a 4+1 just change the names ;-).
Breakdown
It is possible to make one big diagram in each model, one big use case diagram in the analysis model and one big class diagram in the system model. The pro is that you have everything, all the information together in one place, the con is you need a A-1 plotter and a big wall where you can put it on, beside this con there are many more cons than pros.
[not a class diagram, but a generated Web Service Software Factory servicemodel from a Amazon webservice, see this old post]
When there is just a single owner and editor of the diagram it can be done, one big diagram, beside it’s unreadable for the users. But, when there is more than one editor you get in to problems, merging problems. I change a reference to an object and somebody else removes that object… what should happen when both of use check in the diagram? So, one big reason to breakdown your models is merging. Another reason close to merging is you must be able to change your diagrams in an easy way [ready for change]. Within one big model it’s first hard to find where you need to change something and second it’s even harder to find the dependencies. And I think when you breakdown your models, you also think about important architectural guidelines, like functional cohesion, ownership and loose coupling. For more key design principles, see the application architecture guid, Chapter 3 – Architecture and Design Guidelines.
Some more Thoughts
To get the models and modeling content organized in a way so it’s understandable, simple and ready for communication is hard. Writing a book is hard, getting the structure of the book right is even harder, but getting it right for a software solution is even more troublesome, there are that many different dependencies you have to take in to account that there isn’t an one solution fits all. But not to get depressive, we can have a look at the most important ones and find a solution.
This image from the book “Getting Results from Software Development Teams by Lawrence J. Peters” gives a nice overview of the Modeling Method decision making.
The author described in this chapter also challenges in adopting a Modeling Method, interesting reading. One of the inputs for the modeling method is the type if system to be modeled.
Dependency; Architectural Style, [Type of System].
This is where the The Architecture Meta-Frame found in the Application Architecture Guidance V2 comes very helpful. It describes the most common application types and architectural styles, every type has it’s own pros and cons, but also every architectural style has it’s ‘preferred’ way of structuring the modeling files and projects.
An architectural style is a collection of principles that shapes the design of your application. Many of these styles overlap and can be used in combination. Architectural styles tend to be tied both to the application type and to the point in time in which the application was developed.
Because the Business Model and Analysis Model are a kind of solution independent there will be not much difference needed in the structure. [’Kind of’ because different architectural styles can result to different requirements]. The system and implementation models will have a dependency with the architectural style. For example a Client Server style solution often exist out of database which runs on a server [or in the cloud] and some kind of client application type. The client application is most often divided in to layers. the requirements gathering models will probably stay the same but the system model will have additional diagrams, for example the logical data diagram and for sure the breakdown of the diagrams will be different.
In the client server example you will definitely have a client and a server part, where the server part is the logical data model and the database diagrams. With an N-tier architectural style you probably will break down the models in tiers [difference between distributed deployment, non-distributed deployment], while with a SOA style there are many separated services with some kind of layering and some kind of Business Process Model.
Dependency; Team Organization.
There are team scenarios which influenced the structure of the models. The most simple team structure is just one team working on one project, see image below in this situation the default model structure can be used. Everything is available in one solution, every roll can access the information needed to do his job.
As you probably notice I derived the model structure image from the TFS Guidance from the Patterns and Practices group. See this chapter of the guidance. I’ve added the modelprojects to it. When the system model contains an VSTA Layer Diagram we can validation if the refereneces between the projects defined in this layer diagram are the same as the real world.
It gets more complicated in larger projects where a partitioned solution structure is used [again see TFS Guidance]. Within the development department of an insurance company, for example, there are probably many teams working on different applications/ services or different versions of an application. Communication gets even more important when different projectteams have dependencies with other projectteams [image below and this post VSTA, the enterprise architect and the application lifecycle and this too old post Autonomous Develop Services for SOA Projects with Team Architect and Service Factory].
This large development project is divided in several solutions, because their is still one business demand there is just one business model in the master-solution, and one system model [the HLA part see first paragraph] that gives an overview of the structure of all the child-solutions and their relations. Probably [hopefully] during the breakdown is taken care of the architectural guidelines mentioned in the ‘breakdown’ paragraph [functional cohesion, ownership and loose coupling], so the child-solutions can have their own analysis, system [the lower part] and implementation models.
One project team opens his child-solution and want to start defining it’s implementation model, layers, components and classes, what kind of information do they need? first the analysis model to get information what should be build and second, the dependencies [the interfaces] with the other projects. This information is available in the master-solution but it would be inefficient when they also had to open the master-solution just to get a view of the relations. So, a better way should be when with the child-solutions also contains the two modeling projects [business model and system model] from the master-solution. A very easy way to accomplish this is with the add existing project menu-item. One big benefit of adding the business and system model to the child-solutions is that the elements used in these diagrams appear in the model explorer and can be re-used in the child models.
 |  |
| Master solution with all the child projects, the Business and System model named the High Level Architecture. | A child solution with at the right the child analysis, detailed system and implementation models… and the embedded master business / system HLA… which show up in the model explorer for reuse. |
The very large project is actually a combination of ‘normal’ projects and ‘large’projects. Although the solutions which have an dependency are still troublesome and should be build in the order of dependency… see image form again the TFS guidance.
Dependency; Methodology.
CMM vs Agile… a big difference, see Agile Modeling for details.
pfff… don’t feel like typing any more, the story got a bit longer than I wanted... but will be continued, because this also opens opportunities for the Blueprints [see the posts I did with Edward].
One final quote:
The essence of "good design" is it's ability to be absorbed by a human mind. Design is "good" when it can be easily-learned.
...
Good design is about knowledge. We wrap it up in all kinds of terminology, but in the end it's about making smallish bits of software that are easy to understand on their own, and that fit together exquisitely to make things bigger than themselves, and that can still be as easily understood.
"Good Design" Means ...?
VSTA, the enterprise architect and the application lifecycle
There are a many types of architects in an organization and one of them is the enterprise architect, he / she architect’s enterprises. So, what do they do and how can ALM benefit from their work? Very brief they make ICT valuable and adoptable for the business, they are the bridge between business strategy and the ICT of an organization. When looking at the ALM circle I would say they feed the business part. Not very well explained, they better can do it their self… you can find here on wiki and here on DYA some more information.
One important thing for application lifecycle management are the artifacts they deliver to the overall process and products? What kinds of tools are used? And how can the application lifecycle benefit from it, so projects can work in a more collaborative way with the ivory tower. [ouch, I think they don’t like that word]
IBM just acquired Telematica which has a tool System Architect. This tool specially made for enterprise architects and positioned by Gartner as the lead tool in the quadrant for enterprise architect tooling gives a nice overview of the work of enterprise architects.
So, some screenshots from the five minute demo.
 |  |  | 
|
| This is a little bit chaotic model, but it explains the dependency between the business, the applications/ components and infrastructure. | Each of these layers can be modeled separately in System Architect. for example the structure of the business. | The Logical Data Model | and some Business Process Modeling with swim lanes and the ability to make use cases from it. |
So, enterprise architects have / make an overview of the complete business structure, business processes, the relations with infrastructure and software components. Which give them the capability to make decisions about what software components / applications should be made to support the business, which actors have a place in this process and with which other components does this new component / application communicate [have a dependency] with. Beside this, also information about hardware / infrastructure, datamodels and ideas how all this should evolve in the future. [I’m not talking about standards and guidelines, that’s a complete different discussion]
How should development use this information created by enterprise architects?
First of all, if they do their work well, it helps the development department to work on autonomous, loosely coupled projects, that can be managed and executed in isolation, with no dependency on other projects. So you don’t get any deadlocks when one project isn’t finished yet. More practical, the development department can define separate team projects in Team Foundation Server in place of having to put all the project in one Team Project [that's a nice trigger for a bad definition of projects].
The other important part is helping re-use or better stop the re-creation of services/ components which already are made and offer the right [or almost right] functionality. Having an overview of all the software components and the business processes that uses them should help the definition of services and which software component uses it, so having this information available in projects will stop the recreation of this functionality.
More at project level, the actors are already defined even business use cases are already made [generated] so it should be interesting to re-use [import] those in Visual Studio Team Architect, for further modeling of detailed use cases and activity diagrams. With enterprise architecture in place project shouldn’t great their own actor definitions and business uses cases, even external components and their interfaces can be re-used by designers and solution architects.
Get the information in Visual Studio Team Architect.
The best place in VSTA to have this information available, is within the Model Explorer. No predefined sets of actors and use cases for the whole enterprise [that only would make a mess of re-use] but only for one specific project the specific actors, business use cases and external interfaces. Cameron has a nice overview of the model explorer on his blog The UML Model Explorer. I have to mention he uses new bits so not all functionality can be found in the current CTP.
Creating an addin which imports the information from System Architect, Visio or any other enterprise architect tool [even the heavy used tool powerpoint should be possible :-) ] into the model explorer is very easy. The ‘shapes’ available in the model explorer are described in an XML file called “ModelDefinition.uml” adding the necessary xml to this file will show the shapes in the model explorer, ready for further modeling.
For example the XML below is the XML from the shapes shown in the model explorer showed on the left.
How can enterprise architects benefit from development and operations?
It’s for sure a two way communication, it’s even a collaborative effort between operations, development and enterprise architects to work on the enterprise architecture process [and application lifecycle]. The first thing I think when I see all the fancy ‘high level’ diagrams with connections, dependencies and the evolution made by enterprise architecture, is that they never ever represent the real world. The models are made, projects are defines and implemented over time, new projects are added, models are updated… at solution architecture level there is already a challenge to keep models up to date / in sync with the running code. So, having these higher level models representing the real world is even a harder job. But development can help, with the architecture explorer in place we can visualize the real world, even what .NET framework is used and what kind of external components. Interesting information for enterprise architecture to check their models, an import or export should be possible, I think…
On the other side operations can give enterprise architecture additional information about application uses, is a component not used? or by people in a different business process as they thought it would be… when we want to deliver this kind of information back to enterprise architecture we sure have to in cooperate ‘design for operations’ in the architecture [enterprise and solution architecture].
Anyway, interesting thoughts. Have to work and discuss this much deeper to get a good insight in the collaboration between enterprise architecture and Application Lifecycle Management but that there is a tight connection that's for sure.
VSTA 2010 – UML Profiles [make your own…]
Does anyone have seen that there is the capability to attach UML Profiles to the UML Diagrams in the new CTP..?
Just take a look at the property window of the component diagram or use case diagram or any other diagram and you can see that there are 3 out of the box ‘trial’ profiles available.
You can find this ‘profiles’ property on the design surface and after selecting one [or more] profiles you get a new property on the shape named ‘Stereotypes’ with values depending on the profile you selected.
That’s it for Profiles and Stereotypes in the VSTA diagrams. It doesn’t seem that valuable at first sight, but you can do magic with it.
UML Profiles
First a brief explanation of UML Profiles, better and less time consuming a copy-past from Wiki and OMG [a little bit more fuzzy than wiki].
A profile in the Unified Modeling Language provides a generic extension mechanism for customizing UML models for particular domains and platforms. Profiles are defined using stereotypes, tagged values, and constraints that are applied to specific model elements, such as Classes, Attributes, Operations, and Activities. A Profile is a collection of such extensions that collectively customize UML for a particular domain (e.g., aerospace, healthcare, financial) or platform (J2EE, .NET).
- Identifies a subset of the UML metamodel.
- Specifies “well-formedness rules” beyond those specified by the identified subset of the UML metamodel.
“Well-formedness rule” is a term used in the normative UML metamodel specification to describe a set of constraints written in UML’s Object Constraint Language (OCL) that contributes to the definition of a metamodel element. - Specifies “standard elements” beyond those specified by the identified subset of the UML metamodel.
“Standard element” is a term used in the UML metamodel specification to describe a standard instance of a UML stereotype, tagged value or constraint. - Specifies semantics, expressed in natural language, beyond those specified by the identified subset of the UML metamodel.
- Specifies common model elements, expressed in terms of the profile.
An UML Profile for VSTA.
Why do you actually want a profile? you can add additional information to the diagrams and shapes and use this extra information for everything you can think of, just for visualization and communication but also for generation and validation.
For example the component diagram is often used for visualizing the structure [components] of the solution and the interfaces between those components. as Scot Ambler writes:
UML component diagrams are great for doing this as they enable you to model the high-level software components, and more importantly the interfaces to those components. Once the interfaces are defined, and agreed to by your team, it makes it much easier to organize the development effort between subteams.
While in UML 1.1 a component referred to files, UML 2.x describes them more as a autonomous, encapsulated unit with interfaces [see UML basics: The component diagram] which gives us a wider view what we can describe with it. But thinking of subteams, development effort, autonomous, encapsulated unit and file structures we can make a useful profile for our solution structure. Some time ago I wrote something about Autonomous Develop Services for SOA Projects with Team Architect and Service Factory, it’s about in what way you want to have your solution structure to be sure development teams [subteams] don’t interfere with each other.
So, with the component diagram you can design your solution “autonomous, encapsulated units with interfaces”. With a profile attached to this diagram, which gives these units extra meaning according to the solution structure and what kind of units they are, we have valuable information how the solution should be structured, even more interesting we can make a ‘Solution Structure Generator’ for the component diagram.
Make your own
The UML Profiles in VSTA are XML files in the “C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies\UmlProfiles” folder. this is the .NET Profiles profile file. Just copy your own “.Profile” file to this folder and it will appear in the combo box [after restarting VS].
When looking at the property window the structure gets really easy clear. I selected the .NET Profiles profile at the diagram [first yellow marker] and the .NET Assembly stereotype [yellow marker] can be used with components [next yellow marker] and this stereotype has some more properties [vertical yellow marker].
So, now we know how to make a profile… or actually add some additional information to a diagram. We can make it useful create a menuitem for the diagram with some functionality that takes this additional information and creates the solution structure for you.
foreach (Microsoft.VisualStudio.Uml.Classes.ProfileInstance pi in componentmodel.ProfileInstances)
{
if (pi.Name == "Project Structure")
{
foreach (var item in elm.AppliedStereotypes)
{
switch (item.Name)
{
case "Single":
Single(componentmodel);
break;
case "Partinoned":
Partinoned(componentmodel);
break;
case "Multiple":
Multiple(componentmodel);
break;
default:
break;
}
As you can see I used the same solution structure types as described in Chapter 3 – Structuring Projects and Solutions in Source Control of the TFS Guidance from the Patterns and Practices group. [ I still like the "Partinoned" solution structure ] .
_16f93727-aa12-4b78-a748-6b2d6d5257fd.gif "Bb668953_pponline(en-us,MSDN_10)")
and some code to create the projects…
foreach (ComponentProxy cp in componentmodel.ComponentProxies)
{
Microsoft.VisualStudio.Uml.Classes.Element elm = cp as Microsoft.VisualStudio.Uml.Classes.Element;
if (cp.AppliedStereotypes[0].PropertyInstances[3] != null)
{
projectype = cp.AppliedStereotypes[0].PropertyInstances[3].Value;
}
string projectTemplate = "";
Solution2 soln = (Solution2)vsApp.Solution;
System.IO.FileInfo fi = new System.IO.FileInfo(soln.FileName);
string solutiondirectory = fi.Directory.FullName ;
switch (projectype)
{
case "ASP.NET Web Application":
projectTemplate = soln.GetProjectTemplate("WebApplicationProject.zip", "csproj");
break;
Final Notes.
The profile and the use of the profile used in the ‘solution structure’ example has some value, although if you want to use it in the real world it would probably more complex with regeneration, versioning and that kind of things. But that we can add, by using a very simple mechanism, additional information to the diagrams is a very powerful extensibility mechanism. Scenarios like, using a Data Modeling UML Profile for logical modeling and upgrade this model to the physical level with the Entity Framework are very interesting and I need stereotypes for the Usecase diagrams to implement the estimation scenario.
More on this in the future…