6Tools for Software Architects
Various categories of tools are available that support software architects’ tasks. This section introduces these categories and provides decision criteria for the selection of specific and/or typical tools.
6.1Integration with the iSAQB curriculum
An extract from the Tools for software architects section of the iSAQB curriculum [isaqb curriculum] is provided below.
6.1.1Learning goals
- LG5-1:Name and explain important tool categories
- LG5-2:Select tools according to requirements
6.2General information
You don’t need to know specific examples of typical tools or products to take the CPSA-F examination. The examination deals primarily with tool categories and decision criteria (in real life, software architects naturally have to learn to use such tools appropriately, but that is not what this book is about). The examples of tools, mentioned in this book, were considered to be up-to-date and correct at the time of preparation of the book.
As a software architect you will often be confronted with typical “across-the-board” requirements with regard to your choice of tool types. Of course, such tools should perform their tasks comprehensively and reliably, but with minimal impacts on other areas.
In our opinion, there are two other general aspects of tool choices that deserve particular attention. These are:
6.2.1Costs
Commercial tools are available at a wide range of prices and with varying costs structures. Payment models include one-time purchase for a flat-rate price, prices that depend on the system size or the operating and/or development environment, License price plus regular maintenance charges, leasing, and so on. Selecting an appropriate licensing model is part of the tool selection process.
In addition to the cost of the software itself, you also have to consider administration and operating costs, as well as the cost of learning and training. Training costs alone can far exceed the purchase price of many software licenses.
6.2.2Licenses and licensing conditions
As a software architect, you need to be aware of the prevailing license conditions, particularly for the use of free ware and open source tools.
Without going into detail on licensing law, the following sections list some of the available options:
- Some software licenses permit unrestricted, free-of-charge use of the tool in question, independent of the nature or target market of the system created with it.
- Other licensing models permit free use for non-commercial purposes only. Use of the licensed tools is restricted the moment you demand money or an alternative form of payment for use of a system created using such a tool.
- Yet other licensing models require the system created with their tools to be distributed under the same license as the tool itself. This can result in you not being able to sell your software, and instead having to distribute it (and its source code) free of charge.
The range of legal options is extensive, and is not always easy to understand or those without appropriate specialist knowledge. If you are in any doubt, always seek legal advice prior to using a tool, a framework, or a library. Most large software organizations have their own license management departments to deal with these kinds of issues.
Warning: In the case of license violations, you can be sued (or warned) by malevolent users of your system, competitors, rivals, or others. This usually results in significant costs and a lot of effort. Always take this risk seriously and clarify the licensing conditions before using external tools, libraries, and frameworks. Open-source tools especially have highly restrictive usage clauses when it comes to commercial use of products created with them.
6.3Requirements management tools
Requirements management is performed throughout the system development lifecycle, both for new developments and changes to existing systems.
In addition to the collection of requirements, the process also includes measures for their management. The aim of requirements management is to achieve a common understanding of the system under development for the contractor and the customer. The resulting documentation often serves as a contractual basis for the subsequent implementation, and therefore needs to have a predefined structure.
6.3.1Requirements and decision criteria
- Support requirements documentation and analysis
- Text-based and graphical presentation of requirements
- Requirements management
- Reduction of redundancies
- Support of retraceability between requirements and architecture
- Team capability
- Version and configuration management
6.3.2Challenges faced by requirements management tools
- Many current graphical representation tools (such as UML models, mind maps, or free-form diagrams) cannot be edited simultaneously by multiple users. This makes merging diagrams extremely time-consuming and prone to error.
- Version and configuration management support
6.3.3Examples
- CaliberRM (Micro Focus)
- Cameo Requirements (No Magic Inc.)
- CARE (SOPHIST GmbH)
- Enterprise Architect (SparxSystems Ltd.)
- in-Step (microTOOL GmbH)
- Polarion® REQUIREMENTS™ (Siemens)
- Rational DOORS (IBM)
- Rational RequisitePro (IBM)
6.4Modeling tools
Modeling tools can depict functional and/or technical models of software and requirements, and problem domains. They assist in creating and maintaining (mainly) graphical abstractions of reality.
Such tools can, for example, provide support starting with (abstract) business processes via stepwise refinement of more and more detailed representations of the respective circumstances.
6.4.1Requirements and decision criteria
- Support for standardized modeling methods—for example, UML, SysML, entity-relationship models, BPMN, state charts, Petri nets, and others
- Support for informal models
- Support for different views/model types (diagram types)
- Support for static and dynamic modeling
- Model checking (validation, plausibility checking)
- Separation of diagrams and the objects contained in them, particularly with a view to reusing objects in other diagrams
- Linking or concatenation of models and diagrams. Automatic forwarding to the relevant (refining) model elements or diagrams when selected (i.e., clicked).
- Support for explicit meta-models
- Capabilities for manual or program-controlled modification of the meta-models
- Ability tor define your own modeling languages (domain-specific languages, including graphical languages)
- Integration with version management systems (such as Subversion, Git, Mercurial)
- Multi-user capability and rights concept
- Document generation (in various formats) from models. Document layout and structure should be configurable and/or programmable.
- Reverse engineering of source code
6.4.2Challenges faced by modeling tools
- Many current graphical representation tools (such as UML models, Mind Maps, or free-form diagrams) cannot be edited simultaneously by multiple users. This makes merging of diagrams extremely time-consuming and prone to error.
- Notations often unsuitable for non-technical stakeholders
- Often poor or non-existent integration into software development environments, resulting in a lack of acceptance by the developers
6.4.3Examples
- ArgoUML (open source)
- ARIS (IDS Scheer)
- Enterprise Architect (SparxSystems Ltd.)
- Innovator (MID GmbH)
- MagicDraw (No Magic)
- PowerDesigner (SAP SE)
- Rational Software Architect (IBM Rational)
- StarUML (open source)
- Visual Paradigm (Visual Paradigm International)
6.5Generation tools
Generation tools can generate any artifacts on the basis of abstract descriptions. For example:
- Class and method bodies in different programming languages based on UML class models
- SQL or DDL statements for specific database systems, and test data or data access modules based on data models
- Lexers and parsers based on formal grammars
- Classes or functions for programming languages that are able to read or write XML Schema based on XML Schema Definitions (XSDs)
- Documentation from source code
- JPG, PNG or vector graphic images from text-based descriptions
6.5.1Requirements and decision criteria
- Independence from the target platform and the format of the generated artifacts
- Independence from the meta-models of the input data/artifacts
- Flexibility of the transformation process
- Certification for security-critical applications.
6.5.2Challenges faced by code generators
Freely definable meta-models and generation rules offer increased flexibility, but at the expense of simplicity.
6.5.3Examples
- ANTLR (open source parser generator)
- AndroMDA (open source)
- openArchitectureWare (open source)
- Many modeling tools can generate artifacts from models or diagrams. Examples here are database structures such as tables and views.
- Implementation-level convention-over-configuration frameworks such as Ruby on Rails, Grails, and Spring Roo also belong in this category, as they generate (code) artifacts on the basis of abstract description.
6.6Static code analysis tools
When analyzed statically, the source text is subjected to a range of formal checks that scan the application for irregularities and errors. This can take place manually or with tool support.
Tools can help with the evaluation of various quality characteristics (such as complexity) in existing software systems. By identifying dependencies, static code analysis tools can also be used to optimize runtime efficiency. They can also determine whether the implementation complies with the requirements of the architecture and, for example, where permissible dependency rules have been adhered to.
6.6.1Requirements and decision criteria
- Automatable, capable of being integrated into the build process
- Reporting, with processing of results in multiple formats (HTML, RSS, and so on), including visualization
- Flexible analysis criteria and metrics
- Support for multiple programming languages
- Definition of inclusion and exclusion criteria (i.e., which sections of the source code should be analyzed and how)
6.6.2Challenges faced by static code analysis tools
- Support for multiple programming languages
- Dependencies and coupling arise in the source code as a result of either direct dependencies (calls, includes) or indirect dependencies (dependency injection, dependencies via data structures, or via the runtime environment). Indirect dependencies are considerably more difficult to analyze.
6.6.3Examples
Static analysis:
- Application Intelligence Platform (CAST Software .Inc)
- Coverity (Synopsys)
- FindBugs (open source)
- Fortify Static Code Analyzer (Micro Focus)
- JDepend (open source)
- SonarQube (SonarSource)
- Sonargraph (hello2morrow GmbH)
- Sotograph (hello2morrow GmbH)
- structure101 (Headway Software)
6.7Dynamic analysis tools
Dynamic analysis tools examine the runtime behavior of software. By analyzing and comparing running programs they can help developers to identify issues and understand processes.
The aims of dynamic analysis include:
- Speed measurement
- Time measurement of specific system components in relation to others
- Measurement of memory usage
- Statistical analysis (How often are individual system components used?)
6.7.1Requirements and decision criteria
- Minimum possible impact on runtime behavior, memory requirements, and CPU use
- Comprehensible presentation of results, appropriate for the target group
- Also suitable for distributed systems
6.7.2Challenges faced by dynamic analysis tools
- The measurement itself influences the system (known analogously in physics as the Heisenberg uncertainty principle). This is particularly evident in concurrent systems or processes.
- The data produced by dynamic analysis soon becomes incomprehensible due to the sheer volume involved.
6.7.3Examples
- AppDynamics (AppDynamics, Inc.)
- IBM Security AppScan (IBM)
- JBoss Profiler (JBoss Community)
- JProfiler (ej-technologies)
- JRat (open source)
- Jtest (Parasoft)
- Perf4J (open source)
6.8Build management tools
Build management tools enable versioning automation, compilation, packaging, testing, and inspection tasks for source code and associated artifacts.
These include:
- Management of translation and transformation tasks (compile, link, deploy)
- Continuous integration management
- Dependency management (see Section 6.9)
- Execution of and reporting on automated tests
- Checking for compliance with structural specifications and programming conventions
6.8.1Requirements and decision criteria
- Build process definable (i.e., the steps necessary for the build can be defined on a system-specific basis)
- Minimal dissolution of transitive dependencies (i.e., the absolute minimum necessary number of files are retranslated or relinked in a build run)
- Integration with version and configuration management tools, code analysis, execution of automated tests and their associated reporting
- Interface with continuous integration tools and processes
- Support for different programming languages and tools
- The speed at which the build processes run
6.8.2Challenges faced by build management tools
- Build management for large systems is resource intensive
- The description/definition of builds needs to be synchronized with the decisions in the deployment view
- There is currently no established standard syntax/language for build descriptions. Most build tools use their own language/syntax.
- Systems are constructed using multiple programming languages (polyglot programming) with a mixture of compiled and interpreted systems
6.8.3Examples
- Apache Ant (build tool, primarily used for Java systems, task description using XML)
- Apache Buildr (build system for many Java VM languages)
- Apache Ivy (support for Java builds that enables subsequent loading of specific versions of required libraries from repositories)
- Apache Maven (build tool for a wide range of build tasks, specifies conventions for directory and file structures, definition using hierarchically organized XML files)
- Gant or Gradle (Ant equivalents in Groovy)
- Make, NMake (the original tools in this category)
- Rake (Make tool for Ruby)
- Team Foundation Server (Microsoft commercial build and code management)
6.9Configuration and version management tools
A configuration management tool primarily supports the software architect in the following tasks:
- Assignment and selection of configuration elements
- Inventorying
- Configuration reconstruction
6.9.1Requirements and decision criteria
- Scalability for large development teams
- Handling of any variants (branches, versions)
- Reliability and robustness
- Integration with other tools (e.g., version management, issue and requirements management, build tools, code management)
6.9.2Challenges faced by configuration and version management tools
- Fundamental terms and concepts of configuration and version management are often dependent on the tool used
- Operations such as branching or merging are often complex in large systems, and are still prone to error, in spite of tool support. It is practically impossible to merge non-text artifacts (diagrams, models, binary files) from different branches.
- Strategies for staging, transitions between development, test and operational environments, rights assignment between these environments and similar organizational responsibilities are complex tasks for which there are no standard solutions.
- Comprehensibility (greater complexity results in more errors in the handling of configurations or versions)
6.9.3Examples
- Tools for versioning of source code and files, such as CVS, Subversion, Git or Mercurial
- Tools for managing different versions of all artifacts in the development process and their dependencies—for example, Apache Ivy, Maven/Nexus
- Rational ClearCase (IBM Rational)
- OMNITRACKER (OMNINET GmbH)
- Perforce (Perforce Software)
- Surround SCM (Seapine)
- Team Foundation Server (Microsoft)
6.10Code management tools
Code management tools support architects and developers in the creation, editing, and comprehension of source code. (Version and configuration management are addressed in Section 6.9.)
This category of tools includes:
- Syntax-based editors
- Refactoring tools for restructuring source code while retaining its functional characteristics
- Debuggers (see also Sections 6.6 and 6.7)
- Integrated development environments
6.10.1Challenges faced by code management tools
- Stability when faced with large code bases (many and large files)
- Support for different programming languages (including mixed languages)
- Integration of build and deployment tools
- Integration of test tools
6.10.2Examples
- Eclipse (open source IDE for Java and other languages, primarily those based on the Java platform, but also C++, Erlang, Prolog and others; flexible extension via plug-ins)
- IntelliJ (available as an open source and commercial IDE, extendible for many languages and via plug-ins)
- NetBeans (open source IDE for Java and other Java-based languages; flexible extension via plug-ins)
- Visual Studio (Microsoft development environment for Windows operating systems)
- xCode (Apple development environment for Mac OS and iOS)
6.11Testing tools
Automated unit and integration tests provide software architects and developers with early feedback on the structure and internal interfaces of their building blocks and how they collaborate with each other. Tests are often the first users of newly created building blocks, and can provide valuable information on their creation, evolution, and improvement. Unit and integration test tools form part of:
- Unit tests (for example, xUnit derivatives)
- Runtime tests (for example, load/performance tests, stress tests, robustness tests)
- Penetration tests, attack scenarios
- Management of test cases, test data, and test results
6.11.1Requirements and decision criteria
- Integration into the development environment
- Simple, executable description of tests
- Reporting of test results
- Collection of test results from multiple test runs for identification of trends
6.11.2Challenges faced by test tools
- Support for heterogeneous or distributed systems
- Synchronous management of test cases and their associated test data (a version and configuration management task)
- Automatic testing of user interfaces
- Mocking (simulation) of external systems required for testing that are not yet available (or cannot be used) as real systems. Support for a mock frameworks category has become established.
6.11.3Examples
An extensive overview is available at http://www.opensourcetesting.org.
- xUnit frameworks (all open source) for unit tests
- Acceptance test tools (FitNess, Cucumber, Spock)
6.12Documentation tools
Documentation tools are intended to support software architects and developers in the long-term communication of decisions, structures, concepts, and other information. This tool category includes text-based and graphical tools for developing, maintaining, and generating documents.
6.12.1Requirements and decision criteria
- Suitability for user groups/project teams
- Comparison of different document versions or statuses
- Integration with version and configuration management
- Compliance of the final documents with company or organization standards (for example, with corporate layout or corporate design)
- Ability to generate stakeholder-specific documentation
- Simple synchronization of documentation with releases or versions of the software
- Integration with bug- or issue-tracking systems
6.12.2Challenges faced by documentation tools
- Version management
- Multiuser capability, in particular conflict handling (simple source code operations such as diff or merge present a major problem for most text processing systems)
- Generation of results for specific target groups in printed and electronic formats. Such considerations include layout and format requirements (such as corporate identity or corporate design), automatic generation of tables of contents and keyword indexes, compliance with documentation standards.
- Avoiding redundancy. It is essential that all information can be maintained in a single location. The transition from source code through models (diagrams) to documentation is still tricky, but so-called “single-source” approaches are attempting to remedy the issue.
6.12.3Examples
- Classic text processing (“office” products) from various vendors
- Markup-based approaches (DocBook, DITA, SGML, MarkDown, Textile, XHTML) that embed formatting and semantic information in text using special characters/strings
- Wikis (there are many open source wikis such as TWiki, Mediawiki, and TiddlyWiki (offline-capable)
- Confluence Team Collaboration (Atlassian)
- Many modeling tools can generate documentation from their database/repository.
6.13Test your knowledge
Here are some detailed excerpts from the Tools for software architects section of the iSAQB curriculum [isaqb curriculum] to help you consolidate what you have learned.
- LG 5-1: Name and explain important tool categories.
- Ability to list and explain the most important categories of tools and their strengths and weaknesses with regard to the work of software architects
- LG 5-2: Select tools according to requirements.
- Software architects’ work environment and tools depend on the respective conditions, constraints, and influencing factors