Object-oriented modeling: Difference between revisions

Revision as of 22:03, 19 September 2019

Latest revision as of 10:42, 7 August 2025

(14 intermediate revisions by 5 users not shown)

Line 1:

{{Short description |Object-oriented approach to modeling a system}}

{{More citations needed|date=July 2019}}

[[File:Component-based-Software-Engineering-example2.png|class=skin-invert-image|thumb|500px|Object-oriented model of a travel reservation system.]]

'''Object-oriented modeling''' ('''OOM''') is an approach to modeling an application that is used at the beginning of the [[Software development process|software life cycle]] when using an object-oriented approach to software development.

'''Object-oriented modeling''' (OOM) is typicallyan doneapproach viato modeling a system as [[useobject cases(programming)|objects]]. andIt abstractis definitionsprimarily ofused thefor most[[software importantdevelopment objects.|developing]] The[[software]], mostbut commoncan languagebe and is used tofor doother object-orientedtypes modelingof issystems thesuch as [[Objectbusiness Management Group|Object Management Group'sprocess]]. [[Unified Modeling Language|Unified Modeling Language]] (UML) and [[SysML]] are two popular international standard languages used for OOM.<ref name="Jacobsen 1992 https://archive.org/details/objectorientedso00jaco/page/15 15,199">{{cite book|last=Jacobsen|first=Ivar|title=Object Oriented Software Engineering|year=1992|publisher=Addison-Wesley ACM Press|isbn=0-201-54435-0|pages=[https://archive.org/details/objectorientedso00jaco/page/15 15,199]|author2=Magnus Christerson|author3=Patrik Jonsson|author4=Gunnar Overgaard|url-access=registration|url=https://archive.org/details/objectorientedso00jaco/page/15}}</ref>

For [[software development]], OOM is used for [[software requirements analysis |analysis]] and [[software design |design]] and is a key practice of [[object-oriented analysis and design]] (OOAD). The practice is primarily performed during the early stages of the development process although can continue for the [[software life cycle |life]] of a system. The practice can be divided into two aspects: the modeling of dynamic behavior like [[use cases]] and the modeling of static structures like [[Class (programming)|classes]] and [[software component |components]]; generally as [[Visual modeling |visual modeling diagram]]s.

The software life cycle is typically divided up into stages going from abstract descriptions of the problem to designs then to code and testing and finally to deployment. Modeling is done at the beginning of the process. The reasons to model a system before writing the code are:

The benefits of using OOM include:

*Communication. Users typically cannot understand programming language or code. Model diagrams can be more understandable and can allow users to give developers feedback on the appropriate 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 by using terminology that is the same as the functions that users perform. Modeling is an essential tool to facilitate achieving this goal .

*[[Abstraction (computer science)|Abstraction]]. A goal of most software 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 take this abstract description and refine it into an implementable design and code given constraints such as technology and budget. Modeling enables this by allowing abstract descriptions of processes and objects that define their essential structure and behavior.

*Communication.; Efficient and effective communication: Users typically cannothave understanddifficulties programmingunderstanding language[[technical documentation]] and or[[source code]]. ModelVisual 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 Objectobject-Orientedoriented approach is to decrease the "semantic gap" between the system and the real world, byand to have the system be constructed using terminology that is almost the same as the functionsstakeholders thatuse usersin everyday performbusiness. ModelingOOM is an essential tool to facilitate achieving this goal .

Object-oriented modeling is typically done via [[use cases]] and abstract definitions of the most important objects. The most common language used to do object-oriented modeling is the [[Object Management Group|Object Management Group's]] [[Unified Modeling Language|Unified Modeling Language (UML)]].<ref>{{cite book|last=Jacobsen|first=Ivar|title=Object Oriented Software Engineering|year=1992|publisher=Addison-Wesley ACM Press|isbn=0-201-54435-0|pages=15,199|author2=Magnus Christerson|author3=Patrik Jonsson|author4=Gunnar Overgaard|url-access=registration|url=https://archive.org/details/objectorientedso00jaco}}</ref>

*; Useful and stable abstraction: Modeling supports [[Abstractionprogramming (computer science)|Abstractioncoding]]. A goal of most modern [[software development methodology |development methodologies]] is to first address "what" questions and then address "how" questions., Ii.e., first determine the functionality the system is to provide without consideration of implementation constraints, and then consider how to takemake thisspecific solutions to these abstract descriptionrequirements, and refine itthem into andetailed implementable designdesigns and codecodes givenby constraints such as technology and budget. ModelingOOM enables this by allowingproducing [[Abstraction (computer science)|abstract]] and accessible descriptions of processesrequirements and objectsdesigns as models that define their essential structurestructures and behavior.behaviors like processes and objects, which are important and valuable development assets with higher abstraction levels above concrete and complex source code.

==Language==

[[File:UML History.jpg|450px|thumbnail|right|Milestones in the evolution of the UML.<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>]]

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.

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).

<!--

==See also==

-->

* [[Object-oriented analysis and design]]

== References ==