Revista COMPU MAGAZINE, Número 51

Unidad 1 El modelo del proceso del software
1.1 Conceptualización de tecnología orientada a objetos
1.2 Metodologías emergentes de desarrollo de software
1.3 Métodos de desarrollo de software orientado a objetos
1.4 El proceso de desarrollo unificado – RUP
1.5 El lenguaje de modelado unificado – UML
http://carlossanchezluis.wikispaces.com
La programación orientada a objetos o POO (OOP según sus siglas en inglés) es un
paradigma de programación que usa objetos y sus interacciones, para diseñar aplicaciones y
programas informáticos. Está basado en varias técnicas, incluyendo herencia, abstracción,
polimorfismo y encapsulamiento. Su uso se popularizó a principios de la década de los años
1990. En la actualidad, existe variedad de lenguajes de programación que soportan la
orientación a objetos.
Contenido
[ocultar]







1 Introducción
2 Origen
3 Conceptos fundamentales
4 Características de la POO
5 Resumen
6 Lenguajes orientados a objetos
7 Enlaces externos
[editar] Introducción
Los objetos son entidades que tienen un determinado comportamiento (método) e
identidad:



El estado está compuesto de datos, será uno o varios atributos a los que se habrán
asignado unos valores concretos (datos).
El comportamiento está definido por los métodos o mensajes a los que sabe
responder dicho objeto, es decir, qué operaciones se pueden realizar con él.
La identidad es una propiedad de un objeto que lo diferencia del resto, dicho con
otras palabras, es su identificador (concepto análogo al de identificador de una
variable o una constante).
Un objeto contiene toda la información que permite definirlo e identificarlo frente a otros
objetos pertenecientes a otras clases e incluso frente a objetos de una misma clase, al poder
tener valores bien diferenciados en sus atributos. A su vez, los objetos disponen de
mecanismos de interacción llamados métodos, que favorecen la comunicación entre ellos.
Esta comunicación favorece a su vez el cambio de estado en los propios objetos. Esta
característica lleva a tratarlos como unidades indivisibles, en las que no se separa el estado
y el comportamiento.
Los métodos (comportamiento) y atributos (estado) están estrechamente relacionados
por la propiedad de conjunto. Esta propiedad destaca que una clase requiere de métodos
para poder tratar los atributos con los que cuenta. El programador debe pensar
indistintamente en ambos conceptos, sin separar ni darle mayor importancia a alguno de
ellos. Hacerlo podría producir el hábito erróneo de crear clases contenedoras de
información por un lado y clases con métodos que manejen a las primeras por el otro. De
esta manera se estaría realizando una programación estructurada camuflada en un
lenguaje de programación orientado a objetos.
La POO difiere de la programación estructurada tradicional, en la que los datos y los
procedimientos están separados y sin relación, ya que lo único que se busca es el
procesamiento de unos datos de entrada para obtener otros de salida. La programación
estructurada anima al programador a pensar sobre todo en términos de procedimientos o
funciones, y en segundo lugar en las estructuras de datos que esos procedimientos manejan.
En la programación estructurada sólo se escriben funciones que procesan datos. Los
programadores que emplean POO, en cambio, primero definen objetos para luego enviarles
mensajes solicitándoles que realicen sus métodos por sí mismos.
[editar] Origen
Los conceptos de la programación orientada a objetos tienen origen en Simula 67, un
lenguaje diseñado para hacer simulaciones, creado por Ole-Johan Dahl y Kristen Nygaard
del Centro de Cómputo Noruego en Oslo. En este centro, se trabajaba en simulaciones de
naves, que fueron confundidas por la explosión combinatoria de cómo las diversas
cualidades de diferentes naves podían afectar unas a las otras. La idea surgió al agrupar los
diversos tipos de naves en diversas clases de objetos, siendo responsable cada clase de
objetos de definir sus propios datos y comportamientos. Fueron refinados más tarde en
Smalltalk, desarrollado en Simula en Xerox PARC (cuya primera versión fue escrita sobre
Basic) pero diseñado para ser un sistema completamente dinámico en el cual los objetos se
podrían crear y modificar "sobre la marcha" (en tiempo de ejecución) en lugar de tener un
sistema basado en programas estáticos.
La programación orientada a objetos se fue convirtiendo en el estilo de programación
dominante a mediados de los años ochenta, en gran parte debido a la influencia de C++,
una extensión del lenguaje de programación C. Su dominación fue consolidada gracias al
auge de las Interfaces gráficas de usuario, para las cuales la programación orientada a
objetos está particularmente bien adaptada. En este caso, se habla también de programación
dirigida por eventos.
Las características de orientación a objetos fueron agregadas a muchos lenguajes existentes
durante ese tiempo, incluyendo Ada, BASIC, Lisp, Pascal, entre otros. La adición de estas
características a los lenguajes que no fueron diseñados inicialmente para ellas condujo a
menudo a problemas de compatibilidad y en la capacidad de mantenimiento del código. Los
lenguajes orientados a objetos "puros", por su parte, carecían de las características de las
cuales muchos programadores habían venido a depender. Para saltar este obstáculo, se
hicieron muchas tentativas para crear nuevos lenguajes basados en métodos orientados a
objetos, pero permitiendo algunas características imperativas de maneras "seguras". El
Eiffel de Bertrand Meyer fue un temprano y moderadamente acertado lenguaje con esos
objetivos pero ahora ha sido esencialmente reemplazado por Java, en gran parte debido a la
aparición de Internet, y a la implementación de la máquina virtual de Java en la mayoría de
navegadores. PHP en su versión 5 se ha modificado, soporta una orientación completa a
objetos, cumpliendo todas las características propias de la orientación a objetos.
[editar] Conceptos fundamentales
La programación orientada a objetos es una forma de programar que trata de encontrar una
solución a estos problemas. Introduce nuevos conceptos, que superan y amplían conceptos
antiguos ya conocidos. Entre ellos destacan los siguientes:









Clase: definiciones de las propiedades y comportamiento de un tipo de objeto
concreto. La instanciación es la lectura de estas definiciones y la creación de un
objeto a partir de ellas.
Herencia: (por ejemplo, herencia de la clase C a la clase D) Es la facilidad
mediante la cual la clase D hereda en ella cada uno de los atributos y operaciones de
C, como si esos atributos y operaciones hubiesen sido definidos por la misma D.
Por lo tanto, puede usar los mismos métodos y variables publicas declaradas en C.
Los componentes registrados como "privados" (private) también se heredan, pero
como no pertenecen a la clase, se mantienen escondidos al programador y sólo
pueden ser accedidos a través de otros métodos públicos. Esto es así para mantener
hegemónico el ideal de OOP.
Objeto: entidad provista de un conjunto de propiedades o atributos (datos) y de
comportamiento o funcionalidad (métodos) los mismos que consecuentemente
reaccionan a eventos. Se corresponde con los objetos reales del mundo que nos
rodea, o a objetos internos del sistema (del programa). Es una instancia a una clase.
Método: Algoritmo asociado a un objeto (o a una clase de objetos), cuya ejecución
se desencadena tras la recepción de un "mensaje". Desde el punto de vista del
comportamiento, es lo que el objeto puede hacer. Un método puede producir un
cambio en las propiedades del objeto, o la generación de un "evento" con un nuevo
mensaje para otro objeto del sistema.
Evento: Es un suceso en el sistema (tal como una interacción del usuario con la
máquina, o un mensaje enviado por un objeto). El sistema maneja el evento
enviando el mensaje adecuado al objeto pertinente. También se puede definir como
evento, a la reacción que puede desencadenar un objeto, es decir la acción que
genera.
Mensaje: una comunicación dirigida a un objeto, que le ordena que ejecute uno de
sus métodos con ciertos parámetros asociados al evento que lo generó.
Propiedad o atributo: contenedor de un tipo de datos asociados a un objeto (o a
una clase de objetos), que hace los datos visibles desde fuera del objeto y esto se
define como sus características predeterminadas, y cuyo valor puede ser alterado
por la ejecución de algún método.
Estado interno: es una variable que se declara privada, que puede ser únicamente
accedida y alterada por un método del objeto, y que se utiliza para indicar distintas
situaciones posibles para el objeto (o clase de objetos). No es visible al programador
que maneja una instancia de la clase.
Componentes de un objeto: atributos, identidad, relaciones y métodos.

Identificación de un objeto: un objeto se representa por medio de una tabla o
entidad que esté compuesta por sus atributos y funciones correspondientes.
En comparación con un lenguaje imperativo, una "variable", no es más que un contenedor
interno del atributo del objeto o de un estado interno, así como la "función" es un
procedimiento interno del método del objeto.
[editar] Características de la POO
Existe un acuerdo acerca de qué características contempla la "orientación a objetos", las
características siguientes son las más importantes:

Abstracción: denota las características esenciales de un objeto, donde se capturan
sus comportamientos.Cada objeto en el sistema sirve como modelo de un "agente"
abstracto que puede realizar trabajo, informar y cambiar su estado, y "comunicarse"
con otros objetos en el sistema sin revelar cómo se implementan estas
características. Los procesos, las funciones o los métodos pueden también ser
abstraídos y cuando lo están, una variedad de técnicas son requeridas para ampliar
una abstracción.El proceso de abstracción permite seleccionar las características
relevantes dentro de un conjunto e identificar comportamientos comunes para
definir nuevos tipos de entidades en el mundo real. La abstracción es clave en el
proceso de análisis y diseño orientado a objetos, ya que mediante ella podemos
llegar a armar un conjunto de clases que permitan modelar la realidad o el problema
que se quiere atacar.

Encapsulamiento: Significa reunir a todos los elementos que pueden considerarse
pertenecientes a una misma entidad, al mismo nivel de abstracción. Esto permite
aumentar la cohesión de los componentes del sistema. Algunos autores confunden
este concepto con el principio de ocultación, principalmente porque se suelen
emplear conjuntamente.

Modularidad: Se denomina Modularidad a la propiedad que permite subdividir una
aplicación en partes más pequeñas (llamadas módulos), cada una de las cuales debe
ser tan independiente como sea posible de la aplicación en sí y de las restantes
partes. Estos módulos se pueden compilar por separado, pero tienen conexiones con
otros módulos. Al igual que la encapsulación, los lenguajes soportan la Modularidad
de diversas formas.

Principio de ocultación: Cada objeto está aislado del exterior, es un módulo
natural, y cada tipo de objeto expone una interfaz a otros objetos que especifica
cómo pueden interactuar con los objetos de la clase. El aislamiento protege a las
propiedades de un objeto contra su modificación por quien no tenga derecho a
acceder a ellas, solamente los propios métodos internos del objeto pueden acceder a
su estado. Esto asegura que otros objetos no pueden cambiar el estado interno de un
objeto de maneras inesperadas, eliminando efectos secundarios e interacciones
inesperadas. Algunos lenguajes relajan esto, permitiendo un acceso directo a los



datos internos del objeto de una manera controlada y limitando el grado de
abstracción. La aplicación entera se reduce a un agregado o rompecabezas de
objetos.
Polimorfismo: comportamientos diferentes, asociados a objetos distintos, pueden
compartir el mismo nombre, al llamarlos por ese nombre se utilizará el
comportamiento correspondiente al objeto que se esté usando. O dicho de otro
modo, las referencias y las colecciones de objetos pueden contener objetos de
diferentes tipos, y la invocación de un comportamiento en una referencia producirá
el comportamiento correcto para el tipo real del objeto referenciado. Cuando esto
ocurre en "tiempo de ejecución", esta última característica se llama asignación
tardía o asignación dinámica. Algunos lenguajes proporcionan medios más
estáticos (en "tiempo de compilación") de polimorfismo, tales como las plantillas y
la sobrecarga de operadores de C++.
Herencia: las clases no están aisladas, sino que se relacionan entre sí, formando una
jerarquía de clasificación. Los objetos heredan las propiedades y el comportamiento
de todas las clases a las que pertenecen. La herencia organiza y facilita el
polimorfismo y el encapsulamiento permitiendo a los objetos ser definidos y
creados como tipos especializados de objetos preexistentes. Estos pueden compartir
(y extender) su comportamiento sin tener que volver a implementarlo. Esto suele
hacerse habitualmente agrupando los objetos en clases y estas en árboles o
enrejados que reflejan un comportamiento común. Cuando un objeto hereda de más
de una clase se dice que hay herencia múltiple.
Recolección de basura: la recolección de basura o garbage collector es la técnica
por la cual el entorno de objetos se encarga de destruir automáticamente, y por tanto
desvincular la memoria asociada, los objetos que hayan quedado sin ninguna
referencia a ellos. Esto significa que el programador no debe preocuparse por la
asignación o liberación de memoria, ya que el entorno la asignará al crear un nuevo
objeto y la liberará cuando nadie lo esté usando. En la mayoría de los lenguajes
híbridos que se extendieron para soportar el Paradigma de Programación Orientada
a Objetos como C++ u Object Pascal, esta característica no existe y la memoria
debe desasignarse manualmente.
[editar] Resumen
La programación orientada a objetos es un paradigma que utiliza objetos como elementos
fundamentales en la construcción de la solución. Surge en los años 70. Un objeto es una
abstracción de algún hecho o ente del mundo real que tiene atributos que representan sus
características o propiedades y métodos que representan su comportamiento o acciones que
realizan. Todas las propiedades y métodos comunes a los objetos se encapsulan o se
agrupan en clases. Una clase es una plantilla o un prototipo para crear objetos, por eso se
dice que los objetos son instancias de clases.
[editar] Lenguajes orientados a objetos
Simula (1967) es aceptado como el primer lenguaje que posee las características principales
de un lenguaje orientado a objetos. Fue creado para hacer programas de simulación, en
donde los "objetos" son la representación de la información más importante. Smalltalk
(1972 a 1980) es posiblemente el ejemplo canónico, y con el que gran parte de la teoría de
la programación orientada a objetos se ha desarrollado.
Entre los lenguajes orientados a objetos se destacan los siguientes:




































ABAP
ABL Lenguaje de programación de OpenEdge de Progress Software
ActionScript
ActionScript 3
Ada
C++
C#
Clarion
Clipper (lenguaje de programación) (Versión 5.x con librería de objetos Class(y))
D
Object Pascal (Embarcadero Delphi)
Gambas
Harbour
Eiffel
Java
JavaScript (la herencia se realiza por medio de la programación basada en
prototipos)
Lexico (en castellano)
Objective-C
Ocaml
Oz
R
Perl (soporta herencia múltiple. La resolución se realiza en preorden, pero puede
modificarse al algoritmo linearization C3 por medio del módulo Class::C3 en
CPAN)
PHP (a partir de su versión 5)
PowerBuilder
Python
Ruby
Smalltalk (Entorno de objetos puro)
Magik (SmallWorld)
Vala
VB.NET
Visual FoxPro (en su versión 6)
Visual Basic 6.0
Visual Objects
XBase++
Lenguaje DRP
Lenguaje de programación Scala (lenguaje usado por Twitter) http://www.scalalang.org/page.jsp
Muchos de estos lenguajes de programación no son puramente orientados a objetos, sino
que son híbridos que combinan la POO con otros paradigmas.
Al igual que C++ otros lenguajes, como OOCOBOL, OOLISP, OOPROLOG y Object
REXX, han sido creados añadiendo extensiones orientadas a objetos a un lenguaje de
programación clásico.
Un nuevo paso en la abstracción de paradigmas de programación es la Programación
Orientada a Aspectos (POA). Aunque es todavía una metodología en estado de maduración,
cada vez atrae a más investigadores e incluso proyectos comerciales en todo el mundo.
Sistemas de Procesamiento de Datos
INTRODUCCION
Actualmente una de las áreas más candentes en la industria y en el ámbito académico es la
orientación a objetos. La orientación a objetos promete mejoras de amplio alcance en la
forma de diseño, desarrollo y mantenimiento del software ofreciendo una solución a largo
plazo a los problemas y preocupaciones que han existido desde el comienzo en el desarrollo
de software: la falta de portabilidad del código y reusabilidad, código que es dificil de
modificar, ciclos de desarrollo largos y tecnicas de codificacion no intuituvas.
Un lenguaje orientado a objetos ataca estos problemas. Tiene tres características basicas:
debe estar basado en objetos, basado en clases y capaz de tener herencia de clases. Muchos
lenguajes cumplen uno o dos de estos puntos; muchos menos cumplen los tres. La barrera
más difícil de sortear es usualmente la herencia.
El concepto de programación orientada a objetos (OOP) no es nuevo, lenguajes clásicos
como SmallTalk se basan en ella. Dado que la OOP. se basa en la idea natural de la
existencia de un mundo lleno de objetos y que la resolución del problema se realiza en
términos de objetos, un lenguaje se dice que está basado en objetos si soporta objetos como
una característica fundamental del mismo.
El elemento fundamental de la OOP es, como su nombre lo indica, el objeto. Podemos
definir un objeto como un conjunto complejo de datos y programas que poseen
estructura y forman parte de una organización.
Esta definición especifica varias propiedades importantes de los objetos. En primer lugar,
un objeto no es un dato simple, sino que contiene en su interior cierto número de
componentes bién estructurados. En segundo lugar, cada objeto no es un ente aislado, sino
que forma parte de una organización jerárquica o de otro tipo.
ESTRUCTURA DE UN OBJETO
Un objeto puede considerarse como una especie de cápsula dividida en tres partes:
1 - RELACIONES
2 - PROPIEDADES
3 - METODOS
Cada uno de estos componentes desempeña un papel totalmente independiente:
Las relaciones permiten que el objeto se insterte en la organización y están formadas
esencialmente por punteros a otros objetos.
Las propiedades distinguen un objeto determinado de los restantes que forman parte de la
misma organización y tiene valores que dependen de la propiedad de que se trate. Las
propiedades de un objeto pueden ser heredadas a sus descendientes en la organización.
Los métodos son las operaciones que pueden realizarse sobre el objeto, que normalmente
estarán incorporados en forma de programas (código) que el objeto es capaz de ejecutar y
que también pone a disposición de sus descendientes a través de la herencia.
Encapsulamiento y ocultación
Como hemos visto, cada objeto es una estructura compleja en cuyo interior hay datos y
programas, todos ellos relacionados entre sí, como si estuvieran encerrados conjuntamente
en una cápsula. Esta propiedad (encapsulamiento), es una de las características
fundamentales en la OOP.
Los objetos son inaccesibles, e impiden que otros objetos, los usuarios, o incluso los
programadores conozcan cómo está distribuída la información o qué información hay
disponible. Esta propiedad de los objetos se denomina ocultación de la información.
Esto no quiere decir, sin embargo, que sea imposible conocer lo necesario respecto a un
objeto y a lo que contiene. Si así fuera no se podría hacer gran cosa con él. Lo que sucede
es que las peticiones de información a un objeto. deben realizarse a través de mensajes
dirigidos a él, con la orden de realizar la operación pertinente. La respuesta a estas ordenes
será la información requerida, siempre que el objeto considere que quien envía el mensaje
está autorizado para obtenerla.
El hecho de que cada objeto sea una cápsula facilita enormemente que un objeto
determinado pueda ser transportado a otro punto de la organización, o incluso a otra
organización totalmente diferente que precise de él. Si el objeto ha sido bien construído,
sus métodos seguirán funcionando en el nuevo entorno sin problemas. Esta cualidad hace
que la OOP sea muy apta para la reutilización de programas.
Organización de los objetos
En principio, los objetos forman siempre una organización jerárquica, en el sentido de que
ciertos objetos son superiores a otros de cierto modo.
Existen varios tipos tipos de jerarquías: serán simples cuando su estructura pueda ser
representada por medio de un "arbol". En otros casos puede ser más compleja.
En cualquier caso, sea la estructura simple o compleja, podrán distinguirse en ella tres
niveles de objetos.
-La raíz de la jerarquía. Se trata de un objeto único y especial. Este se caracteríza por estar
en el nivel más alto de la estructura y suele recibir un nombre muy genérico, que indica su
categoría especial, como por ejemplo objeto madre, Raíz o Entidad.
-Los objetos intermedios. Son aquellos que descienden directamente de la raíz y que a su
vez tienen descendientes. Representan conjuntos o clases de objetos, que pueden ser muy
generales o muy especializados, según la aplicación. Normalmente reciben nombres
genéricos que denotan al conjunto de objetos que representan, por ejemplo, VENTANA,
CUENTA, FICHERO. En un conjunto reciben el nombre de clases o tipos si descienden de
otra clase o subclase.
-Los objetos terminales. Son todos aquellos que descienden de una clase o subclase y no
tienen descendientes. Suelen llamarse casos particulares, instancias o ítems porque
representan los elementos del conjunto representado por la clase o subclase a la que
pertenecen.
Veamos ahora en detalle los tres elementos mencionados en "Estructura de un Objeto".
1. RELACIONES
Las relaciones entre objetos son, precisamente, los enlaces que permiten a un objeto
relacionarse con aquellos que forman parte de la misma organización.
Las hay de dos tipos fundamentales:
-Relaciones jerárquicas. Son esenciales para la existencia misma de la aplicación porque la
construyen. Son bidireccionales, es decir, un objeto es padre de otro cuando el primer
objeto se encuentra situado inmediatamente encima del segundo en la organización en la
que ambos forman parte; asimismo, si un objeto es padre de otro, el segundo es hijo del
primero (en la fig. 2, B es padre de D,E y F, es decir, D,E y F son hijos de B; en la fig. 3,
los objetos B y C son padres de F, que a su vez es hijo de ambos).
Una organización jerárquica simple puede definirse como aquella en la que un objeto puede
tener un solo padre, mientras que en una organizacion jerárquica compleja un hijo puede
tener varios padres).
-Relaciones semánticas. Se refieren a las relaciones que no tienen nada que ver con la
organización de la que forman parte los objetos que las establecen. Sus propiedades y
consecuencia solo dependen de los objetos en sí mismos (de su significado) y no de su
posición en la organización.
Se puede ver mejor con un ejemplo: supongamos que vamos a construir un diccionario
informatizado que permita al usuario obtener la definición de una palabra cualquiera.
Supongamos que, en dicho diccionario, las palabras son objetos y que la organización
jerárquica es la que proviene de forma natural de la estructura de nuestros conocimientos
sobre el mundo.
La raíz del diccionario podría llamarse TEMAS. De éste término genérico descenderán tres
grandes ramas de objetos llamadas VIDA, MUNDO y HOMBRE. El primero (vida)
comprenderá las ciencias biológicas: Biología y Medicina. El segundo (mundo), las
ciencias de la naturaleza inerte: las Matemáticas, la Física, la Química y la Geología. El
tercero (hombre) comprenderá las ciencias humanas: la Geografía, la Historia, etc.
Veamos un ejemplo: estableceremos la relación trabajo entre los objetos NEWTON y
OPTICA y la interpretaremos diciendo que significa que Newton trabajó en óptica (véase
la fig. 4). La relación es, evidentemente, semántica, pués no establece ninguna connotación
jerárquica entre NEWTON y OPTICA y su interpretación depende exclusivamente del
significado de ambos objetos.
La existencia de esta relación nos permitirá responder a preguntas como:
¿Quién trabajó en óptica?
¿En qué trabajó Newton?
¿Quien trabajó en Física?
Las dos primeras se deducen inmediatamente de la existencia de la relación trabajo. Para la
tercera observamos que si Newton trabajó en óptica automáticamente sabemos que trabajó
en Física, por ser óptica una rama de la Física (en nuestro diccionario, el objeto OPTICA es
hijo del objeto FISICA). Entonces gracias a la OOP podemos responder a la tercera
pregunta sin necesidad de establecer una relación entre NEWTON y FISICA, apoyandonos
sólo en la relación definida entre NEWTON y OPTICA y en que OPTICA es hijo de
FISICA. De este modo se elimina toda redundancia innecesaria y la cantidad de
información que tendremos que definir para todo el diccionario será mínima.
2. PROPIEDADES
Todo objeto puede tener cierto número de propiedades, cada una de las cuales tendrá, a su
vez, uno o varios valores. En OOP, las propiedades corresponden a las clásicas "variables"
de la programación estructurada. Son, por lo tanto, datos encapsulados dentro del objeto,
junto con los métodos (programas) y las relaciones (punteros a otros objetos). Las
propiedades de un objeto pueden tener un valor único o pueden contener un conjunto de
valores mas o menos estructurados (matrices, vectores, listas, etc.). Además, los valores
pueden ser de cualquier tipo (numérico, alfabético, etc.) si el sistema de programación lo
permite.
Pero existe una diferencia con las "variables", y es que las propiedades se pueden heredar
de unos objetos a otros. En consecuencia, un objeto puede tener una propiedad de maneras
diferentes:
-Propiedades propias. Están formadas dentro de la cápsula del objeto.
-Propiedades heredadas. Estan definidas en un objeto diferente, antepasado de éste
(padre,"abuelo", etc.). A veces estas propiedades se llaman propiedades miembro porque
el objeto las posee por el mero hecho de ser miembro de una clase.
3. METODOS
Una operación que realiza acceso a los datos. Podemos definir método como un programa
procedimental o procedural escrito en cualquier lenguaje, que está asociado a un objeto
determinado y cuya ejecución sólo puede desencadenarse a través de un mensaje recibido
por éste o por sus descendientes.
Son sinónimos de 'método' todos aquellos términos que se han aplicado tradicionalmente a
los programas, como procedimiento, función, rutina, etc. Sin embargo, es conveniente
utilizar el término 'método' para que se distingan claramente las propiedades especiales que
adquiere un programa en el entorno OOP, que afectan fundamentalmente a la forma de
invocarlo (únicamente a través de un mensaje) y a su campo de acción, limitado a un objeto
y a sus descendientes, aunque posiblemente no a todos.
Si los métodos son programas, se deduce que podrían tener argumentos, o parámetros.
Puesto que los métodos pueden heredarse de unos objetos a otros, un objeto puede disponer
de un método de dos maneras diferentes:
-Métodos propios. Están incluídos dentro de la cápsula del objeto.
-Métodos heredados. Estan definidos en un objeto diferente, antepasado de éste
(padre,"abuelo", etc.). A veces estos métodos se llaman métodos miembro porque el
objeto los posee por el mero hecho de ser miembro de una clase.
Polimorfísmo
Una de las características fundamentales de la OOP es el polimorfísmo, que no es otra cosa
que la posibilidad de construir varios métodos con el mismo nombre, pero con relación a la
clase a la que pertenece cada uno, con comportamientos diferentes. Esto conlleva la
habilidad de enviar un mismo mensaje a objetos de clases diferentes. Estos objetos
recibirían el mismo mensaje global pero responderían a él de formas diferentes; por
ejemplo, un mensaje "+" a un objeto ENTERO significaría suma, mientras que para un
objeto STRING significaría concatenación ("pegar" strings uno seguido al otro)
Demonios
Es un tipo especial de métodos, relativamente poco frecuente en los sistemas de OOP, que
se activa automáticamente cuando sucede algo especial. Es decir, es un programa, como los
métodos ordinarios, pero se diferencia de estos porque su ejecución no se activa con un
mensaje, sino que se desencadena autmáticamente cuando ocurre un suceso determinado: la
asignación de un valor a una propiedad de un objeto, la lectura de un valor determinado,
etc.
Los demonios, cuando existen, se diferencian de otros métodos por que no son heredables y
porque a veces están ligados a una de las propiedades de un objeto, mas que al objeto
entero.
CONSIDERACIONES FINALES
Beneficios que se obtienen del desarrollo con OOP
Día a día los costos del Hardware decrecen. Así surgen nuevas áreas de aplicación
cotidianamente: procesamiento de imágenes y sonido, bases de datos multimediales,
automatización de oficinas, ambientes de ingeniería de software, etc. Aún en las
aplicaciones tradicionales encontramos que definir interfases hombre-máquina "a-laWindows" suele ser bastante conveniente.
Lamentablemente, los costos de producción de software siguen aumentando; el
mantenimiento y la modificación de sistemas complejos suele ser una tarea trabajosa; cada
aplicación, (aunque tenga aspectos similares a otra) suele encararse como un proyecto
nuevo, etc.
Todos estos problemas aún no han sido solucionados en forma completa. Pero como los
objetos son portables (teóricamente) mientras que la herencia permite la reusabilidad del
código orientado a objetos, es más sencillo modificar código existente porque los objetos
no interaccionan excepto a través de mensajes; en consecuencia un cambio en la
codificación de un objeto no afectará la operación con otro objeto siempre que los métodos
respectivos permanezcan intactos. La introducción de tecnología de objetos como una
herramienta concepual para analizar, diseñar e implementar aplicaciones permite obtener
aplicaciones más modificables, fácilmente extendibles y a partir de componentes reusables.
Esta reusabilidad del código disminuye el tiempo que se utiliza en el desarrollo y hace que
el desarrollo del software sea mas intuitivo porque la gente piensa naturalmente en términos
de objetos más que en términos de algoritmos de software.
Problemas derivados de la utilización de OOP en la actualidad
Un sistema orientado a objetos, por lo visto, puede parecer un paraíso virtual. El problema
sin embargo surge en la implementación de tal sistema. Muchas compañías oyen acerca de
los beneficios de un sistema orientado a objetos e invierten gran cantidad de recursos luego
comienzan a darse cuenta que han impuesto una nueva cultura que es ajena a los
programadores actuales. Específicamente los siguientes temas suelen aparecer
repetidamente:
Curvas de aprendizaje largas. Un sistema orientado a objetos ve al mundo en una forma
única. Involucra la conceptualización de todos los elementos de un programa, desde
subsistemas a los datos, en la forma de objetos. Toda la comunicación entre los objetos
debe realizarse en la forma de mensajes. Esta no es la forma en que están escritos los
programas orientados a objetos actualmente; al hacer la transición a un sistema orientado a
objetos la mayoría de los programadores deben capacitarse nuevamente antes de poder
usarlo.
Dependencia del lenguaje. A pesar de la portabilidad conceptual de los objetos en un
sistema orientado a objetos, en la práctica existen muchas dependencias. Muchos lenguajes
orientados a objetos están compitiendo actualmente para dominar el mercado. Cambiar el
lenguaje de implementación de un sistema orientado a objetos no es una tarea sencilla; por
ejemplo C++ soporta el concepto de herencia multiple mientras que SmallTalk no lo
soporta; en consecuencia la elección de un lenguaje tiene ramificaciones de diseño muy
importamtes.
Determinacion de las clases. Una clase es un molde que se utiliza para crear nuevos
objetos. En consecuencia es importante crear el conjunto de clases adecuado para un
proyecto. Desafortunadamente la definición de las clases es más un arte que una ciencia. Si
bien hay muchas jerarquías de clase predefinidas usualmente se deben crear clases
específicas para la aplicación que se este desarrollando. Luego, en 6 meses ó 1 año se da
cuenta que las clases que se establecieron no son posibles; en ese caso será necesario
reestructurar la jerarquía de clases devastando totalmente la planificación original.
Performance. En un sistema donde todo es un objeto y toda interaccion es a través de
mensajes, el tráfico de mensajes afecta la performance. A medida que la tecnología avanza
y la velocidad de microprocesamiento, potencia y tamaño de la memoria aumentan, la
situacion mejorará; pero en la situación actual, un diseño de una aplicación orientada a
objetos que no tiene en cuenta la performance no será viable comercialmente.
Idealmente, habría una forma de atacar estos problemas eficientemente al mismo tiempo
que se obtienen los beneficios del desarrollo de una estrategia orientada a objetos. Deberia
existir una metodología fácil de aprender e independiente del lenguaje, y facil de
reestructurar que no drene la performance del sistema .
Bibliografía consultada
Revista COMPU MAGAZINE, Número 51, Octubre '92
Revista COMPU MAGAZINE, Número 50, Septiembre '92
(y diversos apuntes conseguidos de distintas publicaciones)
Programación orientada a objetos
Índice
1. Tecnología orientada a objetos
1. Una Perspectiva Histórica
2. ¿Cuáles son las ventajas de un lenguaje orientado a objetos?
2. El modelo orientado a objetos
1. Objetos
2. Clases
3. Herencia
4. Envío de mensajes
3. Características asociadas a la POO
1. Abstracción
2. Encapsulamiento
3. Ocultamiento
4. Lenguajes de programación orientado a objetos
5. Análisis y diseño orientado a objetos
6. Resumen
Tecnología orientada a objetos
Hoy en día la tecnología orientada a objetos ya no se aplica solamente a los lenguajes de
programación, además se viene aplicando en el análisis y diseño con mucho éxito, al igual
que en las bases de datos. Es que para hacer una buena programación orientada a objetos
hay que desarrollar todo el sistema aplicando esta tecnología, de ahí la importancia del
análisis y el diseño orientado a objetos.
La programación orientada a objetos es una de las formas más populares de programar y
viene teniendo gran acogida en el desarrollo de proyectos de software desde los últimos
años. Esta acogida se debe a sus grandes capacidades y ventajas frente a las antiguas formas
de programar.
Una Perspectiva Histórica
Tradicionalmente, la programación fue hecha en una manera secuencial o lineal, es decir
una serie de pasos consecutivos con estructuras consecutivas y bifurcaciones.
Los lenguajes basados en esta forma de programación ofrecían ventajas al principio, pero el
problema ocurre cuando los sistemas se vuelven complejos. Estos programas escritos al
estilo “espaguetti” no ofrecen flexibilidad y el mantener una gran cantidad de líneas de
código en sólo bloque se vuelve una tarea complicada.
Frente a esta dificultad aparecieron los lenguajes basados en la programación estructurada.
La idea principal de esta forma de programación es separar las partes complejas del
programa en módulos o segmentos que sean ejecutados conforme se requieran. De esta
manera tenemos un diseño modular, compuesto por módulos independientes que puedan
comunicarse entre sí. Poco a poco este estilo de programación fue reemplazando al estilo
“espaguetti” impuesto por la programación lineal.
Entonces, vemos que la evolución que se fue dando en la programación se orientaba
siempre a ir descomponiendo más el programa. Este tipo de descomposición conduce
directamente a la programación orientada a objetos.
Pues la creciente tendencia de crear programas cada vez más grandes y complejos llevó a
los desarrolladores a crear una nueva forma de programar que les permita crear sistemas de
niveles empresariales y con reglas de negocios muy complejas. Para estas necesidades ya
no bastaba la programación estructurada ni mucho menos la programación lineal. Es así
como aparece la programación orientada a objetos (POO). La POO viene de la evolución de
la programación estructurada; básicamente la POO simplifica la programación con la nueva
filosofía y nuevos conceptos que tiene. La POO se basa en la dividir el programa en
pequeñas unidades lógicas de código. A estas pequeñas unidades lógicas de código se les
llama objetos. Los objetos son unidades independientes que se comunican entre ellos
mediante mensajes. Veamos con mayor detenimiento este tema.
¿Cuáles son las ventajas de un lenguaje orientado a objetos?








Fomenta la reutilización y extensión del código.
Permite crear sistemas más complejos.
Relacionar el sistema al mundo real.
Facilita la creación de programas visuales.
Construcción de prototipos
Agiliza el desarrollo de software
Facilita el trabajo en equipo
Facilita el mantenimiento del software
Lo interesante de la POO es que proporciona conceptos y herramientas con las cuales se
modela y representa el mundo real tan fielmente como sea posible.
El modelo Orientado a Objetos
Para entender este modelo vamos a revisar 4 conceptos básicos:




Objetos
Clases
Herencia
Envío de mensajes
1. Objetos
Entender que es un objeto es la clave para entender cualquier lenguaje orientado a objetos.
Existen muchas definiciones que se le ha dado al Objeto. Primero empecemos entendiendo
que es un objeto del mundo real. Un objeto del mundo real es cualquier cosa que vemos a
nuestro alrededor. Digamos que para leer este artículo lo hacemos a través del monitor y
una computadora, ambos son objetos, al igual que nuestro teléfono celular, un árbol o un
automóvil.
Analicemos un poco más a un objeto del mundo real, como la computadora. No
necesitamos ser expertos en hardware para saber que una computadora está compuesta
internamente por varios componentes: la tarjeta madre, el chip del procesador, un disco
duro, una tarjeta de video, y otras partes más. El trabajo en conjunto de todos estos
componentes hace operar a una computadora.
Internamente, cada uno de estos componentes puede ser sumamente complicado y puede
ser fabricado por diversas compañías con diversos métodos de diseño. Pero nosotros no
necesitamos saber cómo trabajan cada uno de estos componentes, como saber que hace
cada uno de los chips de la tarjeta madre, o cómo funciona internamente el procesador.
Cada componente es una unidad autónoma, y todo lo que necesitamos saber de adentro es
cómo interactúan entre sí los componentes, saber por ejemplo si el procesador y las
memorias son compatibles con la tarjeta madre, o conocer donde se coloca la tarjeta de
video. Cuando conocemos como interaccionan los componentes entre sí, podremos armar
fácilmente una computadora.
¿Que tiene que ver esto con la programación? La programación orientada a objetos trabaja
de esta manera. Todo el programa está construido en base a diferentes componentes
(Objetos), cada uno tiene un rol específico en el programa y todos los componentes pueden
comunicarse entre ellos de formas predefinidas.
Todo objeto del mundo real tiene 2 componentes: características y comportamiento.
Por ejemplo, los automóviles tienen características (marca, modelo, color, velocidad
máxima, etc.) y comportamiento (frenar, acelerar, retroceder, llenar combustible, cambiar
llantas, etc.).
Los Objetos de Software, al igual que los objetos del mundo real, también tienen
características y comportamientos. Un objeto de software mantiene sus características en
una o más "variables", e implementa su comportamiento con "métodos". Un método es una
función o subrutina asociada a un objeto.
Para redondear estas ideas, imaginemos que tenemos estacionado en nuestra cochera un
Ford Focus color azul que corre hasta 260 km/h. Si pasamos ese objeto del mundo real al
mundo del software, tendremos un objeto Automóvil con sus características
predeterminadas:
Marca = Ford
Modelo = Focus
Color = Azul
Velocidad Máxima = 260 km/h
Cuando a las características del objeto le ponemos valores decimos que el objeto tiene
estados. Las variables almacenan los estados de un objeto en un determinado momento.
Definición teórica: Un objeto es una unidad de código compuesto de variables y métodos
relacionados.
2. Las Clases
En el mundo real, normalmente tenemos muchos objetos del mismo tipo. Por ejemplo,
nuestro teléfono celular es sólo uno de los miles que hay en el mundo. Si hablamos en
términos de la programación orientada a objetos, podemos decir que nuestro objeto celular
es una instancia de una clase conocida como "celular". Los celulares tienen características
(marca, modelo, sistema operativo, pantalla, teclado, etc.) y comportamientos (hacer y
recibir llamadas, enviar mensajes multimedia, transmisión de datos, etc.).
Cuando se fabrican los celulares, los fabricantes aprovechan el hecho de que los celulares
comparten esas características comunes y construyen modelos o plantillas comunes, para
que a partir de esas se puedan crear muchos equipos celulares del mismo modelo. A ese
modelo o plantilla le llamamos CLASE, y a los equipos que sacamos a partir de ella la
llamamos OBJETOS.
Esto mismo se aplica a los objetos de software, se puede tener muchos objetos del mismo
tipo y mismas características.
Definición teórica: La clase es un modelo o prototipo que define las variables y métodos
comunes a todos los objetos de cierta clase. También se puede decir que una clase es una
plantilla genérica para un conjunto de objetos de similares características.
Por otro lado, una instancia de una clase es otra forma de llamar a un objeto. En realidad no
existe diferencia entre un objeto y una instancia. Sólo que el objeto es un término más
general, pero los objetos y las instancias son ambas representación de una clase.
Definición Teórica: Una instancia es un objeto de una clase en particular.
3. Herencia
La herencia es uno de los conceptos más cruciales en la POO. La herencia básicamente
consiste en que una clase puede heredar sus variables y métodos a varias subclases (la clase
que hereda es llamada superclase o clase padre). Esto significa que una subclase, aparte de
los atributos y métodos propios, tiene incorporados los atributos y métodos heredados de la
superclase. De esta manera se crea una jerarquía de herencia.
Por ejemplo, imaginemos que estamos haciendo el análisis de un Sistema para una tienda
que vende y repara equipos celulares.
En el gráfico vemos 2 Clases más que posiblemente necesitemos para crear nuestro
Sistema. Esas 2 Clases nuevas se construirán a partir de la Clase Celular existente. De esa
forma utilizamos el comportamiento de la SuperClase.
En general, podemos tener una gran jerarquía de Clases tal y como vemos en el siguiente
gráfico:
4. Envío de Mensajes
Un objeto es inútil si está aislado. El medio empleado para que un objeto interactúe con
otro son los mensajes. Hablando en términos un poco más técnicos, los mensajes son
invocaciones a los métodos de los objetos.
Características asociadas al POO
Abstracción
La abstracción consiste en captar las características esenciales de un objeto, así como su
comportamiento. Por ejemplo, volvamos al ejemplo de los automóviles, ¿Qué
características podemos abstraer de los automóviles? O lo que es lo mismo ¿Qué
características semejantes tienen todos los automóviles? Todos tendrán una marca, un
modelo, número de chasis, peso, llantas, puertas, ventanas, etc. Y en cuanto a su
comportamiento todos los automóviles podrán acelerar, frenar, retroceder, etc.
En los lenguajes de programación orientada a objetos, el concepto de Clase es la
representación y el mecanismo por el cual se gestionan las abstracciones.
Por ejemplo, en Java tenemos:
public class Automovil {
// variables
// métodos
}
Encapsulamiento
El encapsulamiento consiste en unir en la Clase las características y comportamientos, esto
es, las variables y métodos. Es tener todo esto es una sola entidad. En los lenguajes
estructurados esto era imposible. Es evidente que el encapsulamiento se logra gracias a la
abstracción y el ocultamiento que veremos a continuación.
La utilidad del encapsulamiento va por la facilidad para manejar la complejidad, ya que
tendremos a las Clases como cajas negras donde sólo se conoce el comportamiento pero no
los detalles internos, y esto es conveniente porque nos interesará será conocer qué hace la
Clase pero no será necesario saber cómo lo hace.
Ocultamiento
Es la capacidad de ocultar los detalles internos del comportamiento de una Clase y exponer
sólo los detalles que sean necesarios para el resto del sistema.
El ocultamiento permite 2 cosas: restringir y controlar el uso de la Clase. Restringir porque
habrá cierto comportamiento privado de la Clase que no podrá ser accedido por otras
Clases. Y controlar porque daremos ciertos mecanismos para modificar el estado de nuestra
Clase y es en estos mecanismos dónde se validarán que algunas condiciones se cumplan.
En Java el ocultamiento se logra usando las palabras reservadas: public, private y protected
delante de las variables y métodos.
Lenguajes de Programación Orientado a Objetos
En 1985, E. Stroustrup extendió el lenguaje de programación C a C++, es decir C con
conceptos de clases y objetos, también por esas fechas se creo desde sus bases el lenguaje
EIFFEL.
En 1995 apareció el más reciente lenguaje OO, Java desarrollado por SUN, que hereda
conceptos de C++.
El lenguaje de desarrollo más extendido para aplicaciones Web, el PHP 5, trae todas las
características necesarias para desarrollar software orientado a objetos.
Además de otros lenguajes que fueron evolucionando, como el Pascal a Delphi.
Finalmente también otros lenguajes script como el ActionScript que si bien no es
totalmente orientado a objetos pero sí posee las características.
Análisis y diseño Orientado a Objetos
Para el desarrollo de software orientado a objetos no basta usar un lenguaje orientado a
objetos. También se necesitará realizar un análisis y diseño orientado a objetos.
El modelamiento visual es la clave para realizar el análisis OO. Desde los inicios del
desarrollo de software OO han existido diferentes metodologías para hacer esto del
modelamiento, pero sin lugar a duda, el Lenguaje de Modelamiento Unificado (UML) puso
fin a la guerra de metodologías.
Según los mismos diseñadores del lenguaje UML, éste tiene como fin modelar cualquier
tipo de sistemas (no solamente de software) usando los conceptos de la orientación a
objetos. Y además, este lenguaje debe ser entendible para los humanos y máquinas.
Actualmente en la industria del desarrollo de software tenemos al UML como un estándar
para el modelamiento de sistemas OO. Fue la empresa Racional que creó estas definiciones
y especificaciones del estándar UML, y lo abrió al mercado. La misma empresa creó uno de
los programas más conocidos hoy en día para este fin; el Racional Rose, pero también
existen otros programas como el Poseidon que trae licencias del tipo community edition
que permiten su uso libremente.
El UML consta de todos los elementos y diagramas que permiten modelar los sistemas en
base al paradigma orientado a objetos. Los modelos orientados a objetos cuando se
construyen en forma correcta, son fáciles de comunicar, cambiar, expandir, validar y
verificar. Este modelamiento en UML es flexible al cambio y permite crear componentes
plenamente reutilizables.
Resumen









¿Por qué seguimos buscando nuevas técnicas de desarrollo? Por el aumento de la
complejidad de los sistemas.
En un programa orientado a objetos tendremos a un conjunto de objetos colaborando
entre ellos.
La orientación a objetos es paradigma de que está de moda para el desarrollo de software.
Un objeto es una abstracción conceptual del mundo real que se puede traducir a un
lenguaje de programación orientado a objetos.
Un objeto del mundo real tiene características y comportamientos, y de la misma manera,
un objeto del mundo del software tiene variables y métodos.
Una Clase es una plantilla que define las variables y métodos a ser incluidas en un tipo de
objeto específico.
Los objetos también son llamados instancias de la Clase. Los objetos sólo almacenan su
estado. De dice que un objeto tiene estado cuando tiene valores en sus variables.
Los objetos se comunican entre ellos usando los mensajes. Un mensaje es la invocación de
un método del objeto.
La orientación a objetos requiere de una metodología que integre el proceso de desarrollo
y un lenguaje de modelamiento con herramientas y técnicas adecuadas.
Metodología de desarrollo de software en ingeniería de software es un marco de
trabajo usado para estructurar, planificar y controlar el proceso de desarrollo en sistemas
de información.1
Tres patrones básicos en las metodologías de desarrollo de software.
Contenido
[ocultar]

1 Introducción

2 Historia

3 Metodologías de desarrollo de software

4 Enfoques de desarrollo de software
o
4.1 Modelo en cascada
o
4.2 Prototipado
o
4.3 Incremental
o
4.4 Espiral
o
4.5 Rapid Application Development (RAD)
o
4.6 Otros enfoques de desarrollo de software

5 Referencia
[editar]Introducción
Una metodología de desarrollo de software se refiere a un framework que es usado para
estructurar, planear y controlar el proceso de desarrollo en sistemas de información.
A lo largo del tiempo, una gran cantidad de métodos han sido desarrollados
diferenciándose por su fortaleza y debilidad.
El framework para metodología de desarrollo de software consiste en:

Una filosofía de desarrollo de programas de computacion con el enfoque del proceso
de desarrollo de software

Herramientas, modelos y métodos para asistir al proceso de desarrollo de software
Estos frameworks son a menudo vinculados a algún tipo de organización, que además
desarrolla, apoya el uso y promueve la metodología. La metodología es a menudo
documentada en algún tipo de documentación formal.
[editar]Historia
El desarrollo de los sistemas tradicionales de ciclo de vida se originó en la década de
1960 para desarrollar a gran escala funcional de sistemas de negocio en una época de
grandes conglomerados empresariales. La idea principal era continuar el desarrollo de los
sistemas de información en una muy deliberada, estructurada y metódica, reiterando cada
una de las etapas del ciclo de vida. Los sistemas de información en torno a las actividades
resueltas pesadas para el procesamiento de datos y rutinas de cálculo.
[editar]Metodologías
de desarrollo de software
1970s

Programación estructurada sol desde 1969

Programación estructurada Jackson desde 1975
1980s

Structured Systems Analysis and Design Methodology (SSADM) desde 1980

Structured Analysis and Design Technique (SADT) desde 1980

Ingeniería de la información (IE/IEM) desde 1981
1990s

Rapid application development (RAD) desde 1991.

Programación orientada a objetos (OOP) a lo largo de la década de los 90's

Virtual finite state machine (VFSM) desde 1990s

Dynamic Systems Development Method desarrollado en UK desde 1995.

Scrum (desarrollo), en la última parte de los 90's

Rational Unified Process (RUP) desde 1999.
Nuevo milenio

Extreme Programming(XP) desde 1999

Enterprise Unified Process (EUP) extensiones RUP desde 2002

Constructionist design methodology (CDM) desde 2004 por Kristinn R. Thórisson

Agile Unified Process (AUP) desde 2005 por Scott Ambler
[editar]Enfoques
de desarrollo de software
Cada metodología de desarrollo de software tiene más o menos su propio enfoque para
el desarrollo de software. Estos son los enfoques más generales, que se desarrollan en
varias metodologías específicas. Estos enfoques son los siguientes:1

Modelo en cascada: Framework lineal.

Prototipado: Framework iterativo.

Incremental: Combinación de framework lineal e iterativo.

Espiral: Combinación de framework lineal e iterativo.

RAD: Rapid Application Development, framework iterativo.
[editar]Modelo
en cascada
Es un proceso secuencial de desarrollo en el que los pasos de desarrollo son vistos hacia
abajo (como en una cascada de agua) a través de las fases de análisis de las
necesidades, el diseño, implementación, pruebas (validación), la integración, y
mantenimiento. La primera descripción formal del modelo de cascada se cita a menudo a
un artículo publicado por Winston Royce W.2 en 1970, aunque Royce no utiliza el término
"cascada" de este artículo.
Los principios básicos del modelo de cascada son los siguientes:1

El proyecto está dividido en fases secuenciales, con cierta superposición y splashback
aceptable entre fases.

Se hace hincapié en la planificación, los horarios, fechas, presupuestos y ejecución de
todo un sistema de una sola vez.

Un estricto control se mantiene durante la vida del proyecto a través de la utilización
de una amplia documentación escrita, así como a través de comentarios y aprobación
/ signoff por el usuario y la tecnología de la información de gestión al final de la
mayoría de las fases antes de comenzar la próxima fase.
[editar]Prototipado
El prototipado es el framework de actividades dedicada al desarrollo de software prototipo,
es decir, versiones incompletas del software a desarrollar.
[editar]Incremental
Provee una estrategia para controlar la complejidad y los riesgos, desarrollando una parte
del producto software reservando el resto de aspectos para el futuro.
Los principios básicos son:

Una serie de mini-Cascadas se llevan a cabo, donde todas las fases de la cascada
modelo de desarrollo se han completado para una pequeña parte de los sistemas,
antes de proceder a la próxima incremental

Se definen los requisitos antes de proceder con la evolutivo, se realiza un miniCascada de desarrollo de cada uno de los incrementos del sistema

El concepto inicial de software, análisis de las necesidades, y el diseño de la
arquitectura y colectiva básicas se definen utilizando el enfoque de cascada, seguida
por iterativo de prototipos, que culmina en la instalación del prototipo final.
[editar]Espiral
Los principios básicos son:

La atención se centra en la evaluación y reducción del riesgo del proyecto dividiendo
el proyecto en segmentos más pequeños y proporcionar más facilidad de cambio
durante el proceso de desarrollo, así como ofrecer la oportunidad de evaluar los
riesgos y con un peso de la consideración de la continuación del proyecto durante
todo el ciclo de vida.

Cada viaje alrededor de la espiral atraviesa cuatro cuadrantes básicos: (1) determinar
objetivos, alternativas, y desencadenantes de la iteración; (2) Evaluar alternativas;
Identificar y resolver los riesgos; (3) desarrollar y verificar los resultados de la
iteración, y (4) plan de la próxima iteración.3

Cada ciclo comienza con la identificación de los interesados y sus condiciones de
ganancia, y termina con la revisión y examinación.3
[editar]Rapid
Application Development (RAD)
El desarrollo rápido de aplicaciones (RAD) es una metodología de desarrollo de software,
que implica el desarrollo interativo y la construcción de prototipos. El desarrollo rápido de
aplicaciones es un término originalmente utilizado para describir un proceso de desarrollo
de software introducido por James Martin en 1991.
Principios básicos:

Objetivo clave es para un rápido desarrollo y entrega de una alta calidad en un
sistema de relativamente bajo coste de inversión.

Intenta reducir el riesgos inherente del proyecto partiéndolo en segmentos más
pequeños y proporcionar más facilidad de cambio durante el proceso de desarrollo.

Orientación dedicada a producir sistemas de alta calidad con rapidez, principalmente
mediante el uso de iteración por prototipos (en cualquier etapa de desarrollo),
promueve la participación de los usuarios y el uso de herramientas de desarrollo
computarizadas. Estas herramientas pueden incluir constructores de Interfaz gráfica
de usuario (GUI), Computer Aided Software Engineering (CASE) las herramientas,
los sistemas de gestión de bases de datos (DBMS), lenguajes de programación de
cuarta generación, generadores de código, y técnicas orientada a objetos.

Hace especial hincapié en el cumplimiento de la necesidad comercial, mientras que la
ingeniería tecnológica o la excelencia es de menor importancia.

Control de proyecto implica el desarrollo de prioridades y la definición de los plazos de
entrega. Si el proyecto empieza a aplazarse, se hace hincapié en la reducción de
requisitos para el ajuste, no en el aumento de la fecha límite.

En general incluye Joint application development (JAD), donde los usuarios están
intensamente participando en el diseño del sistema, ya sea a través de la creación de
consenso estructurado en talleres, o por vía electrónica.

La participación activa de los usuarios es imprescindible.

Iterativamente realiza la producción de software, en lugar de enfocarse en un
prototipo.

Produce la documentación necesaria para facilitar el futuro desarrollo y
mantenimiento.
[editar]Otros

enfoques de desarrollo de software
Metodologías de desarrollo Orientado a objetos, Diseño orientado a objetos (OOD)
de Grady Booch, también conocido como Análisis y Diseño Orientado a Objetos
(OOAD). El modelo incluye seis diagramas: de clase, objeto, estado de transición, la
interacción, módulo, y el proceso.

Top-down programming, evolucionado en la década de 1970 por el investigador
de IBM Harlan Mills (y Niklaus Wirth) en Desarrollo Estructurado.

Proceso Unificado, es una metodología de desarrollo de software, basado en UML.
Organiza el desarrollo de software en cuatro fases, cada una de ellas con la ejecución
de una o más iteraciones de desarrollo de software: creación, elaboración,
construcción, y las directrices. Hay una serie de herramientas y productos diseñados
para facilitar la aplicación. Una de las versiones más populares es la de Rational
Unified Process.
Definición de una metodología ágil de ingeniería de
requerimientos para empresas emergentes de desarrollo
de software del sur-occidente colombiano



Autores: Luis Merchán, Alba Urrea, Rubén Rebollar
Localización: Guillermo de Ockham: Revista científica, ISSN 1794-192X, Vol. 6, Nº. 1,
2008 , págs. 37-50
Títulos paralelos:
o Definition of a responsive methodology of engineering of requirements for emergent software
development companies in the southwestern part of Colombia

o

Texto completo (pdf)
o
Como industria, el software requiere de productos y servicios de alta calidad, lo cual se logra
Resumen:
mediante la aplicación de modelos y metodologías de calidad reconocidos in- ternacionalmente.
Las empresas emergentes no logran aplicar estas metodologías pues su gran obstáculo se
observa en los altos costos de implementación, el recurso humano requerido y los estándares
exigidos que restringen la creatividad, parte importante de su capital. El Laboratorio de Investigación para el Desarrollo de la Ingeniería de Software (LIDIS), siendo consecuente con esta
situación, adelantó una investigación que propone un modelo liviano de mejo- ramiento de los
procesos de desarrollo de software partiendo de la caracterización de las empresas emergentes.
o
As an industry, software requires high quality products and services, which are obtained by means
of the application of high quality models and methodologies recognized worldwide. Emergent
companies do not manage to apply these methodologies, due to the high costs of implementation,
the recruitment of a qualifi ed human resource and the demanded standards that restrict creativity,
which are an important part of their capital. & e Research Laboratory for the Development of
Software Engineering (LIDIS), as a response to this situation, carried out an investigation that
proposes a light model of improvement of the software development processes, starting off from the
characterization of emergent companies.
************************************