Object-oriented modeling: Difference between revisions

Revision as of 20:55, 30 May 2011

Latest revision as of 10:42, 7 August 2025

(50 intermediate revisions by 29 users not shown)

Line 1:

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

{{Unreferenced stub|auto=yes|date=December 2009}}

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

'''Object-Oriented Modeling''', or OOM, (Object Oriented Programming - OOP)is a modeling paradigm mainly used in [[computer programming]]. Prior to the rise of OOM, the dominant paradigm was [[procedural programming]], which emphasized the use of discrete reusable code blocks that could stand on their own, take variables, perform a function on them, and return values.

[[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 a system as [[object (programming)|objects]]. It is primarily used for [[software development |developing]] [[software]], but can be and is used for other types of systems such as [[business process]]. [[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=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 Object-Oriented paradigm assists the programmer to address the complexity of a [[problem ___domain]] by considering the problem not as a set of functions that can be performed but primarily as a set of related, interacting Objects. The modeling task then is specifying, for a specific context, those Objects (or the Class the Objects belongs to), their respective set of Properties and Methods, shared by all Objects members of the Class. For more discussion, see [[Object-oriented analysis and design]] and [[Object-oriented programming]]. The description of these Objects is a [[Logical schema|Schema]].

The benefits of using OOM include:

As an example, in a model of a '''Payroll System''', a '''Company''' is an Object. An '''Employee''' is another Object. '''Employment''' is a Relationship or Association. An '''Employee Class''' (or Object for simplicity) has Attributes like Name, Birthdate, etc. The Association itself may be considered as an Object, having Attributes, or Qualifiers like Position, etc. An '''Employee Method''' may be Promote, Raise, etc.

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

The Model description or Schema may grow in complexity to require a Notation. Many notations have been proposed, based on different paradigms, diverged, and converged in a more popular one known as [[Unified Modeling Language|UML]].

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

An informal description or a Schema notation is translated by the programmer or a [[computer-aided software engineering|CASE]] tool in the case of Schema notation (created using a Module specific to the CASE tool application) into a specific programming language that supports [[object-oriented programming]] (or a Class Type), a [[declarative language]] or into a [[logical schema|database schema]].

==Language==

[[Category:Object-oriented programming]]

[[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>]]

[[Category:Software design]]

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.

{{Comp-sci-stub}}

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

[[ja:オブジェクト指向モデリング]]

<!--

==See also==

-->

== References ==

{{reflist}}

[[Category:Object-oriented programming]]

[[Category:Software design]]