Desarrollo de Software Orienta a Objetos

El análisis y diseño orientado a objetos (ADOO) es un enfoque de la ingeniería del software.

·         Modela un Sistema como un grupo de objetos que interactúan entre sí.

·         Dominio en términos de conceptos compuestos por verbos y sustantivos, clasificados de acuerdo a su dependencia funcional.

·         El lenguaje unificado de modelado se ha vuelto el lenguaje de modelado estándar usado en análisis y diseño orientado a objetos

Conceptos De La Poo

Se basa en Objetos y ofrece dos ventajas con respecto a la programación tradicional:

·         Permite al programador organizar un programa de acuerdo a abstracciones de mas alto nivel, la manera de pensar de la gente.

·         Los datos globales desaparecen, se convierten en parte interna de los objetos, por lo tanto los cambios generados en algún objeto solo los afectarían a el nada más

MODELO DE REQUISITOS:

·         Permite delimitar y darle claridad al problema con sus implicaciones, con el acompañamiento del usuario pero con la perspectiva del desarrollador.

MODELO DE REQUISITOS:

Descripción del problema Informe preliminar de necesidades

Modelo de Casos de Uso

·         Describe un sistema desde sus distintas formas de utilización. Cada caso de uso debe ser guiado por el usuario de manera secuencial por eventos.

MODELO DE REQUISITOS

·         Son entidades externas al software que no necesariamente son los usuarios.

·         Son la herramienta principal para modelar los casos de uso

MODELO DE REQUISITOS

 

MODELO DE CASO DE USO

·         Se lee la descripción del problema y se discute con los actores.

MODELO DE REQUISITOS

Modelo de Interfaces

·         Describe la presentación de información entre los actores y el sistema.

·         Se especifica en detalle como se verán las interfaces de usuario al ejecutar cada uno de los casos de uso.

Modelo de Dominio del Problema

·         Define un modelo de clases común, para los analistas y los clientes.

·         El desarrollador deberá definir con base a lo que el usuario describa, los objetos que va a utilizar en el desarrollo.

·         Es importante separar las clases en módulos cuando el sistema es muy grande.

Identificación de Clases

·         Se toma la descripción del problema y se resaltan los sustantivos para obtener las clases candidatas.

Identificación de Clases

Se seleccionan las clases mas relevantes, teniendo en cuenta

·         Que no tengan que ver con interfaces de usuario

·         Que sean claras y no permitan ambigüedades

·         Que no sean de actores del sistema

·         Que no sean redundantes

CLASES IDENTIFICADAS Y DOGRAMAS DE CLASES

                                                    

Diagrama de asociaciones

MODELO DE ANÁLISIS

·         El objetivo del modelo de análisis es comprender y generar una arquitectura de objetos para el sistema en base a lo especificado en el modelo de requisitos.

·         No se considera el ambiente de implementación todavía , en otras palabras el análisis pretende modelar el sistema bajo condiciones ideales.

·         No es una reflexión del dominio del problema sino una representación de ésta adaptada a la aplicación particular, genera una representación conceptual del sistema. Consistiendo de clases de objetos.

ARQUITECTURA DE CLASES

·         El modelo de análisis tiene como objetivo generar una arquitectura de objetos que sirva como base para el diseño posterior del sistema

·         Dependiendo de la aplicación existen diversas arquitecturas que se pueden utilizar, para nuestro caso nos enfocamos en aquellas diseñadas para el manejo de sistemas de información

·         La funcionalidad de cada arquitectura se determina por la de sus objetos involucrados, ejemplo el manejo de bordes y base de datos , si existen distintos tipos se considera la arquitectura de dos dimensiones.

CLASES CON ESTEREOTIPOS

·         El tipo de funcionalidad o “la razón de ser” de un objeto dentro de una arquitectura se le conoce como su estereotipo. Para los sistemas de información la arquitectura del sistema según nuestro modelo de análisis se basa en tres estereotipos básicos de objetos:  

·         El estereotipo entidad (“entity” en inglés)para objetos que guarden información sobre el estado interno del sistema, a corto y largo plazo, correspondiente al dominio del problema. Todo comportamiento naturalmente acoplado con esta información también se incluye en los objeto entidad. Un ejemplo de un objeto entidad es un registro de usuario con sus datos y comportamiento asociados.

·         El estereotipo interface o borde (“boundary” en inglés) para objetos que implementen la presentación o vista correspondiente a las bordes del sistema hacia el mundo externo, para todo tipo de actores, no sólo usuarios humanos. Un ejemplo de un objeto borde es la funcionalidad de interface de usuario para insertar o modificar información sobre el registro de usuario.

·         El estereotipo control (“control” en inglés) para objetos que implementen el comportamiento o control especificando cuando y como el sistema cambia de estado, correspondiente a los casos de uso. Los objetos control modelan funcionalidad que no se liga naturalmente con ningún otro tipo de objeto, como el comportamiento que opera en varios objetos entidad a la vez, por ejemplo, hacer alguna computación y luego devolver el resultado a un objeto borde.

CLASE CON ESPTEREOTIPOS

MODELO DE DISEÑO

Prototipos de Diseño

·         Se desarrolla para explorar y comprender la arquitectura particular del sistema, sirve como base para la evaluación de rendimiento y espacio y para pruebas de redundancia e inconsistencias en el diseño. Identifica cuellos de botella en el sistema y donde se quiere revisar con más detalle el producto final.

·         Se transforma el análisis, a una arquitectura particular y detallada del sistema que satisfaga todos los requisitos del sistema, donde las condiciones dadas durante el análisis se reemplazan por requisitos del ambiente de implantación particular, se contesta la pregunta del “como” del sistema.

MODELO DE IMPLEMENTACION

·         En esta etapa lo más importante es definir el código fuente de la aplicación.

·         El modelo de implementación toma el resultado del modelo de diseño para generar el código final.

·         Un buen diseño, la tarea de implementación es mucho más fluida, y el implementador se ocupa solo de resolver problemas de implementación.

·         Durante el modelo de implementación se hace una adaptación al lenguaje de programación y la base de datos de acuerdo a la especificación del diseño y según las propiedades del lenguaje de implementación y base de datos.

·         La elección del lenguaje influye en el diseño, pero el diseño no debe depender de los detalles del lenguaje.

·         En general, no se debe comenzar prematuramente a programar, es importante primero completar el proceso de planeación del sistema final desarrollado durante el diseño.

Se debe usar guías de programación existentes en la organización. Si no existen, el equipo de software deben crear sus propias guías para decidir aspectos como:

·         Formatos para la asignación de nombres a las variables.

·         Estilo de programación.

·         Métodos de documentación.

·         Documentación en línea.

Proceso Unificado de Desarrollo (RUP)

Es una metodología de desarrollo de software que está basado en componentes e interfaces bien definidas, y junto con el Lenguaje Unificado de Modelado (UML), constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos.

Es un proceso que puede especializarse para una gran variedad de sistemas de software, en diferentes áreas de aplicación, diferentes tipos de organizaciones, diferentes niveles de aptitud y diferentes tamaños de proyecto.

RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización.

Es el resultado de varios años de desarrollo y uso práctico en el que se han unificado técnicas de desarrollo, a través del UML, y trabajo de muchas metodologías utilizadas por los clientes. La versión que se ha estandarizado vio la luz en 1998 y se conoció en sus inicios como Proceso Unificado de Rational 5.0; de ahí las siglas con las que se identifica a este proceso de desarrollo.

Principales Elementos

Como RUP es un proceso, en su modelación define como sus principales elementos:

Trabajadores (“quién”): Define el comportamiento y responsabilidades (rol) de un individuo, grupo de individuos, sistema automatizado o máquina, que trabajan en conjunto como un equipo. Ellos realizan las actividades y son propietarios de elementos.

Actividades (“cómo”): Es una tarea que tiene un propósito claro, es realizada por un trabajador y manipula elementos. 

Artefactos (“qué”): Productos tangibles del proyecto que son producidos, modificados y usados por las actividades. Pueden ser modelos, elementos dentro del modelo, código fuente y ejecutables.

Flujo de actividades (“cuándo”): Secuencia de actividades realizadas por trabajadores y que produce un resultado de valor observable.

Características Principales de RUP

o Unifica los mejores elementos de metodologías anteriores.
o Preparado para desarrollar grandes y complejos proyectos.
o Orientado a Objetos.
o Utiliza el UML como lenguaje de representación visual.

Principales ventajas

o Coste del riesgo a un solo incremento.
o Reduce el riesgo de no sacar el producto en el calendario previsto.
o Acelera el ritmo de desarrollo.
o Se adapta mejor a las necesidades del cliente.

Ciclo de vida de RUP

El ciclo de vida de RUP se caracteriza por:
Dirigido por casos de uso: Los casos de uso reflejan lo que los usuarios futuros necesitan y desean, lo cual se capta cuando se modela el negocio y se representa a través de los requerimientos. A partir de aquí los casos de uso guían el proceso de desarrollo ya que los modelos que se obtienen, como resultado de los diferentes flujos de trabajo, representan la realización de los casos de uso (cómo se llevan a cabo). 

Centrado en la arquitectura: La arquitectura muestra la visión común del sistema completo en la que el equipo de proyecto y los usuarios deben estar de acuerdo, por lo que describe los elementos del modelo que son más importantes para su construcción, los cimientos del sistema que son necesarios como base para comprenderlo, desarrollarlo y producirlo económicamente. RUP se desarrolla mediante iteraciones, comenzando por los CU relevantes desde el punto de vista de la arquitectura. El modelo de arquitectura se representa a través de vistas en las que se incluyen los diagramas de UML. 

Iterativo e Incremental: Una iteración involucra actividades de todos los flujos de trabajo, aunque desarrolla fundamentalmente algunos más que otros.

Por ejemplo, una iteración de elaboración centra su atención en el análisis y diseño, aunque refina los requerimientos y obtiene un producto con un determinado nivel, pero que irá creciendo incrementalmente en cada iteración.
Es práctico dividir el trabajo en partes más pequeñas o miniproyectos. Cada miniproyecto es una iteración que resulta en un incremento. Las iteraciones hacen referencia a pasos en los flujos de trabajo, y los incrementos, al crecimiento del producto. Cada iteración se realiza de forma planificada es por eso que se dice que son miniproyectos. 

Fases

Cada fase representa un ciclo de desarrollo en la vida de un producto de software.

·         La fase de concepción o inicio tiene por finalidad definir la visión, los objetivos y el alcance del proyecto, tanto desde el punto de vista funcional como del técnico, obteniéndose como uno de los principales resultados una lista de los casos de uso y una lista de los factores de riesgo del proyecto.

·         La fase de elaboración tiene como principal finalidad completar el análisis de los casos de uso y definir la arquitectura del sistema, además se obtiene una aplicación ejecutable que responde a los casos de uso que la comprometen

·         La fase de construcción está compuesta por un ciclo de varias iteraciones, en las cuales se van incorporando sucesivamente los casos de uso, de acuerdo a los factores de riesgo del proyecto.

·         La fase de transición se inicia con una versión “beta” del sistema y culmina con el sistema en fase de producción.

Hitos

Fases	Hitos
Conceptualización - Inicio	Objetivos (visión)
Elaboración	Arquitectura
Construcción	Funcionalidad operativa
Transición	Release del sistema

Diferencias de RUP con las demás metodologías

Algunos aspectos que diferencian a RUP de las demás metodologías y lo que lo hace único es que en RUP, los casos de uso no son sólo una herramienta para especificar los requisitos del sistema, sino que también guían su diseño, implementación y prueba. Los casos de uso constituyen un elemento integrador y una guía del trabajo.

Además de utilizar los casos de uso para guiar el proceso; se presta especial atención al establecimiento temprano de una buena arquitectura que no se vea fuertemente impactada ante cambios posteriores durante la construcción y el mantenimiento. También este propone que cada fase se desarrolle en iteraciones.

Enlaces Relacionados

·         MDA

·         Modelo en cascada

·         Modelo Espiral

·         Modelo de desarrollo rápido de aplicaciones

 Lenguaje modelado de UML

UML son las siglas de “Unified Modeling Language” o “Lenguaje Unificado de Modelado”. Se trata de un estándar que se ha adoptado a nivel internacional por numerosos organismos y empresas para crear esquemas, diagramas y documentación relativa a los desarrollos de software (programas informáticos).

UML es una herramienta propia de personas que tienen conocimientos relativamente avanzados de programación y es frecuentemente usada por analistas funcionales (aquellos que definen qué debe hacer un programa sin entrar a escribir el código) y analistas-programadores (aquellos que dado un problema, lo estudian y escriben el código informático para resolverlo en un lenguaje como Java, C#, Python o cualquier otro). Por tanto si estás dando tus primeros pasos en programación, te recomendaríamos que te olvides de UML hasta que tengas unos conocimientos mínimos como uso de condicionales, bucles, y conocimiento de la programación orientada a objetos. Esto es solo una recomendación, en realidad prácticamente cualquier persona puede usar UML, incluso podría usarse para realizar esquemas o documentación de procesos que no tengan que ver con la informática.

Los principales beneficios de UML son:

• Mejores tiempos totales de desarrollo (de 50 % o más).
• Modelar sistemas (y no sólo de software) utilizando conceptos orientados a objetos.
• Establecer conceptos y artefactos ejecutables.
• Encaminar el desarrollo del escalamiento en sistemas complejos de misión crítica.
• Crear un lenguaje de modelado utilizado tanto por humanos como por máquinas.
• Mejor soporte a la planeación y al control de proyectos.
• Alta reutilización y minimización de costos.

UML, ¿Método o Lenguaje de Modelado?

UML es un lenguaje para hacer modelos y es independiente de los métodos de análisis y diseño. Existen diferencias importantes entre un método y un lenguaje de modelado. Un método es una manera explícita de estructurar el pensamiento y las acciones de cada individuo. Además, el método le dice al usuario qué hacer, cómo hacerlo, cuándo hacerlo y por qué hacerlo; mientras que el lenguaje de modelado carece de estas instrucciones. Los métodos contienen modelos y esos modelos son utilizados para describir algo y comunicar los resultados del uso del método.

Un modelo es expresado en un lenguaje de modelado. Un lenguaje de modelado consiste de vistas, diagramas, elementos de modelo los símbolos utilizados en los modelos y un conjunto de mecanismos generales o reglas que indican cómo utilizar los elementos. Las reglas son sintácticas, semánticas y pragmáticas (figura 1).

Vistas: Las vistas muestran diferentes aspectos del sistema modelado. Una vista no es una gráfica, pero sí una abstracción que consiste en un número de diagramas y todos esos diagramas juntos muestran una "fotografía" completa del sistema. Las vistas también ligan el lenguaje de modelado a los métodos o procesos elegidos para el desarrollo. Las diferentes vistas que UML tiene son:

• Vista Use-Case: Una vista que muestra la funcionalidad del sistema como la perciben los actores externos.

• Vista Lógica: Muestra cómo se diseña la funcionalidad dentro del sistema, en términos de la estructura estática y la conducta dinámica del sistema.

• Vista de Componentes: Muestra la organización de los componentes de código.

• Vista Concurrente: Muestra la concurrencia en el sistema, direccionando los problemas con la comunicación y sincronización que están presentes en un sistema concurrente.

• Vista de Distribución: muestra la distribución del sistema en la arquitectura física con computadoras y dispositivos llamados nodos.

Diagramas: Los diagramas son las gráficas que describen el contenido de una vista. UML tiene nueve tipos de diagramas que son utilizados en combinación para proveer todas las vistas de un sistema: diagramas de caso de uso, de clases, de objetos, de estados, de secuencia, de colaboración, de actividad, de componentes y de distribución.

Símbolos o Elementos de modelo: Los conceptos utilizados en los diagramas son los elementos de modelo que representan conceptos comunes orientados a objetos, tales como clases, objetos y mensajes, y las relaciones entre estos conceptos incluyendo la asociación, dependencia y generalización. Un elemento de modelo es utilizado en varios diagramas diferentes, pero siempre tiene el mismo significado y simbología.

Reglas o Mecanismos generales: Proveen comentarios extras, información o semántica acerca del elemento de modelo; además proveen mecanismos de extensión para adaptar o extender UML a un método o proceso específico, organización o usuario.

Fases Del Desarrollo De Un Sistema

Las fases del desarrollo de sistemas que soporta UML son: Análisis de requerimientos, Análisis, Diseño, Programación y Pruebas.

Análisis de Requerimientos

UML tiene casos de uso (use-cases) para capturar los requerimientos del cliente. A través del modelado de casos de uso, los actores externos que tienen interés en el sistema son modelados con la funcionalidad que ellos requieren del sistema (los casos de uso). Los actores y los casos de uso son modelados con relaciones y tienen asociaciones entre ellos o éstas son divididas en jerarquías. Los actores y casos de uso son descritos en un diagrama use-case. Cada use-case es descrito en texto y especifica los requerimientos del cliente: lo que él (o ella) espera del sistema sin considerar la funcionalidad que se implementará. Un análisis de requerimientos puede ser realizado también para procesos de negocios, no solamente para sistemas de software.

Análisis

La fase de análisis abarca las abstracciones primarias (clases y objetos) y mecanismos que están presentes en el dominio del problema. Las clases que se modelan son identificadas, con sus relaciones y descritas en un diagrama de clases. Las colaboraciones entre las clases para ejecutar los casos de uso también se consideran en esta fase a través de los modelos dinámicos en UML. Es importante notar que sólo se consideran clases que están en el dominio del problema (conceptos del mundo real) y todavía no se consideran clases que definen detalles y soluciones en el sistema de software, tales como clases para interfaces de usuario, bases de datos, comunicaciones, concurrencia, etc.

Diseño

En la fase de diseño, el resultado del análisis es expandido a una solución técnica. Se agregan nuevas clases que proveen de la infraestructura técnica: interfaces de usuario, manejo de bases de datos para almacenar objetos en una base de datos, comunicaciones con otros sistemas, etc. Las clases de dominio del problema del análisis son agregadas en esta fase. El diseño resulta en especificaciones detalladas para la fase de programación.

Programación

En esta fase las clases del diseño son convertidas a código en un lenguaje de programación orientado a objetos. Cuando se crean los modelos de análisis y diseño en UML, lo más aconsejable es trasladar mentalmente esos modelos a código.

Pruebas

Normalmente, un sistema es tratado en pruebas de unidades, pruebas de integración, pruebas de sistema, pruebas de aceptación, etc. Las pruebas de unidades se realizan a clases individuales o a un grupo de clases y son típicamente ejecutadas por el programador. Las pruebas de integración integran componentes y clases en orden para verificar que se ejecutan como se especificó. Las pruebas de sistema ven al sistema como una "caja negra" y validan que el sistema tenga la funcionalidad final que le usuario final espera. Las pruebas de aceptación conducidas por el cliente verifican que el sistema satisface los requerimientos y son similares a las pruebas de sistema.