0

I am new to UML and I have a best practices question. I would like to model separately:

  • logical architecture: logically interconnected software components;
  • physical architecture: physical installations of operating systems with possibility of physical interconnections like Ethernet;
  • mapping of one to another, modelled as the last step which does not modify models of the above two architectures.

For example, an engineer can decide, that software components App1 and App2 should both be installed on operating system Linux1, and communicate using sockets. Within this process of mapping, it is not allowed to modify the logical and physical architecture models, only a respective third model should be produced. The two former models need to be read-only, as any number of independent mappings is possible.

This all should be modelled in UML 2. I can imagine the logical architecture as a communication diagram, the physical architecture as a deployment diagram. What I do not known is how to link these using a mappings in question, so that it is easy and intuitive for the engineer (so to avoid documentation rust), and also following the current best practices.

Can all this be realised in a generic UML drawing software like UMLet or MagicDraw?

  • Do you mean 1 UML graph to describe all the possible architectural views? – Laiv Sep 2 at 13:44
  • Not necessarily. – ith Sep 2 at 13:58
  • You are thinking of UML as a drawing thing. It isn't! UML is a language and you should use a modeling tool rather than a drawing tool to work with it. – qwerty_so Sep 2 at 16:57
2

Yes, this is possible.

Logical architecture : Use UML2 component diagram(s) showing components, interfaces, usage dependencies etc.

Physical architecture: Use UML2 deployment diagram(s) showing nodes, communication paths between nodes, operating systems as deployed elements inside nodes etc. but not the components.

Mapping: Use UML2 deployment diagram(s) showing the same nodes as in the physical architecture with the components from the logical architecture as deployed elements inside the nodes. But do not show any communication paths or operating systems.

2

Within this process of mapping, it is not allowed to modify the logical and physical architecture models, only a respective third model should be produced. The two former models need to be read-only, as any number of independent mappings is possible.

If this is truly a requirement, UML (and most modeling tools and frameworks I'm familiar with) isn't a good fit. Although there's nothing in the UML spec about not using multiple models of the same type, what is proposed here (locking down models and creating mappings) goes against good modeling techniques and good engineering practices, particularly Single Source of Information and overproduction.

In UML, the correct way of modeling your system would include a Deployment Diagram to show the physical architectural, connections, and perhaps communication protocols and a Component Diagram to show the software components. Since both diagrams allow for nesting of elements, the top levels of nesting from the Component Diagram may appear as lowest level of nesting elements on the Deployment Diagram. Other types of diagrams may provide additional details of the structure and behavior of components.

Each of the different types of models represents a different view of the system and should be appropriately synchronized if information needs to be conveyed to multiple stakeholders.

Additional models should be used to reduce complexity and make it easier for stakeholders to extract information. If one set of stakeholders needs to use multiple models concurrently to get the understanding of the part of the system that they are interested in, the way you have structured your models is likely deficient.

  • I don't see why UML is no good fit. It's just the opposite. Since you can model and represent multiple aspect of your model, this is exactly what the OP needs. – qwerty_so Sep 2 at 16:59
  • @qwerty_so Read the quotation from the question and the first paragraph. That requirement precludes true modeling, where all models are always in sync. This is what UML and every other modeling language is designed for. Saying that you can't update one view of the model because of decisions made when creating a different view later is wrong. – Thomas Owens Sep 2 at 17:02
  • Well, even with that. You just transform from the r/o part to something derived. You can trace back and develop independently. Of course the derived part will deviate over time from its origins. – qwerty_so Sep 2 at 17:08
  • @qwerty_so And that deviation hurts the whole idea of modeling. – Thomas Owens Sep 2 at 17:17
  • 1
    @Thomas it is exactly about a single source of information. One diagram describes software, another describes hardware, and then there are five diagrams that describe five different mappings between software and hardware. These five diagrams use a single source of information, producing five different models. See the OO principles like inheritance and composition. If that fits the UML world or not, that's another thing. – ith Sep 3 at 17:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.