Page Areas:



Current Submenu:

Additional Information:

Location

Science Park 3

We are located on the second floor of the Computer Science Building (Science Park 3) ...  more of Location (Titel)


Position Indication:

Content

Engineering in the Cloud

Design Space - Collaborative Engineering in the Cloud

Prof. Dr. Alexander Egyed
Johannes Kepler University, Austria
Institute for Software Systems Engineering (ISSE)
alexander.egyed(/\t)jku.at

Conventional wisdom suggests that better engineering tools lead to better engineered systems. Yet, despite an impressive and growing computer-supported tool landscape, engineering remains complex and hard to control. The problem is that most existing tools cater to the needs of individual engineers and not the needs of collaborating engineering teams. These tools divide rather than unite because
1) engineers download and manipulate tool documents (files) separately and
2) they focus on separate kinds of artifacts, tasks, and engineering disciplines.

Consequently, engineers find it hard to maintain a consistent, overall view of the engineering process. Herein lies the dilemma: tool quality alone cannot guarantee engineering quality. What the existing tool landscape misses is how knowledge flows among engineers and the tools they use. Without this knowledge, engineers cannot effectively visualize the bigger picture, propagate changes among tools, and detect errors. This is known as the tool interoperability problem and it is the most critical software and systems engineering problem today. The DesignSpace bridges the gap between single-user tools and collaborative engineering environments by providing engineers with flexible cross-tool sharing, transformation, linking (traceability), and guidance (e.g. inconsistency detection) to enable multi-user collaboration on an unprecedented scale. In terms of ongoing integration efforts, the DesignSpace is a breakthrough in that it does not affect which tools engineers use or how they use them.

Better Tools lead to better Systems?

The engineering of systems is unimaginable without software tools. Engineers use them to capture and analyze engineering problems; specify, implement, test, and maintain engineering solutions, and manage engineering processes. Yet, there is a gap between the needs of independently working engineers and the needs of a collaborative engineering team [1]. The existing tool landscape emphasizes the former. Most engineering tools are single-user applications – often of excellent quality but limited in that they support the works of individuals and not that of a group. However, existing engineering practices place the burden of collaboration on engineers who lack awareness [2]. This problem has been a significant contributor to many high profile engineering failures [3] and it has shaped two beliefs: 1) the future requires integrated engineering tools and 2) tool integration problems can only be overcome through large standardization efforts (covering interoperability, meta models, ontologies, tool chains, and transformations). Collaborative Engineering in a Multi-Tool Environment (DesignSpace) embraces the first belief but rejects the second one. Standardization is very important for engineering but over-standardization forces compromises and favors established routines – both stifling innovation and creativity [4].

The DesignSpace project argues that engineering strength comes from tool diversity. To achieve a breakthrough in engineering, the next generation of engineering environments does not require better tools but innovative ways on how engineers collaborate using the tools they already have.

The Tool Integration Challenge

The severity of the tool integration problem is no exaggeration. The European Commission’s H2020 vision calls for “leadership in enabling and industrial technologies” through “modeling techniques and comprehensive integrated tool chains […] and the seamless interoperability between[…] tools.” This declaration is a stark manifestation of the larger integration problem that pervades software and systems engineering today. Integration is touted as the “next frontier in systems engineering” in numerous articles and blogs. The EU is not alone in this quest. The 2020 vision of the INCOSE states that “currently, the [engineering] process and methods are generally practiced in an ad hoc manner and not integrated into the overall systems engineering processes[…] The resulting lack of tool interoperability has been a significant inhibitor to widespread deployment”. Even companies are alarmed: IBM declared the need to “specify, design, implement and validate complex products and the software that powers them with an integrated set of tools, practices, and services ” and HP claims that “[tool] support is more effective if the [tools] are integrated– if all its components function as part of a single, consistent, coherent whole”.

Collaborative Engineering– The DesignSpace Way

The DesignSpace is about engaging in multi-user engineering while engineers continue to use the single-user tools they know. However, the DesignSpace does more than just combining existing tools: a larger, single-user tool would still be a single-user tool. The groundbreaking nature of the DesignSpace is that it augments existing tools with collaborative engineering services, which enable knowledge propagation on an unprecedented scale. In short, the DesignSpace provides engineering awareness [2] beyond the boundaries of existing tools.

Multi-user engineering is about
1) how knowledge created and manipulated by engineers in their respective single-user tools is being made available to other engineers,
2) how this knowledge is interconnected to express cross-tool dependencies, and
3) how engineers benefit from analysis and transformation techniques that reason over knowledge spanning across engineering tools.


The DesignSpace provides critical cross-tool services that individual engineering tools could never provide because they lack the bigger picture. It thus fundamentally improves on how systems are being built and maintained – in particular the handling of changes where two-thirds of the engineering cost goes – with up to 100-fold cost savings (the documented cost of detecting and repairing integration errors/changes late [5]) and critical improvements in system quality. The DesignSpace benefits any application domain where diverse tools are used and/or multiple engineering disciplines come together. This includes health care, transportation, consumer electronics, factories, telecom, aviation, power grids, automobiles, machinery, and much more.

Cross-Tool Sharing and Tool Adapters
Engineers use tools to capture and analyze engineering knowledge. This knowledge is typically saved in documents (files) and by sharing these documents, engineers share knowledge. Today, document sharing is surprisingly similar across the diverse tool landscape. Engineers generally edit local working copies of documents, which they retrieve/download/check-out from a shared repository, and then store/submit/publish/commit at the end. This form of collaboration is easy to understand and implement. However, this process is inflexible as it discourages the synchronous editing of documents to avoid conflicts. Documents thus tend to be manipulated in sequential order (even across disciplines) which is contrary to iterative and agile engineering [6].

The DesignSpace breaks up this staged process by letting engineers share documents at any level of granularity (from whole documents to their fine-grained artifacts such as classes, use cases, components, physical objects, or any other “thing”) and at any time (from instant to user triggered). This wide range of support is necessary because there is no best way of sharing artifacts. Rather, there are alternatives and engineers prefer to choose what best fits a given situation. Figure 1 illustrates a collaboration among four engineers on a manufacturing robot system. Alice is the architect and collaborates with Bob on the robot’s SysML model. They both use a commercial design tool but, unfortunately, it does not allow them to edit the model together. The DesignSpace realizes different levels of artifact sharing and is able to control who gets to see what artifact and when. On the lowest level, the DesignSpace is always aware of all artifact changes within any tool in its realm. This is realized through tool adapters that propagate changes between tools and the DesignSpace. The DesignSpace itself is a cloud environment where all engineering artifacts reside. Since engineers may not like to publicize changes instantly, the DesignSpace stores artifacts in private tool workspaces – each belonging to an engineer and reflecting unpublished changes. Boxes 1 and 2 in Figure 1represent the two tool workspaces that synchronize with Bob and Alice’s design tools (who are working in separate offices on separate workstations). For Bob and Alice to synchronously work on the SysML model, they must instantly share changes they make. To do so, the DesignSpace lets engineers define collaboration workspaces that cluster around tool workspaces and define when and how changes are shared. There are two basic options: instant or triggered. For live collaboration, Bob and Alice would choose instant sharing between their tool workspaces and the collaboration workspace (Instant Sharing in Figure 1). Changes that Alice makes in her tool are then sent instantly to her tool workspace by her tool’s adapter. The DesignSpace then instantly shares these changes via the collaboration workspace such that Bob’s tool workspace can see them. Bob’s tool adapter finally sends the changes to his tool. The DesignSpace does not force a standardized collaboration. For example, if Carol wants to receive occasional updates of the SysML model with out participating in Alice and Bob’s synchronous collaboration then she can define a separate collaboration with them (Delayed Sharing in Figure 1).

Cross-Tool Transformation and Linking
Artifact sharing lets engineers decide how quickly engineering knowledge is made available to other engineers if they are using the same tool. It allows two programmers to share code or two CAD designers to share drawings. It does not allow a programmer to share code in form of a drawing with a designer. Consider that Alice models the robot as having exactly two arms with equal length (in SysML in Box 1 in Figure 1). David then computes the length of the robot arms (Box 6) and draws the robot (Box 7). Finally, Carol is notified of the length for the code (Box 4). Propagating such knowledge is essential to the engineering process and engineers are very good at it. Problems arise when knowledge changes, which is the norm and not the exception [7, 8]. Here, engineers need to remember how they shared knowledge days, months, or years earlier. Failure to remember this sharing causes inconsistencies that are exponentially expensive to repair the longer they remain undetected [5]. Or worse, they may cause massive system failure [3].

The DesignSpace adopts existing transformation methods [7] and tool chains (e.g., to transform a model to code; see Figure 1) but also supports the far more common, manual propagation of knowledge by letting engineers record cross-tool dependencies in form of links (traceability [9]). For example, Carol can link the actual implementation of the length of the arm in the code (i.e., a field) with the geometric length parameter of the arm in the CAD drawing (Link 1 in Figure 1) – not just coarse-grained from document to document but from artifact to artifact. In turn, engineers can retrieve these dependencies later for precise navigation, change management, and even error detection (discussed below). The DesignSpace realizes links by letting engineers extend the syntax and semantics of tool and collaboration workspaces. It even allows engineers to add arbitrary meaning to links for further reasoning. For example, David may want to define the link between the arm length in the drawing (Box 7) and its computation to define origin (Link 2); or he may want to link the computation method to the SysML models to capture design decisions (recall that the model defines robots as having two equal arms and the computation method reflects this decision; Link 3). Such links are vital to the engineering process.

Cross-Tool Guidance: Error Detection and Change Suggestions
Tools are not merely visualization and editing platforms. One of their most critical uses is to protect engineers from errors [10]and suggest changes. For example, a CAD tool will prevent or at least highlight illegal geometric shapes; or a programming tool will suggest quick fixes for syntax errors. Yet, none of these tools are able to detect errors or suggest changes across tool boundaries with multiple, concurrently working engineers. Engineers are bound to make mistakes and with hundreds of thousands of artifacts in any complex engineering effort these errors are hard to spot.

The DesignSpace provides cross-tool error detection to fill this gap. It lets engineers define arbitrary syntactic and semantic constraints. Link 1was already a trivial example because it identified a value shared between two tools. If we assume that both tools capture the arm lengths as numeric values then the engineer could define the link as an equality link. This added meaning carries additional semantics that the DesignSpace uses for error detection. For example, if David changes the arm length in the drawing (perhaps due to a requirement change) then the DesignSpace would notify Carol of the inequality with the code. Depending on the nature of the collaboration, the DesignSpace notifies engineers instantly (the moment the error is made) or delayed/triggered (when the engineer wants to know). Errors are just another kind of artifact and there is no ideal, best time for error notification or change suggestion.

The DesignSpace also exploits a synergy with an ongoing research project that generates changes/repairs for arbitrary errors. A change is trivial in context of an equality link but we can compute change/repair suggestions for arbitrary complex consistency and well-formedness rules (featured in [11]). Change suggestions are vitally needed for the DesignSpace since cross-tool errors may span across engineering disciplines where no single engineer may understand the reason for the error without additional help. However, not always are constraints formalizable such that errors and change suggestions can be generated automatically. For example, recall that Alice decided that the robot must have two arms of equal lengths (Box 1). This decision fundamentally affects David’s computation of the arm length (Box 6), the subsequent drawing (Box 7), and the code (Box 4). C.3. already discussed that the DesignSpace lets engineers define links among them. However, the DesignSpace also lets engineers annotate these links with additional change impact semantics that explicitly express change implications that are not necessarily automatable. For example, should Alice ever change her decision about the equal arm length then the computation method must change. Changing the computation method is a complex task and requires domain knowledge. No tool could “invent” the new computation but the DesignSpace would at least notify the engineers involved that a change occurred that is related to the linked artifacts – analogous to a task list.

Summary

The novelty of the DesignSpace is in supporting the needs of an engineering team based on tools that cater to the needs of individual engineers. The DesignSpace thus addresses a critical issue of today’s engineering of systems which impacts companies across Europe and the world.

References

  1. V. Clerc, P. Lago, and H. van Vliet, “The usefulness of architectural knowledge management practices in GSD,” in 4th IEEE International Conference on Global Software Engineering, ICGSE 2009, Limerick, Ireland, 13-16 July, 2009, 2009, pp. 73–82.
  2. P. Dourish and V. Bellotti, “Awareness and Coordination in Shared Workspaces,” Intern. Conf. on Computer Supported Cooperative Work, Toronto, Canada, 1992, pp. 107–114.
  3. R. N. Charette, “Why software fails,” IEEE Spectrum, vol. 42, no. 9, pp. 42–49, Sep. 2005.
  4. J. M. Brown, G. Lindgaard, and R. Biddle, “Interactional identity: designers and developers making joint work meaningful and effective,” in Intern. Conf. on Computer Supported Cooperative Work, 2012, pp. 1381–1390.
  5. B. W. Boehm, Software Engineering Economics. Englewood Cliffs, NJ: Prentice Hall, 1981.
  6. C. Larman and V. R. Basili, “Iterative and incremental development: A brief history,” IEEE Computer, vol. 36, no. 6, pp. 47–56, 2003.
  7. H. Giese and R. Wagner, “From model transformation to incremental bidirectional model synchronization,” Software and System Modeling, vol. 8, no. 1, pp. 21–43, 2009.
  8. L.C.Briand, Y.Labiche, and L.O’Sullivan, “Impact analysis and change management of UML models,” Intern. Conf. on Software Maintenance (ICSM), Amsterdam, The Netherlands, Sep. 2003, pp. 256–265.
  9. N. Aizenbud-Reshef, B. T. Nolan, J. Rubin, and Y. Shaham-Gafni, “Model traceability,” IBM Systems Journal, vol. 45, no. 3, pp. 515–526, July 2006.
  10. S. Easterbrook and B. Nuseibeh, “Using viewpoints for inconsistency management,” Journal of Software Engineering, vol. 11, no. 1, pp. 31–43, 1996.
  11. J. Grundy, “Determining the cause of design model inconsistencies,” IEEE Computer, vol. 47, no. 8, p. 6, 2014.
  12. C. Wohlin, P. Runeson, M. Höst, M. C. Ohlsson, and B. Regnell, Experimentation in Software Engineering. Springer, 2012.