CAPITULO
II
2.1 ANTECEDENTES DE LA ORGANIZACIÓN
2.2 PARADIGMA ORIENTADO A OBJETOS
2.3 METODOLOGIAS
2.3.1 METODOLOGIA XP
2.3.2 METODOLOGIA CICLO DE VIDA
2.4 METODOLOGIA RUP
2.2.4.1 DIMENSIONES DEL RUP
2.2.4.2 FASES
A.2.1 PLANEANDO LAS FASES
A.2.2 ESFUERZO RESPECTO DE LOS FLUJOS DE TRABAJO
A.2.3 ESFUERZO RESPECTO DE LAS FASES
2.2.3.3 ITERACIONES
A.3.1 PROCESO ITERATIVO E INCREMENTAL
2.2.3.4 DISCIPLINAS
A.4.1 MODELADO DEL NEGOCIO
A.4.2 REQUERIMIENTOS
A.4.3 ANÁLISIS Y DISEÑO
A.4.4 IMPLEMENTACIÓN
A.4.5 PRUEBAS
A.4.6 DESPLIEGUE
A.4.7 GESTIÓN Y CONFIGURACIÓN DE CAMBIOS
A.4.8 GESTIÓN DEL PROYECTO
A.4.9 ENTORNO
2.2.3.5 ORGANIZACIÓN Y ELEMENTOS EN RUP
A.5.1 ACTORES Ó ROLES
A.5.2 (B) ARTEFACTOS
B.1 CONJUNTO DE ARTEFACTOS
B.2 GRADO DE FINALIZACIÓN DE ARTEFACTOS
2.3 PARADIGMA ORIENTADO A OBJETOS
2.4 UML
2.5 SISTEMAS GESTORES DE BASES DE DATOS
2.5.1 MYSQL
2.5.2 ORACLE
2.6 LENGUAJE DE PROGRAMACION
2.6.1 PHP
2.6.2 AJAX
2.6.3 JAVA2
2.1 ANTECEDENTES DE LA ORGANIZACIÓN
La programación orientada a objetos o POO (OOP según sus siglas en inglés) es un paradigma de programación que usa los objetos en sus interacciones, para diseñar aplicaciones y programas informáticos. Está basado en varias técnicas, incluyendo herencia, cohesión, abstracción, polimorfismo, acoplamiento 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.
INTRODUCCIÓN
Los objetos son entidades que tienen un determinado estado, comportamiento (método) e identidad:
- El estado está compuesto de datos o informaciones;
serán 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).
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 solo 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.
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 y 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.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 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 puedan cambiar el estado interno de un objeto de
manera inesperada, 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.
Definición
La programación extrema es una metodología de desarrollo ágil basada en una serie de valores y de prácticas de buenas maneras que persigue el objetivo de aumentar la productividad a la hora de desarrollar programas. Este modelo de programación se basa en una serie de metodologías de desarrollo de software en la que se da prioridad a los trabajos que dan un resultado directo y que reducen la burocracia que hay al rededor de la programación.
FASES DE
Existen diversas prácticas inherentes al desarrollo de software.
a) PLANIFICACIÓN
XP plantea la planificación como un permanente dialogo entre las parte
la empresarial (deseable) y la técnica (posible). Las personas del negocio
necesitan determinar:
Ámbito: ¿Qué es lo que el software debe de resolver para que este genere valor?
Prioridad: ¿Qué debe ser hecho en primer lugar?
b) DISEÑO
METÁFORA.- Una metáfora es una historia que todo el mundo puede contar a
cerca de cómo funciona el sistema. Algunas veces podremos encontrar metáforas
sencillas “Programa de gestión de compras, ventas, con gestión de cartera y almacén”. Las metáforas ayudan a cualquier persona a entender el objeto del programa.
DISEÑO SENCILLO
El diseño adecuado par el software es aquel que:
- Funciona con todas las pruebas.
- No tiene lógica duplicada.
- Manifiesta cada intención importante para los programadores
- Tiene el menor número de clases y métodos.
·
RECODIFICACIÓN
Cuando
implementamos nuevas características en nuestros programas nos planteamos la
manera de hacerlo lo mas simple posible, después de implementar esta
característica, nos preguntamos como hacer el programa mas simple sin perder
funcionalidad, este proceso se le denomina re codificar o reautorizar
(refactoring). · PROGRAMACIÓN POR PAREJAS
Todo el código de producción lo escriben dos personas frente al ordenador, con un sólo ratón y un sólo teclado. Cada miembro de la pareja juega su papel: uno codifica en el ordenador y piensa la mejor manera de hacerlo, el otro piensa más estratégicamente, ¿Va a funcionar?
Cualquiera que crea que puede aportar valor al código en cualquier parcela puede hacerlo, ningún miembro del equipo es propietario del código. Si alguien quiere hacer cambios en el código puede hacerlo. Si hacemos el código propietario, y necesitamos de su autor para que lo cambie entonces estaremos alejándonos cada vez mas de la comprensión del problema.
·
INTEGRACIÓN
CONTINÚA
El
código se debe integrar como mínimo una vez al día, y realizar las pruebas
sobre la totalidad del sistema. Una pareja de programadores se encargara de
integrar todo el código en una maquina y realizar todas las pruebas hasta que
estas funcionen al 100%.
·
40
HORAS SEMANALES
Si queremos estar frescos y motivados
cada mañana y cansado y satisfecho cada noche. El viernes quiero estar cansado
y satisfecho para sentir que tengo dos días para pensar en algo distinto y
volver el lunes lleno de pasión e ideas. Esto requiere que trabajemos 40 horas
a la semana, mucha gente no puede estar más de 35 horas concentrada a la semana,
otros pueden llegar hasta 45 pero ninguno puede llegar a 60 horas durante
varias semanas y aun seguir fresco, creativo y confiado. · CLIENTE IN-SITU
Un cliente real debe sentarse con el equipo de programadores, estar disponible para responder a sus preguntas, resolver discusiones y fijar las prioridades. Lo difícil es que el cliente nos ceda una persona que conozca el negocio para que se integre en el equipo normalmente estos elementos son muy valiosos, pero debemos de hacerles ver que será mejor para su negocio tener un software pronto en funcionamiento, y esto no implica que el cliente no pueda realizar cualquier otro trabajo.
·
ESTÁNDARES
DE CODIFICACIÓN
Si
los programadores van a estar tocando partes distintas del sistema,
intercambiando compañeros, haciendo refactoring, debemos de establecer un
estándar de codificación aceptado e implantado por todo el equipoa) PRUEBAS
No debe existir ninguna característica en el programa que no haya sido probada, los programadores escriben pruebas para chequear el correcto funcionamiento del programa, los clientes realizan pruebas funcionales. El resultado un programa mas seguro que conforme pasa el tiempo es capaz de aceptar nuevos cambios.
b)
VALORES
La programación extrema, lejos de ser
un proceso incontrolado, es una metodología muy disciplinada y que se apoya en
cuatro valores fundamentales:Comunicación. Se hace énfasis en que la comunicación, para ser efectiva, debe involucrar a todos los participantes en el proyecto, y debe ser libre y sincera.
c)
PRACTICAS
Las prácticas son las actividades que
el equipo de un proyecto lleva a cabo cada día. Las doce prácticas de la
programación extrema tienen su origen en prácticas bien conocidas en la
ingeniería del software y en el sentido común, y por tanto, no pueden resultar extrañas.
Sin embargo, lo que caracteriza a este conjunto es la cohesión de todos los
elementos, y que cada práctica ha sido llevada al extremo:- El juego de la planificación.
Esta práctica busca dividir la funcionalidad de un proyecto en pequeños
fragmentos auto contenido, cada uno de los cuales se denomina historia de
usuario (user story). El cliente y el equipo del proyecto dialogan para
decidir qué historias son más importantes (siempre se hacen las historias
más importantes primero) y estimar cuánto puede tardar el equipo en
completar cada historia;
- Entregas frecuentes. Se trata de
publicar un diseño a sofisticado que contemple hipotéticas necesidades
futuras. La mejor forma de obtener una idea de los futuros requisitos de
un sistema es proporcionar cuanto antes un prototipo al cliente y obtener
realimentación; y la mejor forma de obtener un diseño simple que funcione
es recurrir a los patrones de diseño;
a)
PRINCIPIOS
Los
principios fundamentales se apoyan en los valores y también son cuatro. Se
busca realimentación veloz, modificaciones incrementales, trabajo de calidad y
asunción de simplicidad.
b)
CICLO DE VIDA
El
ciclo de vida de Xp se enfatiza en el carácter interactivo e incremental del
desarrollo, Según una iteración de desarrollo es un período de tiempo en el que
se realiza un conjunto de funcionalidades determinadas que en el caso de Xp
corresponden a un conjunto de historias de usuarios.
·
FASE DE LA EXPLORACIÓN
En
esta fase, los clientes plantean a grandes rasgos las historias de usuario que
son de interés para la primera entrega del producto. Al mismo tiempo el equipo
de desarrollo se familiariza con las herramientas, tecnologías y prácticas que
se utilizarán en el proyecto.
·
FASE DEL PLANTEAMIENTO
Se priorizan las
historias de usuario y se acuerda el alcance del reléase. Los programadores
estiman cuánto esfuerzo requiere cada historia y a partir de allí se define el
cronograma. La duración del cronograma del primer reléase no excede normalmente
dos meses. La fase de planeamiento toma un par de días. Se deben incluir varias
iteraciones para lograr un reléase.
·
FASE DE PRODUCCIÓN
Requiere
prueba y comprobación extra del funcionamiento del sistema antes de que éste se
de si se incluyen o no en el reléase actual. Durante esta fase, las iteraciones
pueden ser aceleradas de una a tres semanas.
·
FASE DE MANTENIMIENTO
Requiere
de un mayor esfuerzo para satisfacer también las tareas del cliente. Así, la
velocidad del desarrollo puede desacelerar después de que el sistema esté en la
producción. La fase de mantenimiento puede requerir la incorporación de nueva
gente y cambiar la estructura del equipo.
·
FASE DE MUERTE
Es cuando el
cliente no tiene más historias para ser incluidas en el sistema. Esto requiere
que se satisfagan las necesidades del cliente en otros aspectos como
rendimiento y confiabilidad del sistema
2.4
METODOLOGIA RUP
Las siglas RUP en ingles
significa
Rational Unified
Process (Proceso
Unificado de Rational) es un
producto del proceso de
ingeniería de software
que proporciona un
enfoque disciplinado
para asignar tareas
y
responsabilidades
dentro de una organización del desarrollo. Su meta es asegurar la producción del software de alta calidad
que resuelve
las necesidades
de
los usuarios
dentro
de un
presupuesto y tiempo establecidos.
2.2.4.1 ESTRUCTURA
DEL RUP
El RUP tiene dos dimensiones:
·
El eje horizontal representa tiempo y demuestra los aspectos del ciclo de vida
del proceso;
·
El
eje vertical
representa
las disciplinas,
que
agrupan actividades definidas lógicamente
por
la naturaleza;
La primera dimensión representa
el aspecto
dinámico del proceso y se
expresa en términos de fases, de iteraciones, y la finalización de las fases. La
segunda dimensión representa el aspecto
estático del proceso: cómo
se describe
en términos de componentes de
proceso,
las disciplinas,
las actividades,
los
flujos de trabajo, los artefactos, y los roles.
Figura 1. Disciplinas, fases, iteraciones
del RUP
Se puede hacer
mención de las tres características esenciales que
definen
al RUP:
·
Proceso Dirigido por los Casos de Uso: Con esto se refiere a la utilización de los Casos de Uso para el desenvolvimiento y
desarrollo
de
las
disciplinas con los artefactos, roles y actividades necesarias.
Los Casos de Uso son la base para la implementación de las fases y disciplinas del RUP. Un Caso de Uso es una secuencia de pasos a seguir para la realización de un fin o propósito, y se relaciona directamente con los requerimientos, ya
que
un Caso de Uso es la secuencia de pasos que conlleva la realización e
implementación de un Requerimiento
planteado por el Cliente;
·
Proceso Iterativo
e
Incremental: Es el modelo
utilizado por
RUP para
el desarrollo
de un
proyecto
de software.
Este modelo plantea
la implementación del proyecto a realizar
en Iteraciones, con
lo
cual
se pueden
definir objetivos
por cumplir en
cada iteración y así poder ir completando todo el proyecto iteración por iteración, con lo cual se tienen
varias
ventajas, entre
ellas
se
puede
mencionar la de tener pequeños
avances del proyectos que son entregables al cliente el cual puede probar mientras se esta desarrollando otra iteración del
proyecto,
con lo cual
el proyecto va creciendo hasta completarlo en su totalidad.
·
Proceso Centrado en la Arquitectura : Define la Arquitectura de un sistema,
y una arquitectura ejecutable construida
como un
prototipo evolutivo. Arquitectura
de un
sistema es
la
organización
o
estructura
de sus partes más relevantes.
Una
arquitectura ejecutable es una
implementación parcial
del sistema, construida para
demostrar algunas funciones y propiedades.
Figura 2. Fases del RUP
El ciclo de vida del
software del RUP
se
descompone
en cuatro fases secuenciales (figura 2).
En cada extremo de una fase se
realiza una evaluación
(actividad: Revisión del ciclo de vida de la
finalización de fase) para determinar
si los objetivos de
la fase se han cumplido. Una evaluación satisfactoria
permite que el proyecto se
mueva a la próxima fase.
A.2.1 DESCRIPCIÓN DE LAS
FASES
El ciclo de vida consiste en una serie de ciclos, cada uno de los cuales
produce una nueva versión del producto, cada ciclo está compuesto por fases y cada una de estas fases está compuesta por un número de iteraciones, estas
fases son:
1. Concepción, Inicio
·
Define
el ámbito y
objetivos del proyecto;
·
Se define la
funcionalidad y capacidades del producto;
2. Elaboración
·
Tanto
la
funcionalidad como
el dominio del
problema se estudian
en profundidad;
·
Se define una arquitectura
básica;
·
Se planifica el proyecto considerando recursos disponibles;
3. Construcción
·
El producto se desarrolla a través de iteraciones donde cada iteración
involucra tareas de análisis, diseño e implementación;
·
Las fases de estudio y análisis sólo dieron una arquitectura básica que
es
aquí refinada de manera incremental conforme se construye
(se permiten cambios en la estructura);
·
Gran parte
del
trabajo es programación y pruebas;
4. Transición
·
Se libera
el producto y se
entrega al usuario para un uso
real;
·
Se
incluyen
tareas
de marketing, empaquetado atractivo, instalación, configuración, entrenamiento, soporte, mantenimiento, etc.
A.2.2 ESFUERZO RESPECTO DE LOS FLUJOS DE TRABAJO
En la figura 5 se muestran ciertos porcentajes, de forma vertical se muestra el esfuerzo que se tiene que realizar por cada una de las disciplinas o flujos de trabajo, y los dos porcentajes que se muestran de forma horizontal son para todo el proyecto. Explicando mas puntualmente la figura 5 se puede observar que para la obtención de requerimientos o requisitos en la fase de concepción se empiezan a obtener, en la fase de elaboración tiene su auge y va declinando en la fase de construcción, realizar todo esto requiere aproximadamente un 15% de esfuerzo, y así sucesivamente con las demás disciplinas.
A.2.3 ESFUERZO RESPECTO DE LAS FASES
En la figura 6 se muestran dos filas de porcentajes, el primero que es el
esfuerzo realizado por cada fase en forma general e incluyendo las iteraciones
dentro
de cada fase, y en
la segunda fila, la duración
que tiene
aproximadamente en porcentajes del
tiempo total
del
proyecto para cada
una de
las
fases incluyendo todas las iteraciones que conlleven
realizar cada fase.
2.2.3.3 ITERACIONES
El RUP maneja el proceso Iterativo Incremental para el desarrollo de las
aplicaciones
o
proyectos, por
tal motivo
es de suma
importancia explicar
brevemente en
que consiste este
proceso.
A.3.1 PROCESO ITERATIVO E INCREMENTAL
El proceso se
refiere
a la realización
de un ciclo de vida de un proyecto
y se
basa
en la evolución
de prototipos ejecutables
que se muestran a los
usuarios y clientes. En este ciclo de vida iterativo a cada iteración se reproduce el ciclo de vida en cascada a menor escala, estableciendo los objetivos de una
iteración en función de
la
evaluación
de
las iteraciones
precedentes y las
actividades se encadenan en una mini-cascada con un alcance limitado por los
objetivos de la iteración.
Para la
realización
de cada iteración se tiene que
tomar
en
cuenta
la
planificación de la iteración, estudiando los riesgos que conlleva su realización, también incluye
el análisis
de los
casos
de
uso y escenarios, el
diseño
de opciones
arquitectónicas,
la
codificación
y
pruebas, la integración gradual
durante
la
construcción
del nuevo
código
con
el existente
de iteraciones anteriores,
la evaluación de la entrega
ejecutable
(evaluación
del prototipo
en función
de las
pruebas y
de los criterios definidos)
y
la
preparación de la entrega
(documentación
e instalación
del prototipo).
Algunos de estos elementos no
se realizan en todas las fases.
No hay comentarios:
Publicar un comentario