Architecture preview and projects
Overview
The architecture preview is the most eye-catching part of a CAST Profiler result and the part with the strictest limits. It is a projection of the technologies found onto a fixed set of architectural layers, derived from imports, annotations and dependency declarations. It is not a call graph, it does not trace a transaction, and it can be wrong in ways a deep analysis will correct.
The preview is produced by basic parsing and technical assumptions. Treat it as a hypothesis to confirm, not a finding to report. The semantic and contextual analysis performed by CAST Imaging is what produces the accurate picture of an application’s inner workings, mapped across all layers with their interdependencies.
How the diagram is built
Each detected technology, package namespace and annotation carries a layer assignment in the reference knowledge base, recorded as its function. CAST Profiler collects those assignments and renders the layers that have at least one occupant, together with the edges implied by the roles involved. The raw scan result carries the diagram as a Graphviz digraph in its graphviz field, which is what the results page renders.
Because the assignment is per technology rather than per code element:
- A layer appears as soon as one file imports something assigned to it. A single logging facade is enough to raise a monitoring layer.
- A layer is absent when the technology that would occupy it was not detected, which can mean it is genuinely absent, or that it is reached through configuration, reflection or an in-house wrapper that no reference entry matches.
- Custom code with no recognised imports contributes nothing to the diagram, however central it is to the application.
The layers
| Layer | What occupies it |
|---|---|
| Web Presentation | Display and interaction components of a web application |
| Mobile Presentation | Mobile client components |
| Business Logic | Custom rules and algorithms handling data exchange and processing |
| Business Logic Communication | Communication initiated from the business logic layer |
| Exposed API | Interfaces the application publishes to its callers |
| Web Communication | Communication over web protocols |
| Data Access | Direct data access code |
| Data Access Services | Components managing access to databases, file systems and other storage |
| Messaging Services | Asynchronous messaging and message-oriented middleware |
| Monitoring Alerting | Health and activity observation, and the alerting built on it |
| Reporting Services | Components producing reports |
The reference data holds a description for each layer, which the results page shows on hover, and more specific variants of these names appear for particular technologies - RDBMS Data Access Services, for example, rather than the generic Data Access Services.
Architecture pattern detection
Alongside the diagram, CAST Profiler attempts to name the architecture. It scores the evidence against a set of known patterns and reports the best match with a one-line summary, for example a Spring Boot application exposing a REST API through Spring MVC. Each candidate pattern carries a direct score, a weighted score and a hybrid score, and the application gets an overall complexity value between 0 and 1.
Use the pattern name as a sanity check on your own understanding of the application. Use the complexity value as an early warning: a high value is what drives the alert recommending you contact CAST before configuring the analysis, covered in Alerts reference.
Indicators
The evaluation also produces a small set of indicators that are quicker to act on than the diagram:
| Indicator | What it tells you |
|---|---|
| Dominant language | The language with the largest share of the code, with its percentage |
| Runtimes | The runtime stacks detected, for example JEE and Web |
| RDBMS check | Whether explicit relational persistence was found, with a ranking and an explanation of the evidence |
| Polyglot | Whether the application spans enough languages to be treated as polyglot |
| .NET discoverability | Whether the .NET delivery contains what is needed to resolve it |
| Support coverage | Per capability - RDBMS, Relational, NoSQL, FileStorage, Hierarchical, Messaging, REST - how many of the detected technologies are covered by a deep scan |
The support coverage indicator is the one to read closely. Each capability gets a ranking of NONE, PARTIAL or FULL and a count of detected, supported and unsupported technologies. A capability ranked NONE because nothing was detected means something different from one ranked PARTIAL because half its technologies are unsupported, and the counts are what tell the two apart.
Detected projects and dependencies
The projects panel lists every project descriptor CAST Profiler found, with its type, its path and the external dependencies it declares. A Maven pom.xml and a Node package.json in the same tree produce two separate projects.
This panel is more reliable than the architecture preview, because a declared dependency is direct evidence rather than an inference. Use it to:
- Establish the real module boundaries of the delivery, which frequently differ from the repository layout.
- Build the list of third-party components whose versions matter for the analysis.
- Spot a project descriptor with no source code beside it, which usually means part of the delivery is missing.
- Spot source code with no project descriptor, which means the build configuration was not delivered and the dependency picture is incomplete.
Dependency names are reported as declared, so a Maven coordinate appears in full as groupId:artifactId while a Node dependency appears as a bare package name. Versions are recorded where the descriptor states them.