Controllers that control a building's state functions can be controlled by a master controller that the controllers choose themselves. The master controller communicates with the controllers and sensors to determine when a building state should change. When the building state should change, the master controller or another controller determines the device or devices that need to modify state values of the building, and send messages to the devices so that they can change building state. If the master controller has a fault, the working controllers can choose another master controller. When a sensor indicates that a building state needs to be changed the master controller determines which device should change state, then tells the controller that is attached to the device.

Aspects of the disclosure relate to managing a set of warning data with respect to a development phase in a computing environment. In embodiments, the computing environment may include a distributed computing environment or a stream computing environment. The set of warning data may be detected with respect to the development phase. In embodiments, the set of warning data may be used to develop an application. By analyzing the set of warning data, a relationship between the set of warning data and a component of the application may be identified. In embodiments, the component of the application may include a computing artifact or a computing object. An indication of the relationship between the set of warning data and the component of the application may be provided for utilization to develop the application.

Aspects of the disclosure relate to managing a set of warning data with respect to a compilation phase in a computing environment. In embodiments, the computing environment may include a distributed computing environment or a stream computing environment. The set of warning data may be detected with respect to the compilation phase. By analyzing the set of warning data, it may be identified that the set of warning data relates to a computing object. In embodiments, the computing object may include a set of implementation code. The set of warning data may be established in association with the computing object.

Various methods, apparatuses/systems, and media for implementing an API design and development module are disclosed. A receiver receives inputs for designing a specification. Codes are generated from the API specification and necessary business logic is added. A processor pushes the specification along with the code to a source control which automatically triggers a continuous integration/continuous deployment (CI/CD) pipeline in response to pushing of the specification along with the code to the source control. The CI/CD pipeline automatically executes, through pre-defined configuration, each phase of an API development life cycle to develop the API based on the designed specification.

The disclosure provides a method for detection of an uninitialized variable. The method includes running a first function, wherein the first function comprises a local variable and a first flag associated with the local variable for indicating an initialization state of the local variable; calling a second function from the first function, with the local variable as a parameter of the second function, wherein the second function comprises a second flag associated with the parameter for indicating an initialization state of the parameter; and updating the first flag based at least on the second flag returned from the second function.

An interface definition language compiler can be designed to generate different versions of stubs or library files from a same IDL source code. A developer can maintain a single IDL file with code for various versions by using version directives. As part of front end compiling, the IDL compiler will determine which sections of IDL code are compatible with a specified version and compile those determined sections of IDL code. When performing semantic analysis, the IDL compiler will determine whether changes across versions create semantic issues that can be resolved in the target program language by the backend of the compiler. For those changes that cannot be resolved in the target program language, the IDL compiler can generate error notifications.

When verifying rapidly the equivalence between source codes with respect to refactoring, the present invention performs two types of verification: verification based on structural comparison using structure graphs obtained by analyzing the source codes, and verification based on symbolic execution. If the structural comparison using the structure graphs can verify that the structures are identical with each other, then symbolic execution is not performed. Further, before the verification based on the structural comparison, the structure graphs of the source codes before and after refactoring are normalized on the basis of normalization information, which is defined for each refactoring pattern, and thereby adjusted so that the resulting structures are identical with each other when the refactoring is valid. Further, the structure graphs before and after the refactoring are subjected to abstraction before being subjected to symbolic execution for verification, thereby limiting locations to which symbolic execution is to be applied.

The present invention concerns a method for verifying traceability of first code instructions in a procedural programming language generated from second code instructions in a modelling language, characterised in that it comprises the implementation, by a piece of equipment (1), of steps of: (a) Syntactic analysis: o of the first instructions so as to generate an AST, and o of the second instructions so as to generate an MDT; (b) Semantic analysis: o Of the AST so as to identify patterns representative of basic functional blocks of the first instructions; o Of the MDT so as to identify characteristic properties of basic functional blocks of the second instructions; (c) Matching, pairwise, the identified basic functional blocks, and confirming the traceability of first code instructions only if: o for each block of the first instructions, there is a functionally equivalent block in the second instructions, and o for each block of the second instructions, there is a functionally equivalent block in the first instructions.

A language extension that advances safety in system programming in that an entire type may be declared to be immutable in the case in which all instances of that type are immutable. The immutable type declaration automatically causes any instances of that type to be treated as immutable, and automatically causes all directly or indirectly reachable members (e.g., fields, methods, properties) of the instance to also be treated as immutable. Furthermore, any construction time reference that allows for field assignment of the instance is not permitted to survive beyond the point at which the instance becomes accessible to its creator. Accordingly, this instance, and any other instance of that same type, will be immutable from the very time of construction. The ability to classify all such instances as immutable is beneficial as the immutable characteristic permits actions that normally would not be allowed due to resource access safety.

Tools and techniques are described to create a controller wiring board. A user, using a user interface associated with a controller, can determine which devices will be attached to a controller. The features of the devices may be already known by the controller. The controller can change wiring terminal types depending on the requirements of the devices wired to the controllers. In some embodiments, a device is wired to a module associated with the controller. The controller can signal to the module to modify its wiring terminal to match the needs of the device to be wired to that location.