User:Mdd/Quotes about Unified Modeling Language

Unified Modeling Language (UML) is a standardized (ISO/IEC 19501:2005), general-purpose modeling language in the field of software engineering. The Unified Modeling Language includes a set of graphic notation techniques to create visual models of object-oriented software-intensive systems. Quotes about Unified Modeling Language:

Quotes

 * Quotes are arranged in chronological order

1990s

 * The Unified Modeling Language is the new official OMG standard for object-oriented modeling languages.
 * Martin Schader, Axel Korthaus (1998) The Unified modeling language: technical aspects and applications


 * The Unified Modeling Language is described as a language for “specifying, visualizing, constructing, and documenting the artifacts of software systems” and for business modeling (OMG UML V1.x documents). The UML reflects some of the best experiences in object-oriented modeling, thus it has the potential to become a widely-used standard object-oriented modeling language.
 * Robert France, Bernhard Rumpe (1999) UML'99 - The Unified Modeling Language. Beyond the Standard. p. v


 * As a generally-applicable standard the UML has to be both flexible (extensible, adaptable, modifiable) and precise. Flexibility is needed if the UML is to be used in a variety of application domains. Tailoring of UML syntax and adaptation of UML semantics to system domains is highly desirable. Incorporating domain-specific concepts into the language will yield modeling languages that more effectively support system development in these domains. Tailoring may involve determining a subset of the UML that is applicable to the domain, extending or modifying existing language elements, or defining new language elements. One can envisage UML variants that are tailored to specific domains, for example, UML for real-time systems, multimedia systems, and for internet-based systems.
 * Robert France, Bernhard Rumpe (1999) UML'99 - The Unified Modeling Language. Beyond the Standard. p. v

2000s

 * Technical design is presented in Chapter 18, a thick chapter with a lot of discussion of large object oriented design. Unified Modeling Language is revisited here to see how it is used to model the software from different views, such as static views of deployment, packages and class diagrams, and the dynamic views of activity and sequence diagrams.
 * Erik Bethke (2003) Game development and production. p. 28


 * The Unified Modeling Language is the standard language for modeling systems.
 * Thomas Baar, Alfred Strohmeier, Ana Moreira (2004) UML 2004 - The Unified Modeling Language: Modeling Languages and Applications. 7th International Conference, Lisbon, Portugal, October 11-15, 2004. Proceedings. p. 241


 * UML 2004 - The Unified Modeling Language: Modeling Languages and Applications. 7th International Conference, Lisbon, Portugal, October 11-15, 2004. Proceedings. This book constitutes the refereed proceedings of the 7th International Conference on the Unified Modeling Language, UML 2004, held in Lisbon, Portugal, in October 2004. The 30 revised full papers presented together with summaries on the workshops and tutorials were carefully reviewed and selected from 135 technical paper submissions. The papers are organized in topical sections on metamodeling, aspects, profiles and extensions, OCL, model transformation, verification and model consistency, security, and methodology.
 * Thomas Baar, Alfred Strohmeier, Ana Moreira (2004) UML 2004 - The Unified Modeling Language: Modeling Languages and Applications. 7th International Conference, Lisbon, Portugal, October 11-15, 2004. Proceedings.


 * UML has been extended to model web applications. At the same time, Web technology has become largely relying on XML documents.
 * Thomas Baar, Alfred Strohmeier, Ana Moreira (2004) ''UML 2004 - The Unified Modeling Language: Modeling Languages and...". p. 241


 * UML can be used in many ways, but the most common is as a widely recognized notation for sketching designs.
 * Steve Cook, Software Architect Microsoft Corporation cited in: Martin Fowler (2004)


 * Graphical design notations have been with us for a while... their primary value is in communication and understanding. A good diagram can often help communicate ideas about a design, particularly when you want to avoid a lot of details. Diagrams can also help you understand either a software system or a business process . As part of a team trying to figure out something, diagrams both help understanding and communicate that understanding throughout a team. Although they aren't, at least yet, a replacement for textual programming languages, they are a helpful assistant... Of these graphical notations, the UML's importance comes from its wide use and standardization within the OO development community. The UML has become not only the dominant graphical notation within the OO world but also a popular technique in non-OO circles.
 * Martin Fowler (2004) UML distilled: a brief guide to the standard object modeling language. p. xxvi


 * You can't physically touch software. You can hold a floppy disk or CD-ROM in your hand, but the software itself is a ghost that can be moved from one object to another with little difficulty. In contrast, a road is a solid object that has a definite size and shape. You can touch the .the material and walk the route... Software is a codification of a huge set of behaviors: if this occurs, then that should happen, and so on. We can visualize individual behaviors, but we have great difficulty visualizing large numbers of sequential and alternative behaviors... The same things that make it hard to visualize software make it hard to draw blueprints of that software. A road plan can show the exact location, elevation, and dimensions of any part of the structure. The map corresponds to the structure, but it's not the same as the structure. Software, on the other hand, is just a codification of the behaviors that the programmers and users want to take place. The map is the same as the structure... This means that software can only be described accurately at the level of individual instructions... A map or a blueprint for a piece of software must greatly simplify the representation in order to be comprehensible. But by doing so, it becomes inaccurate and ultimately incorrect. This is an important realization: any architecture, design, or diagram we create for software is essentially inadequate. If we represent every detail, then we're merely duplicating the software in another form, and we're wasting our time and effort.
 * George Stepanek (2005) Software Project Secrets: Why Software Projects Fail. p. 10-11

2010s

 * Software is very abstract and hard to visualise. A visual modelling language, such as UML, allows software to be visualised in multiple dimension, so that a computer system can be completely understood before construction begins. Furthermore, UML can be used to produce several models at increasing levels of detail. The overall scope of the software can quickly and easily be defined at the start of the project with a high level model allowing for accurate estimation. Increasing levels of detail can then be added to each part of the software as it is constructed, until finally the software appears as code. The code can then be tested against a test model that is derived from the original model of requirements.
 * CRaG Systems (UK) (2012) Why Use UML? at cragsystems.co.uk, retrieved 2012-12-10