Has UML Reached It's End of Life?
In my last post, Breaking the Cost Barrier: Implementing a Cognitive Enterprise Information Framework I mention that CIO's are outsourcing to stay competitive and I put forth the argument this approach will only addresses the symptom, not the problem of breaking through the Information Technology cost barrier.
The barrier that is holding back true cost savings, thus real competitive advantage is the velocity of information flow - the speed in which it takes to turn raw data into actionable information. The root cause of this barrier is how the industry is modeling information systems today. UML has been around and extensively used for the last twenty years. The development of UML began in late 1994 with Grady Booch and Jim Rumbaugh of Rational Software Corporation providing the foundation. In 1996, the Object Management Group (OMG) provided the catalyst producing the standard that we use today.
UML is starting to show it's age and cracks are starting to appear under the weight and pace of today's progression of information systems. The ability to develop systems that can manage the proliferation of information is becoming problematic. Information systems are becoming more complex with more dependencies. These large scale information systems are no longer representing a collection of discrete components "wired" together but, a "body of knowledge" with metadata of how an enterprise systems may work.
The financial industry has come to recognize the short comings of UML for modeling large enterprise systems and understand the need to provide additional capabilities for modeling "knowledge" based information systems.
In fact, the OMG has created a Finance Domain Task Force (OMG FDTF) to "develop sustainable business and technology standards that will promote the notion that Data and its Semantics are the DNA of financial services." See OMG FIBO link at: https://www.omg.org/spec/EDMC-FIBO/FND/1.0/Final for a list of ontologies that support the financial industry.
OMG is now promoting Ontology Definition Metamodel (ODM) as a formal means of supporting metamodel packages to include RDF, RDF Schema, and Web Ontology Language (OWL) for modeling conceptual representation of knowledge. The Ontology Definition Metamodel (ODM) specification provides a means to represent OWL constructs using UML tools. This is achieved using UML’s extension capability called 'profiles' for OWL and for RDF Schema.
Knowledge models (or better known as Ontologies) are becoming a more powerful way to represent the "real world" interdependence with the ability to validate the model constructs. This validation is done through an inferencing engine known as a "reasoner." The reasoner will evaluate assertions of the model, how these inferences are realized algorithmically is not part of the OWL model construct, but depends on the specific implementations of the reasoner. (A list of Reasoners engines can be found at: https://www.w3.org/2001/sw/wiki/OWL/Implementations)
As an example, you might model a Person and have a subclass of Man and Woman. There is nothing in UML that is stopping you from being able to add a subclass of Airplane under Person. Airplane is a thing, not a person. A good knowledge modeling system should prevent you from introducing conceptual integrity issues into your model.
In our above example, using the OWL Disjoint construct, you can specify the concept Person is "Disjoint" from the concept Airplane. You will not be able to add Airplane as a subclass of Person (or Person as subclass to Airplane) . In other words, membership in one class specifically excludes membership in another. If you try to subclass a disjointed concept, the reasoner will flag this as a model error.
This same integrity checking also happens at the property level, if you have a message called setSocialSecurityNumber that has been defined to the Domain of Person, then assigning the message on a Company will generate a modeling error, since a Company is a type of Corporation, not Person.
UML 2.0 simply doesn’t provide the explicit construct necessary to perform model validation or advance capabilities of inferencing. UML and OWL share a lot of similarities. However, there are enough nuances to give someone who is experienced in UML a false sense of understanding of OWL. As an example, the root class in UML is object whereas, the root class in OWL is Thing. In OWL, you would ask "What facts distinguish it from other things?" A completely different philosophy from modeling objects in UML where a concept of "object" is a structure that encapsulates data. Instances in UML are instantiated from a class. Whereas in OWL, an instance (known as an Individual) is completely separate and stands alone from the OWL class and only belongs to a OWL class as a member. See below table 1 for a complete list of differences.
Table 1 - OWL vs. UML
The biggest obstacle for an experienced UML modeler in adopting OWL as a modeling language is their lack of understanding that OWL is grounded in Set Theory (See Figure 1 for examples of Set Operators).
It's an unfortunate fact that OWL uses the reserved words of "OR" for Union, "AND" for Intersection, "NOT" for Complements to represent set operators. Again, back to our seasoned UML modeler, unaware/not mindful of OWL's basic modeling premise of set theory, the UML modeler will assume that "OR", "AND", "NOT" are binary operations and become extremely frustrated on the unexpected results!
As an example for defining a class called Mother, you would use the declarative statement: "Female and (hasChild some Person)." The reasoner would perform an intersection (that's the "and") on the set "Female" with the set of (Persons that has a Child), resulting with the Mother class having all members who are Female and that have a child.
Figure 1 Set Operators
Symmetric Difference is only mention to show completeness to the set operators. It is a unfortunate fact that OWL does NOT support Symmetric Difference operator for modeling. (There are other means of compensating for this deficiency through the use of SPARQL query language.)
Other areas that are similar but different is that, as in UML, OWL also has properties. The difference is that OWL properties have "Characteristics." Characteristics is a feature of OWL properties that allow for more advanced constructs.
As an example, one popular characteristic is the inverse function. Take the property "hasWife," which has been defined as the inverse property of "hasHusband." So, what does this mean? If you define a relationship between Robert with the property of hasWife connecting Mary, the reasoner (i.e. inference engine) will assign Mary with the property of "hasHusband" connecting Robert automatically - no modeler intervention required! (See the below Figure 2 of all the OWL supported Characteristics, note the dashed line indicates relationships that are inferred by the reasoner.)
Figure 2 - OWL Properties Characteristics
This is a extremely powerful means of modeling, simply because you can model the primary relationships that your interested in and have the reasoner fill in those secondary relationships assuring you have a complete model of your domain which also has been validated!!!
There are numerous other features of OWL that distinguished itself from UML. This includes the support of Property Chaining, Defining Classes from Properties, using Min & Max Cardinality Restrictions, Datatypes and the ability to query the model using SPARQL query language to name a few. (For a complete overview of the Semantic Web technology stack, see my post: Cognitive Computing - Semantically Speaking).
If you're saying to yourself, this is really great, how do I get started in modeling in OWL? The first step is to download an Ontology editor. (There a number of ontology editors that can be found at: https://www.w3.org/wiki/Ontology_editors. University of Stanford supports an open source ontology editor called Protege, it is free and is one of the more popular ontology editors. The second step is to reach out for some formalized training on building ontologies; there are a number of consultant companies and web sites that provide courses. One website is Linked Data Tools at https://www.linkeddatatools.com for free tutorials.
The goal of this blog is to introduce a more advanced concept of modeling of information and bring awareness that continuing to model with the current methodology will have a limited effectiveness. Business agility is becoming a strategic necessity. Greater globalization, increasing amounts of data available to the business, how is a company to make sense of it all? The realization is that companies will not be competitive if they can’t keep on top of their information. Especially, if your competitor knows more about your customers than you do…
The ability to quickly build advance information systems that understands the context of your business will be a strategic enabler for companies to thrive in the 21 century!
Emerging Technology. Architecture. Innovation. Strategist. Blessed.
9 年Mitch, I would love to get this in PDF format if possible? Great information presented and a good argument for why UML has run its course. While there is undoubtedly an initial cost to building a proper model, it should pay dividends over time. Another way of saying it - 10 years from now, we will know who adopted such approaches with their data and who did not because it will be reflected in their position in the market. Information is the new diamond.