The North American venue for the Eclipse conference is Reston, Virginia (basically Washington, D.C.) March 7-10. One Fact will present in the Embedded Control track on modeling incrementally so that your application advances forward without being broken. Register to attend at www.eclipsecon.org/na2016/.
The xtUML team uses Redmine for issue tracking. At the open-sourcing of BridgePoint, we evaluated Redmine as the best of the free and open issue trackers. One Fact customers use it to report service requests. The overall community uses it to report BridgePoint bugs and then to assign, participate and track progress. Redmine has nice
-> Continue reading Issue Tracking with Redmine
An action language needs to do only five (5) things. Now it happens that these five things cover everything you might ever want to do. The five fundamental actions are categorized: – accessor: create, delete, relate, unrelate, read, write – transform: +, -, *, /, other data manipulation – generator: state machine synchronization – bridge:
-> Continue reading Action Language Fundamentals
An action language is just a programming language. However, it is characterized as being a bit more abstract than most target programming languages. It separates the concerns of functionality from design decisions regarding containers, memory, tasking and the like. It is model aware; it knows about classes, associations and state machines. It is “chunkier” in
-> Continue reading Action Language
Our involvement in the Papyrus Industrial Consortium continues to grow and progress. This strong team of companies is focusing interest on modeling for complex systems. Keep an eye on developments during the next several months!
xtUML interfaces can be uni-directional or bi-directional. From this graphic you can see small arrows in the port boxes indicating whether the port contains messages that are inbound, outbound or both. The LocationProvider and LocationUtil interfaces are uni-directional and on the Tracking component the messages are all outbound. The UI and HeartRateProvider interfaces contain messages
-> Continue reading xtUML Interfaces
When modeling an application, you may encounter subject matters that deal with the same information but addressing different requirements. When the requirements are varied enough, it may make sense to model parts of the application on separate class diagrams… each with its own view of the data. For example, here is a model of the syntax of a
-> Continue reading 2 Views