{'fraction_non_alphanumeric': 0.02382388419782871, 'fraction_numerical': 0.0039203860072376355, 'mean_word_length': 5.542406311637081, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 1, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Dimensions for the Separation of Concerns in Describing Software Development Processes

This paper suggests a model that provides orthogonal separation of concerns for software development and management artifacts, describes a pattern for structuring units within each dimension of separation and provides a model for describing interactions between units in different dimensions. This position paper focuses on multi-dimensional separation of concerns throughout the software lifecycle and handling of concerns that span lifecycle phases. This paper can be considered as an instantiation of the model [5], [7] for software development artifacts, such as UML models, and management artifacts, such as project and team. Introduction One of the most influential approaches for a separation of concerns in software architecture is the “4+1 view” model [3]. The “4+1 view” model separates the static structure of software development artifacts into 5 views: logical, process, physical and development and scenario views. The logical view is the object model of the software system. The process view captures the static relationships between processes and tasks. The physical view describes the mapping of the components onto nodes. The development view describes the static relationships between components. The scenario view describes the dynamic aspects of all four views. In later versions of this model [4] the physical view has been renamed as the deployment view, the development view as the component view and the scenario view as the use case view. The “4+1 view” model does not provide orthogonal separation of concerns because the scenario view overlaps the other four views. This paper suggests a model that provides orthogonal separation of concerns for software development artifacts, suggests additional dimensions to cover full description of a software development process and provides a model for capturing interactions between units in different dimensions. Dimensions for the Separation of Concerns This section will introduce an orthogonal concern space in which four Kruchten’s views are some of the dimensions. Unlike the Kruchten’s model, each dimension in our model contains both information about static structure and dynamic interactions. In our model, the use case dimension is similar to other dimensions; it captures both the static structure (that is, relationships between use cases and actors), and the dynamics (scenarios consisting of use case instances). This approach makes the use case dimension consistent with other dimensions and orthogonal to them. To summarize, our dimensions of separations of concerns are: • The logical dimension describes the logical structure of the software system in terms of the responsibilities of the system, actors, subsystems and classes and their interfaces, relationships, interactions and lifecycles. • The component dimension describes the implementation of the system in terms of components, their responsibilities, interfaces, relationships, interactions and lifecycles. • The deployment dimension describes the physical structure of the system in terms of hardware devices, their responsibilities, relationships, interactions and lifecycles. 1 Description of this artifact is not within the scope of this paper. See reference [1] for details.