Site

RW - Navigation

RW - Recent

Last 10 entries [comments]:

Forums

Last 10 posts [threads/views]:

Wiki

Last 10 pages updated:

There are 484 wiki pages in total.



RSS logoRSS Feed
 

The Residual World::Tag = 'Relationship'

Entries that have been tagged with 'Relationship'.-

Using Relationships and a Repository - Visualisation

by Nic Plum on Sunday 21 November, 2010 - 14:32 GMT

Posted in Architecture ModellingTools

Tags: berlowrelationshiprepositoryvisualisation

This is a recurring theme. Systems-thinking, systems engineering and architecture description are primarily concerned with identifying and managing the important relationships with other things in the world. They are relationship-centric rather than object-centric.

It is often hard for folks used to using flat 2D diagrams produced in PowerPoint or Visio to appreciate the potential power behind relationships. Having said this a lot of tools marketed for architecture description or enterprise architecture are software development tools which are naturally and properly object-oriented rather than relationship-oriented.

Having a repository with a rich set of (consistent) objects and relationships allows you to explore beyond the immediate vicinity to assess impacts and dependencies. Although not intended for this purpose there is a very nice example on TED.com of the use of relationships by ecologist Eric Berlow which is helped by the ability to visualise them in a nice way. This could equally be achieved using a repository.

This is why sticking to the flat-land isn’t adequate to understanding where things sit and therefore how best to manage risk. The world isn’t flat!

Anybody used visualisation software for this sort of thing? What works best? Any good case studies where this has helped to either save the day or revealed something unexpected?

Comments

Comment on this article

Related Articles

    {REL[6083][related1_blog]wtxuUvlqREL}

    Sharing tags:

    External Links

    Trapped in an Unfulfilled Relationship? Perhaps Wise Not to Rush for a Tool Just Yet

    by Nic Plum on Thursday 24 June, 2010 - 16:04 GMT

    Posted in Architecture ModellingTools

    Tags: exploitisserelationshipsoftwaretool

    A Blast from the Past - ISSE as it Used to BeRelationships are one of the cornerstones to using an architecture framework, even more so if you’ve constrained the permutations of allowed relationships and object types though imposing a metamodel. For starters if you select (choose) an element in your model you know that it can only be connected to a limited set of other types of object and using one or a few relationships. So before you even touch the element you have expectations and therefore ideas about how you might then navigate through the model. Equally it helps you to spot errors.

    If someone comes and asks what, if any dependency there is between System A and System P you immediately know what possible paths to look for in terms of the constructs provided by the metamodel.

    So why, then are relationships very much second class citizens in modelling tools? I suspect the answer lies in their pedigree. Most will have developed from tools for the creators of software where the focus is on defining classes and attributes and on the objects themselves. Of course you can explore relationships but there are often very few ways of making these more explicit. For a software project the scope is often much more limited - usually local to the organisation whereas often what we’re up against is trying to map out how bits of an entire sector relate to each other. In this case we’re often asked to define or explore the relationships between a system and the ‘residual world’ as much as any exploration within the system itself. For the software creator the end result is the generation of code (from the same tool) rather than a model of their world where probably the number of relationships far exceed the number of objects.

    The exploration of relationships is concerned primarily with access to the underlying database rather than the views that sit on the top. How easy is it in your tool of choice to expand or follow paths? Is it purely manual with experience driving it or does the tool itself help or offer suggestions? Does it offer many ways to query the database and how easy or hard is it? One of the best exploitations of relationships in a tool I’ve seen was in the probably now defunct ISSE, the then prescribed tool for the MoD’s Integration Authority within the Defence Procurement Agency. What ISSE did nicely was provide a dialog from which you could add a succession of lines, each representing a metamodel stereotype - relationship - stereotype so that you could construct a path. For example, you might simply have Capability Configuration - Resource Interaction - Capability Configuration. What ISSE would then allow is for the architect to tell it how many of these steps (iterations) to follow when starting from the selected model element and the result could be shown in detail or using a summarised notation with a dotted line. This made it much easier to quickly explore the database and find out if and how things depended on each other.

    I’ve not seen anything quite like this since which is a shame. I suspect Im going to have to wait patiently as all sorts of clever features for coders are delivered and keep my fingers crossed that someone has actually figured out that the needs of the 2 communities that use these tools are different.

    Comments

    Comment on this article

    Related Articles

      Sharing tags:

      External Links

      Is this Architecture? Where is the sentence?

      by Nic Plum on Sunday 07 February, 2010 - 15:42 GMT

      Posted in Architecture Modelling

      Tags: meaningnatural languagenounontologyrelationshipsentencesystem authoritytupleusabilityverb

      What is architecture when we are modelling? We might have architecture elements but is this enough? Consider the following thought experiment.

      Is this Architecture?

      On the first line we have 2 things. We don’t know what type they are. We can’t say anything about them and therefore this cannot be architecture.

      On the second line we know that they are both systems and there is some unidentified relationship between them. We know nothing about this relationship in terms of what it is or the direction. This still cannot be architecture.

      On the third line we know we have 2 systems and that System A is configured with System B. At last, this is architecture! But why? The fact is that we know how these 2 things relate to each other and this is at the core of architectural modelling. It is about describing relationships between things and placing things in their proper context. In many cases we are probably more concerned with the relationships between architecture elements than the detail of the elements themselves since we can then navigate along these paths or use them in queries to answer questions or discover things. This is one of the key differences in emphasis between an Enterprise Architect using, say, a UML tool, to a Software Designer. It probably also is at the base of a lot of frustration with tools.

      At a more general level this is architecture because it provides all the parts of a language to allow us to describe what the situation is - we have 2 nouns and a verb so that we have a proper sentence. Without the verb (the relationship) we do not have a sentence and therefore cannot communicate anything meaningful.

      This might sound trivial but it is important. It states that we need 3 things for it to be considered architecture - an object, a verb and the subject of the verb. In other words this looks like a tuple or a triple which is an important construct for an ontology. I suppose I sort of realised this but it was only in trying to define what is mandatory and what is optional for an architecture viewpoint (in ISO 42010 terms) that it became clear that just specifying metamodel elements wasn’t enough - the meaning is in the tuples.

      The other advantage of treating it like a natural language is that it makes it easy to communicate with folks who aren’t UML experts. Take for example the following 2 examples.

      Examples - Architecture Provides a Natural Language


      Reading from left to right we have;

      • Whizzo Dynamics (an organisation) plays the role of system authority which extends to Confabulator (a system)
      • System Authority (a role) requires competence in architecture modelling in order to conduct Design System (a function)

      and as architecture modelling ought to be about communication this is starting to be both useful and effective from a usability perspective.

      Comments

      Comment on this article

      Related Articles

          Sharing tags:

          External Links

          1.2.004 adl admin advice applescript application architecture architecture description architecture description language architecture framework artefact artisan studio award berlow blog boundary browser bug c3 capability capability configuration colaboration collaboration committee compare compliance concept concert conference configuration control conformance consistency content contrast css cv01 def stan defence definition demonstration denmark department for transport develop discovery dndaf document dod dodaf drawing enterprise enterprise architect ertms event evolve exchange exploit forum fun geneology gfdl gnu graph group handbook hazard head-model history humour ibm rhapsody iec ieee ieee1471 iet ietf implement implementation incose innovation institute integrated ea interoperability introduction ipad iso iso42010 isse keynote knowledge language linkedin lockheed martin london london underground m3 mac management mdg meaning meeting metamodel mil std modaf model modelling style naf nato natural language needline news nist no magic magicdraw noun omg omnigraffle ontology open source opensource operational organisation oxfordshire perspective plan platform playlist portability presentation procurement profile project public publication publish purpose rail relationship release repository research resource rfc4677 risk role rssb rule safety sea search security sentence service singapore site softeam modelio software solution song sos sourceforge sparx systems sparx systems enterprise architect specification spreadsheet stakeholder concern standard steering group stencil stereotype store strategy structure support sysml system system authority system of systems systems engineering team template test threat
           

          All articles/posts © of the respective authors

          Site design and architecture © 2010 - 2011 Eclectica Systems Ltd.