You are on page 1of 106

INTRODUCCIÓN A LA

TECNOLOGÍA DE
OBJETOS
Orientación a Objetos
Objetivos
 Describir los conceptos fundamentales de tecnología y terminología
relacionada
 Describir los beneficios de la construcción de aplicaciones OO
 Describir los procesos incremental e iterativo para el desarrollo de
aplicaciones utilizando la tecnología de objetos, y como difieren de
los enfoques tradicionales, como el modelo en cascada
 Describir los principales productos, que son desarrollados para dar
soporte al desarrollo de aplicaciones que utilizan la tecnología de
objetos y sus relaciones
 Describir el impacto del diseño de una aplicación para manipular
posibles cambios y los diferentes enfoques para soportar tales
diseños
 Describir las tendencias actuales en el soporte de la programación
orientada a objetos, incluyendo metodologías, herramientas y
marcos de trabajo
 Listar las similitudes y diferencias entre el desarrollo de aplicaciones
procedural y el desarrollo de aplicaciones orientado a objetos
Introducción
La Crisis del SW

 A finales de los 60 se acuñó el término crisis del


software:
 Los proyectos no cumplían los plazos y presupuestos.
 Dificultades inherentes a la naturaleza del software:
 Complejidad
 Dificultad de enumerar todos los estados posibles del
programa
 Dominios de aplicación complejos

 Dificultad de comunicación entre los miembros del equipo

 Sujeto a continuos cambios


Introducción
La Crisis del SW

 El software era caro, poco fiable y escaso.


 Metodologías y técnicas estructuradas no
resuelven el problema.
 Crecimiento de la complejidad de los
problemas a representar.
 Mayor problema: Mantenimiento del
software.
Introducción
La Crisis del SW

 Ciclo de vida del software (clásico):


Introducción
La Crisis del SW

 Mantenimiento del software:


 Mantenimiento es lo que sucede después de que
se ha distribuido un producto de software.
 Se le dedica aprox. el 70 % del coste del
software.
 ¿Qué significa “mantenimiento” en software?
 Parte noble: MODIFICACIÓN
 adaptación a los cambios
 Parte no noble: DEPURACIÓN
 quitar errores
Introducción
La Crisis del SW

 Mantenimiento del software:


Introducción
La Crisis del SW

 Las consecuencias son Sistemas:

 Que no cumplen los requisitos iniciales.


 Entregados fuera de plazo.
 Sobrepasando ampliamente los presupuestos
iniciales.
 Con poca satisfacción por parte del usuario.
La calidad del software
 Factores Externos
 Pueden ser detectados por los usuarios
 Calidad externa es la que realmente preocupa
 Factores Internos
 Sólo los perciben los diseñadores e implementadores
 Medio de conseguir la calidad externa
 OBJETIVO

La POO es un conjunto de técnicas para obtener calidad interna como


medio para obtener calidad externa (Reutilización y Extensibilidad)
La calidad del software
 Factores Externos
 Corrección  Eficiencia  Economía
 Robustez  Portabilidad  Integridad
 Extensibilidad  Facilidad de uso  Facilidad de reparación
 Reutilización  Funcionalidad  Facilidad de verificación
 Compatibilidad  Oportunidad

 Factores Internos
 Modularidad
 Legibilidad
La calidad del software
Factores de calidad externos

 Corrección:
 Es la capacidad de los productos software de
realizar con exactitud su tarea, tal y como es
definida en la especificación.
 Hay que definir los requisitos de manera precisa.
 Robustez:
 Es la capacidad de los productos software de
reaccionar adecuadamente ante situaciones
excepcionales.
La calidad del software
Factores de calidad externos

 Extensibilidad:
 Es la facilidad de adaptación de los productos software a
los cambios en la especificación.
 Cambios son frecuentes puesto que en la base de todo
software hay algún fenómeno humano.
 Dificultad de adaptación proporcional al tamaño del
sistema.
 Principios esenciales para facilitar la extensibilidad:
 Simplicidad de la arquitectura del software.

 Descentralización: módulos autónomos.


La calidad del software
Factores de calidad externos

 Reutilización:
 Es la capacidad de un producto software de ser utilizado
en la construcción de diferentes aplicaciones.
 No reinventar soluciones para problemas ya resueltos.

 Se escribe menos software, luego se puede dedicar más


tiempo a mejorar otros factores (fiabilidad).
 Compatibilidad:
 Es la facilidad de combinar unos elementos software con
otros.
 Los sistemas necesitan interactuar con otros.

 Convenciones estándar de comunicación inter-módulos.


La calidad del software
Factores de calidad externos

 Eficiencia:
 Es la capacidad de un sistema software de
requerir la menor cantidad posible de recursos
hardware.
 Factor importante para la utilización.
 Debemos conjugar eficiencia con los otros objetivos.
 Portabilidad:
 Es la facilidad de transferir productos software a
diferentes plataformas (entornos hw y sw).
La calidad del software
Factores de calidad externos

 Facilidad de uso:
 Es la facilidad con la que personas con diferentes niveles
de experiencia pueden aprender a usar los productos
software y aplicarlos a resolver problemas. También
incluye la facilidad de instalación, operación y supervisión.
 Funcionalidad:
 Conjunto de posibilidades ofrecido por un sistema.
 Evitar añadir propiedades de forma incontrolada.

 Un buen producto software debe estar basado en un


pequeño número de grandes ideas.
 Mantener constante el nivel de calidad.
La calidad del software
Factores de calidad externos

 Oportunidad:
 Es la capacidad de un sistema software de ser lanzado
cuando los usuarios lo desean, o antes.
 Otros factores:
 Economía:
 Debe completarse con el presupuesto asignado.
 Integridad:
 Protección del sistema contra modificaciones y accesos no
autorizados.
 Facilidad para reparaciones (de defectos)
 Facilidades de verificación:
 Datos de prueba y procedimientos para detectar fallos.
La calidad del software
 Consecuencias de estos criterios:
 Necesidad de una BUENA DOCUMENTACIÓN:
 externa (usuarios) → facilidad de uso
 interna (desarrolladores) → extensibilidad
 interfaz del módulo → extensibilidad y reutilización
 Factores que pueden entrar en CONFLICTO:
 integridad ↔ facilidad de uso
 economía ↔ funcionalidad
 eficiencia ↔ portabilidad
 ajustarse a la especificación ↔ reutilización
La calidad del software
Factores de calidad internos

 Modularidad:
 “Propiedad que tiene un sistema que ha sido
descompuesto en un conjunto de módulos
cohesivos y débilmente acoplados” [Booch’96]
 Alta cohesión:
 Un módulo con responsabilidades altamente
relacionadas y que no hace una gran cantidad de
trabajo.
 Bajo acoplamiento:
 Un módulo que no depende de demasiados otros
módulos.
La calidad del software
Modularidad
 Programa modular: formado por un conjunto de módulos.
 Módulo: unidad básica de descomposición de un sistema
software. Los módulos deben ser lo más independientes
posibles.
 Un método de construcción de software es modular si ayuda a
producir sistemas software a partir de elementos
autónomos interconectados por una estructura simple y
coherente.
 La programación modular trata de descomponer un programa en
un pequeño número de abstracciones coherentes que
pertenecen al dominio del problema y cuya complejidad interna
esta oculta por el interfaz.
La calidad del software
Modularidad

 Un módulo se estructura mediante una interfaz y


una implementación.
 Esta compuesto por un conjunto de operaciones y
atributos.
La calidad del software
Modularidad

 EJEMPLO: Módulo que


define “cuentas
bancarias”
 Un modulo incluye una
estructura de datos
junto con un conjunto de
operaciones para
manipularla.
Modularidad:
Tipos abstractos de datos

 Abstracción (I):
 Supresión intencionada, u ocultamiento, de algunos
detalles de un proceso o artefacto, con el objeto de
destacar de manera más clara otros aspectos, detalles o
estructuras.
 Capacidad de centrarse en las características esenciales
de las distintas partes de un sistema, ignorando sus
propiedades accidentales.
 Permite dividir la información en componentes aislados
que posteriormente se ensamblan para construir el “todo”.
 Limitación de la capacidad humana para operar la
complejidad:
 Ordenando el caos: ”divide et impera”.
 En SW: Abstracción → Modularidad
Modularidad:
Tipos abstractos de datos

 Abstracción (II):
Modularidad:
Tipos abstractos de datos

 Encapsulación:
 “Proceso de almacenar en un mismo
compartimento los elementos de una abstracción
que constituyen su estructura y su
comportamiento” [Booch’96]
Modularidad:
Tipos abstractos de datos

 Tipos de Datos:
 Un tipo de dato es un conjunto de valores y un
conjunto de operaciones definidas por sus
valores.
 Tipo de dato = Representación + Operaciones.
 Ejemplos:
 Tipo de datos entero, operaciones de +,-,*,/.
 Tipo cadena, operaciones de concatenación,
subcadena, etc.
Modularidad:
Tipos abstractos de datos

 Tipos Abstractos de Datos:


 Los TADs permiten ampliar los tipos de datos definidos por
el lenguaje de programación.
 Un tipo de dato definido por el programador se denomina
TAD.
 Un TAD es un tipo de datos que consta de datos y
operaciones que se pueden realizar sobre esos datos.
 Los TADs ocultan la implementación de las operaciones
definidas por el usuario asociadas con el tipo de datos.
 La ocultación de información de un TAD significa que
poseen interfaces públicos (operaciones que se pueden
realizar), sin embargo, las implementaciones de esos
interfaces son privados.
Paradigmas - Lenguajes
 A lo largo del tiempo se han utilizado diferentes maneras
de construir sistemas (paradigmas) persiguiendo
parecidos objetivos.
 Paradigma de Construcción de un Sistema:
 Colección de conceptos que guían el proceso de
construcción de un sistema, determinando su estructura.
Estos conceptos controlan la forma en que pensamos y
formulamos los sistemas.
 Un lenguaje de programación refleja un paradigma:
PARADIGMA LENGUAJE ELEMENTOS
Imperativo COBOL, Pascal, C Algoritmos
Funcional Lisp, Miranda, Caml Funciones-Reglas If-Then
Lógico Prolog Predicados-Reglas If-Then
Orientado a Objetos Smalltalk, Eiffel, C++, Java Clases y Objetos
Enfoque estructurado vs. OO
 ¿Qué criterio utilizamos para encontrar los
módulos?
 Descomposición modular atendiendo:
 Funciones:
 Enfoque tradicional
 Descomposición funcional descendente
 Basándose en los principales tipos de datos:
 Enfoque orientado a objetos
Enfoque estructurado vs. OO
 Descomposición funcional:
 Respuesta tradicional a la cuestión de modularización
 ¿Qué hace el sistema?
Enfoque estructurado vs. OO
 Limitaciones de la descomposición funcional:
 Se basa en propiedades poco estables que dificulta la
extensibilidad
 Supone que todo sistema se caracteriza por una función
principal
 Se basa en la interfaz externa
 Ordenación temporal prematura
 No promueve la reutilización
 Se desarrollan elementos software para satisfacer
necesidades específi
Enfoque estructurado vs. OO
 Ventajas de la descomposición funcional:
 Disciplina de pensamiento lógica y bien
organizada.
 Técnica simple, fácil de aplicar.
 Útil para pequeños programas y algoritmos
individuales.
 Buena para documentar diseños (describir
algoritmos).
 Promueve el desarrollo ordenado de sistemas
 Adecuada para dominar la complejidad
Enfoque estructurado vs. OO
 En la programación tradicional tenemos por un lado
los datos y por otro las operaciones sobre esos
datos, pero son entidades independientes.
Enfoque estructurado vs. OO
 En la programación OO agrupamos (encapsulamos)
conjuntos de datos relacionados entre sí y
operaciones sobre esos datos en entidades que
llamamos objetos.
Enfoque estructurado vs. OO
 Con la orientación a objetos, construimos pequeños
modelos software de la realidad y simulamos ésta.
 Un sistema O.O. es un conjunto de objetos que
interactúan entre sí enviándose mensajes mediante
los cuáles se solicitan servicios unos a otros.
Enfoque estructurado vs. OO
 ¿Qué significa Orientación a Objetos?
 El software se organiza como una colección de objetos
que contienen tanto estructura como comportamiento.
 ¿Qué es el desarrollo Orientado a Objetos?
 Una nueva forma de pensar acerca del software
basándose en abstracciones que existen en el mundo real.
 Hay que centrar la atención no sobre lo que HACE el
sistema, sino principalmente sobre lo que ES el sistema,
en términos de datos, de componentes, en término de
manejo de entidades, de reacción a las solicitudes.
Programación OO
 ¿Qué es la POO?
 “Un método de implementación en el que los programas se
organizan como colecciones cooperativas de objetos, cada
una de las cuales representan una instancia de alguna
clase, y cuyas clases son todas miembros de una jerarquía
de clases unidas mediante relaciones de herencia” Booch.
Programación OO
Términos
Programación OO
Objeto
Programación OO
Objeto

 Un “paquete” de software
independiente formado por
un conjunto de datos junto
con los procedimientos que
operan sobre estos datos.

 Un objeto puede ser real o


abstracto.
Programación OO
Objeto = Módulo Software

 Cada objeto constituye un universo cerrado bien definido.


 Todo lo que un objeto “sabe” se expresa en sus atributos.
 Todo lo que un objeto “puede hacer” se expresa por sus
operaciones (métodos).
Programación OO
Objeto
Programación OO
Clase
Programación OO
Clase
Programación OO
Ejemplo de Clase

 Esta lista de atributos y


de operaciones
asegura el hecho de
que el conjunto de
instancias de la clase
Automóvil dispondrá de
estos atributos y de los
valores asociados, así
como de la facultad de
ejecutar las
operaciones citadas.
Programación OO
Ejemplo de Objeto

 Se especifican sus
atributos.
 Este coche tiene ahora
una “existencia
informática”.
 Está en condiciones de
participaren las
secuencias de
interacciones.
Programación OO
Clase

 Una clase es un tipo definido que determina la estructura de


datos y las operaciones asociadas a ese
 Una clase se puede ver como una plantilla que describe
objetos que van a tener la misma estructura y el mismo
comportamiento.
 Un programa OO es una colección estructurada de clases.
Programación OO
Clase

 Doble naturaleza de las clases:


 Una clase es un módulo y un tipo de dato:
 Módulo (concepto sintáctico)
 Mecanismo para organizar el software (sintáctico)
 Encapsula componentes software
 Tipo (concepto semántico)
 Mecanismo de definición de nuevos tipos de datos:
describe una estructura de datos (objetos) para representar
valores de un dominio y las operaciones aplicables.
 “Los servicios proporcionados por una clase, vista
como un módulo, son precisamente las
operaciones disponibles sobre las instancias de la
clase, vista como un tipo”.
Programación OO
Clase

 Componentes de una clase:


 Atributos
 Determinan una estructura de almacenamiento para cada
objeto de la clase
 Operaciones (Métodos)
 Operaciones aplicables a los objetos

 Único modo de acceder a los atributos


Programación OO
Clases e Instancias

 Una clase es un generador de


objetos (las instancias de la
clase).
 Una instancia es una estructura
constituida por los atributos
descritos para la clase.
 La creación de un objeto a partir
de una clase se llama
instanciación.
 Muchas instancias de una misma
clase pueden existir
simultáneamente en memoria.
Programación OO
Instanciación

 La clase Empleado describe a todos los empleados,


a partir de ella podemos dirigirnos a un empleado
concreto dando valores a sus datos (atributos).
Programación OO
Instanciación

 Es una estructura de datos formada por tantos atributos


como tiene la clase.
 El estado de un objeto viene dado por el valor de los
atributos. El estado suele cambiar con el paso del tiempo.
 Los métodos permiten consultar y modificar el estado del
objeto.
 Durante la ejecución de un programa OO se crearán un
conjunto de objetos.
Programación OO
Análisis y diseño OO
Programación OO
Super-clase
Programación OO
Super-clase
Programación OO
Herencia

 Se establece una estructura jerárquica en la


que cada clase hereda atributos y métodos
de las clases que están por encima de ella.
La clase derivada (Subclase) puede usar los
procedimientos y los atributos de su Super-
Clase.
 Cada subclase puede tener nuevos atributos
y métodos y/o redefinir los heredados.
 Objetivo: permitir el análisis por clasificación.
 Ventajas: granularidad, reutilización.
Programación OO
Herencia
Programación OO
Herencia
Programación OO
Herencia
 La búsqueda de los métodos y de los atributos sigue la
jerarquía de las clases.
 Un objeto busca tanto los métodos y los atributos en su clase,
después en sus super-clases.
Programación OO
Herencia
Programación OO
Herencia: Tipos (I)

 Simple: una clase hereda de una única super-clase.


Programación OO
Herencia: Tipos (II)

 Múltiple: una clase hereda de varias super-clases


Programación OO
Jerarquías de clases
 Cada sub-clase puede
establecer sus propias
características, bien
añadiéndolas a las definidas
por la clase padre, o
suprimiendo algunas de estas
características.
 Para construir sistemas de
software complejos y además
comprensibles, la tecnología
orientada a objetos utiliza
nuestros mecanismos
conceptuales innatos.
Programación OO
Clasificación vs. Composición
Programación OO
Herencia

 Reutilización de software.
 Mayor seguridad, menor coste.
 Reutilización de componentes.
 Rápido prototipado.
 Consistencia de la interface.
 Comportamiento similar de todas las clases que
heredan de una superclase.
Programación OO
Clases abstractas

 A veces es útil aislar en clases conceptos


incompletos aunque coherentes y cohesivos.
 Los atributos y los métodos de estas clases
están disponibles para ser especializados vía
herencia.
 Una clase abstracta no puede tener
instancias.
Programación OO
Relaciones entre objetos

 Los objetos tienen, aparte de atributos y


métodos y relaciones de herencia, relaciones
con otros objetos.Las relaciones más
importantes son:
 Asociación
 Agregación (composición)
Programación OO
Relaciones entre objetos: Asociación

 Es una conexión entre clases, una conexión


(enlace) semántica entre objetos de las clases
implicadas en la relación. Esto se consigue usando
algún objeto de una de las clases como atributo de
la clase asociada.
Programación OO
Relaciones entre objetos: Agregación (Composición)

 Se da cuando una clase está estructuralmente compuesta de


otras clases. Una clase está formada por objetos de objetos
(objeto compuesto) de otra u otras clases. Para la existencia
del objeto compuesto deben existir los demás objetos.
Programación OO
Relaciones entre objetos: Cardinalidad

 Asociación y Agregación tienen cardinalidad:


Número de instancias de una clase que están
relacionadas con una instancia de la otra clase
Programación OO
Comunicación
Programación OO
Comunicación
 Los objetos se comunican entre sí mediante el envío de
mensajes.
 El propósito de un mensaje es pedir al objeto que lo recibe que
active el método que se le indica y que devuelva al objeto
original el resultado de esa acción.
 Una secuencia de instrucciones en un lenguaje clásico es
reemplazada por una secuencia de comunicaciones.
 La sintaxis de una comunicación es muy simple:
 <sujeto> <verbo> <complemento>
 o también:
 <destinatario> <mensaje> <datos>
 <objeto receptor> <método seleccionado> <parámetros>
Programación OO
Comunicación

 Los mensajes que recibe un objeto son los únicos


conductos que conectan el objeto con el mundo
exterior.
 Los datos de un objeto están disponibles para ser
manipulados solo por los métodos del propio
objeto.
 Cuando se ejecuta un POO ocurren tres cosas:
1. Los objetos se crean a medida que se necesitan.
2. Los mensajes se mueven de un objeto a otro (o desde el
usuario a un objeto) a medida que el programa procesa la
información.
3. Cuando los objetos no se necesitan se borran y se libera
la memoria.
Programación OO
Comunicación
Programación OO
Comunicación

 Unificación de la sintaxis
 funciones:
 restar ( a, b ) : restar a de b o restar b de a ?
 mensaje: a restar: b, a - b
 Simplificación de la sintaxis
 "El gato come al ratón"
 ¿Qué es lo más natural ?
 Comer (gato, ratón)
 gato.come(ratón)
Programación OO
Polimorfismo
 Significa tener o asumir distintas formas. En el contexto de POO
se refiere a la capacidad de los diferentes objetos para
responder de distinta forma a la misma operación. Esta
característica habilita al programador para tratar uniformemente
objetos que provienen de clases diferentes.
 Permite enviar el mismo mensaje a objetos diferentes y que
cada uno responda en la forma apropiada según el tipo de objeto
que sea, ejecutando su método.
 El polimorfismo está asociado a la ligadura dinámica
(“dynamic binding”). La asociación de un método con su nombre
no se determina hasta el momento de su ejecución.
 El polimorfismo es una aplicación particular de la herencia de
comportamiento. Una misma operación (un mismo elemento de
comportamiento) podrá interpretarse de diversas maneras según
la posición en la que se encuentre dentro de la jerarquía.
 Usualmente requiere del empleo de clases abstractas.
Programación OO
Polimorfismo
Programación OO
Polimorfismo

 Ventajas:
 Da uniformidad a la sintaxis.
 Disminuye la cantidad del código a escribir (por
eliminación de las estructuras alternativas con
opciones múltiples).
 Facilita el tratamiento de colecciones
heterogéneas.
Análisis y Diseño
Orientado a Objetos con UML
Ingeniería del Software

 La Ingeniería del Software aplica los principios de la ciencia de


la computación y las matemáticas para lograr soluciones costo-
efectivas a los problemas de desarrollo de software.
 Proceso de ingeniería de software: Conjunto de etapas
parcialmente ordenadas con la intención de lograr un producto
software de calidad.
 Análisis/Diseño Orientado a Objetos: Es un método de
análisis y diseño que examina los requerimientos desde la
perspectiva de las clases y objetos encontrados en el
vocabulario del dominio del problema.
 Metodología de Desarrollo: Es un conjunto integrado de
técnicas y métodos (actividades) que permiten obtener de forma
homogénea (sistemática) y abierta (a cambios y adaptaciones),
cada una de las fases del ciclo de vida del software.
Análisis y Diseño
Orientado a Objetos con UML
Ciclo de vida del SW
Análisis y Diseño
Orientado a Objetos con UML
El proceso de desarrollo OO (I)

 Fases en que se descompone el proceso de desarrollo OO:


1. Planificación y Especificación de Requisitos: Planificación,
definición de requisitos, conocer los procesos del dominio, etc.
2. Construcción: La construcción del sistema. Se subdivide en las
siguientes:
 Análisis: Se analiza el problema a resolver desde la perspectiva de
los usuarios y de las entidades externas que van a solicitar servicios
al sistema.
 Diseño: El sistema se especifica en detalle, describiendo cómo va a
funcionar internamente para satisfacer lo especificado en el análisis.
 Implementación: Se lleva lo especificado en el diseño a un lenguaje
de programación.
 Pruebas: Se llevan a cabo una serie de pruebas para corroborar que
el software funciona correctamente y que satisface lo especificado en
la etapa de Planificación y Especificación de Requisitos.
3. Instalación: La puesta en marcha del sistema en el entorno
previsto de uso.
Análisis y Diseño
Orientado a Objetos con UML
El proceso de desarrollo OO (II)

1. Planificación y Especificación de Requisitos:


 Estudiar la especificación de requisitos para descubrir las
secuencias típicas de acciones desde la perspectiva del usuario.
 Estas acciones son los denominados casos de uso.
 Un caso de uso es una secuencia típica de acciones en un
sistema, desde el punto de vista del usuario, que muestra cómo
el sistema interacciona con el exterior y que se obtiene como
resultado del uso del sistema.
 Los casos de uso son descritos en un documento en el que se
detallan los siguientes puntos de cada uno:
 Nombre del caso de uso
 Actores participantes
 Tipo de caso (importancia del mismo – primario, secundario)
 Descripción del caso de uso
Análisis y Diseño
Orientado a Objetos con UML
El proceso de desarrollo OO (III)

2. 1) Análisis:
 Se intenta llegar a una buena comprensión del problema por
parte del equipo de desarrollo, sin entrar en cómo va a ser la
solución en cuanto a detalles de implementación.
 Trabajamos con los modelos de casos de uso construidos en la
fase anterior, ampliándolos y refinándolos.
 Se construye un Modelo de Objetos Conceptual o Modelo de
Análisis mediante un diagrama de clases, compuesto de
clases y relaciones entre las clases.
 Se deberán identificar los conceptos más importantes del
sistema (objetos físicos, roles de una persona, etc.), los
atributos de los mismos y las relaciones existentes entre
ellos. Por ejemplo en un sistema bancario se pueden identificar
conceptos como cuenta, cliente, tarjeta de crédito, saldo, recibo,
etc.
Análisis y Diseño
Orientado a Objetos con UML
El proceso de desarrollo OO (IV)
Análisis y Diseño
Orientado a Objetos con UML
El proceso de desarrollo OO (V)

2. 2) Diseño:
 En la fase de Diseño se crea una solución a nivel lógico para
satisfacer los requisitos, basándose en el conocimiento reunido
en la fase de análisis.
 Las tareas que se realizan en esta fase son las siguientes:
 Definir el Diagrama de Clases de Diseño detallado.
 Definir las estructuras de datos necesarias para almacenar la
información que utiliza el sistema.
 Definir la Interfaz de Usuario e Informes.
 Los diagramas de clases definidos en la fase anterior se
pueden refinar con la especificación de atributos y operaciones
para cada una de las clases y las relaciones con otras clases
(generalización, agregación, composición, uso, etc). Con la
información obtenida en los casos de uso, se pueden derivar las
operaciones y asignarse a las clases existentes.
Análisis y Diseño
Orientado a Objetos con UML
UML (I)

 El Unified Modeling Language (UML) define un lenguaje de


modelado orientado a objetos común para visualizar, especificar,
construir y documentar los componentes de un sistema software
OO.
 El UML no es una metodología, sino una notación que trata de
posibilitar el intercambio de modelos de software.
 Un modelo es una simplificación de la realidad creada para
comprender mejor un sistema.
 Un proceso de desarrollo de software debe ofrecer un
conjunto de modelos que permitan expresar el producto desde
cada una de las perspectivas de interés.
Análisis y Diseño
Orientado a Objetos con UML
UML (II)

 Los modelos de UML se utilizan para representar las distintas


fases o etapas que se plantean en una metodología de
desarrollo software. Ejemplos de metodologías: Métrica 3 y el
Proceso Unificado.
 UML utiliza modelos orientados a objetos: Representación de
un sistema a partir de los objetos o entidades que lo constituyen,
con atributos y operaciones, y relaciones con otros objetos.
 UML es un lenguaje de modelado visual, utiliza diagramas, para
la representación de los sistemas. Los diagramas se utilizan
para visualizar un sistema desde diferentes perspectivas, de
forma que un diagrama es una proyección de un sistema.
Análisis y Diseño
Orientado a Objetos con UML
UML (III)

 Diagramas para modelar el Comportamiento del Sistema:


 Diagrama de Casos de Uso: Muestra un conjunto de casos de uso y
actores y sus relaciones.
 Diagrama de Secuencia: Diagrama de interacción con la relación temporal
de los mensajes y los objetos.
 Diagrama de Colaboración: Diagrama de interacción que resalta la
organización estructural de los objetos que envían y reciben mensajes.
 Diagrama de Estados: Muestra una máquina de estados, que consta de
estados, transiciones, eventos y actividades. Vista dinámica del sistema.
 Diagrama de Actividades: Muestra el flujo de actividades dentro de un
sistema.
 Diagramas para modelar la Estructura del Sistema:
 Diagrama de Clases: Muestra un conjunto de clases, interfaces y
colaboraciones, así como sus relaciones.
 Diagrama de Objetos: Muestra un conjunto de objetos y sus relaciones.
 Diagrama de Componentes: Muestra la organización y las dependencias
entre un conjunto de componentes.
 Diagrama de Despliegue: Representa la infraestructura de un sistema en
tiempo de ejecución.
Análisis y Diseño
Orientado a Objetos con UML
Notación UML: Diagrama de casos de uso (I)

 Un Diagrama de Caso de Uso muestra la relación


entre Actores y los Casos de Uso del sistema.
 Estos conceptos permiten definir:
1. qué elementos externos al sistema interactúan con él
(Actor)
2. qué funciones deben ser realizadas por el sistema (Caso
de Uso)
 Los casos de uso describen bajo la forma de
acciones y reacciones el comportamiento de un
sistema desde el punto de vista de un usuario;
permiten definir los límites del sistema y las
relaciones entre el sistema y el entorno.
Análisis y Diseño
Orientado a Objetos con UML
Notación UML: Diagrama de casos de uso (II)

 Un Caso de Uso es un concepto que representa una unidad


funcional coherente, proporcionada por el sistema y que se
manifiesta con un intercambio de mensajes entre el sistema y
los interlocutores exteriores (llamados actores). Se
representan gráficamente mediante una elipse que contiene
el nombre del caso de uso.
 Un actor representa un rol (o conjunto de roles) que un
usuario puede representar al interactuar con el sistema. Su
representación gráfica es la figura de un hombre dibujado con
unas líneas simples.
Análisis y Diseño
Orientado a Objetos con UML
Notación UML: Diagrama de casos de uso (III)

 El Diagrama de Casos de Uso representa las relaciones


entre los actores y los casos de uso, además de poder
expresar las relaciones entre casos de uso si es que las
hubiera. Las relaciones entre casos de uso pueden ser de
dos tipos:
 La relación extiende: que significa que un caso de uso A
aumenta el comportamiento de un caso B.

 La relación de inclusión: que significa que el caso de uso A


incorpora el comportamiento del caso de uso B como parte
de su propio comportamiento.
Análisis y Diseño
Orientado a Objetos con UML
Notación UML: Diagrama de casos de uso (IV)

 Ejemplo: Casos
de uso de un
empleado de un
banco que
gestiona
clientes y
cuentas:
Análisis y Diseño
Orientado a Objetos con UML
Notación UML: Diagrama de clases (I)

 Un Diagrama de Estructura Estática (conocido más


popularmente como Diagrama de Clases) muestra la
estructura estática del modelo del sistema, es decir, todo
aquello que “exista” en el sistema, mostrando su estructura
interna así como sus relaciones entre los diferentes
elementos.
 En un diagrama de clases, los elementos que nos vamos a
encontrar son: las clases, los interfaces y las relaciones entre
clases/Interfaces.
 Clase: Nombre + Atributos + Operaciones
Análisis y Diseño
Orientado a Objetos con UML
Notación UML: Diagrama de clases (II)

 Interfaces: Representan un conjunto de operaciones que


especifican los servicios que puede brindar una clase o
componente y nunca debe especificar sus
implementaciones.

 Las asociaciones pueden estar formadas por un número


indeterminado de clases pero las más comunes y
utilizadas son las asociaciones binarias, es decir, aquellas
relaciones entre dos clases.
Análisis y Diseño
Orientado a Objetos con UML
Notación UML: Diagrama de clases (III)

 Agregación (relación del tipo todo/parte) entre clases se


expresa mediante un rombo adyacente a la clase que
representa la totalidad y de dicho rombo parten las
asociaciones al resto de clases que forman dicha
agregación.

 Composición (relación de pertenencia) es representada de


igual forma que la agregación pero con el interior del rombo
pintado de negro.
Análisis y Diseño
Orientado a Objetos con UML
Notación UML: Diagrama de clases (IV)

 Herencia (o generalización) se representa mediante un


triángulo unido a la clase padre por un vértice y del cual
salen las relaciones a las clases hijas.
Análisis y Diseño
Orientado a Objetos con UML
Notación UML: Diagrama de clases (V)

 Ejemplo: En este ejemplo se pueden apreciar las relaciones


que hay entre una facultad, sus departamentos, sus
profesores y sus alumnos:
Análisis y Diseño
Orientado a Objetos con UML
Notación UML: Diagrama de clases (VI)

1. Realizar un análisis sintáctico-gramatical de la documentación


existente:
 Utilizar la documentación de los casos de uso.
 Subrayar cada nombre (sustantivo) o cláusula nominal.
2. Decidir qué objetos se admiten como objetos del sistema.
 A partir de los nombres subrayados, proponer varios objetos potenciales.
3. Identificación de relaciones:
 Las relaciones se obtienen analizando la estructura de la información del
sistema.
 Expresiones como: “es”, “tiene”, “consta de”, en la descripción del sistema,
sugieren la existencia de relaciones entre objetos.
4. Identificación de atributos:
 Los atributos se obtienen de la lista de objetos candidatos y de la descripción del
sistema.
 Los objetos descartados por simples serán atributos.
5. Identificación de operaciones:
 Las operaciones de los objetos se derivan de los verbos que aparecen en la
descripción del sistema.
 Los parámetros de las operaciones se derivan de la información intercambiada
por los objetos que interactúan.
Análisis y Diseño
Orientado a Objetos con UML
Ejemplo: Gestión Académica (I)

 Se desea desarrollar una aplicación para la gestión


académica de una universidad. Especificaciones:
 El sistema debe ser capaz de gestionar todos los
expedientes académicos de los alumnos dando la
posibilidad de realizar las operaciones típicas de altas,
bajas, modificaciones y consultas de los datos del mismo.
Debemos dar un número de expediente único en el
sistema y una fecha de apertura.
 La información mínima que se debe guardar de un alumno
son el DNI, nombre, dirección, la titulación en la que está
matriculado, así como las asignaturas que está cursando
actualmente. También debemos almacenar su historial
académico, donde deben aparecer todas las asignaturas
cursadas y sus respectivas notas y convocatoria
Análisis y Diseño
Orientado a Objetos con UML
Ejemplo: Gestión Académica (II)

 Se debe realizar la gestión de las distintas titulaciones que


existen en la universidad teniendo en cuenta que una titulación
sólo se da en un campus determinado y los datos que podemos
consultar son el nombre, el número de créditos, si es de primer o
segundo ciclo, etc.
 Se tienen que gestionar las asignaturas que se imparten en
una titulación, teniendo en cuenta que una asignatura solo se
puede dar en un único curso. Algunos de los datos que se
pueden consultar de una asignatura son: el nombre, número de
créditos, cuatrimestre en el que se imparte y su tipo (obligatoria,
troncal, optativa).
 Se debe guardar la información de los profesores que imparten
las distintas asignaturas de la titulación. Se debe almacenar
como mínimo su DNI, nombre, dirección y departamento al que
pertenece. También se podrá consultar las distintas asignaturas
que imparte.
Análisis y Diseño
Orientado a Objetos con UML
Ejemplo: Gestión Académica (III)
Análisis y Diseño
Orientado a Objetos con UML
Ejemplo: Gestión Académica (IV)
Ejercicios

0. Un cerrojo con combinación tiene las siguientes propiedades básicas:


la combinación (una secuencia de tres números) está oculta; el
cerrojo se puede abrir proporcionando la combinación; y la
combinación se puede cambiar, pero solamente por alguien que
conoce la combinación actual. Diseñe una clase con métodos
públicos abrir y cambiarComb, y atributos privados para almacenar la
combinación. La combinación debería asignarse en el constructor.
Ejercicios

1. Un correo electrónico tiene asunto, remitente, destinatarios, texto,


ficheros adjuntos. Indica las posibles clases, responsabilidades y
relaciones.
Ejercicios

2. Se desea diseñar una aplicación de reserva de habitaciones de un


hotel. El hotel tiene habitaciones individuales, dobles y triples. Las
habitaciones tienen dos calidades en función del espacio. El precio se
calcula en función del tipo de habitación y de su calidad. Identifica las
clases, responsabilidades (propiedades y métodos) y sus relaciones.
.
Ejercicios

3. Se desea diseñar un simulador de red local. La red local conecta


nodos, equipos (estaciones de trabajo o servidores) e impresoras.
Cada nodo se conecta a otro nodo formando un anillo. Por la red
circulan paquetes. Cuando un nodo recibe un paquete comprueba el
destinatario y, en caso de ser él, realiza las acciones pertinentes
(imprimir, visualizar, etc). Solamente los equipos pueden enviar
paquetes a otros nodos. Un paquete incluye remitente, destinatario y
contenidos. Identifica las clases, responsabilidades (propiedades y
métodos) y sus relaciones.
Ejercicios

4. Diseñar el siguiente supuesto: Tenemos una Web donde los usuarios


de la misma pueden agregar comentarios a los libros publicados. Los
comentario constan del texto del comentario, una puntuación del libro
y de la fecha en que fueron realizados. De los libros que aparecen en
la web se presenta su autor( que ha podido escribir varios de los
libros) y se identifican por un ISBN, un título y el nombre de la
editorial que edita dicho libro. Los libros se agrupan por temática y
cada temática puede tener (o no) subtemáticas.

You might also like