Intro Background Projects Offers Publications
ISPRAS Description Logo
Home   R&D Groups   Projects   Grants   Publications   Downloads


inSignt Project:

      Tools support for Managed Architectures
      Klocwork Suite is a Software Intelligence Tool (see The goal tools support for existing code is to accelerate software development when existing software assets are part of the development process. Klocwork inSight uses state-of-the-art, patents-pending, code-analysis algorithms to extract software architecture, interactions, logic flow, and execution threads directly from the source code of both full and partial systems. Klocwork tools allow architectural comprehension, automatic control, and management through its graphic visualization of software architecture, architectural rules setting, and automatic tracking capabilities. Klocwork tools also includes an on-the-fly logical error finder for the early detection and removal of defects. With an intuitive, easy-to-use graphical interface, it quickly and directly provides architects and designers with unique on-demand intelligence never before available, thereby reducing cycle time and increasing quality. Klocwork also provides an innovative and automated software-assessment solution that provides a report on full or partial software systems with 100% accuracy.

      What is a managed software architecture? We will use the following definition, based on the well-known SEI CMM model. In fact, this is a projection of the SEI CMM model to the domain of the software architecute, the so-called Architecture Capability Maturity Model (ACMM).

      ACMM covers a single aspect of SEI-CMM the architecture of the existing software.

Level 1: Initial architecture

Any software has a certain structure - whether it is defined or not; understood or not. It consists of some components (maybe just a single monolith), components have some dependencies and are delivered as configurations.

Level 2: Repeatable architecture

Often organizations use repeatable patterns for constructing and delivering software: some packaging rules, some use of libraries, some code reuse. Usually patterns start at the physical level (the loadbuild  ). Any organization that has large software assets  involving variation  (any embedded software) becomes interested in software architecture issues, since the start to determine success of the product line. There are other drivers for organizations to start being aware of their software architectures and to start optimizing  them.

Level 3: Defined architecture

Components, their interfaces and configurations are formally defined and maintained together with the rest of the code, component environment is used, modeling tools like Rational Rose are used. There are different scenarios as to when a organization moves to this level. Some may start from the green field and define their architecture before they start construction. Others do it later, when the product line concerns become pressing enough.

However, the fact that an organization has defined the software architecture is the initial step to actually managing the software from the architecture perspective.

Level 4: Managed architecture

Software architecture is managed  when the organization understands the up-to-date, precise and quantifiable situation of the components and their dependencies and configurations. This requires several items:

  • visualization of existing software is available
  • feedback between the "as designed" architecture and the "as built" architecture is available
  • metrics of existing architecture are used
The organization uses this understanding to enforce the architecture integrity of their software.

Level 5: Optimizing architecture

Architecture integrity is enforced  and improved ; The on-going architecture improvement is part of the overall development process.

It is interesting that the Model-Driven Architecture (MDA) approach, now standardized by OMG ( may be considered as an application of the principle of Managed Software Architectures to green field projects through up-front modeling using UML, where the model is the primary maintained artifact. Department for CASE tools is involved in MDA standardization though Klocwork, Inc., who is a permanent Domain-Member of OMG. See more information on OMG MDA and Klocwork tools.

There is a big difference between Defined Architectures and Managed Architectures in terms of software tools used. Modeling tools are used at Defined Architecture level. However, the tools that are usually classified as Reverse Engineering or Software Quality Assurance are used for Managing Architectures.

One of the biggest challenges is to extend the modeling tools into the existing software assets situations. I've referred to it as the "legacy barrier" for adoption of modeling tools and techniques, since over 70% of development effort nowadays is associated with extending existing assets, rather than developing new ones completely from scratch. And this rate is growing, as more software is successfully deployed.

A typical architecture authority role  is rather reactive : first some guidelines are formulated then they are given to developers to implements, then the results are evaluated. Usually, the construction cycle is the longest, so bad things have already happened and it is somewhat too late to fix them and it is often late to apply the stick except for potential long-term effects. Therefore we often talk about architecture erosion  - the process of degradation of the component dependencies over time when the architecture authority loosens his or her grip.

Good tools for software architecture management shorten the cycle evaluation cycle.

However, a proactive approach to managing software architecture should integrate integrity enforcement right into the construction process. For example, certain architecture rules should be checked on fly right at the time when designer attempts to submit an updated  module into the configuration management system.

      Klocwork inSight Product Specifications
      Klocwork focuses on extracting intelligence from existing source code of any full or partial systems, making this intelligence and knowledge available for the first time to architects and designers, and enabling better decision making and management on subsequent recovery, maintenance, reuse, development, and project estimation of software projects/products. Klocwork shows the architecture of software systems along those systems' structures and relationships. The aim of Klocwork is to improve the comprehensibility and maintainability of software systems.
      Klocwork provides comprehensive navigation capabilities; its automatic model-building results in powerful round-trip engineering for both structure and behavior. The following are some of the key features of Klocwork inSight:

  • It automatically inspects and protects load-build by performing a number of checks on the source code--and raises flags if any checks fail. It also extracts information on architecture regression, code regression, and metric regression. This ensures better time, usability, risk, and quality improvement.
  • It automatically displays the number of logical errors detected in a specific file or software system using the On-the-fly logical error finder. This ensures better quality, reducing risk of field failure and reducing field cost.
  • It automatically extracts metrics for a selected block or identifier using the Metrics tool. These are used to evaluate quality by calculating the complexity of code and identifying those modules at high risk for defects.
  • It automatically and on-fly generates an easy-to-comprehend, standard flowchart of any given software file, while preserving the file's code and comments, using the Flowchart. This code-inspection solution takes away a developer's coding style and personality while preserving the code. This helps shorten the time required to understand the code.
  • It automatically generates an editable model of any given software using the Architect. The model provides a graphic representation of a system's structural components and their relationships in a form that is familiar to architects and designers. This ensures full architecture comprehension and allows for quick assessment of the soundness of the software architecture.
  • It allows architecture manipulation before altering a single line of code using Impact Analysis. This powerful "see-before-you-do" capability eliminates unforeseen destructors and picks up errors before integrating new code into the system.
  • It allows architectural control and management through the architectural-rules setting and automatic-tracking capabilities. This ensures that no "risky" code is submitted and keeps architectural integrity in check.
  • Its Automated Software Assessment kicks out a comprehensive report on the state of both full and partial software systems, and outlines details such as defects, risks of failure, and metrics. This report is a basis for corrective actions.
  • It creates complex queries that drill deep into dependencies.
  • It harvests existing code and lifts components of base code for reuse and redocumentation of the code base. This addresses time-to-market pressures.
  • It provides integrated context-sensitive information retrieval and provides designers with instant access to all relevant documentation through the Web-Enabled Project Communicator and Coordinator. This ensures that everyone has the same knowledge.
       KLOCwork database-centric solutions set is designed to accelerate the development and to support the maintenance of full or partial software systems.
       For more detailed information about KLOCwork inSight, please contact us at 1-866-KLOCwork (1-866-556-2967).


      Closing the gap between scenarios and state-machine modeling

The value of good requirements
"The hardest single part of building a software system is deciding precisely what to build... Therefore , the most important function that the software builder performs for the client is the iterative extraction   and refinement of the product requirements".

F. Brooks, "No silver bullet: Essence and Accidents of Software Engineering", IEEE Computer, (20), 4 April 1987, pp. 10-19

      Defining and validating requirements early in the software development life cycle is one of the keys to a successful time-to-market strategy in the software industry. Proper requirements management helps development teams build software systems right from the start, avoiding costly redesign and rework late in the development cycle. In order to validate the requirements one can look for the feedback from the customers and other project stakeholders, or use some formal techniques.

      Department for CASE tools together with Klocwork, Inc develops a tool-supported methodology in which requirements are captured in an intuitive and manageable format, which can automatically be transformed into effective visual prototypes as well as formal validation model. The suggested notation is also scaleable enough to allow refinement from requirements to design and to implementation in order to deliver productivity gains at later stages in the software development cycle.

      Early prototyping can help you achieve that much-needed feedback on requirements, especially when the prototype is visual. But developing a prototype that collects customer feedback effectively can take time. A prototype is not the most effective form of managing and changing requirements, but it is necessary to capture requirements in some sort of a formal notation in order to apply formal validation techniques. This type of notation requires advanced skills and significant effort. Moreover, the three goals - ease of management and change, visual prototyping and formal validation - seem to be rather incompatible. Or are they?

Using scenarios to create prototypes

      Scenarios are well recognized as useful ways to define requirements for real-time embedded software. Scenarios describe sequences of events in time and can be used to illustrate certain behavior in a way that is easy to understand and that can be discussed with non-technical stakeholders. Scenarios are also making their way into several other aspects of software development. For example, scenarios are great for visualizing traces, especially for systems with concurrency. Scenarios are used to represent validation traces. There are also similarities between scenarios and test cases. However, not all scenario techniques are equal:

      Illustrative scenarios  tell stories about how users interact with a system, or how components of the system interact with each other. While these scenarios are easy to understand, the do not formally relate requirements to the system design and implementation. There is little guarantee that the system that gets built will really map to the one envisioned in these scenarios.

      Analytical scenarios , on the other hand, use a formal scenario notation, such as Message Sequence Charts (MSC), which are standardized by ITU-T (International Telecommunications Union). The meaning of a scenario-based specification is precise, however its relation to the implementation is still vague. MSCs can describe multiple situations, for example complete or partial intended behavior, or even undesired behavior. Analytical scenarios are great when it comes to reasoning precisely and unambiguously about behavior, but they do not map scenario events to an implementation.

      Executable scenarios , like illustrative scenarios, tell stories that easily elicit feedback. And, like analytic scenarios, they use a formal MSC notation. Executable scenarios have certain characteristics that enhance their value. By definition, they describe sequences of events exactly, and provide a one-to-one mapping  between scenario events and implementation events. Therefore executable scenarios define not only the meaning of the specification itself, but also the behavior of the prototype implementation.

  • Executable scenarios let you model complete behavior, not just a set of illustrations. Basic MSCs allow you to describe simple sequences  of events while HMSCs (Hierarchical MSCs, also an ITU-T standard) allow you to describe compositions of simple scenarios including alternatives and loops. Executable scenarios also include means for describing flows of data  through scenarios, data-dependent behavior  as well as user interface  details.
  • Executable scenarios can be transformed into an executable prototype or a formal validation model.
  • Executable scenarios constitute a single notation that represents requirements, traces, validations and tests.
Using executable scenarios for simulation...

      Executable scenarios can be automatically transformed into codein a given programming language for a particular run-time environment. The Klocwork Synthesizer from Klocwork,Inc. contains a synthesis algorithm that performs this transformation. Our synthesis algorithm produces a collection of communicating event automata  (state machines that support the events for a single scenario instance). A code generator  produces the implementation of the automata in the selected programming language.

      As users interact with the executable prototype, they simulate the original specification. Results of the simulation can be presented in three ways: in a text log as events are executed, highlighted step-by-step in the original scenarios, or as a new scenario. In the later case the simulation trace is presented using the same notation as the requirements.

... for animation

      Additionally, events can be related to the way they appear in the user interface thus co-simulating  behavior and the user interface. Co-simulating scenarios and the user interface achieves animation  of both, which is very important for getting feedback from the stakeholders (see Figure 1).

Figure 1. Co-simulation of the user interface and a scenario

... for validation

      A special code generator can transform an executable scenario into a formal validation model. For example, the Klocwork Synthesizer can transform event automata into a formal model expressed in SDL (the ITU-T Specification and Description Language). The SDL model can then be validated using a tool that supports SDL, such as Telelogic Tau (see Figure 2). The Telelogic Tau "Validator" performs efficient state-space exploration of SDL models and automatically detects faults such as deadlocks, infinite loops, and communication buffer overflows. Faults in automatically synthesized validation models correlate directly with faults in the initial requirements specification. In our experience, the validation approach is capable of automatically detecting very complex faults, including feature interactions involving data. Faults are presented as traces in the same notation as the input constructive scenarios. Once again, you benefit from using just one notation.

... and for testing

      Executable scenarios can be used for testing in two ways. Firstly, requirements captured using executable scenarios can be tested using test cases also expressed as executable scenarios. The same approach described for validating executable scenarios works for testing them. The Telelogic Tau Validator verifies a scenario by proving that a certain SDL model satisfies a certain scenario. In the case of executable scenarios, the SDL model is automatically synthesized from the input requirements model using the synthesis algorithm. The requirements model itself serves as a test case for the implementation.

Figure 2. Using Telelogic Tau for validating executable scenarios

The tools for the job

      Executable scenarios are productized through Klocwork ( Klocwork and Telelogic ( have formed a partnership to make the above-mentioned methodology available to a wider market. The resulting Klocwork MSC to SDL Synthesizer is now offered as an integrated module in Telelogic Tau. The steps described below demonstrate how, using Telelogic and Klocwork tools, you can start to take advantage of the benefits of using executable scenarios for rapid prototyping:

  • Use Telelogic Tau to capture functional requirements as MSC and HMSC scenarios that focus on the interaction between your system and its environment
  • Use the KLOCwork MSC to SDL Synthesizer to synthesize SDL models from scenarios
  • Run the synthesized models in the Telelogic Tau "Simulator" to simulate system behavior and get feedback from stakeholders
  • If you discover problem areas, revise the MSCs or add more scenarios to solve the problems
  • Rerun the KLOCwork MSC to SDL Synthesizer to create a SDL specification
  • Repeat this process until you are satisfied with your prototype

      Executable scenarios use a flexible and abstract notation for defining and managing requirements. A synthesis algorithm can transform executable scenarios into a number of useful artifacts such as an executable prototype and a validation model. Further productivity improvement results from learning just one flexible notation that is used to represent requirements, traces, validation results and tests. The integrated rapid prototyping solution based on executable scenarios is now available through the partnership between Telelogic and KLOCwork.


Copyright © 2002 ISP RAS