Rational software architect design reviewer

On the other hand, management and architects will tend to have an opposite view and find that models provide a necessary abstraction on top of the code that allow them to make decisions around the direction of a particular product or component. How do we consolidate these points of view such that we make modeling and design more accessible to both types of practitioners?

In development organizations they tend to be knowledgeable about certain ways to develop applications and they will continue to use that knowledge in future tasks.

An organization may be very code centric and as such doesn't have much or any knowledge about state of the art modeling techniques or how modeling can help them to develop more robust architectures. They may have some design that takes the form of Word documents or informal sketches using a tool like Visio, but they struggle to keep those documents relevant once they transition to development.

Or an organization may be fully immersed in the use of UML Unified Modeling Language and has a clear process around creating their models and generating code from them. In this case, they have issues around managing complexity and making the models accessible to other roles in the organization.

Often in the early stages of design, UML has more detail than is required and is not accessible to the high level architects. Each of these different organizations could benefit from an alternate approach to design that can complement their existing processes without changing them to any considerable extent. This article will describe an alternate approach to Modeling that can complement the existing design process of organizations without any requirement for drastic changes.

Lightweight modeling can help with some of the issues organizations are facing by providing an intermediary description of their design before moving into more complex modeling or directly into code.

In essence a Design is an artifact or set or artifacts that describe in enough detail what needs to be done in order to implement or bring an idea to production. There's no specific way to represent a Design as long as it accomplishes this goal. A Design could be a simple text representation, it could be a visual or diagrammatic representation, a combination thereof or it could be a specific model formal representation such as UML.

How does one get to the point where a Design can be considered ready to implement? This is where some agreement needs to be made as to whether the current form of a Design is adequate to continue to implementation.

Design is by its nature a collaborative and creative process. At some point the Design is reviewed and a decision is made that it is ready to continue towards development. It's possible that the Design may only exist in the Developer's head and that the review was done by the Developer himself, but this simple process will exist in all design scenarios.

The challenge is making sure this Design exists in some concrete form such that other people can review or read it without having to use Vulcan Mild meld. In typical organizations, Design will usually start with some sort of informal meeting between developers, perhaps by using a whiteboard to capture some ideas with simple boxes and lines. Following this, the white board discussion is translated into an artifact that formalizes the discussion as either a document or potentially a model of some form.

Further collaboration will occur on this document or model artifact and there will be incremental changes until it is deemed final. The problem with this approach is that there are a number of gaps between each of these steps that can lead to issues.

The whiteboard drawings will most often simply be left in the conference room where they can be erased in the next meeting. Next the document that transcribes the whiteboard discussion is often passed around in email where copies of the document will be modified by different people. The author then has a difficult task of consolidating these changes. The result is that multiple versions of the document can exist throughout the team leading to inconsistent impressions of the design.

Finally, there may not be any consistent way to represent the Design — different people in the organization are using different tools or design concepts that may not be fully understood by all or readable if the tools aren't installed.

This may be perfectly alright to have the different representations, but having a common repository and way to view them would solve the problem of accessibility. These issues around having persistent designs that are shareable, reviewable, reportable, version-able and accessible to all roles in an Enterprise can be solved with a server based installation of Jazz Design Manager. Design Manager has all the capability out of the box that can assist any organization with basic design construction and management.

We will examine through the use of Sketching, Document creation and then subsequent use of Informal Modeling Domains how these capabilities can help an Enterprise to create robust designs and more quickly move to implementation. The most basic function that Design Manager provides is a common repository for all design artifacts. All of these artifacts can be accessed through the HTTP protocol web browser and can be organized in Project Areas that have user authorization associated with them.

You can either upload existing artifacts into the repository, such as documents or images, or you can create Design Manager specific artifacts, such as sketches, rich text documents or informal modeling documents Use-case, Process, Architecture Design Knowledge. Subsequently, you can use the Rhapsody or Rational Software Architect application clients integrated with Design Manager to edit and create UML models and other client specific artifacts that will reside on the server as well.

Any of the models or artifacts created in these application clients can be commented on live in the web client so that everyone can see them immediately.

They can also be added to a formal Review of multiple artifacts and have all the stakeholders in the design officially sign off on the design. Then a snapshot of the designs can be made in the repository so that the designs can continue to evolve but older versions of the design can always be referenced if desired. For the purposes of this article we will focus on the design creation process, but it's important to be aware of the commenting and review capability since it's a fundamental part of the Design Manager value statement.

Now we can re-examine the different steps in the generic design process diagram to incorporate some of the Design Manager functionality to track and manage the different aspects of the design process. Identifying the design problem could take the form of a requirement or artifact managed by a different tool such as Rational Requirements Composer , DOORs or even a work item in Rational Team Concert.

ADK is a simple way to manage information about architecture and design issues and decisions. In doing so it helps to enable agile architecture and design practices. In collaborative design this information can then be shared with other users so they can benefit from the decision making process the original user went through to resolve the problem.

The ADK domain consists of a set of different resource types that together can fully describe the decision process. An issue resource captures the essence of the issue and describes all the possible alternatives that could solve the issue. This allows you to extrapolate all the alternative solutions to an issue and collaborate with other people on what the pros and cons are of implementing a particular solution.

You can also make an issue depend on other issues and ensure that certain solutions are compatible with other solutions before moving to implementation.

A Decision resource binds an issue to a particular solution Alternative and allows for discussion and review before the decision is finalized. The Decision can be then be linked to subsequent design and implementation artifacts so that you can trace any change or resource back to the original decision that required its existence.

In the course of going through the various alternatives or solutions for a particular issue it may be convenient to have meetings or discussions around the impact of a particular solution. You may have meetings where a white-board is utilized to draw out scenarios or simple designs for the benefit of the group.

Jazz Design Manager can be used to complement these meetings by having offline discussions using the Sketch capability which can simulate a white board style of describing architecture and design. When saved, these Sketches can be viewed by remote team members. If you prefer classic whiteboard discussions with in-person collaboration, you could simply take a picture of the whiteboard after the discussion with your cell-phone and then upload the image to the Design Manager server using the native Image upload capability.

This image can then be used in further discussions by allowing sidebar commenting or by pasting it into a text field. Since the whiteboard image becomes an artifact in the Design Manager repository it can be linked to any other resource that is part of the design process including native resources like Rich Text, ADK Issues, or resources managed by other applications like requirements or test management.

This image can be commented on or reviewed individually as an uploaded image or it can be inserted into a Rich Text Document or Sketch and referenced indirectly. Instead of uploading or pasting the image, you could also transcribe the image into a sketch using the web tooling to create the individual shapes and lines. This is fairly straightforward with the intuitive in-context UI that allows creation immediately where the mouse or touch point is in the UI. Then the image can be evolved and shared within the larger team as well as having a better comment integration such as the ability to sketch on sketch.

The original whiteboard image could still be uploaded if desired and the transcribed sketch can link to the image as a reference. Design Manager Sketches have a number of capabilities that make them well suited for representing high level designs.

First, there aren't any semantics that constrain the user with respect to the relationships between the different shapes.

The user is free to draw any diagram that comes to their mind so that the idea can be represented at a high level. Sketches support a number of predefined shapes such as Rectangle, Oval, Cloud, Cylinder, Stick figure, etc. Each shape can be overridden with a custom image if desired that can be uploaded onto the server and reused in multiple shapes. The user can also control the fill and line colors, line style and all the font attributes to highlight particular shapes or call out some implied semantic differences between them.

Figure VI: Control over line style and appearance. With these capabilities the Sketch represents ideas that can easily be conveyed and shared to facilitate moving a design concept forward in the development process. Once all the high level design decisions have been made, the lower level design process can start in earnest.

Specifications or architecture diagrams with descriptions of components and services may be necessary before having enough detail to begin implementation.

This may be a done with a more classic waterfall approach where a design is reviewed and finalized before moving to implementation or with an agile approach where design and implementation are more closely tied together. Sharing a changeset to a workspace commits the changes to the workspace. No other modifications of the resources are permitted in the context of the changeset. They can of course be modified again, but that must be done in a new changeset, and shared again with the workspace.

There are two modes in which the changes get committed to the workspace. In this mode changes made to the resource get committed to the workspace when the user saves the resource. The other mode is explicitly using change sets which allow the user to combine multiple edits into a change set and then explicitly commit the changes to the workspace. Completing a changeset freezes the changeset. The resource deltas cannot be altered. Explicitly completing a changeset is often done when you want to review the changes with others to get their opinion on them.

A completed changeset can be shared back into a workspace. Changesets can be explicitly created and even named. Making changes directly to a resource in the context of workspace with the web UI, however will create an implicit changeset and automatically share it with the workspace.

So if you want to accumulate multiple changes to multiple resources in the same changeset, possibly for a review, while in the web UI you must explicitly create a changeset and change your default configuration to that changeset.

This URI, not including any query part, is a unique identifier for all versions of a resource. This resource may have different properties depending on the configuration you view it in.

We identify a specific version of a resource with its URI and a query part that references the configuration, which is either a snapshot or workspace. After the work is done in a workspace, it is often desired to merge the changes into a common, team or integration workspace.

All or a subset of the changes to resources are copied into the ancestor workspace. Rational Software Architect provides a visual merge editor to help select which changes are to be copied. The following example demonstrates how two different designers or design teams can asynchronously edit model resources and when finished merge those changes together into a common configuration.

In this scenario manager Deb, and designers Al and Bob collaborate to make changes to a design. The overall scenario is as follows:. In this scenario Bob and Al will be the only ones working out of the Account Management and Logging workspaces respectively. However RSADM workspaces are not limited to an individual and instead there could be sub-teams working together on the changes in the child workspaces.

The configurations menu in the upper right corner of the DM web UI provides options for setting, searching and switching configurations. This puts Deb in the Configuration Management application.

From here Deb selects the create snapshot action in the configuration explorer. The configuration explorer includes all projects managed by the server. Configurations are not bound to a single project. A configuration can be shared by many projects. With a snapshot created it is now possible for Deb to create the workspaces that her team will use to modify the models independently.

The configuration explorer provides actions to create workspaces directly off of a snapshot. With the workspaces created, Deb can now goes back to the Design Management application using the link at the top of the page and switches to one of the new workspaces to start adding comments to resources in it. When a comment is made to a resource, the comment is only visible in that configuration. Deb uses the configuration menu to select the Account Management Workspace as the default configuration.

Deb navigates to the Login Unsuccessful sequence diagram, and adds a comment describing the work she wants done. When a resource is locked it is done so in the context of a changeset, which gets implicitly created, and is displayed in the Design Changes view.

By default the name of the changeset is date and time. The name of an active changeset can be changed at any time. To help explain the individual steps of what is happening in this scenario, Al has turned that option off. With this option off, only the changeset is updated. Others working in the workspace would not see the updates. Al makes many changes to the diagram. These include adding a new operation to a component. RSADM will automatically lock all resources in the configuration that are being changed.

Saving the diagram adds the changes to the changeset.