what is UML and do we need it in Software Architecture?
Tags: uml, software, architecture, systems
Published: 2021-01-19 00:28:05

###**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.