Object-oriented modeling: Difference between revisions

Revision as of 12:40, 6 August 2025

Revision as of 13:16, 6 August 2025

Line 1:

{{Short description|Approach to modeling a computer application}}

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

'''Object-oriented modeling''' (OOM) is typicallyan doneapproach viato [[usemodeling cases]]a andsystem abstract{{endash}} definitionssuch ofas thea most[[software importantsystem]] objects.or The most common language used to do object-oriented modeling is thea [[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>

'''Object-oriented modeling''' (OOM) is an approach to modeling [[software]] for the purpose of [[software development |development]] [[software requirements analysis |analysis]] and [[software design |design]] and is a key practice of [[object-oriented analysis and design]] (OOAD). OOM is primarily performed during the early stages of the [[software development process]] although can continue for the [[software life cycle |life]] of a software system.

'''Object-orientedIn modeling'''the (OOM)context is an approach to modelingof [[software development]], forit theis purposeused of [[software development |development]]for [[software requirements analysis |analysisanalyis]] and [[software design |design]] and is a key practice of [[object-oriented analysis and design]] (OOAD). OOMThe practice is primarily performed during the early stages of the [[software 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 systemcomponent |components]].

The reasons to model a system before writing the code are:

==Benefits==

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

The benefits OOM for software development include:

*[[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.

; Efficient and effective communication

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

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

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

<!--