VSTS 2010: Overview of Team System 2010 for Architects
In this article we will take an overview of diagrams, features and tools provided in Team System 2010 for Architects. Although we will not cover the concepts of UML and other architectural concepts in details, we will refer to them time to time.
Till VSTS 2008 there was no support for various architectural diagrams which form the UML. Team Edition for Software Architects supported some non-UML but very practical diagrams. Those diagrams provided us ability to do High Level Design of solution architecture and infrastructure architecture. Except in case of WebService the Application Diagram did not support the Low Level Design and on the infrastructure side, except for deployment diagram no other design elements were supported. Team System 2010 for Architects has quite a number of enhanced capabilities compared to Team Edition of Software Architects 2008. Distributed Diagrams model which was present in the Team Edition for Software Architects 2008 is no longer available with Team System 2010 for Architects.
First two phases of traditional Microsoft Solution Framework (MSF) are Envisioning and Planning. Although some of the architectural diagrams are started to be created in envisioning, the completion of those happen during the planning phase. Planning phase is further divided in three processes which run to an extent parallel but are started with a little bit of phase difference. Those processes are:
· Conceptual Design
· Logical Design
· Physical Design
In this article we will look at the details of various diagrams which are required during each of the design process and check if it is supported by Team System 2010 for Architects. Architectural diagrams can be created using Team System 2010 for Architect in which there is a project template for ‘Modeling Project’ which allows us to create various diagrams. We will take an overview of those in the article.
Conceptual Design: This is a process in which from a hazy cloud of needs, crystallization of requirements happens. Requirements are gathered, analyzed and prioritized. Requirements are modeled using ‘Requirement Document’ and ‘Use Case’ diagrams. We also document the processes that are followed by the business. These processes are workflows within the business system. We can use ‘Activity Diagram’ to model those processes and workflows. During the conceptual design the architect will also list all the user roles that will be interacting with the system and the general architecture of the system. General architecture definition will contain the list of logical layers and physical tiers which will be present in the future state of the system. To model it, we can use the ‘Layer diagram’ which is available in the Team System 2010 for Architects.
· Use Case Diagram: A requirement can be modeled with a ‘Use Case’ which may have a graphical representation. Use Case Diagram Toolbox allows us to model Actors, Use Cases, Sub-Systems and comments. It also allows us to create relationships between them. Those relationships can be of the types: Association, Dependency, Inclusion, Extension and Generalization.
Using these elements we can create a Use Case diagram. An example is shown below:
All the elements of the model are can be browsed in the ‘UML Model Explorer’ as shown below:
One of the best features of these diagrams is that we can associate elements with some workitems. Those workitems may exist earlier with which they can be linked or they can also be created on the fly and linked automatically.
As you can view here, we can create new workitems, link existing ones and view all the workitems which are linked to an element.
· Activity Diagram: If anyone has used flow charts, they know almost all details of activity chart. The following image shows all the elements which can be used to create activity diagram. Although both Use Case and Activity diagram can model the requirements, while Use Case provides the scope in the nutshell, activity diagram provides the flow of activities in a serial and specific order. It shows the business processes which are executing.
Most important of them are the Initial and Final Nodes, Action, Merge Node, Fork Node, Join Node and the connectors between all of these. An activity diagram created using these and showing the flow of activities of the earlier use case is as follows:
Similar to linking workitems with the Use Cases we can link existing or newly created workitems with the action shapes in this diagram. For example we can link a ‘Test Case’ workitem with the action shape for ‘Write Test Case’.
· Layer Diagram: In the process of Conceptual Design we baseline the Layer Diagram. Layers are the abstracted grouping of model elements which provide similar functionality and communicate with each other as well as elements of other layers. For example all elements which provide User Interface are grouped into Presentation Layer whereas elements which implement business logic, rules and constraints are grouped in the Business Logic Layer. They either are dependants or dependencies. Dependency relationship sometimes can be bidirectional. Team System for Architects provides packaged solutions to implement patterns related to layers. It provides solutions for Three Layers (Presentation, Business Logic, Data Access), Four Layers (Earlier three and Service) and M-V-C (Model, View, Controller) patterns. Layers can provide links to either projects in the solution or other model elements from UML Model Browser. Since all of those may not be ready, we can decide upon the pattern to use for our solution and baseline the Layer diagram. We can add links to elements as and when they become available. Example of layer diagram with three layer pattern is as shown below:
In this example three layers are shown and in the layer explorer the project linked to selected layer also is shown. It is possible to link workitems to layers but does not seem to be logical to do so.
Logical Design: During this process, we define the structure of various logical entities which will be forming the solution and the behavior of those to interact with each other. Process to create the logical design is as follows:
1. Identify Business Objects: The objects which either provide some kind of service or use some service or hold data which is useful for the business processes are the candidate business objects. Finalized business objects will be modeled as Classes.
2. Identify the services that will be offered by these business objects. These services later on will be modeled as Methods of the classes.
3. Identify attributes of the business objects. Attributes will hold the data and will be modeled as Fields and Properties of the classes.
4. Based upon the business processes which are modeled during the Conceptual Design process, we define the behavior of business objects with other business objects. These behaviors result into the implementation of business processes. Behavior of the business objects to implement a specific business process is modeled using Sequence Diagram.
Let us now take an overview of the Class Diagram and Sequence Diagram as they are created in the Team System for Architects 2010.
· Class Diagram: This is a logical class diagram which provides the structure of elements on which the behavior of the system can be based and a solution can be built. On the logical diagram we can model classes, interfaces, enumerations, packages and relations between all of them. These relations can be of the types – Association, Inheritance, Dependency and Package Import. All of these are available in the toolbox.
Interfaces can be shown either as a box with full details or just a lollypop attached to a class to indicate that the specific class implements that interface. Classes and Interfaces will have the attributes and operations. If we attach an interface to a class and then add members to the interface then those members will automatically appear in the implementation class. An example of class diagram which carries on with the same case that we have taken so far is shown here:
Implementation of these classes in concrete projects by code generation is planned in the future versions but in Beta 1 of the Team System 2010 for Architects has not provided that feature as yet.
· Sequence Diagram: This diagram models the behavior of the classes which are modeled in the class diagram. It graphically shows the method calls on various class instances from the other class instances. It may show synchronous as well as asynchronous method calls and their returns. Usually it is in the time ordered fashion.
This sequence diagram shows the behavior of some of the classes that we have modeled earlier. The vertical line representing each class or interface is a lifeline of instance of that class and the messages depict the interaction by way of method calls in the orderly fashion happening between them.
Physical Design: This is a process where we define the technology which will be used to implement the solution, components and their packaging, database schemas, UI models etc. Although in Beta 1 of Team System 2010 for Architects does not provide explicit tools for architects, it does provide a diagram named Component Diagram.
· Component Diagram: It can show various classes, interfaces, pages, executables etc. packaged into deployable units called components. Components expose interfaces which are either the provider interface or the paired consumer interface. Component can have internal other multiple components which represent any deployable unit like web site, class library, page etc. and the container component can delegate the interface implementation to these internal components. In the following example the ITester interface of the Development component is consuming the ITester interface of the Testing component. Testing component has Tests and Unit Tests as further internal components. Tests component implements the ITester interface so the Testing component delegates tasks of ITester interface to Tests component. Similarly Unit Tests component implements IUnitTest interface so the Tests component further delegates the tasks of IUnitTest to Unit Tests component.
Summary: In this article we have taken an overview of various UML diagrams which are supported in Team System 2010 for Architects (Beta 1). We have seen where they appear in the MSF lifecycle of software development. We have also learned where and how to use them and scope of each of the diagrams. The acceleration to process can be achieved if we can generate code from diagrams but as learned from Microsoft, in Beta 1 the code generation is not supported but will be a major improvement in the latter versions of Team System 2010 for Architects.
If you liked the article, Subscribe to the RSS Feed or Subscribe Via Email
Subodh Sohoni is a VSTS MVP, MCTS - Microsoft Team Foundation Server - Configuration and Development and also is a Microsoft Certified Trainer(MCT) since 2004. Subodh works as VP, Technology with SEED Infotech Ltd