The same dependent functions as above appear within a Subsystem Architecture view. The resulting information about the subsystems involved aids in understanding both the functionality and dependencies of the code involved. (Full Size)Ī simple change of view displays this same portion of your software in a Subsystem Architecture Diagram. In a standard Function Calls graph, the focus is on the control flow of calls among dependent functions. Here's an example of where switching from a Function Calls graph to a Subsystem Architecture view provides context about a particular hierarchy of calls within your code. You're able to switch in and out of an architectural context as you study various aspects of your software, such as control flow, data usage, task interactions, etc. The Subsystem Architecture Diagrams interact fully with the rest of Imagix 4D's extensive range of graphical views. In this manner, you're able to gather insight into both the hierarchy and the interface dependencies among your software's subsystems. You can expand and collapse subsystems, drilling down to the appropriate level of detail. You can focus the diagram on whatever portion of the system architecture that is of interest. The layout of the boxes indicates the dependency hierarchy among the subsystems, with upper subsystems making calls into lower subsystems. In the Subsystem Architecture Diagram, each subsystem is broken down into further subsystems, represented by interior boxes. To the extent that the physical or logical partitions have been used to segregate the source code's functionality, these diagrams also provide valuable understanding of the inherent components of the software architecture. For C++ and Java, this partitioning can be either physical (directory to file to class to member) or logical (namespace/package to class to member). For C code, this is the physical partitioning (directory to file to functions and global variables). The diagram can also serve as a critical tool for initiatives to measure and improve the subsystem partitioning, layering and interfaces.Īs initially generated, the diagrams represent the current partitioning of a software system, showing its subsystems, layers and interfaces. Here, the insight into dependencies provided by the diagram can be significant in reducing both effort and defects as source code is changed. For a software architecture that is well structured, the diagram provides immediate understanding of the essential design of the system, and facilitates on-going tracking to ensure that the good structure is maintained.įor poorly structured software, the challenges of modifying and testing software are greater. The diagram is based on the Subsystem Interface Dependency View, described by Jeff Garland and Richard Anthony in Large-Scale Software Architecture, A Practical Guide Using UML. Imagix 4D's Subsystem Architecture Diagram view provides visualization and analysis of the existing architecture of a software system. And even when the initial system architecture is well structured, the software structure can degrade over the life of the system. Success in this endeavor is key in ensuring that the source code can be efficiently developed, enhanced, tested and maintained. In mid-to-large sized software systems, breaking the overall functionality and implementation down into well segmented subsystems with cleanly specified interfaces is one of the principle challenges of a software architect.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |