analisis y diseño orientado objetos

Análisis y diseño de sistemas orientado a objetos

Johana carolina camargo buelvas

Lady johana tristancho paez

UPC

Introducción

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. 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.

Perspectiva histórica

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.

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

Ventajas del lenguaje orientado a objetos

El modelo orientado a objetos

Para entender este modelo debemos tratar con los siguientes conceptos básicos:

Objeto

Clase

Herencia

¿ Qué es un objeto ?

Un objeto del mundo real es cualquier cosa que vemos a nuestro alrededor, donde poseen las siguientes cualidades : identidad , estado y comportamiento.

¿ Que es una clase ?

Conjunto de objetos que poseen características similares , es decir objetos del mismo tipo.

Diferencia entre clase y objeto

Clase: Es un conjunto de objetos relacionados. Ejemplo: La clase Zapato.

Objeto: Es una instancia de una clase. Ejemplo: Zapato mocasín.

¿ Que es la 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.

En general, podemos tener una gran jerarquía de Clases tal y como vemos en el siguiente gráfico:

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.

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.

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.

Polimorfismo: capacidad que tienen objetos de diferentes clases de responder al mismo mensaje. Comportamientos alternos entre clases derivadas relacionadas.

Servicio: Es el comportamiento de los objetos. Son métodos o procedimientos, que llegan a ser parte de los objetos, en forma muy similar a los atributos.

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.

Análisis y diseño orientado a objetos

OOD es...

• Modular• Efectos laterales mínimos (encapsulamiento)• Programación por extensión• Orientado a datos• Explota la herencia (jerárquico)• Reutilización de clases• Fácil de modificar

Ventajas de OOD

• Módulos con fuerte cohesión interna y escaso acoplamiento externo (sin variables globales, …)

• Facilita el funcionamiento en entorno multiprocesador (objetos distribuidos)

• Correspondencia directa con el mundo real• Prototipos rápidos• Herramientas y bibliotecas muy amplias• Aplicaciones construidas enganchando objetos• Mejor comprensión y mantenimiento

Inconvenientes de OOD

• Impactos desfavorables sobre espacio y tiempo de ejecución

• Forma de pensar diferente: curva de aprendizaje lenta

• Peligro de atomización, con dificultad de comprensión global

• Herencia y ligadura dinámica dificulta las pruebas

Metodologías de Análisis y Diseño (OOA/OOD)

• Booch (OOAD)• Rumbaugh (OMT)• Jacobson (OOSE)• UML (Unified Modelling Language)

– Lenguaje visual– Unión de los tres anteriores– Estándar internacional (OMG)– Versión actual: 2.0

• UP (Unified Process)– Metodología de diseño iterativo– Basada en casos de uso– Incorpora UML de forma natural

- Diseñar es un proceso iterativo e incremental- Ni top-down, ni bottom-up: "ida y vuelta"- Modelo en espiral- dirigido según los riesgos (risk driven)

Pasos de la Metodología de Booch

1- Identificar las clases y los objetos a un cierto nivel de abstracción2- Identificar la semántica de esas clases y objetos3- Identificar las relaciones entre esas clases y objetos4- Implementar esas clases y objetos

Metodología de Booch

Metodología de Rumbaugh (OMT)

Modelos

Metodología de Diseño

Metodología de Jacobson (OOSE)

¿ Que es UML ?

• El Lenguaje de Modelamiento Unificado (UML) es un lenguaje para especificar, construir, visualizar y documentar los elementos que componen un sistema de software intensivo.

• El UML es una notación para escribir modelos de objetos

• Define los diagramas, sus gráficos y su semántica

principales beneficios de UML

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.

Autores de UML

- Autores * Grady Booch: Booch-91, 93

* James Rumbaugh y otros : OMT-1, OMT-2* Ivar Jacobson y otros: OOSE

- Aportes importantes * Rebeca Wirfs-Brock * Shlaer y Mellor - Aportes importantes No-OO * Harrel: Diagramas de estados

* Work flow: Diagramas de Actividades

UML, ¿Método o Lenguaje de Modelado?

Un modelo es expresado en un lenguaje de modelado. Un lenguaje de modelado consiste de vistas, diagramas, elementos de modelo y 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.

Proceso de Unificación

Partes de UML

• Vistas– Conjunto de diagramas

• Diagramas– 9 tipos de grafos– Combinan los elementos del modelo

• Elementos del modelo– Clases, objetos, mensajes, relaciones

• Mecanismos generales– Comentarios, información, semántica, extensiones y

adaptaciones

VISTAS

• Vista de Casos de Uso– Funcionalidad externa del sistema

• Vista Lógica– Estructura estática y conducta dinámica del sistema

• Vista de Componentes (software)– Organización de las componentes

• Vista de Concurrencia– Comunicaciones y sincronización

• Vista de Despliegue (deployment)– Arquitectura física

Las Vistas en UML

Casosuso

lógica

compconc

despliegue

Casos de uso

Los casos de uso requieren tener al menos un conocimiento parcial

de los requerimientos del sistema. Un caso de uso es un documento

narrativo que describe la secuencia de eventos de un actor (agente

externo) que utiliza un sistema para completar un proceso.

Vista de Casos de usoVista de Casos de uso

El formato para la descripción de los casos de uso es el siguiente:

Caso de uso: Nombre

Actores: Lista de actores (agentes externos)

Propósito: Intención del caso de uso

Resumen: Repetición del caso de uso de alto nivel o alguna síntesis.

Tipo: Primario, secundario u opcional. Esencial o real.

Referencias

cruzadas: Casos de uso relacionados y funciones relacionadas del sistema.

Descripción: Descripción del caso de uso.

Vista de Casos de usoVista de Casos de uso

Ejemplo: el siguiente caso de uso describe el proceso de comprar artículos en una tienda, a través de un terminal de punto de venta.

Caso de uso: Comprar productosActores: Cliente, cajeroTipo: PrimarioDescripción: Un Cliente llega a la caja registradora con los artículos que va a comprar. El Cajero registra los artículos y cobra el importe. Al terminar la operación, el Cliente se marcha con los productos.Es conveniente comenzar con los casos de uso de más alto nivel paralograr comprender mejor los principales procesos globales.

Vista de Casos de usoVista de Casos de uso

Diagrama UML de casos de uso para el sistema de punto de venta:

Este esquema tiene por objeto ofrecer un diagrama contextual que nos permita conocer rápidamente los actores externos de un sistema y las formas básicas en que éstos lo utilizan.

Vista de Casos de usoVista de Casos de uso

Un diagrama de casos de uso más refinado seria el siguiente:

Vista de Casos de usoVista de Casos de uso

Casos de Uso

• Dirigida al Análisis de Requisitos (lo que quiere hacer el usuario)• Describe la funcionalidad del sistema, como la perciben los actores

externos• Dirige el desarrollo de las otras vistas• Define los objetivos finales del sistema• Permite validar el sistema• Actor externo:

– Usuario– Otro sistema

• Se plasma en diagramas– de Casos de Uso– de Actividad

Vista Lógica

• Describe la funcionalidad interna• Dirigida a diseñadores y desarrolladores• Define la estructura estática

– Clases, objetos y relaciones

• Define las colaboraciones dinámicas– Mensajes y funciones

• Propiedades adicionales– Persistencia y concurrencia– Interfaces y estructura interna de las clases

• Se plasma en diagramas– Estáticos

• de Clases• de Objetos

– Dinámicos• de Estado• de Secuencia• de Colaboración• de Actividad

Vista Lógica

Vista de Componentes

• Describe los módulos del sistema y sus dependencias

• Dirigida a desarrolladores

• Se plasma en diagramas– de Componentes

Vista de Concurrencia

• Describe la división del sistema en procesos y procesadores

• Dirigida a desarrolladores e integradores• Resuelve problemas de

– uso eficiente de los recursos– ejecución en paralelo (hilos)– comunicación y sincronización de hilos

• Se plasma en diagramas– dinámicos– de Componentes– de Despliegue

Vista de Despliegue

• Muestra la distribución física del sistema (ordenadores, dispositivos) y sus conexiones

• Dirigida a desarrolladores, integradores y probadores

• Se plasma en– el diagrama de Despliegue

– el mapa de asignación de componentes a la arquitectura física

Tipos de Diagramas

• De Casos de Uso• Estáticos

– de Clases– de Objetos

• Dinámicos– de Estado– de Secuencia– de Colaboración– de Actividad

• De Componentes• De Despliegue (deployment)

Diagramas de secuenciaDiagramas de secuencia

El diagrama de secuencia de un sistema muestra gráficamente los eventos que originan los actores y que impactan al sistema.

La creación de los diagramas de secuencia depende de la formulación de los casos de uso.

Durante la operación del sistema, los actores generan eventos, solicitando alguna operación a cambio. Ejemplo: cuando un cajero ingresa un código de barras de un artículo, está pidiendo al sistema de TPV que registre esa compra. Con este evento se inicia una operación en el sistema.

Antes de hacer el diseño lógico de la aplicación de software,

es conveniente investigar y definir su comportamiento como

una "caja negra".

Se estudia el comportamiento del sistema, desde la

perspectiva de qué es lo que hace, y no de cómo lo hace.

Diagramas de secuenciaDiagramas de secuencia

Definición: El diagrama de secuencia de un sistema es una representación que muestra, en determinado escenario de un caso de uso, los eventos generados por actores externos, su orden y los eventos internos del sistema. En esta fase del proyecto, el sistema mismo es una caja negra.

Recordemos el caso de uso Comprar productos:

Caso de uso: Comprar productos Actores: Cliente, cajero Tipo: Primario Descripción: Un Cliente llega a la caja registradora con los artículos que va a comprar. El Cajero registra los artículos y cobra el importe. Al terminar la operación, el Cliente se marcha con los productos.

Diagramas de secuenciaDiagramas de secuencia

El diagrama de secuencia del caso de uso ComprarProductospodría ser el siguiente:

Diagramas de secuenciaDiagramas de secuencia

Diagramas de colaboraciónDiagramas de colaboración

Diagramas de colaboración

Los diagramas de interacción (diagramas de secuencia y diagramas

de colaboración) explican gráficamente cómo los objetos interactúan

a través de mensajes para realizar las tareas.

Antes de definir estos diagramas, hay que generar el modelo

conceptual y los casos de uso reales (estos últimos se generan a

partir de los casos de uso definidos en el análisis).

Diagramas de colaboraciónDiagramas de colaboración

Los diagramas de colaboración explican gráficamente las interacciones entre las instancias del modelo (objetos). Por ejemplo:

Diseño de la solución

Para cada evento del sistema se debe construir un diagramade colaboración cuyo mensaje inicial sea el de sus eventos.En el caso del punto de venta, tendremos tres diagramas,uno para cada evento: pasarProducto, terminarVenta, yefectuarPago.

Diagramas de colaboraciónDiagramas de colaboración

El diagrama de colaboración del caso de uso pasarProducto seríael siguiente:

Diagramas de colaboraciónDiagramas de colaboración

Diagramas de clasesDiagramas de clases

Análisis y Diseño OOAnálisis y Diseño OO

Las herramientas usadas en la etapa de análisis (investigacióndel problema) se pueden resumir en la siguiente tabla.

Herramienta de análisis Preguntas que contesta

Casos de uso ¿Cuáles son los procesos del dominio?

Modelo conceptual ¿Cuáles son los conceptos, los términos?

Diagramas de secuencia ¿Cuáles son los eventos y las operac. del sistema?

Análisis y Diseño OOAnálisis y Diseño OO