the benefits of cogility

© 2010 Cogility Software Corporation All Rights Reserved. Proprietary and Confidential. 1 1

Cogility Studio: Product Differentiation Cogility Studio Conceptual Background

COGILITY SOFTWARE The Leader In Model Driven Complex Event Processing

© 2010 Cogility Software Corporation All Rights Reserved. Proprietary and Confidential. 2

When the Model is Not the System

  Most modeling software is like the Legotm H2 Hummer

  The Model creates a facsimile of the real thing

  The Model is not executable like the real thing

  Nobody mistakes the model for the real thing

  The Model has value because it helps you understand the high-level components of the real system by using high level abstractions

  In other words, if you actually want a Hummer that you can drive, you still have a lot of work to do


  An actual system is like the General Motors H2 Hummer

  It requires much more effort to build

  There are many other actual sub-systems that need to be designed and implemented, beyond the high level abstractions provided by the model

  It takes an enormous amount of effort to actually realize the modeling abstractions

  It actually needs to operate in a real environment

  Nobody mistakes the GM H2 for the Lego H2

  Most normal people do not attempt to build their own equivalent of the GM H2, even though this is theoretically possible

The Real System is MUCH More Complex


  It were possible to build a model of a system using a much superior modeling environment with rich semantics that allowed you to describe the most complex artifacts of a real Hummer

  Such a model, after it was built, could actually become the system it represents by animating the model semantics

  It could be operated in a manner indistinguishable from the desired real system…(except that it is much easier to maintain and repair)

What if…

This is the fundamental difference between Cogility and other modeling tools: Cogility enables the Hummer model to operate like a real Hummer!


  A model of an IT system built within Cogility Studio is not a facsimile of the system being modeled, with static representations of desired behavior

  The model specified semantics will actually execute exactly as specified, enabling the model to become the system

  When the Model is the System, as the model is maintained the system follows, automatically

  The executable model can be easily extended to encompass new capabilities as business requirements change

  The model executes in a high-performance, scalable environment

Cogility Studio: The Model is the System

This is the fundamental difference between Cogility and other modeling tools: Cogility enables the system model to run like

the real system, because the Model becomes the System!

© 2010 Cogility Software Corporation All Rights Reserved. Proprietary and Confidential.

Studio

6

Cogility Studio: Architecture Big Picture

Cogility Studio: Architecture Big

EAI EII BPM

Data Transforms

EDA: Event Driven Architecture SOA: Service Oriented Architecture

J2EE: Application Abstraction Layer JDBC: Storage abstraction Layer

Schema Processes Event

Handlers

Web Service

Deployment

Web Service

Orchestration Schema Data

Transforms

IBM WebSphere

BEA Weblogic

JBoss Oracle 9i

IBM DB2

SQL Server

Windows Linux Solaris AIX MacOS OS400


Conventional MDA Approach: Model Translation

UML System Model

3GL Form Model

Virtual Model Execution Environment

  Conventional approach to an MDA based executable model is via translation. The UML model is translated by some means to a 3GL language, which is then executed after compilation and deployment in a Virtual Model Execution Environment.

  Problems: Deployment, testability, debugging, interaction, divergence, using pre-existing 3GL libraries, disjoint data and behavior.

Data


  Model Driven systems are a paradigm shift in the way in which systems are generated.

  MDA with translation is an evolutionary change, since what is ultimately executing is the compiled 3GL code, just as in the hand-coded systems.

  The translation is inherently lossy, because the execution environment does not have the capacity to understand the model semantically

  Furthermore, there is a varying degree of completeness in the translation

  A paradigm shift cannot be effected by evolutionary changes.

  Too easy to fall back into the previous paradigm

Translation: An Evolutionary Approach


  Cogility’s approach is more akin to “programming with objects” than “object oriented programming”, while offering full benefits of the latter.

  Each model artifact has predefined executable behavior that implements a useful capability

  Generic model artifacts can be combined to create systems that could not have been conceived when the class of model artifacts was created

  Software “Legos”

  Cogility’s MDX approach keeps the model and the implementation tightly synchronized by maintaining the model as an invariant from high-level abstraction to the lowest level of implementation detail.

  Simply put, it is WYSIWYG when it comes to model and implementation

Cogility Studio: Model Driven Execution (MDX)


Cogility Studio: Model Driven Execution

Information

Process Services

XForms

Transaction

Messaging

Behavior

Executable Model

Direct Model Execution Environment

  Cogility does not depend upon model translation into 3GL code for execution.

  Instead, Cogility’s extensible Model Action Semantics are directly executable within a Model Execution Environment with integrated execution data, which alleviates the problems associated with translation techniques. Auto-deployment, direct debugging, direct interaction, no divergence, direct usage of pre-existing 3GL libraries, integrated data and behavior. Integrated Execution Data and Behavior

Configuration Managed Model

Cogility Manager


Cogility Studio: Execution Architecture

Logic + Data Repository

Cogility Modeler

App Server

Exec Action

Semantics

Repository Authoring Interface

WS/JMS Interface

Cogility Manager


Cogility Studio: Automated J2EE Model Interface

Executable Model


SOA Services

DB Activation

Generated Browser

View

EDA Messaging

Timing Daemon

Cogility Manager


Cogility Studio: Directly Executable Model-Driven Action Semantics

Executable Model


Action Semantics

Tests

Service Invocation

Database Access

Message Publish

Action Semantics

Reports

Action Semantics

Scripts

Action Semantics Extracts

Cogility Manager


Cogility Studio: Highly Accessible Execution Data

Model Metadata

Execution Data

SQL Reports

Database Tuning

Database Backups Restores

Direct Database Cleanup

Federated Data

Solutions


Cogility Manager: Model Aware Execution Environment

  Cogility’s execution environment has complete semantic awareness of the model, with the full richness of the modeling environment

  The system is self aware and has a semantic understanding of the system information model, as well as the interfaces to it and to any other system it communicates with

  The system is aware of the Model Action Semantics it can execute and how these relate to specifics in the system model

  Every row of data in the execution database is self-aware and knows how it relates to others and the business processes and behaviors it provides within the system

  System data structures are aware of behaviors they provide


System Command Console: Cogility ActionPad


Limits of Human Comprehension

  Research in cognitive science indicates that on average we can integrate 7 ± 2 unrelated concepts at a time without error

  Beyond that, we use a technique called “chunking” to group similar, well understood concepts together to reduce complexity

  These chunks can then be used as building blocks for higher level concepts

  Thus, even highly detailed, extremely complex concepts can be successively aggregated into a finite number of high level building blocks that can be intuitively understood


Chunking and Evolution of Computer Languages

  The concept of aggregating low-level detail into a reusable chunk is common in the evolution of computer languages

  Converting Binary to Hex is a form of chunking

  Every generation of computer language provides a higher level understanding of the domain, which allows a single command to define a complex sequence of lower-level commands

  1GL (Machine Language): every instruction is at the machine level

  2GL (Assembler): created for specific processors, has a set of structured commands that reflect many machine language instructions   RISC processor does more chunking

  3GL (C, Java etc): general purpose higher level language that is not processor specific and allows for more general commands than 2GL

  Each higher level language aggregates details of the lower level into reusable chunks


Applying Chunking to a Typical IT System

Parse Input

Transform?

Do Work

Read/Save Stuff

Talk to Other

Command

Response


Cogility Studio: Reducing IT Complexity by Chunking

  Cogility defines an IT System using a combination of powerful, executable, system scaffolding modeling artifacts, which can be instantiated as necessary to represent the functional chunks

  Model Driven Smart Persistent Objects, exhibiting   Automatic transacted database CRUD behavior with association traversal   Inheritance   Behavior Definition   Process Definition (state full, long-lived)

  Model Driven Smart Data Structures, exhibiting   Inheritance   Behavior Definition

  Model Driven Communication Artifacts, exhibiting   Synchronous input/output using SOA   Asynchronous input/output using EDA

  Model Driven Data Activation Artifacts, exhibiting   Remote database input/output   Ability to respond to remote data triggers

  Model Driven Transformation Artifacts, exhibiting   Common Warehouse Metamodel based transforms   XSLT based transforms


Cogility Studio: Executable Action Semantics

  Further, Cogility provides a number of powerful, executable, system logic modeling artifacts in the form of Model Action Semantics keywords

  Each Action Semantic keyword has inherent executable capability and does not need to be decomposed further and translated to 3GL code to execute   It would take many lines of 3GL code to implement equivalent capability

effectively and consistently for every usage

  Action Semantics can be safely and easily expanded if required.

  Action Semantics artifacts can be combined in arbitrary ways and embedded inside the scaffolding modeling artifacts, allowing them to behave in a manner that is completely new and directly representative of system requirements

  Programmable Software Legos

  Modeling constructs are like a RISC system, making them easier to grasp and retain based upon rules of human cognition, resulting in a flatter learning curve

  Repetitive use of well understood, well tested, automated patterns can build highly complex solutions while drastically reducing hand-coded low-level artifacts


Cogility Studio: Action Semantics Chunks

  The Action Semantics itself can be chunked as follows

  Basic (Declaration, Assignment, Arithmetic, Logical Operators)

  Database

  Control Structure

  Behavior Invocation

  Communication

  Exceptions


Conclusion: Model Driven Execution With Cogility Studio

  Cogility Studio provides essential executable modeling artifacts which can be used to model and execute the required system.   System is much easier to develop

  Each type of modeling artifact provides useful executable capability in the domain where Cogility is used   It would take an extensive, systematic and expensive coding effort to reproduce

the execution capability provided by the modeling artifacts in a 3GL language

  Modeling artifacts are directly executable, and auto deploy to a scalable, cross platform execution environment in a manner that closely integrates execution data with system behavior   Shields users from technological complexities of the execution environment

while maintaining interaction at the system model level

  Modeling artifacts do not require translation into 3GL form, either manually or through code-generation   System is easier to manage, test, document, certify and maintain

  With Cogility, the Model Is The System, and the two never diverge   The model becomes the single source of system information and organizational

competitive advantage


Additional Reading

  Some of the concepts that have been discussed here have been discussed by others.

  Some practical books that provide useful concepts

  Business Engineering With Object Technology by David A. Taylor. Published by John Wiley & Sons.   Old book, but extremely easy to understand and easy to read. Good for model-

based concepts.

  The Object Primer, by Scott W. Ambler. Cambridge University Press.   Parts of this are aimed at hands-on developers, but others are relevant for just

about anyone, to understand the modeling process.

  See www.agilemodeling.com

  CAVEAT: These books assume that the modeling effort will be followed by coding, which is NOT the case in Cogility since Cogility models are executable.


Cogility Studio: The Model Is The System

  Cogility’s unique abilities   Cogility’s unique capability is Model Driven Execution, which goes beyond just

being MDA compatible.   Cogility Studio uniquely provides a directly executable, auto-generated end-

application, unlike other MDA approaches that generate code stubs that have to be manually hand-coded to conform to the system model and then manually synchronized as the system model changes.

  Cogility’s unique features:   Model Driven Transacted Persistence, allowing model action semantics to

automatically control low-level database operations.   Model Driven Durable Messaging, allowing model action semantics to control

low level messaging operations.   Model Driven Behavior Specification using executable action semantics.   Model Driven Process Execution, allowing high level business process models

to directly execute at the physical level.   Model Driven Data Transformation, allowing for model action semantics to

seamlessly control the access of similar data in dissimilar formats.   Model Driven Service Specification and Orchestration, allowing the model to

directly specify complex services and orchestrate complex remote services with full control over the associated data flow.

  Model Driven Data Activation, allowing the system model to react to changes in data in remote databases.

  Model Driven Test Scenarios, with executable action semantics based tests that can interact directly with the low level physical layer.

  Model Driven Documentation, by exploiting the detailed system metadata inherent in the model.

  Comprehensive Model Configuration Management, from high level abstraction to low level implementation artifact within the execution environment.