In UML 2.5, it is written : A component acts like a Package for all model elements that are involved in or related to its definition, which should be
either owned or imported explicitly. Typically the Classifiers that realize a Component are owned by it.
So if we need to modeled that a set of classes are used to realize two different components, we have to use something like a packageMerge ?
For example, how to model two components, one dedicated to CRUD operations, the other dedicated to reports, and that these two components use the same set of classes to check access rights ?
I found two solutions, which one is the best for you ?
model three components, one for the CRUD, one for the reports, one for the access rights and model dependencies between each one. But the classes used to check rights are not a component as UML defines a component.
model two components and a package rights containing the classes and model that the two components depend of this package
I wouldn't be too dogmatic in such a case:
The String class is used in both components. Whether you merge it or not is sort of a question for configuration management. So would you link a binary or do you have sources that are being compiled where you can use either component independently. The question should be: who is the reader for this construct? If you have a clear picture you could detail it. Else just leave it open as shown above.
Related
I'm working on a project where I'm using an SDK that provides things I need via some classes. I've named these ProviderProvider and Provider, that grant access to OneThing that is an IThing.
An example is shown here
.
My question is: What is the correct (or best) way to show that the Model provides the list of OneThings to the View through those classes?
Do you show this explicitly as in my example, by drawing a dependency arrow from Model to OneThing? That doesn't seem right to me and quickly becomes visually cluttered.
Do you not explicitly define that relationship, but is it simply implicitly defined through the other relationships?
Do you define that relationship semi-explicitly through attributes, notes or some other way?
What relations and attributes should I add/remove specifically and why?
You already have the implicit relationship since you use this class as a type of data returned by Model so you do not need to add that relationship explicitly.
It may be useful though, especially for classes that are core in the system, to add a diagram with dependencies only. Then you don't care about relationships between other classes, you only show on one diagram all classes that depend on the core one (it may be even more than one diagram).
One hint - in Case tool (like EA) even if you don't intend to show the relationship on the diagram since it is indicated implicitly it is still good to create the explicit dependency and just remove the arrow. This will support the traceability through tools like traceability matrix or dependency tree.
I am working at modelling a software system using Sparx Enterprise Architect 13. This system contains different versions of software components. We typically add services and/or APIs when we release a new version of a software component.
Currently, to reflect the fact that component ServiceV1 exposes an interface A and ServiceV2 exposes interfaces A (the same as ServiceV1) and B, I make ServiceV2 extend ServiceV1. But that is not straightforward:
the generalization link is not available in diagrams between components, so I have to use Advanced > Parent...
it lacks flexibility, because I cannot override interface A with a newer version of the interface
Is there a better way to do so? What is the standard way of maintaining several versions of the same component?
Thank you!
I don't think this is standardized by some standards body, but I would recommend to introduce two levels of abstraction: the unversioned component level and the versioned component level.
On the unversioned component level, you have just a single element in the project repository for each component (not for each component version).
On the versioned component level, you have a single element in the project repository for each version of each component.
Each versioned component, e.g. MyComponentV2 has a ≪trace≫ dependency to the unversioned one, e.g. MyComponent.
To prevent unnecessary design work, you may decide to draw relationships between different components only between versioned component elements, not between unversioned component elements, or only vice versa. But this depends on the needs of your organization.
When you create a new version of a component, you copy the most recent version of the component (MyComponentV2) with all its connections, including the ≪trace≫-dependency to the unversioned component (MyComponent) and give it the right name (MyComponentV3).
I have applied this in a large project.
Actually there is no standard for modeling such a scenario. At best you can have conventions - which may differ from domain to domain. However, here's how I would model it:
ServiceV2 has a <<trace>> relation to ServiceV1. UML 2.5.1 says on p. 682:
«Trace» | Abstraction | Specifies a trace relationship between model elements or sets of model elements that represent the same concept in different models. Traces are mainly used for tracking requirements and changes across models. As model changes can occur in both directions, the directionality of the dependency can often be ignored. The mapping specifies the relationship between the two, but it is rarely computable and is usually informal.
So that should mean in this context ServiceV2 is created using ServiceV1 (I formerly used <<derive>> here since it seemed logical. But actually the UML semantic is defined differently; see p. 680 of UML 2.5.1). You could well invent your own stereotype here and explain it in the domain context (e.g. <<version of>>).
You would probably create a copy of ServiceV1 or model it manually as new element (you don't do that on a mass scenario, do you?). Here I added provided interfaces that both realize the common interface A. The quick linker does not offer those relations. You need to either go the clumsy Ctrl-I way or you grab the realization from the toolbox.
The <<derive>> dependency is not offered directly (unless you have your own MDG and defined it in QL or toolbox). So you create a dependency and choose derive from the stereotype menu.
This is a broad field and versioning is not as simple as just adding a numbering schema. In any case if you create a new component it will be something different. So the <<derive>> is probably the best option here.
EA supports this. See documentation of "Time aware models" here:
https://sparxsystems.com/enterprise_architect_user_guide/13.0/model_domains/time_aware_models.html
Allows maintaining separate versions of each package
I was wondering if it was possible to have differences between my conceptual model and the class diagram?
In the conceptual model, I explain that the user can create a message.
But in the class diagram the user must go through a class that contains all methods of creating a "ManageMessage" message.
here is an example
Can you help me ? Thank you
It's up to you how you show your classes in different diagrams. So in one you can show detailed attributes and operations and in another you show just the class name. However, in most cases it's better to create domain model which focuses on business aspects in the beginning. It does not have technically imposed structural elements and mainly you use attributes (YMMV). Later you derive a technical design from that model where you create a copy that links back with <<trace>> dependencies (UML tools offer transformation for that). Although you have to (mostly) manually synch the two models it's best to communicate with either business and developers.
N.B. about your design above: A message with zero related users does not seem to make much sense. Also you should not use the shared aggregation since it has no defined semantics.
I am very confused on what are these "components" should be. I am just starting with UML by the way. I don't know what components should be used or be place in the diagram. I've searched for definitions about these components and they are very hard to understand. Can you please explain it in a very simple way on what these components should be?
P.S.: This component diagram will be about a website. A planner website.
I can't post what I had in mind because I am a new user and new users aren't allowed to post images.
The way I think of them is as a large, logical, chunk of the functionality of a system; a bit like that which might be found in a single library or a .jar file. They tend to be associated more with software intensive systems distributed over multiple nodes (computers) and locations. They idea is that they interact, mainly, through well defined interfaces and that they can be replaced or "swapped out" with another component that will do the same job. An example would be changing to a different database management system, or updating some hardware drivers.
Components are used most in component and sequence diagrams.
I believe there is a debate as to what the real the differences between components and classes are. Both are specialisations of the concept of a classifier in UML
In your case —without knowing much about the specifics— you might have the following components with interfaces between them:
a web client component
a business/problem logic component or components
some sort of data management component.
At the end of the day though, you use the UML in whatever way works for you. A simple software project might not benefit at all from using component diagrams. It's up to each project team to define what context and level of abstraction they are working at and choose diagram types accordingly.
I am reverse engineering some Java code into a class diagram. Now I'm wondering how to model classes that are from a library that I didn't design. If I'm writing them down as classes, I should maybe also know what interfaces they implement, etc, and put that in the diagram. How far do I go with this? Is it better to write them down as attributes of my own classes?
Include whatever classes and interfaces your code uses in the diagram for your code.
Place the elements from the library into a package which represents the library's package.
Use whatever level of detail is sufficient for what the diagram represents.
If you only want to record that your code uses the library, a «uses» relationship to the package representing the library
If you have associations to elements in the library, model the elements you relate to but no detail in them.
If you or extend or implement classes or interfaces, model the attributes and operations of those elements.
If your code relies on a sequence of operations on elements in the library, you may model the operations, or may just use messages which are not directly linked to them, depending what your tool allows.
I found an interesting link which could help: http://www.ejb3.org/jar_file_reverse/jar_file_reverse.html
You can reverse your java project to show .java classes and then just drag and drop .class classes coming from the jar to your diagram. You can make a differentiation between them by adding the package name in the class name, or by changing the color of the class etc....