in

The ORM Foundation

Get the facts!

Concept Maps

Last post 05-29-2010 21:05 by Terry Halpin. 11 replies.
Page 1 of 1 (12 items)
Sort Posts: Previous Next
  • 04-25-2010 9:35

    Concept Maps

    Hey

    Well it seems that ORM is quite similar to Concept Map. In ORM you only have to add constraints.

    JB

  • 04-25-2010 12:58 In reply to

    Re: Concept Maps

    Well, if you agree with propositions like "all diagrams are similar" then yes, an object-role model is a diagram and a concept map is a diagram.

    However, when you look at the detail then concept maps are just informal diagrams that connect informal words in an arbitrary way.

    The differences become obvious when you look at the example at: http://cmap.ihmc.us/Publications/ResearchPapers/TheoryCmaps/TheoryUnderlyingConceptMaps.htm

    The boxes contain terms such as "creativity", "linking words",   "propositions" ,   "interrelationships" "context dependent" and so on.
    An ORM modeler is not likely to use such terms as "ORM object labels" because the terms do not represent names for sets of things.

    For example:

    Try to make a list of the identifiable members of the set called "linking words".
    Try to make a list of the identifiable members of the set called "creativity".
    and so on....

    Pretty meaningless. Don't you agree?

    This is even clearer when you compare the ideas behind "concept" and "ORM object"

    In the reference, a concept is defined as a perceived regularity (or pattern) in events or objects, or records of events or objects, designated by label.  

     In ORM, an object name is a label for a set of things.

    So, whilst a "concept map" (as described in the reference) may help some folks to describe the "perceived regularities" in their mind, as I see it, the concept map is just a description of some informal relationships between some equally informal symbols.

    Don't get me wrong, I sometimes use a brain map to clarify things. For example, to better understand the author's message,  I recently made a brain map of the book "Language in Thought and Action"    (ISBN-10: 0156482401).  But at the end of this exercise, all I had was a better understanding of the author's message and the relevance of his examples. And now that I have made the brain map, I can review the book in a minute or two. However, I could not transform the brain map into a relational structure or a class diagram.

    So a brain map(concept diagram) can be very helpful but it is a totally different kind of artefact to an object-role model.

    Ken

    Filed under:
  • 04-26-2010 14:27 In reply to

    Re: Concept Maps

    Hey

     By set of things do you mean like group of things? For example CAR - small car, big car, fast car etc

    I also don't agree with declaration that ORM doesn't use attributes (like UML). You instead are using value objects or value types. It seems similar to attributes.

    JB

  • 04-26-2010 17:05 In reply to

    Re: Concept Maps

    JohnBorowiec:
     By set of things do you mean like group of things? For example CAR - small car, big car, fast car etc

    ORM uses set theory which is a mathematical theory introduced by Georg Cantor in 1874. 
    When you use set theory, you look at an object and ask, "Is this object a member of the set in question?"
    So in your example the basic object is "Car". So once you know what a car is, you can look at other objects and ask "Is this a car?". The answer is either yes or no.
    If you want to define the characteristics of a car then you use what we call "Fact Types"  
    For example:
    Fact 1 "Car has Size". The object "Size" could have the exact measurements or just simple categories such as "small" ," medium" or "big".
    Fact 2 "Car can be driven at Speed" where the object "Speed" is a value object using measurements such as km/hr or mph.
    Fact 3  "Car is of Colour" and so on.

    JohnBorowiec:
    I also don't agree with declaration that ORM doesn't use attributes (like UML). You instead are using value objects or value types. It seems similar to attributes.

    One of the differences between a UML "Car" object with attributes and the ORM facts, is that ORM objects are declared only once whereas in UML each attribute may have to be declared (and maintained) across multiple objects which makes maintenance much more complex.

    For example the ORM object "Colour" exists in its own right and can be used in facts such as "Car has Colour", "House has Colour", "Shirt has Colour" and so on. In UML you would have three objects (Car, House and Shirt) with each object having its own "Colour" attribute. (which might have a different data type or a different value range.)

    ORM does not use attributes.

    Ken   

  • 04-27-2010 18:34 In reply to

    Re: Concept Maps

     The issue about whether ORM uses attributes often comes up, and ORM's position in this regard is sometimes misunderstood by people who are used to other approaches. The following explanation will hopefully shed some light on this issue.

    If you think in terms of the relational model, then ORM object types are like Domains on which attributes are based, where the domains are semantic domains rather than the merely syntactic domains supported by most SQL systems.

    For example, in UML or ER we might have a Class called Employee, with birthdate and hiredate as attributes. These attributes should be based on a Date domain or type. In ORM, we instead represent this example with two fact types: Employee was born on Date; Employee was hired on Date. ORM also requires value-based reference schemes for these object types. Here Employee and Date are object types, and "was born on" and "was hired on" are predicate readings. There are two roles (relationship parts) in this fact type, one played by Employee and one played by Date.

    In ORM, a fact type must have at least one predicate reading, but role names are optional. If you consider binary fact types only, and name a role, then in one sense you can think of that as naming an attribute of the object type that plays the other role. For example, I might name the roles played by Date in the two fact types above as "birthdate" and "hiredate". This can be handy for specifying rules in FORML in "attribute-style", e.g. For each Employee, hiredate >= birthdate.

    In principle, you could name the roles played by Employee as "employeeBornOn" and "employeeHiredOn", and think of them as multi-valued attributes of Date, but this is unnatural. As an aside, one of the annoying aspects of UML is that in that UML requires every role (association end) to have a name. Having to invent a meaningful role name can sometimes be challenging and unnatural.

    For example, consider the following two associations in UML:

    Person is brother of Person; Person is mother of Person.

    Here Person is a class, and all four roles must be named. It's easy to name the left-hand roles (e.g. "brother", "mother"), but the right-hand roles are awkward and unnatural to name (e.g. "siblingOfMale", "childOfFemale"). ORM avoids such impositions on the modeler by not forcing you to name roles (because you can always navigate using predicate readings instead).

    Note that roles in unary fact types (e.g. Employee smokes), roles are not attributes at all, even though you can transform a unary to a binary (e.g. Employee has SmokingStatus) where one could treat a role as an attribute.

    If you name roles in ternary or longer fact types (e.g. Company supplied Product to Customer; Person introduced Person to Person), these may be thought of as "attributes" of the whole relationship (which may be implicitly or explicitly objectified), rather than as attributes of one of the participating object types.


  • 05-26-2010 13:37 In reply to

    Re: Concept Maps

    Hey

    I did some research about UML and I am not sure that concentrating only for data is such a good idea anymore. In order to create functional IS, modeler should also consider other aspects – how is work or process organized (who is doing what with data), functionalities (how the IS should or could be used), information need for every user etc. Yes raw data is more stable, but if I have to procure the new IS then with UML I am able to create also other models (behavioral etc).  Could it really be possible to procure IS just with ORM conceptual schemas with elementary facts?

    V.K

  • 05-26-2010 13:49 In reply to

    Re: Concept Maps

    Is it possible to validate the conceptual model without the behavioral, process or functional views? According to enterprise architecture (Zacman, Togaf) it is neccessary to have complex views.

    V.K

  • 05-26-2010 14:15 In reply to

    Re: Concept Maps

    vkannel:
    concentrating only for data
    . Not sure what you mean by this but the underlying question seems to be: What's best to analyze first? Process or Data?.
    What do you think?
    ------------------------------

    vkannel:
    who is doing what with data
    Well it seems to me that this is related to roles and permissions in the database.
    The related question is : What's best to analyze first? Data or roles and permissions?
    ---------------------------------


    vkannel:
    with UML I am able to create also other models (behavioral etc)
    So the question is: What's best to analyze first: "Behaviour" or Data? 
    Also - what do you mean by "behaviour"?. How is it different from "Process"?
    --------------------------------

    vkannel:
    Could it really be possible to procure IS just with ORM conceptual schemas with elementary facts?
       
    I don't recall anyone I know claiming that this is true.
    From where did you get this idea?

    Ken   

  • 05-26-2010 14:24 In reply to

    Re: Concept Maps

    vkannel:
    According to enterprise architecture (Zacman, Togaf) it is neccessary to have complex views.

    Yes Zachman and TOGAF do say this. 
    But the central questions are
    1: Complex views of what?
    2: What is the purpose of these "complex views"?
    3: Who uses these complex views and for what?

    Ken 

    Filed under:
  • 05-27-2010 0:52 In reply to

    Re: Concept Maps

    Hey 

    Well I just readed the Big Brown Book and thought that if someone needs to develop or procure the IS then is it enough to have ORM conceptual model. So if I would model the user needs with ORM then is it enough or I still need to have something else..like process model. And you are correct offcourse, there is no difference between "behaviour" and "process" if we look IS.

    Terry wrote in his book, that data perspective is more stable and this is the reason why we should concentrate on it. Offcourse concentration doesn't mean that we should forget other things, but as I also understood then ORM is meant for static modeling. So in order to model processes I would have to use other tools and why not to use them from the beginning?

     V.K

  • 05-27-2010 1:53 In reply to

    Re: Concept Maps

    Dear V.K.

    While ORM is ideal for static data modeling, it doesn't yet handle other modeling perspectives (business processes, workflows, state transitions etc.). We are currently researching extensions to ORM to handle dynamic rules, which would at least cover state transitions, but that is not yet available in the NORMA tool.

    Chapter 15 of the BBB is devoted to process and state modeling. If you need to do modeling of that kind right now, then consider using tools specifically designed for that purpose (e.g workflow tools like YAWL, or BPMN tools, or even UML tools), in addition to using ORM for data modeling.

    For large applications, I find it's usually best to early on do a services model to indicate the services that need to be delivered (not the detailed processes that determine how these services are delivered), and then to get a clear understanding of the data required to support those services (for which data modeling in ORM is ideal). Once you have your data model determined, you can then do a detailed process model and relate processes to the data they input/output. In other words, focus on WHAT before HOW. Of course, not everybody prefers to work that way.

    Different kinds of applications may need different approaches or different combinations of approaches. Nobody I know of claims that ORM can model all aspects of all applications.

    Hope this clarifies things

    Terry

     

     

  • 05-29-2010 21:05 In reply to

    Re: Concept Maps

    As a follow-up to my previous response, please note that some others in the ORM community are researching ways to enable state and process modeling to be fully captured in ORM. For example, it is my understanding that Victor Morgante is aiming to achieve this with his Richmond tool. 

    Cheers

    Terry

     

Page 1 of 1 (12 items)
© 2008-2014 The ORM Foundation: A UK not-for-profit organisation -------------- Terms of Service