ANALISIS Y DISEÑO DE

SISTEMAS

SESION 07

UNIVERSIDAD NACIONAL DE INGENIERIA

Facultad de Ingeniería Industrial y de Sistemas
Ing. Jesús Walter Antaurco Trujillo
Wantaurco@yahoo.com
 Objetivos de la clase
 Analizar con detalle el modelado
estructural
Contenidos

1. Modelado Estructural
 Objetos y clase
 Diagramas de Clases
 Diagrama de paquetes
Bibliografia
 El Lenguaje Unificado de Modelado.
 Grady Booch
 James Rumbaugh
 Ivar Jacobson
 Segunda edición 2006; Capitulo 4, 8, 9 12, y
14
 Addison-Wesley

 http://www.uml.org/
Objetos y clases
 ¿Qué es un objeto?

• Representa un ítem, unidad o entidad, real o abstracta,

individual e identificable con un definido rol en el Dominio
del Problema. (Booch Grady, 1993)
• Es un concepto, abstracción o cosa con un significado y
límites definidos para el problema a manejar. (Rambaugh
James, 1991)
• Abstracción de algo en el dominio del problema, que
refleja la capacidad del Sistema para mantener
información e interactuar sobre ese dominio. Es una
encapsulación de valores determinados de atributos y
servicios exclusivos. Coad Peter and Yourdon Edward,
1991
 Un Objeto tiene Identidad
 Cada objeto posee un identificador de objeto.
 El identificador establece la identidad del objeto y
tiene las siguientes características:
 Constituye un identificador único y global para cada
objeto dentro del sistema.
 Es determinado en el momento de la creación del objeto
 Es independiente de las propiedades del objeto, lo cual
implica independencia de valor y de estructura
 Sin embargo, es preciso contar con algún medio
para hacer referencia a un objeto utilizando
referencias del dominio (valores de atributos)
 Un Objeto tiene Identidad
 Cada objeto tiene una identidad única, incluso
si su estado es idéntico al de otro objeto

Profesor “J Clark” Profesor “J Clark” Profesor “J Clark”

enseña Algebra enseña Algebra enseña Algebra
Un Objeto Tiene Estado
 El estado evoluciona con el tiempo
 Algunos atributos pueden ser constantes
 El comportamiento agrupa las competencias
de un objeto y describe las acciones y
reacciones de ese objeto
 Las operaciones de un objeto son
consecuencia de un estímulo externo
representado como mensaje enviado desde
otro objeto
Un Objeto Tiene Estado
 El estado de un objeto es una de las
posibles condiciones en que el objeto
puede existir

a + b = 10
Nombre : Joyce Clark
Nº Empleado : 567138
Fecha de Ingreso : 21 de marzo 1987
Estado : Adjunto

Profesor Clark
 Un objeto tiene comportamiento
 El comportamiento de un objeto determina
cómo éste actúa y reacciona frente a las
peticiones de otros objetos

a + b = 10

Asignación del profesor

Clark
(Retorna:confirmación)
Registro del
Sistema Curso Algebra 101
 ......Comportamiento
 Ejemplo de interacción:

Otro objeto
Un mensaje

Operacion 2

Un objeto

Operacion 1
 … Comportamiento
 Estado y comportamiento están relacionados
 Ejemplo: no es posible aterrizar un avión si
no está volando. Está volando como
consecuencia de haber despegado del suelo
 Herencia

Utiliza mecanismos que permiten a un objeto incorporar

todo o parte de una definición de otro objeto como parte
de su propia definición.
Herencia múltiple
 Polimorfismo

Usa mecanismos que permiten diferentes operaciones

en diferente tipos de objetos que tienen el mismo
nombre.

Animal
dormir()
?
dormir

?
León Oso Tigre
....Polimorfismo
 ¿Qué son las Clases?
 Hay muchos objetos identificados para cada dominio
 Una clase es una descripción de un grupo de objetos con
propiedades en común (atributos), comportamiento
similar (operaciones), la misma manera de relacionarse
entre objetos (asociaciones y agregados) y una
semántica en común
 Un objeto es una instancia de una clase

 Una clase es una abstracción en que:

 Se enfatizan las características relevantes

 Se suprimen otras características

 La abstracción nos ayuda a trabajar con cosas complejas

 Ejemplo de una Clase
Clase
Curso
Estructura Comportamiento
Nombre Agregar un alumno
Ubicación Borrar un alumno
a + b = 10
Días ofrecidos Dar una lista del curso
Horas Créditos Determinar si está lleno
Horario de inicio
Horario de término
Clases de Objetos
 ¿Cuántas clases ve?
 Relación entre clases y objetos

 Una clase es una definición abstracta de un objeto

 Define la estructura y el comportamiento de cada objeto en la
clase
 Sirve como modelo para la creación de objetos
 Los objetos pueden ser agrupados en clases

Objetos
Profesor

Profesor Smith Profesor Mellon

Clase

Profesor Jones
Modelado Estructural:
Diagrama de clases
Modelado estructural

 Se describen los tipos de objetos de un

sistema y las relaciones estáticas que
existen entre ellos.
 Clases
 Interfaces
 Relaciones de dependencia, realización,
generalización y asociación (agregación,
composición)
 También pueden incluir paquetes y colaboraciones

 Un diagrama de clase es una representación

gráfica de un modelo estructural.
 Modelado estructural:
Diferentes perspectivas
 Modelado Conceptual
 Conceptos del dominio del problema: atributos,
restricciones y relaciones entre ellos.
 Modelo del Análisis
 Clases que corresponden a conceptos del dominio
 Atributos y operaciones (métodos)
 Modelo de Diseño
 Incluye clases que corresponden a decisiones del
diseño
 Modelo de Implementación
 Clases que corresponden a un lenguaje de
programación
Modelo
Conceptual
Del modelo conceptual a las clases

 Los modelos de análisis se obtienen a partir

del modelo conceptual:
 Conceptos a clases
 Atributos de un concepto a atributos de la clase
 Añadir comportamiento (métodos)
 Modelo de
diseño
IteradorCuenta

Cuenta Domiciliacion
1 0..n

Ahorro Corriente

Operacion
Periodica
Colaboración (parte estática)
 Colaboración (parte dinámica)
: Usuario
11: recalcularTotal()
1: añadirItem(codigo)
4: añadirItem(codigo)
2: añadirItem(codigo) 3: [primer producto] crear()

: MostrarProductos : Añadir : CarroCompras 6: [!nuevoItem]incrementarUnidades()

10: [nuevoItem]put(codigo,i)

5: i:=getItemCarro(codigo) 7: [nuevoItem]p:=get(codigo) 9: [nuevoItem]i:=creaItem(p)

: ItemCarro : CatalagoProductos
i : ItemCarro
8: [nuevoItem]p:=buscar(codigo)

: Producto
Ingeniería directa e Inversa

 Ingeniería directa
 Transformar modelos en código en un
lenguaje de programación determinado
 Ingeniería inversa
 Obtener un modelo a partir de código.
 Más difícil ya que hay pérdida de
información al pasar de los modelos al
código.
Clases

Atributos

Operaciones

 No se tienen por qué mostrar todos las propiedades

 Se pueden agrupar operaciones: <<constructor>>,
<<query>>
Interfaces

 Una interfaz es una colección de

operaciones que especifica los servicios
de una clase o componente.

<<Interface>>
Collection <<Interface>>
Iterator
add()
remove() next()
size() hasNext()
contains()
iterator()
 Atributos

[visibilidad] nombre [: tipo] [= valor_inicial ] [{propiedades}]

+ = pública
visibilidad # = protegida
- = privada

Nombre : nombre del atributo

Tipo : tipo del atributo
valor_inicial : valor inicial o por defecto
Atributos

 Nivel Conceptual: “Los clientes tienen un nombre”

 Nivel de Especificación: “El cliente puede
almacenar y consultar su nombre”
 Nivel de Implementación: “Una instancia de
Cliente tiene un campo de tipo String que almacena
su nombre y un método que lo devuelve”
 Operaciones

[visibilidad] nombre [(lista_parametros)] [: tipo_retorno]

[{propiedades}]
+ = pública
visibilidad # = protegida
- = privada

nombre: nombre de la operación

lista_parámetros: lista de parámetros separados por comas

tipo retorno: tipo de valor devuelto por la operación

propiedades: {isQuery}, {sequential}, {concurrent}

Operaciones

Cuenta Atributos
- codigoCuenta : int
# cliente : int
# saldo : int
# ultimaOperacion : int
+ getSaldo () : int Operaciones
+ getUltimaOperacion () : int
- nuevoCodigo () : int
 Relaciones
 Dependencia
Un cambio en la especificación de un elemento afecta a
otro
PlanDelCurso
Curso
Window
añadir(c : Curso)
position eliminar(c : Curso)
parent
children
size Clock

open()
close() Nodo Lista
move()
resize()
<<friend>>
Estereotipos para dependencias

 bind: entre una clase genérica y una instanciación

 friend: dependencia de clase amiga
 use: relación de uso, el más común entre clases y se da por
defecto

 import: un paquete importa los elementos de otro.

 extend: para casos de uso
 include: para casos de uso
Relaciones
 Generalización
 “Es-un-tipo-de”

Cuenta Window

CuentaAhorro CuentaCorriente TextWindow BoxDialog

 Generalización

 Nivel Conceptual
 “Todas las instancias de CuentaCorriente son
instancias de Cuenta”
 Nivel Especificación
 “La interfaz de CuentaCorriente incluye la interfaz de
Cuenta”
 Nivel Implementación
 Herencia
 Asociación
 Asociación
 Relación estructural que especifica que los objetos
de un tipo están conectados con los de otro.

Persona +empleado +patron Empresa

1..* *

impartido
Curso Profesor
* 1..*
 Asociaciones
 Agregación
 Caso especial de asociación
 Relación estructural parte-de
Empresa

1..1

*
Departamento
 Asociaciones

 Nivel Conceptual
 Muestran la relación conceptual entre dos clases.
“Un cliente tiene varios pedidos”
 Nivel de Especificación
 Representan responsabilidades
 Detectamos los mensajes del protocolo de una
clase con respecto a la otra
 Nivel de Implementación
 Establecer atributos: navegabilidad
 Asociaciones

 Especificación:
class Pedido {
public Cliente getCliente();
public Set getLineaPedido();
... }
 Implementación
class Pedido {
private Cliente _cliente;
private HashSet _lineasPedido;
…}
 Navegación

 Posibilidad de limitar la navegación a una sola dirección

 Determina si una clase de la asociación tiene
“conocimiento” de la otra.
 Nivel de especificación o implementación

impartido
Curso Profesor
* 1..*
Navegabilidad (UML 2.0)

A B Navegabilidad indefinida

A B Navegable de A a B, de B a A indefinida

A B Navegable en ambos sentidos

A B Navegable sólo de A a B

A B No navegable en ningún sentido

Navegabilidad (Práctica habitual)

A B Navegabilidad en ambos sentidos

A B Navegable sólo de A a B

A B No se usa

A B No se usa

A B No se usa
 Visibilidad
 Pública: +propietario
 Protegida: #propietario
 Privada: -propietario

GrupoUsuarios Usuario +propietario -clave Clave

* * 1..1 *
 Agregación
 Dos criterios:
 Dependencia:
¿La existencia de una parte va ligada a la
del agregado?
 Exclusividad:
¿Una parte puede pertenecer a más de un
agregado?
 Composición

 Es un caso particular de agregación:

exclusiva y dependiente
 Las partes pueden crearse después del
agregado compuesta al que pertenecen, pero
una vez creadas viven y mueren con ella.
 La parte sólo puede formar parte de un
agregado.
 El agregado gestiona la creación y
destrucción de las partes.
 Las partes se pueden eliminar antes de
eliminar el agregado.
 Composición
Ventana agregado /todo

1..1

composición
*
Marco parte
 Composición

POLIGONO

1
Relleno:Diseño

1
{ordered}

{ordered} 3..*

Punto
 Clases Asociación

 Una asociación que también es una clase

 Una clase asociación añade una restricción:
“Sólo puede existir una instancia de la
asociación entre cualquiera par de
objetos participantes”

 No podríamos modelar que una persona tiene

diferentes contratos para una misma compañía
a lo largo del tiempo.
Ejemplo de clase asociación
Ejemplo de clase asociación
Restricciones para Asociaciones
Empresa
Departamento

Cuenta * *
{or}

Persona
{subconjunto}

+miembro 1..* +Director

1..1
Persona
Diagrama de Paquetes
 Paquetes

 Elemento organizativo
 Puede agrupar elementos de cualquier tipo.
 Un elemento es exclusivo a un paquete.
 Establece un espacio de nombres
 Posibilidad de anidar paquetes.

Modelo

Modelo + Producto
+ CarroCompra
+ Comercio
 Importación/Exportación en paquetes

 “Los paquetes permiten controlar la complejidad del

manejo de un gran número de abstracciones,
controlando los accesos mediante la importación”.
 Relaciones de importación, acceso y generalización
 La parte pública de un paquete son sus exportaciones.
 Las partes públicas son visibles en los paquetes que
importan al paquete contenedor.
 La importación no es transitiva.
 Los paquetes anidados pueden ver todo lo que ven los
paquetes que los contienen.
 Cliente

Servidor + FormularioPedido
+ FormularioDeSeguimiento
+ BaseDeDatos - Pedido
+ ServicioDeRegistro

<<import>>

Politicas
+ ReglasPedidos
+ GUI:Ventana

<<import>>
GUI
+ Ventana
+ Formulario
# GestorEventos
Generalización de Paquetes
GUI
+ Ventana
+ Formulario
# GestorEventos

WindowsGUI
+ GUI:Ventana MacGUI
+ Formulario
# GUI:GestorEventos
+ VBForm
 Paquetes

 Un paquete bien estructurado debe:

 ser cohesivo
 estar poco acoplado
 pocos anidamientos
 conjunto equilibrado de elementos
Uso de los paquetes

<<subsystem>> <<layer>>
Pedidos Servicios
Básicos

<<model>> <<framework>>
Diseño Struts
 Uso de los paquetes

 Agrupar elementos relacionados para

manejarlo en conjunto.
Paquete “Clases e interfaces del modelo”
Paquete “Interfaces de usuario”
Paquete “Servicios base de datos”
Paquete “Modelo del análisis”

 Un modelo es un paquete incluyendo todos

los elementos que constituyen una particular
vista del sistema modelado.
 Análisis y Diseño de Sistemas

FIN Sesión 7

UNIVERSIDAD NACIONAL DE INGENIERIA

Facultad de Ingeniería Industrial y de Sistemas
Ing. Jesús Walter Antaurco Trujillo
Wantaurco@yahoo.com