Software Development
In the past, explicit documentation and a keen memory were enough to understand the architecture and logistics of all but the largest structures. Today, our systems are simply too large and complex—add the burden of maintaining regulatory audit trails, and we're faced with a design process that demands a more thorough approach.
The problem is further complicated when the developed system is doled out for implementation. Larger projects are usually assigned to different teams, with individual project managers taking responsibility for a specific device or portion of the application. The usual approach is to parse out the system, with each developer responsible for a logical component. The varying components are then reassembled into a complete, larger system.
This approach works fine for small systems, but can lead to confusion, overlap and missing functionality on larger projects—especially, when the system is comprised of several independently designed devices that must function in a coordinated or symbiotic fashion. Furthermore, many teams rely on the component developers to track their own work and later show how it should be integrated into the overall application, placing a project's success in the hands of individuals.
Virtually every system consists of components that utilize software. This software is expected to satisfy the demands of the specific components, as well as interrelate with other system components. Developers are often able to whip up a prototype application within a day or two, using tricks and procedures developed through their career. And, due to their often-overwhelming backlog, they will move on to the next requirement before polishing the current one. As is often the case, documentation and testing suffer, creating havoc if the developer leaves the project or company. No matter what level of functional quality is obtained, the project manager or build manager has to merge these individual efforts to create the functioning application.
Part of the chaos is tamed by the use of sophisticated environments to track and manage system specifications and requirements, as well as to manage the changes that inevitably occur during design and implementation. Yet the ever-increasing intricacies of system development and design require further evolution: A visual means of planning and displaying the system's architecture, from basic concepts through final testing and implementation. The latest generation of model-based development languages let organizations apply the principles of Model-Driven Development to focus development efforts, while expanding overall vision and creativity. The team can then work as a unit, with planners, designers, developers and testers, without forcing anyone to play catch-up the day before the targeted release date.
A Visual Medium
The Unified Modeling Language was created to solve software design and development problems. The Object Management Group's latest version, UML 2.0, helps specify, visualize and document models of software systems, including their structure and design. Users can analyze their future application's requirements and design a solution that meets them, representing the results using UML 2.0's 13 standard diagram types. Integrated code generation lets the resulting models be translated into the development teams' programming language, be it C, C++ or Java, and be treated the same as code from any other source.
The Systems Modeling Language (SysML) is a similar notation for systems engineers. A system refers to an often-complex interaction of individual application components that function together for a defined set of purposes and goals. Examples can include the inner workings of a cell phone or even the entire wireless telephone network. SysML (www.sysml.org) is used for the specification, analysis, design, verification and validation of systems that may include hardware, software, data, personnel, procedures and facilities. It's a dialect of UML 2.0—or a UML 2.0 profile—designed by systems engineers for systems engineers.
The language's primary goals are to improve communications across the system development lifecycle, enhance knowledge capture, increase reuse of designs, permit early verification of designs and lower maintenance costs. Systems engineers have used models for decades to analyze requirements, perform high-level design, and to assess and verify design alternatives. Up until now, modeling was done using different notations, each with their own supporting tools. This has lead to poor traceability, errors in transcription of information between tools, and difficulties maintaining consistency between the disconnected models. SysML provides, for the first time, a vendor-supported unified visual modeling notation tool for systems engineering.
By providing unified modeling notation and associated tool support, SysML enables true model-based design leading to consistent, unambiguous designs and specifications. Model consistency can be automated and checked during design and maintenance. Tools can further increase quality and reduce risk by enabling simulation and execution of the models to verify that they satisfy the requirements. A typical "SysML Requirement Diagram" (see below), for example, shows requirements derivation for a fuel-economy requirement.
Furthermore, because SysML is based on UML 2.0, the same model can be reused as the specification and initial starting point for those system parts allocated to software, further extending the model-driven nature of the development process. This further reduces errors and maintenance cost, by bridging the gap between systems and software engineering.
The application of UML 2.0 and SysML to the domain of designing complex products is known as Model-Driven Development. MDD is an iterative, top-down development process that ensures that the big picture is clearly defined before the focus shifts to the details.
 [click for larger image] SysML Requirement Diagram By providing unified modeling notation and associated tool support, SysML enables consistent, unambiguous designs and specifications. This SysML requirements diagram, showing requirements derivation for a fuel-economy requirement, is typical. |
MDD is essentially a primary subset of the OMG's Model-Driven Architecture (MDA), which is a more all-encompassing and formalized method of using a modeling approach to define, develop and test products and applications in a platform-neutral fashion. More details on MDA will evolve as the standard continues to develop.
A model-driven approach lets you partition your project and reassemble it in multiple scenarios. Test development occurs in parallel, allowing test teams to fully understand the application and its functions the moment they begin work.
Embedded devices are fully functioning applications that have the added constraint of being resource limited. To achieve low-cost and a small footprint, resources like processor power, memory size and battery must be kept as small as possible. These resources must stay focused on the platform's specific application—it's a serious penalty if additional resources are wasted when fitting the platform into the overall system.
Once again, MDD plays a significant role. Software engineers can be very effective at optimizing the code for their component's specific function, but usually don't or can't optimize the system's integration. It's often the aspects of the final systems integration that cause applications to exceed their allocated resources, forcing costly and difficult decisions to be made in optimizing and modifying the application. Because this usually happens at the end of the development lifecycle, many embedded devices miss their committed delivery dates or are even scrapped altogether.
Systems engineering is an established discipline, within the framework of complex product and application design and development. Rather than attempting to recreate the methodology, SysML was developed as a model-based notation to suit systems engineers in a familiar setting, while increasing their efficiency and effectiveness as part of the overall product design process.
Chris Sibbald (chrissibbald@ telelogic.com) is vice president of standards and technology and Scott McKorkle is the Director of Product Marketing at Telelogic (www.telelogic.com).
