EclipseCON North America 2016
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/.
Issue Tracking with Redmine
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 […]
Action Language Fundamentals
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: […]
Action Language
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 […]
PIC Members
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
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 […]
2 Views
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 […]