|
You are reading the Pathfinder Beacon, Pathfinder Solutions’ quarterly newsletter. This is not another online advertisement masquerading as news. The Pathfinder Beacon presents useful information regarding the most noteworthy and cutting edge MDD and MDA trends and topics.
In this issue, our Feature Article introduces SysML, a systems-engineering-focused language that can create effective communication between systems and software engineers, while HS Lahman continues his discussion on Logical Indivisibility.
Also, see our Upcoming Events to find out what’s to come in the next few months. Don’t forget to place your subscription so you can stay on top of all the latest news from Pathfinder Solutions!
Happy reading!
The Editor
SysML, or Systems Modeling Language, is a domain-specific modeling language tailored for systems engineering. It contains a subset of UML 2.0, and adds additional capacities. The basic unit of structure in SysML is a <<block>> representing a system element. System structure is represented by Block Definition Diagrams, used to describe system hierarchy and system/component classifications, and Internal Block Diagrams, which describe parts, ports, and connectors of a system’s internal structure.
Before SysML, even with all the different modeling language standards available, including UML, UML, DoDAF, and AADL, a specific modeling language for systems engineers to express systems architecture was not available. SysML offers the solution through selection of appropriate overlapping semantics from UML with the addition of specialized abstractions. SysML is a smaller and easier to learn language than UML, and is specialized for a systems engineering workspace. It allows systems engineers to address structure, requirements, behavior, and parametrics easily and efficiently. Not only can SysML increase productivity of systems engineers, but the communication gap between systems engineers and software developers can be bridged with an easily translatable language standard.
The ancient Babylonians constructed the Tower of Babel to reach the heavens. Legend has it that the entire population spoke one uniform language, and thus the creation of this complex structure was easy and manageable. At God’s will, however, the language was changed and fragmented, causing confusion and the tower soon collapsed. Today, the age-old problem of communication languages still exists between software and systems engineers. SysML facilitates communication in many aspects of development between systems and software engineers through the use of a common language. Where the semantics of systems engineering overlap with software semantics, SysML shares language abstractions with UML, and these overlaps are substantial. For instance, both SysML Activity Diagrams and UML Activity Diagrams use identical naming standards with only subtle extensions for SysML. Software engineers can use UML profiles to carry the additional information forward, providing a translation path.
Systems engineering and software engineering are each distinct disciplines and, in areas where SysML semantics differ substantially from UML, complications can arise when trying to simplistically map all SysML elements into UML elements for software development. While SysML is an extension of UML, some SysML artifacts face difficulty in direct translation. In particular, the transition from the SysML Block Definition/Internal Block diagrams to UML Class/Internal Structure/Component diagrams illuminates a common fundamental perspective shift from a functional focus in systems engineering to an object-oriented focus in software engineering. Here the flow from SysML to UML must be thoughtfully and creatively established, and an overly simplistic or automatic approach often leads to poor software design.
Leading practitioners and methodologists are exercising and evolving the creative path from systems engineering to software development. For software engineers using Model Driven Architecture, open and extensible MDA environments like PathMATE offer a direct bridge between key elements of SysML and UML. Pathfinder Solutions is engaged in research efforts its advanced customers refining systems engineering modeling methods and technology to build a tighter path from SysML models to implementation. Join us.
By: H. S. Lahman
In the first installment in this series I provided the basic background on OO logical indivisibility. In this installment I will talk about how it is applied during application partitioning. The ideal partitioning of an application is into a directed acyclic graph (DAG) of subsystems. Each subsystem encapsulates a single subject matter. Subsystems are connected via dependencies that reflect a client/service relationship where the client defines requirements for the service. Subsystems are encapsulated by interfaces so that their implementations are hidden. Almost always the DAG represents changing levels of abstraction from very high level control at the top to highly focused, detailed services at the bottom.
At the level of view represented by UML Package or Component Diagrams, each subsystem is a logically indivisible unit of modularization. This allows us to think of the overall organization of the problem solution – and the basic software structure – without a lot of concern for details. So at this level of abstraction we focus on basic structure, requirements flows, and interfaces. A beneficial side effect is that once one defines modularization in this manner individual developer teams can implement subsystems in a largely autonomous manner. But that only works if each subsystem is logically a “black box” that is encapsulated behind a decoupling interface.
Superficially it is usually fairly easy to ensure logical indivisibility for subsystems. That’s because we identify subsystems based upon subject matters that are already defined in some problem space. Thus the problem space itself has already defined logical indivisibility by providing an identifiable entity (usually conceptual for subsystems) with known boundaries. Unfortunately things are often not quite so simple in practice.
One problem is that the problem space itself may be vague about what the scope of the entity is. If the domain experts disagree, the developers have no alternative but to push back on the requirements until they do reach a consensus. The notion of logical indivisibility allows one to raise the level of abstraction of that conversation to a class of requirements rather than focusing on one specific requirement. Quite often that will help clarify the issue and eliminate the need for the same discussion when a similar requirement comes up in the future.
A tougher problem is that some subject matters in the problem space may be too complex to handle as a single unit in the software. That is, one needs to decompose them for maintainability, project management, or some other reason. This is where the notion of “service” subsystems comes into play in the application DAG. One performs a decomposition based on delegating specific detailed activities to service subsystems. Typically this means that the original subject matter is redefined to be a high level control function that coordinates the lower level services. Thus one uses different levels of abstraction of the responsibilities to break up complex subject matters.
The best way to do this is by looking to the problem space for a definition of the delegated services. For example, in a device driver for electronic automated test equipment one may have a notion of Test Execution that is quite complex. However, the problem space itself will provide delegations like Analog Test Execution and Digital Test Execution. In fact, the problem space may provide even lower level delegations like Edge Connector Testing and In-Circuit Testing for a service like Digital Test Execution that may still be too complex. So long as one can map the service subject matters to problem space components, one still gets the benefit of the problem space defining the scope of logical indivisibility.
In the next installment I will discuss the role of logical indivisibility in objects.
Pathfinder Solutions has been invited to participate in the Ready for Rational Pavilion at the IBM Rational Software Development Conference in Orlando, Florida, from June 10-14. This year, the 10th anniversary of the conference features over 20 hands-on technical workshops, more than 285 sessions, keynote speakers from industry leaders, a high-energy Exhibit Hall, and much more. For more information, visit:
http://www-306.ibm.com/software/rational/events/rsdc2007/.
Look for Pathfinder’s new advertisement partnered with IBM Rational in the March 2007 issue of Software Development Times!
Stay tuned for a report from Pathfinder Fellow Greg Eakman detailing an exciting customer project to integrate PathMATE with the Rational Technical Developer (Rose RealTime) runtime environment. Details to follow in the next issue of the Beacon.
The following is a list of web sources of interest to the MDA community:
-
http://www.sysmlforum.com/
The SysML Forum is a web community offering a number of resources for Systems Modeling Language. Visit here to find information on SysML modeling tools, specifications, and tutorials, as well as informative mailing lists and blogs.
http://www.omgsysml.org/
The Object Management Group’s website for SysML. The Object Management Group is an open membership, non-profit consortium that produces and maintains computer industry specifications for interoperable enterprise applications, including Model Driven Architecture.
|
 |
|
