I have this simple diagram, it doesn't follow any type of UML diagram. Its goal is to show all the parts of our solution, and how they're related.
In the image: the web scraper scraps the data in some websites and stores it in the database. The web application receives filter options and implement it using a Rest API that returns some data to be exported in xlsx and csv. The API uses the database populated by the web scraper.
I need to make a new diagram with the highlighted process above, using UML. I had a suggestion to use a package diagram, so I made this version:
Edit: In the image: Fonts -> Web Scraper -> Database -> Api(Filters(type of filters)) -> Front end (results, search options) -> User
Is it the right way of making a package diagram? I couldn't find a similar example or specific rules for this case.
Are packages the right modeling tool for your needs?
Packages are namespaces and aim to structure a model. A package diagram therefore does in not represent a process with data flows (dynamic behavior). The relations between packages are namespace relations such as «imports» and «merges» and dependencies.
Your package diagram certainly shows some valid decomposition of your design with nested packages. But you would normally not represent users (usario), or flows of data (dados) coming from a database (Banco de dados).
What are the better alternatives in UML?
Your initial diagram shows in one picture, using some flowcharting symbols, very different things:
conceptual classes of objects such as fonts, filters, or files
components such as web scraper, the database, front-end, back-end,
flows of objects like the webscraper that feeds the database that is queried by the backend, or interactions between freont-end suppliying filters and back-end that provides data.
If you want to represent this in UML you need to clarify the focus, because UML requires some precision since it separates structure and behavior. The answer will depend on what you want to show:
the flow of processes and data? Use an activity diagram (behavior). This is perfect to show the flow from the source to the end-result, but not so easily the parts of the system that are involved.
the relationship between components ? Use a component diagram (structure). This is perfect to identify the components, how these are nested, and how their interfaces are connected. But it does not show the order in which all this happens.
the interaction between components ? Use communication or sequence diagrams (behavior). Here you see what the components exchange in what order, but not so well how the components are structured.
Spontaneously, I'd go for components, since I have the impression that this dominates your original diagram. But in the end, you may use different diagrams for showing the different aspects.
Other alternatives
If you're looking for a single diagram to combine the different thoughts of your original diagram, alternatively to UML, you could consider C4 model diagrams.
It's less precise than UML, but very convenient for communicating the big picture of a system architecture. The C4 context diagram and the C4 container diagram in paticula allow to show the system's main components, and some high-level relations (including data flows) between them.
The good news is that C4 relies on UML for the the more detailed design of the identified components.
Related
I want to develop mobile applications, but I only focus on frontend development not on the backend.
I want to make a UML diagram, but I am confused about what to do, at this point I think I will make a use case diagram, a use case description, and an activity diagram. Do i need to add other diagram types like sequences or other? and if so what i need to make that diagram??
When drawing diagrams, you can draw them either from the entire system or just it's part perspective. Of course it is normal to use both approaches in a single project. It all depends what is your goal and what are you trying to model.
When looking at the FE, you can of course draw at least following diagrams:
Use case diagram to indicate what functions are offered by the FE. It will often be similar to UC diagram of the entire system, however it will definitely not contain the APIs exposed by the system for other systems to integrate as those are BE specific. Besides, you may have different front-ends (e.g. fat vs thin client), offering different functionalities
Activity diagram to show flow (e.g. screens' flow, e.g. per UC)
Class diagram to show data structures used by FE (they often differ to some level to the BE part, however usually are generated by the FE-BE integration layer)
Sequence diagram or Communication diagram to indicate points of integration with BE, especially in complex cases
Of course there can be much more, depending on your specific situation (e.g. timing diagram can be important in your specific case)
Having said that, take into account that you don't need to draw any diagrams. The idea of modelling is to draw those diagrams, that are needed, i.e. help grasp some ideas that may be otherwise be difficult to understand.
I'm currently designing the UML diagram for a project that involves the usage of MySQL (for data storing) and Java (for data "presentation"), my question is, is it correct to use a single UML diagram in a project that involves multiple languages? and also, do I need to explicitly show which part "belongs" to each language?
Even though I know UML is a generic representation I had this question because I plan to do all the data processing in the server, and for that I have a class in the package "datos" (data) but for databases I have always used the ER model and also, the class "Reportero" has a bunch of methods that are "symbolic" because their functionality will be achieved with Queries.
Class in the UML diagram I'm referring to
Thank you in advance!
In general you need to decompose your system into subsystems or components, which you can realize using different languages. The pure UML way is using deployment diagrams, that models the deployment to hardware or to runtime environements like application servers. A less UMLish way is using custom stereotypes at the components that you have defined.
More specifacally, you are asking for a MySQL. In a UML model you model static parts of your system, their properties and interactions based on them. But you usually dont model databases. So what you can do using UML is object oriented analysis, which gives you classes that can represent the entities in your database. But when you say you have class, which operations are realized by queries, you still have something implemented in your language that triggers the execution of the query; in that case I would either define a stereotype used for classes or for operations indicating that the contained operations or the operation has no own logic but just calls the queries.
Further you should get familar with the term model and diagram :-)
UML is not about diagramming. It is about models - and communicating them to humans by means of diagrams.
What you do in more complex systems is to split them into sub-domains and package them in a meaningful way. In the same way you would create individual diagrams showing static and dynamic system aspects. In your concrete case you could show the database design separate from the runtime design. However, it is also possible to mix both in overview diagrams.
I would like to make a component diagram for a multiple robot coordination system.
I would like to show on the component diagram that the sub-component "Perception" of each "Robot" component communicates through an interface with each other. Indeed, the sensors of all robots are used in order to estimate the position/velocity of each robot, it is a cooperative sensing.
How can I do that ? Should I have an interface which would be both provided and required by the component "Robot" ?
Thanks.
For this type of system you are in position to use full power of UML and make really effective documentation. You will most likely need some (or all) of the following diagrams:
Component diagram - to show the "big picture" and the main parts of your system ant their interfaces and dependencies. Components are "black boxes" here and will be detailed in the following diagram
Composite structure - are perfect to open up the components and show their internal structure. You can take "black boxes" and their interfaces as kind of input to this work. Each component (except the external ones) should be modelled internally. This kind of diagrams lets you use the whole-part paradigm to model internal structure as a network of interconnected elements. Previously detected interfaces will be used here to show how they are actually implemented.
Class diagrams. If you need to further specify the elements of internal structure (their attributes, methods, associations, etc), this is the diagram to draw.
State machines. In embedded real-time systems, lots of classes are active and have states. Identify those classes (or even components) and use state diagrams to show their internal logic.
Sequences and interactions. These diagrams will help you to specify how different elements of your system work together to implement different scenarios.
Deployment diagram. As robot is a piece of hardware and these components run on it (or them, if there are more than one hardware node) you might want to show how the components are distributed over the hardware structure.
You could also have a look on timing diagram, relativelly new one, designed especially for real-time systems. It might come on handy if you need to express time restrictions, durations, etc.
If you are new to UML, I would recommend to start with components and deployment. They are relativelly easy to learn. As you feel understanding and need to express your ideas further, dive in the composite structure and states. And finally classes.
Have fun!
EXAMPLE
This is how I understand your model and its elements. This extends my comments.
Explanations are in comments and in the diagram notes.
A component diagram:
A component instances' diagram:
Note that the first diagram should be extended with the "connectivity rules" that define all valid connectivity possibilities. Is there only one CentralManager? Must each Robot be connected to CentralManager? Can a Robot talk to itself? And so on...
These and other questions should be modelled separatelly. On class diagrams benavior diagams, according to concrete details.
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.
Can anyone tell which UML diagram I should change if there is a slight change in the design of application.
The change is -> Earlier the application was using Active directory for authentication now I want to use the Membership provider instead.
I want to keep the change minimum in diagrams.
Thanks
Sounds like component diagrams or class diagrams. Check out the following topics and illustrations for VS 2010 Ultimate RC:
UML Component Diagrams: Reference at http://msdn.microsoft.com/en-us/library/dd409390%28VS.100%29.aspx:
A component diagram shows the parts of a design for a software system. A component diagram helps you
visualize the high-level structure of the system and the service behavior that those pieces provide
and consume through interfaces.
UML Class Diagrams: Reference at http://msdn.microsoft.com/en-us/library/dd409437%28VS.100%29.aspx
A UML class diagram describes the object and information structures used by your application, both
internally and in communication with its users. It describes the information without reference to any
particular implementation.
It will surely depend the diagrams at your disposal. Sound like a correction in one of the static diagram types, like the component diagram ...
This of course depends on how you structure your documents and your uml-diagrams.
In general I have a Conceptual model, Class Diagram and a Design Diagram which are diractly linked to the architecture. And then you should in most cases have System Sequence Diagrams and more. However, depending on how your structure is and to minimize the "changes" required.
I would suggest that you use something more generic for the parts that might be changed. Active Directory Authentication and Membership Provider Authentication is both Authentication methods, which means that you can, instead of displaying the whole sequence at the Authentication step, just use "Authentication".
Now, in the conceptual models and in the design + class diagrams, you will need to change and add some fields, tables or whatever is added. But it shouldn't matter if you need to add more or less, because the documents need to reflect upon your software as accurate as possible.
So, to minimize changes, use more generic types.