Tools support for Managed Architectures
Klocwork Suite is a Software Intelligence Tool (see http://www.klocwork.com). 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
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 (http://www.omg.org/mda) 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.
For more detailed information about KLOCwork inSight, please contact us at 1-866-KLOCwork (1-866-556-2967).
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.
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).