Software development team collaboration across disciplines using UML/SysML
Communicating through modeling
If you want to build a house then you may go to an architect and describe your set of requirements - four bedrooms, two bathrooms, family room, fireplace, etc. If the architect were to come back to you with a thousand page text document describing your house such as "a wall will run 10 feet from the front doors to a set of stairs that will go up to the second floor" then you quickly would be looking for another architect. You expect to see a set of blueprints that show a picture of what your house will look like which provides you with the required overall view of your house.
In a similar fashion, modeling, through the Unified Modeling Language (UML) and the Systems Modeling Language (SysML) provides a set of diagrams with semantic meaning that enable users to communicate the structure and behavior of a design while also maintaining consistency across these views.
Similar to the architectural plans of a house that include a drawing of the electrical wiring, the modeling diagrams can be used to present different levels of detail of the system to facilitate communication with the different interests of the various disciplines involved in a project. For example, use case diagrams may show high level functionality. Class diagrams may show architecture and state diagrams may show detailed modes of operation of a specific class within the design.
Consistency across design views
There is one big difference between UML and SysML diagrams and architectural diagrams for a house. Even though they may represent different levels of abstraction, the UML and SysML diagrams are not just pictures but are both interconnected and cohesive.
A change in a diagram of the model is also reflected in the other diagrams impacted by that change (Figure 1 below). This enables consistency across the different views of the design. For example, changing the name of a class on one diagram results in the name changing in all other diagrams so all views stay updated with the latest information.
 |
| Figure 1: UML Diagrams depict high level architecture, detailed subsystem structure, and collaboration of system. |
The model can be transformed or "generated" into code for the design that would run on an embedded target. The structure and even behavior of the complete design can be automatically created from the model, if using higher end tools such as IBM Rational Rhapsody.
Effectively the code is nothing more than another view of the same model. The benefit of this is the ability to work in a visual fashion in the model and then automatically delivering consistent production code from the model. Since these transformations are based around a common point -- the model -- information in each view is maintained improving robustness of the design.
A common problem in many projects is maintaining consistency between code and documentation. Most developers seldom enjoy writing documentation. Fortunately, the model can also be transformed into documentation for the design. Since the model is a common source for the code and documentation, it can help to avoid errors resulting from inconsistencies in the documentation and design.
Loading comments... Write a comment