MODELO LINEAL SECUENCIAL ventajas
Enviado por Chuletator online y clasificado en Informática y Telecomunicaciones
Escrito el en 
español con un tamaño de 38,39 KB
Metodologías de desarrollo
Las metodologías son el medio a través del cual nos guiaremos durante el desarrollo de un sistema aplicando prolijidad, corrección y control para asegurarnos que el sistema resultante será de alta calidad y que efectivamente resuelva los problemas para os cuales fue creado libre de errores.
Las metodologías las podemos dividir básicamente en dos, de acuerdo a los paradigmas de programación:
La metodología estructurada pone su atención en los procesos que son parte del sistema a desarrollar. Cada proceso es analizado por partes generando una subdivisión hasta llegar a las actividades y tareas más pequeñas de dicho proceso (yendo de lo más general a lo más detallado).
La metodología orientada a objetos al contrario de la anterior centra su atención en los componentes u objetos de datos que están presentes en el sistema. Estos componentes serán independientes unos de otros permitiendo la “reutilización del código” y “facilidad de mantención” ya que los cambios se centran en cada componente.
Para el desarrollo orientado a objetos es primordial reconocer y organizar los elementos del dominio de la aplicación. Reconoce los objetos presentes y los agrupa en clases que se relacionan entre sí. Cada clase define sus atributos y sus operaciones.
El Modelo Clásico o de Cascada
Llamado algunas veces «ciclo de vida básico» o «modelo en cascada», el modelo lineal secuencial sugiere un enfoque sistemático, secuencial del desarrollo del software que comienza en un nivel de sistemas y progresa con el análisis, diseño, codificación, pruebas
y mantenimiento.
Figura 1: Modelo Clásico
Modelado según el ciclo de ingeniería convencional, el modelo lineal secuencial acompaña a las actividades siguientes:
Análisis de los requerimientos: El proceso de recopilación de los requisitos se centra e intensifica especialmente para el software. Para comprender la naturaleza de los programas que hay que construir, el ingeniero de software (“analista”) debe comprender el ámbito de la información de software, así como la función, el rendimiento y las interfaces requeridas. Los requisitos, tanto del sistema como del software, se documentan y se revisan con el cliente.
Diseño: El diseño del software es realmente un proceso multipaso que se enfoca sobre cuatro atributos distintos del programa: la estructura de los datos, la arquitectura del software, el detalle procedimental y la caracterización de la interfaz. El proceso de diseño traduce los requisitos en una representación del software que pueda ser establecida de forma que obtenga la calidad requerida antes de que comience la codificación. Al igual que los requisitos, el diseño se documenta y forma parte de la configuración del software
Codificación: El diseño debe traducirse en una forma legible para la máquina. El paso de codificación realiza esta tarea. Si el diseño se realiza de una manera detallada, la codificación puede realizarse mecánicamente.
Prueba: Una vez que se ha generado el código, comienza la prueba del programa. La prueba se centra en la lógica interna del software, asegurando que todas las sentencias se han probado, y las funciones externas, realizando pruebas que aseguren que la entrada definida produce los resultados que realmente se requieren.
Mantenimiento: El software, indudablemente, sufrirá cambios después de que se entregue al cliente (una posible excepción es el software empotrado). Los cambios ocurrirán debido a que se hayan encontrado errores, a que el software deba adaptarse a cambios del entorno externo (por ejemplo, un cambio solicitado debido a que se tiene un sistema operativo o dispositivo periférico), o debido a que el cliente requiera ampliaciones funcionales o del rendimiento. El mantenimiento del software aplica cada uno de los pasos procedentes del ciclo de vida a un programa existente en vez de a uno nuevo.
Carácterísticas:
•Resultado de cada fase: uno o más documentos aprobados.
•Una fase comienza cuando la anterior termina.
•En la práctica, las etapas se solapan.
•Iteraciones de coste elevado y reelaboración del trabajo: tendencia a la congelación de partes del desarrollo (especificaciones).
•Se retrasa la localización y corrección de errores.
•Pueden producir sistemas poco útiles para usuarios o mal estructurados.
•Inflexibilidad del modelo: dificultad para responder a cambios en los requerimientos.
El modelo lineal secuencial es el paradigma más antiguo y más extensamente utilizado en la ingeniería del software. Sin embargo, la crítica del paradigma ha puesto en duda su eficacia.
El Modelo de construcción de prototipos
Un cliente a menudo define un conjunto de objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento, o salida. En otros casos, el responsable del desarrollo del software puede no estar seguro de la eficacia de un algoritmo, de la capacidad de adaptación de un sistema operativo, o de la forma en que debería tomarse la interacción hombre-máquina. En éstas y en otras muchas situaciones, un paradigma de construcción de prototipos puede ofrecer el mejor enfoque.
El paradigma de construcción de prototipos comienza con la recolección de requisitos. El desarrollador y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos, y las áreas del esquema en donde es obligatoria más definición. Entonces aparece un diseño rápido. El diseño rápido se centra en una representación de esos aspectos del software que serán visibles para el usuario/cliente.
(Por ejemplo: enfoques de entrada y formatos de salida). El diseño rápido lleva a la construcción de un prototipo. El prototipo lo evalúa el cliente/usuario y lo utiliza para refinar los requisitos del software a desarrollar. La interacción ocurre cuando el prototipo satisface las necesidades del cliente, a la vez que permite que el desarrollador comprenda mejor lo que se necesita hacer.
Figura 2: Modelo Prototipos
Lo ideal sería que el prototipo sirviera como un mecanismo para identificar los requisitos del software. Si se construye un prototipo de trabajo, el desarrollador intenta hacer uso de los fragmentos del programa ya existentes o aplica herramientas (p ej.: generadores de informes, gestores de ventanas, etc.) que permiten generar rápidamente programas de trabajo.
En la mayoría de los proyectos el primer sistema construido apenas se puede utilizar.
Puede ser demasiado lento, demasiado grande o torpe en su uso o las tres a la vez. No hay alternativa sino comenzar de nuevo y construir una versión rediseñada en la que se resuelvan estos problemas Cuando se utiliza un concepto nuevo de sistema o una tecnología nueva, se tiene que construir un sistema que no sirva y se tenga que tirar porque incluso la mejor planificación no es omnisciente como para que este perfecta la primera vez. Por tanto, la pregunta sobre la gestión no es si construir un sistema piloto y tirarlo. Tendrá que hacerlo. La única pregunta es si planificar de antemano construir un desechable, o prometer entregárselo a los cliente.
El Modelo Incremental
Figura 3: Modelo Incremental
Este modelo se construye a partir del ciclo de vida en cascada puro donde su objetivo es reducir el riesgo que se genera al no considerar todas las necesidades que van surgiendo desde el inicio del proyecto hasta la entrega final; otro motivo puede ser una mala comprensión de los requerimientos por parte del equipo informático.
La iteración de muchos ciclos de cascada nos permite entregar al final de cada iteración una versión mucho mejor que la anterior a la cual se le han agregado nuevas funcionalidades: es una versión aumentada funcionalmente respecto de la anterior ya entregada.
El modelo incremental combina elementos del modelo lineal secuencial (aplicados repetitivamente) con la filosofía interactiva de construcción de prototipos. Como muestra la Figura el modelo incremental aplica secuencias lineales de forma sorprendente de la misma forma que progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento del software. Se debería tener en cuenta que el flujo del proceso de cualquier incremento puede incorporar el paradigma de construcción de prototipos.
Cuando se utiliza un modelo incremental, el primer incremento a menudo es un producto esencial (núcleo). Es decir, se afrontan requisitos básicos, pero muchas funciones suplementarias (algunas conocidas, otras no) quedan sin extraer. El cliente utiliza el producto central (o sufre la revisión detallada).
El modelo de proceso incremental, como la construcción de prototipos y otros enfoques evolutivos, es interactivo por naturaleza. Pero a diferencia de la construcción de prototipos, el modelo incremental se centra en la entrega de un producto operacional con cada incremento. Los primeros incrementos son versiones «desmontadas» del producto final, pero proporcionan la capacidad que sirve al usuario y también proporciona una plataforma para la evaluación por parte del usuario.
El desarrollo incremental es particularmente útil cuando la dotación de personal no está disponible para una implementación completa en cuanto a de la fecha límite de gestión que se haya establecido para el proyecto.
También es muy útil cuando el usuario necesita entregas rápidas aunque el proyecto no esté terminado.
El Modelo en Espiral
El modelo en espiral, propuesto originalmente por Boehm, es un modelo de proceso de software evolutivo que acompaña la naturaleza interactiva de construcción de prototipos con los aspectos controlados y sistemáticos del modelo lineal secuencial. Se proporciona el potencial para el desarrollo rápido de versiones increméntales del software. En el modelo espiral, el software se desarrolla en una serie de versiones increméntales.
Durante las primeras iteraciones, la versión incremental podría ser un modelo en papel o un prototipo. Durante las últimas iteraciones, se producen versiones cada vez más completas de ingeniería del sistema.
Figura 4: Modelo Espiral
El modelo en espiral se divide en un número de actividades estructurales, también llamadas regiones de tareas 6, Generalmente, existen entre tres y seis regiones de tareas. La Figura representa un modelo en espiral que contiene seis regiones de tareas:
1. Comunicación con el cliente, las tareas requeridas para establecer comunicación entre el desarrollador y el cliente.
2. Planificación, las tareas requeridas para definir recursos, el tiempo y otras informaciones relacionadas con el proyecto.
3. Análisis de riesgos, las tareas requeridas para evaluar riesgos técnicos y de gestión.
4. Ingeniería, las tareas requeridas para construir una o más representaciones de la aplicación.
5. Construcción y adaptación, las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario (p.Ej.: documentación y práctica).
6. Evaluación del cliente, las tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementada durante la etapa de instalación.
Cada una de las regiones está poblada por una serie de tareas que se adaptan a las carácterísticas del proyecto que va a emprenderse. Para proyectos pequeños, el número de tareas y su formalidad es bajo. Para proyectos mayores y más críticos, cada regíón contiene tareas que se definen para lograr un nivel más alto de formalidad. En todos los casos, se aplican las actividades de protección (p.Ej.: gestión de configuración del software y garantía de calidad del software).
Modelo DRA (Desarrollo Rápido de Aplicaciones)
Es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. Este modelo es una adaptación a alta velocidad del modelo lineal secuencial en el que se logra el desarrollo rápido utilizando una construcción basada en componentes.
Si se comprenden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un «sistema completamente funcional dentro de períodos cortos de tiempo.
Figura 5: Modelo DRA
El enfoque DRA comprende las siguientes fases:
Modelado de Gestión, El flujo de información entre las funciones de gestión se modela de forma que responda a las siguientes preguntas: ¿Qué información conduce el proceso de gestión? ¿Qué información se genera? ¿Quién la genera? ¿A dónde va la información?
¿Quién la procesa?
Modelado de datos, El flujo de información definido como parte de la fase de modelado de gestión se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las carácterísticas (llamadas atributos) de cada uno de los objetos y las relaciones entre estos objetos.
Modelado del proceso, Los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de información necesario para implementar una función de gestión. Las descripciones del proceso se crean para añadir, modificar, suprimir, o recuperar un objeto de datos.
Generación de aplicaciones. El DRA asume la utilización de técnicas de cuarta generación. En lugar de crear software con lenguajes de programación de tercera generación, el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas para facilitar la construcción del software.
Pruebas y entrega. Como el proceso DRA enfatiza la reutilización, ya se han comprobado muchos de los componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las interfaces a fondo.
---
USO DE HERRAMIENTAS CASE
Los analistas que adoptan la metodología SDLC (ciclo de vida del desarrollo de sistemas) a menudo se benefician de las herramientas de productividad, conocidas como herramientas de Ingeniería de Software Asistida por Computadora (CASE), las cuales se crearon de manera explícita para mejorar el trabajo rutinario a través del uso del soporte automatizado. Los analistas emplean herramientas CASE para aumentar la productividad, comunicarse con los usuarios de una manera más efectiva e integrar el trabajo que realizan en el sistema, desde el inicio hasta el fin del ciclo de vida.
Visible Analyst (VA) es un ejemplo de herramienta CASE que permite a los analistas de sistemas realizar planificación, análisis y diseño en forma gráfica para crear bases de datos y aplicaciones cliente/servidor complejas.
Visible Analyst, aunado a otro producto de software conocido como Microsoft Visio, permite a los usuarios dibujar y modificar diagramas con facilidad.
Los analistas y usuarios en general reportan que las herramientas CASE les ofrecen un medio de comunicación relacionado con el sistema durante su conceptualización. Mediante el uso de soporte automatizado que incluye resultados en pantalla, los clientes pueden ver de inmediato la forma en que fluyen los datos y cómo se representan otros conceptos del sistema, para así poder solicitar correcciones o modificaciones que hubieran requerido de mucho más tiempo si se utilizaran herramientas anteriores.
Algunos analistas marcan la diferencia entre las herramientas CASE superiores e inferiores. Una herramienta CASE superior permite al analista crear y modificar el diseño del sistema. Toda la información sobre el proyecto se almacena en una enciclopedia conocida como repositorio CASE, una extensa colección de registros, elementos, diagramas, pantallas, informes y demás información relacionada (vea la figura 1.6). Es posible producir informes del análisis mediante el uso de la información del repositorio para mostrar en qué partes está incompleto el diseño o dónde hay errores. Las herramientas CASE superiores también ayudan a sustentar el modelado de los requerimientos funcionales de una organización, auxiliar a los analistas y usuarios para dibujar los límites de un proyecto dado y ayudarlos a visualizar la forma en que el proyecto encaja con otras partes de la organización.
Las herramientas CASE inferiores se utilizan para generar código fuente de computadora, con lo cual se elimina la necesidad de programar el sistema. La generación de código ofrece varias ventajas:
1) el sistema se puede producir con más rapidez que si se escribieran programas computacionales; 2) la cantidad de tiempo invertido en el mantenimiento se reduce con la generación de código; 3) se puede generar código en más de un lenguaje computacional, por lo que es más sencillo migrar los sistemas de una plataforma a otra;
4) la generación de código provee una manera efectiva en costo de personalizar los sistemas que se compran a terceros distribuidores para ajustarlos a las necesidades de la organización, y 5) el código generado está libre de los errores típicos de los programas computacionales.
LA METODOLOGÍA ÁGIL
Aunque este texto tiende a enfocarse en el SDLC —la metodología más utilizada en la práctica—, el analista deberá reconocer algunas veces que la organización podría beneficiarse de una metodología alternativa. Tal vez recientemente un proyecto de sistemas en el que se utilizaba una metodología estructurada falló o quizás las subculturas de la organización, compuestas por varios grupos de usuarios distintos, parecen identificarse más con el uso de un método alternativo. Es imposible hacer justicia a estos métodos en un espacio pequeño; cada uno merece y ha inspirado sus propios libros e investigaciones. Sin embargo, mencionamos estas metodologías con la esperanza de que tome conciencia de que, bajo ciertas circunstancias, tal vez su organización quiera considerar una alternativa o suplemento al análisis y diseño estructurado y al SDLC.
La metodología ágil es una metodología de desarrollo de software que se basa en valores, principios y prácticas básicas. Los cuatro valores son comunicación, simpleza, retroalimentación y valentía. Recomendamos que los analistas de sistemas adopten estos valores en todos los proyectos que emprendan y no sólo cuando adopten la metodología ágil.
Para poder terminar un proyecto, a menudo hay que realizar ciertos ajustes en la administración del mismo.
En el capítulo 6 veremos que los métodos ágiles pueden asegurar que un proyecto se complete con éxito mediante un ajuste en los importantes recursos de tiempo, costo, calidad y alcance. Cuando se incluyen estas cuatro variables de control en forma apropiada en la planificación, hay un estado de equilibrio entre los recursos y las actividades necesarias para completar el proyecto.
Es más notable llevar las prácticas de desarrollo al extremo cuando se persiguen prácticas únicas para el desarrollo ágil. En el capítulo 6 hablaremos sobre cuatro prácticas ágiles básicas: liberaciones de versiones cortas, la semana de trabajo de 40 horas, hospedar un cliente en el sitio y utilizar programación en pareja. A primera vista estas prácticas parecen extremas, pero como veremos más adelante, podemos aprender ciertas lecciones importantes al incorporar muchos de los valores y prácticas de la metodología ágil a los proyectos de análisis y diseño de sistemas.
Proceso de desarrollo para un proyecto ágil
Hay actividades y comportamientos que determinan la manera en que actúan los miembros del equipo y los clientes durante el desarrollo de un proyecto ágil. Dos palabras que caracterizan a un proyecto realizado mediante una metodología ágil son interactivo e incremental. Si examina la figura 1.7 podrá ver que hay cinco etapas: exploración, planeación, iteraciones para la liberación de la primera versión, puesta en producción y mantenimiento. Observe que las primeras tres flechas grises que iteran de vuelta a la caja “Iteraciones” simbolizan los cambios incrementales creados por medio de los procesos repetidos de prueba y retroalimentación que en cierto momento conducen a un sistema estable pero en evolución. Observe además que el ritmo de iteraciones aumenta una vez que se libera el producto. La flecha sale de la etapa de mantenimiento y regresa a la etapa de planeación, de manera que hay un ciclo continuo de retroalimentación que involucra a los clientes y al equipo de desarrollo a medida que se ponen de acuerdo para alterar el sistema en evolución.
EXPLORACIÓN Durante ella usted explorará su entorno para evaluar su convicción de que puede y debe lidiar con el problema mediante el desarrollo ágil, ensamblará el equipo y evaluará las habilidades de sus miembros.
Esta etapa puede requerir desde unas cuantas semanas (si conoce de antemano a los miembros de su equipo y la tecnología que va a usar) hasta unos cuantos meses (si todo es nuevo). También tendrá que examinar activamente
las tecnologías potenciales necesarias para crear el sistema. Durante esta etapa debe practicar con la estimación del tiempo necesario para realizar varias tareas. En la exploración, los clientes también experimentan escribiendo historias de los usuarios. El punto es hacer que el cliente refine una historia con el detalle suficiente como para que usted pueda estimar en forma competente la cantidad de tiempo necesaria para crear la solución y convertirla en el sistema que está planeando. Todo en esta etapa tiene que ver con adoptar una actitud juguetona y curiosa hacia el entorno de trabajo, sus problemas, tecnologías y personas.
PLANEACIÓN La siguiente etapa del proceso de desarrollo ágil se llama planeación. Al contrario de la primera etapa, la planeación tal vez sólo requiera de unos cuantos días. En esta etapa, usted y sus clientes se ponen de acuerdo en una fecha, que puede ser cualquier día a partir de dos meses hasta medio año después de la fecha en curso, para entregar soluciones a sus problemas empresariales más estresantes (usted se concentrará en el conjunto más pequeño y valioso de historias). Si sus actividades de exploración fueron suficientes, esta etapa debe ser muy corta.
Todo el proceso de planeación ágil se ha caracterizado mediante la idea de un juego de planeación según la idea de Beck. El juego de planeación establece reglas que pueden ayudar a formular la relación del equipo de desarrollo ágil con sus clientes empresariales. Aunque las reglas forman una idea de cómo quiere usted que actúe cada una de las partes durante el desarrollo, no están diseñadas para sustituir una relación. Son la base para crear y mantener una relación.
Entonces, utilizamos la metáfora de un juego. Para ello hablaremos en términos del objetivo del juego, la estrategia a perseguir, las piezas a mover y los jugadores involucrados. El objetivo del juego es maximizar el valor del sistema producido por el equipo ágil. Para poder averiguar el valor, usted debe deducir los costos de desarrollo y el tiempo, los gastos y la incertidumbre requeridos para que el proyecto de desarrollo pueda continuar.
La estrategia que persigue el equipo de desarrollo ágil siempre tiene una incertidumbre limitante (minimización del riesgo). Para hacer esto, el equipo diseña la solución más simple posible, pone el sistema en producción tan pronto como sea posible, obtiene retroalimentación del cliente empresarial sobre lo que está funcionando y adapta su diseño a partir de ahí.
Las tarjetas de historias se convierten en las piezas del juego de planeación que describen con brevedad la tarea, proveen anotaciones y un área para rastrear las tareas.
Hay dos jugadores principales en el juego de planeación: el equipo de desarrollo y el cliente empresarial. No siempre es fácil decidir qué grupo empresarial en particular será el cliente empresarial, ya que el proceso ágil es un rol excepcionalmente exigente para el cliente. Los clientes deciden qué debe abordar primero el equipo de desarrollo.
Sus decisiones establecerán prioridades y revisarán la funcionalidad durante todo el proceso.
ITERACIONES PARA LA LIBERACIÓN DE LA PRIMERA VERSIÓN La tercera etapa en el proceso de desarrollo ágil está compuesta por las iteraciones para la liberación de la primera versión. Por lo general éstas son iteraciones (ciclos de prueba, retroalimentación y modificación) de aproximadamente tres semanas de duración. Usted se esforzará en bosquejar toda la arquitectura del sistema, aun y cuando sólo esté en forma de bosquejo o esqueleto.
Uno de los objetivos es realizar pruebas funcionales escritas por el cliente al final de cada iteración. Durante la etapa de las iteraciones también debe preguntarse si hay que alterar el itinerario de trabajo o si está lidiando con demasiadas historias. Convierta cada iteración exitosa en pequeños rituales e involucre en ellos tanto a los clientes como a los desarrolladores. Celebre siempre su progreso aunque éste sea pequeño, debido a que esto forma parte de la cultura de motivar a todos a que trabajen lo más duro que puedan en el proyecto.
PUESTA EN PRODUCCIÓN Durante esta fase se llevan a cabo varias actividades. El ciclo de retroalimentación se agiliza de manera que en vez de recibir retroalimentación por una iteración cada tres semanas, las revisiones de software se entregan en una semana. Puede instituir sesiones informativas diarias para que todos sepan lo que los demás están haciendo. El producto se libera durante esta fase, pero se puede mejorar si se le agregan otras carácterísticas. Poner un sistema en producción es un suceso emocionante; disponga de tiempo para celebrar con sus compañeros de equipo la ocasión. Uno de los lemas de la metodología ágil con el que todos estamos sinceramente de acuerdo es que ¡desarrollar sistemas debe ser divertido!
MANTENIMIENTO Una vez liberado el sistema, debe seguir funcionando sin problemas. Es posible agregar carácterísticas, considerar las sugerencias más riesgosas de los clientes y a rotar los miembros del equipo. La actitud que usted debe tomar en este punto del proceso de desarrollo es más conservadora que en cualquier otro.
Ahora tiene que desempeñar el papel de “guardián de la llama” en vez de ser el juguetón y curioso de la fase de exploración.
----
se configura correo, se realizan pruebas, usuario conforme
Enfoque Orientado a Objeto Aplicado a un Sistema de
Información
Vivimos en un mundo en el cual clasificamos todo, los productos, los árboles, los negocios, etc. Por lo cual no es tan sorprendente que se plantee una visión orientada a objetos para la creación de un software, es decir, una abstracción que modela el mundo de tal forma que proporciona un apoyo para entenderlo y diseñarlo.
La primera vez que se propuso un enfoque orientado a objetos para el desarrollo de software fue a finales de los años sesenta. Sin embargo, las tecnologías de objetos han necesitado casi veinte años para llegar a ser ampliamente usadas.
A medida que pasa el tiempo, las tecnologías de objetos están sustituyendo a los enfoques clásicos de desarrollo de software.
Las tecnologías de objetos llevan a reutilizar, y la reutilización de componente de software, lleva a un desarrollo de software más rápido y a programas de mejor calidad. El software orientado a objetos es más fácil de mantener debido a que su estructura es inherentemente poco acoplada. Esto lleva a menores efectos colaterales cuando se deben hacer cambios y provoca menos frustración en los especialistas del área informática y en el cliente. Además, los sistemas orientados a objetos son más fáciles de adaptar y más fácilmente escalables (por ejemplo: pueden crearse grandes sistemas ensamblando subsistemas reutilizables).
Conceptos y Definiciones
La orientación a objetos se basa en conceptos como clase, objeto, herencia, polimorfismo, método, mensaje y encapsulamiento, y muchos más.
Objeto: Un Objeto representa una entidad del mundo real o inventada. Es un concepto, una abstracción o algo que dispone de unos límites bien definidos y tiene una significación para el sistema que se pretende modelar.
Todo lo que un objeto “conoce” está representado en sus atributos (variables y estado actual), y todo lo que puede “realizar” está definido en sus métodos (comportamiento), y en sus “interacciones” con otros objetos a través del intercambio de mensajes (dinámica del ciclo de vida).
Clase: Desde una perspectiva conceptual, una Clase representa un conjunto de Objetos que comparten: Las mismas propiedades (Atributos), el mismo comportamiento (Métodos), las mismas relaciones con otros Objetos (Mensajes) y la misma semántica dentro del sistema.
Método: Es una operación concreta de una determinada clase.
Abstracción: A partir de una abstracción del mundo real, definimos objetos que representan micromódulos de software ideales. Desde su creación, se mantienen de manera independiente unos de otros, sólo interaccionan con otros objetos a través de sus mensajes. Cada objeto configura un universo ordenado y autosuficiente.
Mensaje: Una aplicación orientada a objetos consiste en un número determinado de objetos que interactúan entre sí enviándose mensajes unos a otros para invocar sus métodos. Este intercambio de mensajes facilita su comportamiento, cambios de estado, destrucción o almacenamiento. Ya que todo lo que un objeto puede realizar está expresado en sus métodos, este simple mecanismo de mensajes soporta todas las posibles interacciones entre ellos.
Encapsulamiento: El empaquetado de métodos y atributos dentro de un objeto mediante una interface de mensajes, es lo que denominamos encapsulación. La clave está precisamente en este envoltorio del objeto. La interface que rodea por completo al objeto actúa como punto de contacto para todos los mensajes que llegan desde cualquier objeto emisor.
Polimorfismo: Diferentes objetos pueden responder a un mismo mensaje de diferentes maneras. El polimorfismo permite a los objetos interactuar entre ellos sin necesidad de conocer previamente a que tipo pertenecen.
Herencia: Es un mecanismo mediante el cual se puede crear una nueva clase partiendo de una existente, se dice entonces que la nueva clase hereda las carácterísticas de la case existentes aunque se le puede añadir más capacidades (añadiendo datos o capacidades) o modificar las que tiene.
Ventajas de la orientación a objetos
Las ventajas más importantes de la programación orientada a objetos son las siguientes:
Mantenibilidad (facilidad de mantenimiento). Los programas que se diseñan utilizando el concepto de orientación a objetos son más fáciles de leer y comprender y el control de la complejidad del programa se consigue gracias a la ocultación de la información que permite dejar visibles sólo los detalles más relevantes.
Modificabilidad (facilidad para modificar los programas). Se pueden realizar añadidos o supresiones a programas simplemente añadiendo, suprimiendo o modificando objetos.
Reusabilidad. Los objetos, si han sido correctamente diseñados, se pueden usar numerosas veces y en distintos proyectos.
Fiabilidad. Los programas orientados a objetos suelen ser más fiables ya que se basan en el uso de objetos ya definidos que están ampliamente testados.
Proceso unificado de desarrollo (RUP)
Conceptos, elementos y carácterísticas.
RUP (Racional Unified Process) o Proceso Unificado Racional es una metodología de la Ingeniería en Software. Entrega en forma ordenada tareas y responsabilidades, tiene como meta primordial asegurar la calidad del software.
RUP utiliza un desarrollo iterativo para enfrentar el riesgo, incorpora además el modelamiento visual a través de UML, se guía por la representación de la problemática mediante Casos de Uso.
Divide el sistema en componentes con interfaces bien definidas que posteriormente se ensamblara para formar el sistema. Así se le otorga un mayor tiempo de desarrollo y maduración a cada componente.
Etapas de RUP
1.Dimensión temporal
La dimensión temporal está constituida por: Ciclos, fases, iteraciones e hitos.
Los ciclos trabajan en una nueva generación del desarrollo, cada ciclo del desarrollo se divide en cuatro fases consecutivas. Cada una de las fases concluye con hito muy bien definido.
Fases del RUP
Concepción: Se hace una especificación de la visión del producto final y su caso de negocio definiendo claramente el alcance del negocio. Se identifican los principales casos de uso y los riesgos.
Elaboración: Desarrollo de planificación y recursos necesarios, complementando los casos de usos y eliminando los riesgos.
Construcción: Evolución de la visión, se desarrolla e integran el resto de los componentes. El resultado de esta fase se suele conocer como versión “Beta”.
Transición: Traspaso a los usuarios. Desarrollo de nuevas versiones, corrección de problemas. Entrenamiento y soporte hasta que los usuarios estén satisfechos.
2.Dimensión estática
La dimensión estática se define en bases a cuatro elementos: Roles, Actividades, productos y flujos.
Roles: Definición del comportamiento y responsabilidades de los participantes, responde a la pregunta ¿Quién?. Una persona puede representar varios roles así como el mismo rol puede ser representado por varias personas. La responsabilidad de un rol tiene asociado un conjunto de actividades y el ser dueño de un conjunto de artefactos (productos).
Actividades: Unidad de trabajo que puede ejecutar un individuo en un rol especifico. Las actividades tienen un objetivo concreto generalmente asociado a la creación o actualización de un producto.
Producto: Conocido también como artefactos son un trozo de información, que es producido usado o modificado por un proceso. Son tangibles y son el resultado de las actividades realizadas por los roles.
Flujo de trabajo: representa una forma de describir la secuencia de actividades que producen resultado y la interacción entre cargos.
Flujos de trabajo.
Los flujos de trabajo de proceso son: Modelado de Negocio, Requisito, Análisis y diseño,
Implementación, Test y despliegue.
Modelado de Negocio: Este flujo tiene como objeto llegar a un mejor entendimiento de la organización donde se va a implementar el producto.
Requisito: Con este flujo se estable explícitamente lo QUÉ es lo que exactamente hará el sistema.
Análisis y diseño: El objetivo de este flujo es traducir los requisitos a una especificación que describa como implementar el sistema.
Implementación: Se implementan clases y ficheros en archivos fuentes, binarios, ejecutables y otros. El resultado final de este flujo es un sistema ejecutable. Se deben realizar además los test de unidad.
Test: Evalúa la calidad del producto que se está desarrollando, no asegura la calidad pero si entrega una realimentación a tiempo, para que así las cuestiones de calidad puedan resolverse.
Distribución: Produce con éxito distribuciones del producto y lo distribuye a los usuarios. Se desarrolla con más intensidad en la fase de transición.
Los flujos de Trabajo de apoyo son: Administración del Proyecto, Configuración y control de cambio y Entorno.
Administración del proyecto: Consigue equilibrar; completar los objetivos, administración del riesgo y superar restricciones para el desarrollo acorde a los requisitos.
Configuración y control de cambios: mantiene la integridad de los artefactos que se crean y mantiene la información del proceso evolutivo
Entorno: Da soporte al proyecto con las adecuadas, herramientas, procesos y métodos.