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.