Unified Modeling Language or UML in short it is Language used in systems and software development for specifying, visualizing, constructing, and documenting the artifacts and views of software systems and other non-software systems. we look at a system from many different viewpoints. Software development will have many stakeholders playing a part. for example:
Analysts, Designers, Coders, Testers
Customers, Managers, Executives, Company-owners
Investors, Sponsors, End-users
All of these people are interested in different aspects of the system, and each of them require a different level of detail. For example, a coder needs to understand the design of the system and be able to convert the design to a low level code. By contrast, a technical writer is interested in the behavior of the system as a whole, and needs to understand how the product functions. The UML attempts to provide a language so expressive that all stakeholders can benefit from at least one UML diagram. and there a lot of diagrams that I am not gonna go through but I will give a list of reference of 14 UML Diagram Types:
Structure Diagrams. Class Diagram. Component Diagram. Deployment Diagram. Object Diagram. Package Diagram. Profile Diagram. Composite Structure Diagram.
Behavioral Diagrams. Use Case Diagram. Activity Diagram. State Machine Diagram. Sequence Diagram. Communication Diagram. Interaction Overview Diagram.
For Example One of the most vexing realities about architecture-based software development is the gulf between architectural and implementation ontologies, the set of concepts and terms inherent in an area.
Ask an architect what concepts they work with all day, and you’re likely to hear things like modules, components, connectors, stakeholders, evaluation, analysis, documentation, views, modeling, quality attributes, business goals, and technology roadmaps.
Ask an implementer the same question, and you likely won’t hear any of those words. Instead, you’ll hear about objects, methods, algorithms, data structures, variables, debugging, statements, code comments, compilers, generics, operator overloading, pointers, and build scripts. This is a gap in language that reflects a gap in concepts. This gap is, in turn, reflected in the languages of the tools that each community uses.
UML started out as a way to model object-oriented designs that could be quickly converted to code—that is, UML is conceptually “close” to code. Today it is a de facto architecture description language, and likely the most popular one.
Architecture is an abstraction of implementation is almost its whole point: architecture lets us achieve intellectual control over a system without having to capture, let alone master, all of the countless and myriad truths about its implementation. And here comes the gap again: All of those truths about its implementation are what coders produce for a living, without which the system remains but an idea. Architects, on the other hand, dismiss all of that reality by
announcing that they are not interested in implementation “details.”
Can’t we all get along?
The good news is that even though architecture and implementation speak different languages, they aren’t languages from different planets. Concepts in one ontology usually correspond pretty well to concepts in another. Frameworks are an area where the languages enjoy a fair amount of overlap. So are interfaces. These constructs live on the cusp of the two domains and provide hope that we might one day speak the same language.
Top comments (2)
I do not know many people that use it. The only people that use it seem to be people with OCD. At least where I work. They spend too much time on UML and it causes projects to be late and move along very slowly.
from small to medium-sized projects it can be overkill. but for complex and projects that evolve with time, it can help you discover flaws or possible optimizations that you might not have thought of before.