Object Oriented Process is a class of Software Engineering which may be used in full accordance with the Object Oriented Paradigm. In this sense, for us at least, it is synonymous with Software Engineering.
“Object-orientation is a technique for system modeling… Using object-orientation as a base, we model the system as a number of objects that interact. Hence, irrespective of the type of system being modeled, we regard its contents as a number of objects which inone way or another are related.”
“Among the most prominent qualities of a system designed with an object-oriented method are the following:
- Understanding of the system is easier as the semantic gap between the system and reality is small.
- Modifications to the model tend to be local as they often result from an individual item, which is represented by a single object.”
Ivar Jacobson, Object Oriented Software Engineering
It should be noted that strictly speaking the coding may not be done with Object Oriented Programming. But of course, in our case that is almost never the case.
Object Oriented Process would definitely be based on Best Practices.
There are a huge number of tools, both Open Source and/or free, as well as commercially available. But Object Oriented Process cannot be boiled down to those tools.
UML is used as a notational and graphic language for the generation of the various models (business, use case, analysis and design, component, deployment…) which emerge from the process itself, but the process cannot be reduced either to UML or the models that are generated in its use.
And last but not least, and this cannot be emphasized sufficiently nor repeated too many times: Any Object Oriented Process, or Software Engineering process observing Best Practices, be it RUP, Agile, CMMI or any other, cannot be simply taken and used. It must be instantiated for the particular project at hand. So Process Intantiation is one of the most important tasks a Process Engineer has to do in the Project Life Cycle.
Object Oriented Process must lean heavily on Use Case Driven modeling. This lies at the heart of the question: How do you get from requirements to code?
In this sense the process takes on both a dynamic and static aspect:
See ICONIX), a pre-RUP methodology which had a great influence on me, for a pithy but important description of the method. As Ruby On Rails addicts, we should pay special attention to the Robustness Diagram, since, like the User Experience Model, it spells everything in the system out as MVC, in this case as entities, boundaries and controllers!
Object Oriented Process, or Object Oriented Software Engineering, brings to bear a series of disciplines marshalled during each and every one of the iterations making up the lifecycle of a project, each and every one emerging from the Requirements Management, passing through the MVC pattern applied in the course of generating the Design Model, and ending in the Deployment of a new Release.
Disciples:
Tools:
See
Victor Kane (ProjectMaster) and awebfactory.com.ar