//Artefact:SoftwareBundle/com/sphenon/products/EMOS (2.0)


Die EM/OS-Engine

Die Enterprise Model Operation Services (EM/OS) der Sphenon GmbH sind ein System zur Erzeugung und zum Betrieb produktionsreifer Unternehmenslösungen direkt aus fachlichen Modellen.

EM/OS ist das Ergebnis einer über 20-jährigen Produkt-Entwicklung und ständigen Reifung in der Praxis. EM/OS kann aus unserer Sicht als die derzeit innovativste Technologie im Bereich modellgetriebener Software-Entwicklung angesehen werden.

Vom Modell zur Software

EM/OS transformiert übersichtliche, fachlich ausgerichtete Modelle in einem mehrstufigen Prozeß in Bauteile und Baupläne, die zur Laufzeit dynamisch zusammengesetzt und an ihre Umgebung angepaßt werden.

Erfahren Sie mehr über die Entstehung von EM/OS auf der Website der Sphenon GmbH.


Mit EM/OS-Technologie wurden folgende Lösungen erstellt:

  • ‣ Warenwirtchafts-System, SCT Media Solution GmbH
  • ‣ Versicherungs-Portal, Robert Bosch Risk and Insurance Management GmbH
  • ‣ Stammdaten-Verwaltung, Hermes Logistik Gruppe
  • ‣ Online Elektronik Katalog, Skymaster SM Electronic GmbH
  • ‣ Online-Rechner, Rekord Versicherung AG
  • ‣ Internet Versicherungsportal, Onsecure AG
  • ‣ Database Publishing, POET Software
  • ‣ Business Board, venfragrid, Website, Sphenon GmbH

Usage/Development - Guide

EM/OS Solution Modelling Guide
EM/OS (Enterprise Model Operation Services) is a comprehensive system for operating quality business software solutions, specified and automatically created from OOEM Models.
EM/OS Components
Roughly speaking, EM/OS consists of two augmenting subsystems, which can be used seperated as well as combined:
  • Application Provisioning System (EM/OS APS)

  • Application Operating System (EM/OS AOS)

Purpose of the APS is the transformation of the models into a form of code, which allows to instantly operate the respective business solution. This includes, among other things, the automatic creation of an amount of optimised program code.
Purpose of the AOS is to run the solution, typically based on material provided by the APS. This includes, among other things, the provision of a variety of infrastructure services, as well as the aggregation of the solution code according to construction plans and adopted to the environment in which the solution runs.
The complete solution, i.e. the AOS in conjunction with the prepared solution code, is called EM/OS Runtime.
OOEM Models
OOEM Models (Object Oriented Enterprise Models) are a complete, fully functional specification of a quality business software solution.
They consist of:
  • Canvases (BSC, CJC, BMC and alike)

  • Components (UML)

  • Classes and State Machines (OOEM), defining a multitude of structural aspects of the solution, like business domain objects, database schema, programming and service interfaces, exchange formats, user interface dialogs and fields, plus behaviour like user interface micro transactions, class state transitions and protocols

  • Business Processes (UBPML)

  • Business Spaces and Landscapes

  • Definitions (Facts and Rules)

  • Properties and Stereotypes (XModel)

  • Integrated Multipurpose Documentation (Doclets)

  • User Interface Styling

  • Test Specifications

  • Technical Models (UML) and Construction Plans (OCP)

  • Target Language Code (Java)

Abstraction Levels and Modelling Jobs
While Customers or Business Analysts usually operate with high level modelling constructs, which are sufficient to describe the desired business properties of the solution (Canvases, Definitions, Classes, Processes, possibly Stereotypes), the job of the EM/OS Solution Architect requires more detailed as well as more technical knowledge.
To fine tune the systems to precisely meet the expectations of the customer, the EM/OS Solution Architect specifies business details and technical aspects (State Machines, Properties, Technical Models, Construction Plans, Target Language Code).
Like many sophisticated modern software solutions, the inner workings of EM/OS are complex. A long list of measurements has been taken to manage that complexity, effectively. Yet, to find the optimal solution for a requirement, which might consist of just some proper setting or a few modifications in the model, one needs a good general idea of the interdependencies in the EM/OS system.
The purpose of this guide is to provide this necessary information, organised around recurring requirements topics.
The Modelling Guide
Visibility and Changability
Whether an item is visible or not is influenced by a variety of factors.
State Dependent Visibility
State Dependent Changability
Display Context Dependent Visibility
Presentation contexts Importance Tightness Attribute Stereotypes
Presentation of a Class contained in another Class
Importance, Tightness, Relationship canEdit, canDelete, canCreate, canSelect Samples: - contained class is always only editable within attributes @Class: Dependent and StrictlyOwned - contained class is sometimes editable within certain attributes, sometimes selectable within others @Class: EditableInplace @Attribute: XMVUI/EnableDefaultSelector == false then, an InplaceEditor is shown, which can be tuned via @Attribute: XMVUI/DisableCreate XMVUI/DisableSelect XMVUI/DisableEdit XMVUI/DisableDelete
Tree Views
Hierarchically organised data often shall be visualised in tree form.