Anlisis y diseo de sistemas orientado a objetos

Johana caroIina camargo bueIvas

Lady johana tristancho paez
UPC
Introduccin
Hoy en dia la tecnologia orientada a objetos ya no se aplica solamente
a los lenguajes de programacion, ademas se viene aplicando en el
analisis y diseo con mucho exito, al igual que en las bases de datos.
para hacer una buena programacion orientada a objetos hay que
desarrollar todo el sistema aplicando esta tecnologia, de ahi la
importancia del analisis y el diseo orientado a objetos.
La programacion orientada a objetos es una de las Iormas mas
populares de programar y viene teniendo gran acogida en el desarrollo
de proyectos de soItware desde los ultimos aos.
Perspectiva histrica
la programacion Iue hecha en una manera
secuencial o lineal, es decir una serie de
pasos consecutivos con estructuras
consecutivas y biIurcaciones.
Los lenguajes basados en esta Iorma de
programacion oIrecian ventajas al principio,
pero el problema ocurre cuando los sistemas
se vuelven complejos. Estos programas
escritos al estilo 'espaguetti no oIrecen
Ilexibilidad y el mantener una gran cantidad
de lineas de codigo en solo bloque se vuelve
una tarea complicada.
Frente a esta diIicultad aparecieron los
lenguajes basados en la programacion
estructurada. La idea principal de esta Iorma
de programacion es separar las partes
complejas del programa en modulos o
segmentos que sean ejecutados conIorme se
requieran. De esta manera tenemos un diseo
modular, compuesto por modulos
independientes que puedan comunicarse entre
si. Poco a poco este estilo de programacion
Iue reemplazando al estilo 'espaguetti
impuesto por la programacion lineal.
Fomenta la reutilizacion y extension del codigo.
Permite crear sistemas mas complejos.
Relacionar el sistema al mundo real.
Facilita la creacion de programas visuales.
Construccion de prototipos
Agiliza el desarrollo de soItware
Facilita el trabajo en equipo
Facilita el mantenimiento del soItware
Ventajas del lenguaje orientado a objetos
El modelo orientado a objetos
Para entender este modelo debemos tratar
con los siguientes conceptos basicos:
Objeto
Clase
Herencia
Qu es un objeto ?
&n 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 caracteristicas 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 mocasin.
Que es la herencia ?
La herencia es uno de los
conceptos mas cruciales en la
POO. La herencia basicamente
consiste en que una clase
puede heredar sus variables y
metodos a varias subclases (la
clase que hereda es llamada
superclase o clase padre). Esto
signiIica que una subclase,
aparte de los atributos y
metodos propios, tiene
incorporados los atributos y
metodos heredados de la
superclase. De esta manera se
crea una jerarquia de herencia.
En general, podemos tener una gran jerarqua de Clases tal
y como vemos en el siguiente grfico:
Envo de mensajes
&n objeto es inutil si esta aislado. El medio
empleado para que un objeto interactue con
otro son los mensajes. Hablando en
terminos un poco mas tecnicos, los
mensajes son invocaciones a los metodos de
los objetos.
Caractersticas asociadas al poo
Abstraccion: La abstraccion consiste en captar las caracteristicas esenciales de un
objeto, asi como su comportamiento.
Encapsulamiento: El encapsulamiento consiste en unir en la Clase las caracteristicas
y comportamientos, esto es, las variables y metodos. Es tener todo esto es una sola
entidad.
Ocultamiento: Es la capacidad de ocultar los detalles internos del comportamiento de
una Clase y exponer solo los detalles que sean necesarios para el resto del sistema.
PolimorIismo: capacidad que tienen objetos de diIerentes clases de responder al
mismo mensaje. Comportamientos alternos entre clases derivadas relacionadas.
Servicio: Es el comportamiento de los objetos. Son metodos o procedimientos, que
llegan a ser parte de los objetos, en Iorma muy similar a los atributos.
Para el desarrollo de soItware orientado a objetos no basta usar un
lenguaje orientado a objetos. Tambien se necesitara realizar un
analisis y diseo orientado a objetos.
El modelamiento visual es la clave para realizar el analisis OO.
Desde los inicios del desarrollo de soItware OO han existido
diIerentes metodologias para hacer esto del modelamiento, pero sin
lugar a duda, el Lenguaje de Modelamiento &niIicado (&ML) puso
Iin a la guerra de metodologias.
Segun los mismos diseadores del lenguaje &ML, este tiene como
Iin modelar cualquier tipo de sistemas (no solamente de soItware)
usando los conceptos de la orientacion a objetos. Y ademas, este
lenguaje debe ser entendible para los humanos y maquinas.
Anlisis y diseo orientado a objetos
OOD es...
W Modular
W EIectos laterales minimos (encapsulamiento)
W Programacion por extension
W Orientado a datos
W Explota la herencia (jerarquico)
W Reutilizacion de clases
W Facil de modiIicar
Ventajas de OOD
W Modulos con Iuerte cohesion interna y escaso
acoplamiento externo (sin variables globales, .)
W Facilita el Iuncionamiento en entorno
multiprocesador (objetos distribuidos)
W Correspondencia directa con el mundo real
W Prototipos rapidos
W Herramientas y bibliotecas muy amplias
W Aplicaciones construidas enganchando objetos
W Mejor comprension y mantenimiento
Inconvenientes de OOD
W mpactos desIavorables sobre espacio y
tiempo de ejecucion
W Forma de pensar diIerente: curva de
aprendizaje lenta
W Peligro de atomizacion, con diIicultad de
comprension global
W Herencia y ligadura dinamica diIiculta las
pruebas
Metodologas de Anlisis y Diseo (OOA/OOD)
W ooch (OOAD)
W Rumbaugh (OMT)
W acobson (OOSE)
W &ML (&niIied Modelling Language)
Lenguaje visual
&nion de los tres anteriores
Estandar internacional (OMG)
Version actual: 2.0
W &P (&niIied Process)
Metodologia de diseo iterativo
asada en casos de uso
ncorpora &ML de Iorma natural
Disear es un proceso iterativo e incremental
i topdown, ni bottomup: "ida y vuelta"
Modelo en espiral
dirigido segun los riesgos (risk driven)
Pasos de la Metodologa de Booch
1- dentiIicar las clases y los objetos a un cierto nivel de
abstraccion
2- dentiIicar la semantica de esas clases y objetos
3- dentiIicar las relaciones entre esas clases y objetos
4- mplementar esas clases y objetos
Metodologa de Booch
Metodologa de Rumbaugh (OMT)
Modelos
Metodologa de Diseo
Metodologa de 1acobson (OOSE)
Que es UML ?
W El Lenguaje de Modelamiento &niIicado (&ML)
es un lenguaje para especiIicar, construir,
visualizar y documentar los elementos que
componen un sistema de soItware intensivo.
W El &ML es una notacion para escribir modelos de
objetos
W DeIine los diagramas, sus graIicos y su semantica
principales beneficios de UML
Mejores tiempos totales de desarrollo (de 50 o mas).
Modelar sistemas (y no solo de soItware) utilizando
conceptos orientados a objetos.
Establecer conceptos y arteIactos ejecutables.
Encaminar el desarrollo del escalamiento en sistemas
complejos de mision critica.
Crear un lenguaje de modelado utilizado tanto por
humanos como por maquinas.
Mejor soporte a la planeacion y al control de proyectos.
Alta reutilizacion y minimizacion de costos.
Autores de UML
Autores
* Grady ooch: ooch,
* ames Rumbaugh y otros : OMT, OMT2
* var acobson y otros: OOSE
Aportes importantes
* Rebeca WirIsrock
* Shlaer y Mellor
Aportes importantes oOO
* Harrel: Diagramas de estados
* Work Ilow: Diagramas de Actividades
UML, Mtodo o Lenguaje de Modelado?
Un modelo es expresado en un 03:,0 /0 24/0,/4. Un lenguaje de modelado
consiste de vistas, diagramas, elementos de modelo y los smbolos utilizados en
los modelos y un conjunto de mecanismos generales o reglas que indican cmo
utilizar los elementos. Las reglas son sintcticas, semnticas y pragmticas.
Proceso de Unificacin
Partes de UML
W Vistas
Conjunto de diagramas
W Diagramas
tipos de graIos
Combinan los elementos del modelo
W Elementos del modelo
Clases, objetos, mensajes, relaciones
W Mecanismos generales
Comentarios, inIormacion, semantica, extensiones y
adaptaciones
VISTAS
W Vista de Casos de Uso
Funcionalidad externa del sistema
W Vista Lgica
Estructura estatica y conducta dinamica del sistema
W Vista de Componentes (software)
Organizacion de las componentes
W Vista de Concurrencia
Comunicaciones y sincronizacion
W Vista de Despliegue (/eployment)
Arquitectura Iisica
Las Vistas en UML
asos
uso
lgica
comp
conc
despliegue
Casos de uso
os 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 uso Vista de Casos de uso
El formato para la descripcin de los casos de uso es el siguiente:
Caso de uso: Nombre
Actores: ista de actores (agentes externos)
Propsito: ntencin del caso de uso
Resumen: Repeticin del caso de uso de alto nivel o alguna sntesis.
Tipo: Primario, secundario u opcional. Esencial o real.
Referencias
cruzadas: asos de uso relacionados y funciones relacionadas del sistema.
Descripcin: Descripcin del caso de uso.
Vista de Casos de uso Vista de Casos de uso
jempIo: el siguiente caso de uso describe el proceso de comprar
artculos en una tienda, a travs de un terminal de punto de venta.
Caso de uso: omprar productos
Actores: liente, cajero
Tipo: Primario
Descripcin: Un liente llega a la caja registradora con los artculos
que va a comprar. El ajero registra los artculos y cobra
el importe. Al terminar la operacin, el liente se marcha
con los productos.
Es conveniente comenzar con los casos de uso de ms alto nivel para
lograr comprender mejor los principales procesos globales.
Vista de Casos de uso Vista de Casos de uso
Diagrama UM de casos de uso para el sistema de punto de venta:
Este esquema tiene por objeto ofrecer un diagrama contextual que nos
permita conocer rpidamente los actores externos de un sistema y las formas
bsicas en que stos lo utilizan.
Vista de Casos de uso Vista de Casos de uso
Un diagrama de casos
de uso ms refinado
seria el siguiente:
Vista de Casos de uso Vista de Casos de uso
Casos de Uso
W Dirigida al Analisis de Requisitos (lo que quiere hacer el usuario)
W Describe la Iuncionalidad del sistema, como la perciben los actores
externos
W Dirige el desarrollo de las otras vistas
W DeIine los objetivos Iinales del sistema
W Permite validar el sistema
W Actor externo:
&suario
Otro sistema
W Se plasma en diagramas
de Casos de &so
de Actividad
Vista Lgica
W Describe la Iuncionalidad interna
W Dirigida a diseadores y desarrolladores
W DeIine la estructura estatica
Clases, objetos y relaciones
W DeIine las colaboraciones dinamicas
Mensajes y Iunciones
W Propiedades adicionales
Persistencia y concurrencia
nterIaces y estructura interna de las clases
W Se plasma en diagramas
Estaticos
W de Clases
W de Objetos
Dinamicos
W de Estado
W de Secuencia
W de Colaboracion
W de Actividad
Vista Lgica
Vista de Componentes
W Describe los modulos del sistema y sus
dependencias
W Dirigida a desarrolladores
W Se plasma en diagramas
de Componentes
Vista de Concurrencia
W Describe la division del sistema en procesos y
procesadores
W Dirigida a desarrolladores e integradores
W Resuelve problemas de
uso eIiciente de los recursos
ejecucion en paralelo (hilos)
comunicacion y sincronizacion de hilos
W Se plasma en diagramas
dinamicos
de Componentes
de Despliegue
Vista de Despliegue
W Muestra la distribucion Iisica del sistema
(ordenadores, dispositivos) y sus conexiones
W Dirigida a desarrolladores, integradores y
probadores
W Se plasma en
el diagrama de Despliegue
el mapa de asignacion de componentes a la arquitectura
Iisica
Tipos de Diagramas
W De Casos de &so
W Estaticos
de Clases
de Objetos
W Dinamicos
de Estado
de Secuencia
de Colaboracion
de Actividad
W De Componentes
W De Despliegue (deployment)
Diagramas de secuencia Diagramas de secuencia
El /iagrama /e secuencia de un sistema muestra grficamente los
eventos que originan los actores y que impactan al sistema.
a creacin de los diagramas de secuencia depende de la formulacin
de los casos de uso.
Durante la operacin del sistema, los actores generan eventos,
solicitando alguna operacin a cambio. Ejemplo: cuando un cajero
ingresa un cdigo de barras de un artculo, est pidiendo al sistema de
TPV que registre esa compra. on este evento se inicia una operacin
en el sistema.
Antes de hacer el diseo lgico de la aplicacin de software,
es conveniente investigar y definir su comportamiento como
una "caja negra".
Se estudia el comportamiento deI sistema, desde la
perspectiva de qu es lo que hace, y no de cmo lo hace.
Diagramas de secuencia Diagramas de secuencia
Definicin: El /iagrama /e secuencia de un sistema es una
representacin 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 omprar productos:
aso de uso: omprar productos
Actores: liente, cajero
Tipo: Primario
Descripcin: Un liente llega a la caja registradora con los artculos que va a
comprar. El ajero registra los artculos y cobra el importe. Al
terminar la operacin, el liente se marcha con los productos.
Diagramas de secuencia Diagramas de secuencia
El diagrama de secuencia del caso de uso omprarPro/uctos
podra ser el siguiente:
Diagramas de secuencia Diagramas de secuencia
Diagramas de colaboracin Diagramas de colaboracin
Diagramas de coIaboracin
os diagramas de interaccin (diagramas de secuencia y diagramas
de colaboracin) explican grficamente cmo los objetos interactan
a travs 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 anlisis).
Diagramas de colaboracin Diagramas de colaboracin
os /iagramas /e colaboracin explican grficamente las interacciones
entre las instancias del modelo (objetos). Por ejemplo:
Diseo de Ia soIucin
Para cada evento del sistema se debe construir un diagrama
de colaboracin cuyo mensaje inicial sea el de sus eventos.
En el caso del punto de venta, tendremos tres diagramas,
uno para cada evento: pasarPro/ucto, terminarVenta, y
efectuarPago.
Diagramas de colaboracin Diagramas de colaboracin
El diagrama de colaboracin del caso de uso pasarPro/ucto sera
el siguiente:
Diagramas de colaboracin Diagramas de colaboracin
Diagramas de clases Diagramas de clases
Anlisis y Diseo OO Anlisis y Diseo OO
as herramientas usadas en la etapa de anlisis (investigacin
del problema) se pueden resumir en la siguiente tabla.
Herramienta de anlisis Preguntas que contesta
asos de uso ules son los procesos del dominio?
Modelo conceptual ules son los conceptos, los trminos?
Diagramas de secuencia ules son los eventos y las operac. del sistema?
Anlisis y Diseo OO Anlisis y Diseo OO