Content deleted Content added
Stevebroshar (talk | contribs) Diagrams are not used for use cases |
Stevebroshar (talk | contribs) Move in relevant info from object-modeling language in preparation to convert it to a redirect |
||
Line 8:
The benefits of using OOM include:
; Efficient and effective communication: Users typically have difficulties understanding [[technical documentation]] and [[source code]]. Visual diagrams can be more understandable and can allow users and stakeholders to give developers feedback on the appropriate requirements and structure of the system. A key goal of the object-oriented approach is to decrease the "semantic gap" between the system and the real world, and to have the system be constructed using terminology that is almost the same as the stakeholders use in everyday business. OOM is an essential tool to facilitate this.▼
▲Users typically have difficulties understanding [[technical documentation]] and [[source code]]. Visual diagrams can be more understandable and can allow users and stakeholders to give developers feedback on the appropriate requirements and structure of the system. A key goal of the object-oriented approach is to decrease the "semantic gap" between the system and the real world, and to have the system be constructed using terminology that is almost the same as the stakeholders use in everyday business. OOM is an essential tool to facilitate this.
; Useful and stable abstraction: Modeling supports [[programming |coding]]. A goal of most modern [[software development methodology |development methodologies]] is to first address "what" questions and then address "how" questions, i.e. first determine the functionality the system is to provide without consideration of implementation constraints, and then consider how to make specific solutions to these abstract requirements, and refine them into detailed designs and codes by constraints such as technology and budget. OOM enables this by producing [[Abstraction (computer science)|abstract]] and accessible descriptions of requirements and designs as models that define their essential structures and behaviors like processes and objects, which are important and valuable development assets with higher abstraction levels above concrete and complex source code.▼
▲Modeling supports [[programming |coding]]. A goal of most modern [[software development methodology |development methodologies]] is to first address "what" questions and then address "how" questions, i.e. first determine the functionality the system is to provide without consideration of implementation constraints, and then consider how to make specific solutions to these abstract requirements, and refine them into detailed designs and codes by constraints such as technology and budget. OOM enables this by producing [[Abstraction (computer science)|abstract]] and accessible descriptions of requirements and designs as models that define their essential structures and behaviors like processes and objects, which are important and valuable development assets with higher abstraction levels above concrete and complex source code.
==Language==
The notation used for modelling is a language of graphical elements that imply design based on convention. Many conventions have been devised and they vary in formality. It may be relatively informal in nature, or consist of predefined graphical templates or consist of a formally defined [[grammar]].
A modeling language is often associated with a object-oriented [[software development methodology]] since a methodology often spawns a language. The modeling language defines the elements of a model, such as [[class (programming)|classes]], [[method (programming)|methods]], [[property (programming)|properties]], etc. The methodology defines the steps developers take to create and maintain a software system in relation to the models. For example, the [[Booch method]] may refer to [[Grady Booch]]'s standard for diagramming, his methodology, or both. Or the Rumbaugh [[Object Modeling Technique]] is both a set of diagrams and a process model for developing object-oriented systems.
[[File:UML History.jpg|450px|thumbnail|right|Important milestones in the evolution of the UML: One of the most significant object modeling languages currently in use.<ref>{{cite web|last=Riley|first=Mike|title=A Special Guide-MDA and UML Tools: CASE 2.0—or the Developer's Dream|url=http://www.drdobbs.com/a-special-guide-mda-and-uml-tools-case-2/184415500|work=drdobbs.com|publisher=Dr. Dobb's|access-date=19 December 2013|date=April 1, 2006|quote=If it weren't for the dominance that UML has gained over the industry, MDA and related modeling standards couldn't even exist.}}</ref>]]
In the early years of the object-oriented development there were several competing modeling and methodology variants. Booch and Rumbaugh were two of the most popular, and [[Ivar Jacobson]]'s Objectory, Shlaer-Mellor, and Yourdon-Coad were also popular. Starting in the mid-1990s, efforts began to harmonize modelling languages; to reconcile the leading models and focus on one unified specification. The graphic shows the evolution of and adoption of the [[Unified Modeling Language]] (UML).
<!--
| |||