Dynamic diagrams describe the system in motion. Static diagrams describe the state of a system-like a snapshot of a system in motion. The place to start is with understanding the two basic types of UML diagrams: static and dynamic diagrams. Fortunately, you don't have to gobble UML up all at once. However, the language is flexible enough to allow a variety of styles of expression using the symbols and diagram syntax the language specifies. You're either "speaking" UML diagrams and symbols or not the specification is that precise. There is no making it up as you go along. Each line and geometric shape means something special, and each arrowhead has a predefined meaning. As such, every aspect of the given diagram has a specific meaning. You can think of each diagram type as a formal graphical language, on par with hieroglyphics. The most important thing to understand about UML is this: UML defines a standard set of diagram types and symbols you can use to describe just about any aspect of an enterprise architecture. In the world of software development, the devil is always in the details, and UML has a lot of details-more than I can cover in an introductory article. The current release is version 2.5.1, released in 2017 and runs nearly 800 pages in length. The UML specification has gone through many version upgrades since its release. OMG accepted the specification and, in November 1997, adopted UML as a standard. ![]() OMG is a nonprofit standards organization supported by some of the biggest names in technology, including Red Hat, Microsoft, Salesforce, and Toshiba. In 1997, they submitted their specification to the Object Management Group (OMG) for adoption consideration. Their goal was to unify their work into a single standard and publish it as the Unified Modeling Language (UML). Each had already made significant contributions to the software industry with their own diagramming techniques. In 1996, Rational Software developed the early version of UML under the authorship of Grady Booch, Ivar Jacobson, and James Rumbaugh. Of course, this assumes all parties follow the same diagramming standard. In the same manner, applying a standard to diagramming software would make it possible for any developer in any company to work on any system designed by any architect. The motivation behind creating UML was to mirror the way structural architects use the same methods to draw building blueprints, making it possible for any construction company to put up a high-rise building designed by any architect. Thus came the impetus to create a standard diagramming format. ![]() This "getting up to speed" labor can incur significant overhead. An architect changing jobs to a new company had to take the time to learn how the new company's diagrams worked and what they represented. ![]() The variety of diagramming styles affected productivity and increased the cost of doing business. It seemed as if every company had its own way of diagramming systems. Some significant enterprise architects and application developers created UML because they got tired of the plethora of roll-your-own diagramming styles prevalent in the industry. However, to get the full benefit from the parts that detail the different diagrams, it's helpful to have a general understanding of application programming and some knowledge of classes, interfaces, and objects. These articles are for a general technical audience. In two companion articles, I offer a more detailed description of UML's particulars, including examples of the various diagram types it supports. This article provides a brief overview of UML's origins. UML provides a standard to describe software systems in a very detailed manner graphically. UML is not getting much attention these days on the front pages of popular technical sites. Take a Linux infrastructure planning assessment.An architect's guide to multicloud infrastructure.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |