China
Africa
Explore chapters and articles related to this topic
Flow—Applying Industrial Insights to Software Production
Published in Peter Middleton, James Sutton, Lean Software Strategies, 2020
Seldom are requirements and hardware changes coupled together. Adding functionality may expand a system, however, more often than not, the system continues to use the same hardware to do the new tasks. Or, a system may be ported to different hardware because of a change in vendor, or the desire to prepare for future functional expansion, but such porting is often not directly connected to any specific functional change. An example of a direct connection between functionality and hardware would be something like adding voice-recognition, necessitating the addition of a hardware microphone: Such direct coupling is much less common than decoupled change. In fact, good software management intentionally works to separate implementations due to different causes, a technique sometimes called separation of concerns or change isolation. Separation of concerns makes it easier to verify that changes have been made properly, or to identify the cause for failure when they have not.
Fundamentals of Systems Engineering
Published in Julio Sanchez, Maria P. Canton, Software Solutions for Engineers and Scientists, 2018
Julio Sanchez, Maria P. Canton
It is common sense that when dealing with complex issues we must look separately at its various facets. Since software development is an inherently complex activity, separation of concerns becomes a practical necessity. A coarse-grain observation of any construction project immediately reveals three concerns or levels of activity: technical, managerial, and financial. Technical concerns deal with the technological and scientific part of the project. The managerial concerns refer to project administration. The financial concerns relate to the monetary and fiscal activities.
Realising Variability in Dynamic Software Product Lines
Published in Ivan Mistrik, Matthias Galster, Bruce R. Maxim, Software Engineering for Variability Intensive Systems, 2019
Jane D. A. Sandim Eleutério, Breno B. N. de França, Cecilia M. F. Rubira, Rogério de Lemos
Q7. Separation of Concerns. This principle is used to deal with the complexities that exist in the definition and use of software systems (van Zyl 2002). Separation of concerns can be understood as the principle of software design that the source code be separated into layers and components that each have distinct functionality with as little overlap as possible (Hursch and Lopes 1995).
A Review of Energy Aware Cyber-Physical Systems
Published in Cyber-Physical Systems, 2023
Houssam Kanso, Adel Noureddine, Ernesto Exposito
The authors in [49] present an energy-efficient reconfiguration tool built on Raspberry Pi in an intelligent transportation scenario. They identified energy-consuming concerns at design time, analyse configurations and variants, create a file containing all the possible configurations and the consumption of each of them, selecting initial configuration, and reconfigure at run-time according to the context. It is based on aspect-oriented programming by using the separation of concerns and adapting the configuration of each concern. For example, the compression algorithm can change during the run-time based on the size of the message that needs to be sent. In this solution, energy can be optimised on many layers by changing parameters based on the concerns mainly on the sensing layer (monitoring concern) such as sampling frequency. Other parameters also affect the power consumption on the services layer (software concern) such as compression protocols and on the communication layer (networking concern) such as exchange protocols.
Architecture and knowledge modelling for self-organized reconfiguration management of cyber-physical production systems
Published in International Journal of Computer Integrated Manufacturing, 2022
Timo Müller, Simon Kamm, Andreas Löcklin, Dustin White, Marius Mellinger, Nasser Jazdi, Michael Weyrich
Since the emergence of CPPS is an evolutional development, there are some established basic principles that should be incorporated for the realization of these systems and their architecture as well. Therefore, principles like ‘(de-)composition’ (divide and conquer), which encompasses the ‘separation of concerns’, that in turn, together with the principle of ‘information hiding’ (including the utilization of well-defined interfaces), implements the principle of modularity, are fundamental (Gharbi et al. 2017). The principle of modularity is especially, but not exclusively, important in the context of reconfiguration as it increases the reconfigurability of a system. To that end, some techniques for a good design should be considered, which are known as the SOLID principles, i.e. the Single responsibility, Open-closed, Liskov substitution, Interface segregation, and the Dependency inversion principle first introduced by (Martin 2000). Based on the above, a general advice for software architects in most cases is to aim for a loose coupling and a high (functional) cohesion of components.
Versatile IT-system architecture for smart manufacturing solutions: the example for green manufacturing
Published in International Journal of Computer Integrated Manufacturing, 2021
Martin Plank, Sebastian Thiede, Christoph Herrmann
IT systems usually have a high inherent complexity, which can be made controllable by a suitable architecture (Vogel et al. 2011). When designing and developing the architecture, it is important to maintain a balance between sufficient flexibility and the complexity (Vogel et al. 2011; Starke and Hruschka 2011). To address this issue in the case of the system architecture model, various existing principles of software engineering from literature were examined regarding their transferability and applicability. In order to create a versatile IT system, well-known principles of software engineering are considered and applied to the system architecture model. This includes the separation of concerns, the modularity principle, the loose coupling and tight cohesion of system components, the information hiding and the abstraction between concept and implementation.