Principos de Diseño de Clases: Phd. Ana María Zambrano V

29/10/2018
PhD. Ana María Zambrano V.
Principos de diseño de Clases
 LEGIBILIDAD DE CÓDIGO:
 Asignar nombres significativos para identificadores de
atributos, variables, y métodos.
 Inicializar los atributos
 EXPERTO EN INFORMACIÓN:
 Asignar una responsabilidad al experto en información, la
clase que tiene la información necesaria para llevar a cabo la
responsabilidad.
1
29/10/2018
Principos de diseño Clases

 FAVORECER LA EXTENSIBILIDAD:
 Utilizar constantes simbólicas significativas.
 Seguir los principios de diseño modular
 OCULTACIÓN DE LA INFORMACIÓN:
 Los atributos de una clase son privados y ofrecer los métodos
de consulta necesarios dependiendo de su nivel de acceso
(set y get).
 Diferenciar entre métodos públicos y métodos privados.
 Para acceder a una constante, ésta debe ser pública en lugar
de ofrecer un método de consulta
Principos de diseño Clases
 ALTA COHESIÓN
 Fragmentar clases que tengan demasiadas responsabilidades.
 BAJO ACOPLAMIENTO
 Ley de Demeter: “Habla sólo con tus amigos ”
2
29/10/2018
 Empleado para especificar, visualizar y documentar

esquemas de sistemas de software orientado a objetos.
 Ayuda a visualizar el diseño de una aplicación.
 Está formado por elementos de esquematización para
representar las partes de un sistema de software.
 Es un lenguaje gráfico para visualizar, especificar,
construir y documentar un sistema.
 No es un lenguaje de programación.
 Diagrama de estado  Muestra estados, cambios de estado y

eventos en un objeto o en parte del sistema.
 Diagrama de actividad  Muestra actividades, así como los cambios
de una a otra actividad junto con los eventos que ocurren en ciertas
partes del sistema.
 Diagrama de componentes  Muestra los componentes de mayor
nivel de la programación (cosas como Kparts o Java Beans).
 Diagrama de implementación  Muestra las instancias de los
componentes y sus relaciones.
 Diagrama de relaciones de entidad  Muestra los datos y las
relaciones y restricciones entre ellos.
 Diagrama de colaboración  Muestra objetos y sus relaciones,
destacando los objetos que participan en el intercambio de
mensajes.
3
29/10/2018
 Diagrama de casos de uso  Muestra a los actores del

sistema, las situaciones que se producen cuando
utilizan el sistema y sus relaciones.
 Diagrama de clases Muestra las clases y la relaciones

entre ellas.
 Diagrama de secuencia  Muestra los objetos y sus

múltiples relaciones entre ellos.
 Caso de uso:
 Ayuda a descubrir que es lo que el sistema debe
hacer.
 Describe las interacciones entre los usuarios de un
Sistema.
 Reglas:
o Cada caso de uso está relacionado como
mínimo con un actor
o Cada caso de uso es un iniciador (es decir, un
actor)
o Cada caso de uso lleva a un resultado relevante
4
29/10/2018
 Caso de uso:
 Actor
o Entidad externa que interactúa con el sistema.
o Función/rol que el usuario va a desempeñar en el
sistema.
o Relación:
 Generalización
Gerente
Empleado
Médico
 Diagrama de casos de uso:

 Caso de uso:
 Representación
Nombre- Registrar Imprimir

Caso-Uso usuario usuario
 Los nombres deben ser:

o Cortos
o Tener un verbo que indique el comportamiento
del sistema
5
29/10/2018
 Diagrama de casos de uso:

 Sistema
 El rectángulo representa los límites del sistema que
contiene los casos de uso. Los actores se ubican fuera
de los límites del sistema.
 Relaciones
 Las relaciones entre un
actor y un caso de uso, se
dibujan con una línea
simple.
 Para relaciones entre casos
de uso, se usan etiquetas
<<include>>
<<exclude>>
6
29/10/2018
 Relación entre casos de uso y actores:

 Relación asociación
Nombre
Caso uso
Número CU
Actor
 Caso de uso:
 Relaciones entre casos de uso
o <<include>> Especifica una situación en la que

un caso de uso tiene lugar dentro de otro caso de
uso.
o <<extends>> Especifica que en ciertas
situaciones, o en algún punto (llamado punto de
extensión) un caso de uso será extendido por
otro.
o Generalización Especifica que un caso de uso
toma las características del «super» caso de uso.
7
29/10/2018
 Relación entre casos de uso:

 Relación <<include>>
Caso Base Registrar pedido
<<Include>>
Caso obligatorio Validar usuario

 Relación <<extends>>
Hacer reservación Caso Base
<<Extends>>
Pagar reservación
Caso opcional
8
29/10/2018

 Relación generalización
Caso abstracto
Pagar reserva
Caso concreto Caso concreto
Pagar con tarjeta Pagar en efectivo
 Caso de uso:
 Notación
Nombre del Sistema

Generalización
Nombre Caso <<include>>
uso <<extends>>
Número CU
Nombre Caso
uso
Número CU
Nombre del
Actor PhD. Ana María Zambrano V.
9
29/10/2018
 Caso de uso:
 Ejemplo: venta en un almacén
Actor 1 Actor 2
Comprar
productos
Registrar datos
Cambiar
Cliente productos Cajero
Ejemplo de caso de uso
10
29/10/2018
Ejemplo de caso de uso
11
29/10/2018
 Muestra las diferentes clases que componen un

sistema y cómo se relacionan unas con otras.
 Detallan las clases, sus atributos y métodos, además
las relaciones estáticas entre ellas.
Nombre de clase
Atributos de clase
M[eMM
Métodos de clase
12
29/10/2018
 Relaciones entre clases:
 Asociación
 Agregación
 Composición
 Generalización / Especialización
 Dependencia
 Asociación
<Descripción>
Clase A <rol A> <rol B> Clase B
<mult A> <mult B>
 Descripción  Nombre de la relación
 rol  Responsabilidad de la clase en la asociación
 Multiplicidad Indica el número de objetos que

participan en la relación
13
29/10/2018
 Asociación
 Asociación
 Multiplicidad Indica el número de objetos que

participan en la relación
Número de Símbolo
objetos
0 ó más *
1 ó más 1..*
De 2 a 6 2..6
Sólo 8 8
14
29/10/2018
 Asociación
Número de Símbolo
objetos
0 ó más *
1 ó más 1..*
De 2 a 6 2..6
Sólo 8 8
 Asociación
 Grado de asociaciónNúmero de clases conectadas por

la asociación
Estudiante Profesor
Universidad
Asociación ternaria
15
29/10/2018
 Agregación y composición
 Agregación
 Un objeto de un tipo, PUEDE contener a otro Relación
tipo “Todo/Parte”.
 Una cosa grande (todo) consta de elementos más
pequeños (partes)
 Se indica por un rombo transparente
Universidad Estudiante
*
Ciudad Aeropuerto
*
16
29/10/2018
 Composición
 Compuesto por..
 Las partes no pueden existir sin que exista el objeto
todo.
 El primero no tiene sentido suelto, y el segundo
necesita definir al primero para ampliar su
significado.
Cuerpo Brazo Avión Ala

2
 Composición
17
29/10/2018
 Ejemplo Composición y Agregación
18
29/10/2018
 Ejemplo Composición y Agregación
 Asociación, Composición y Agregación
19
29/10/2018
 Generalización
 Generalización o Herencia
 Cada instancia de las clases “hijas” es a su vez una
instancia de la clase padre:
Persona
Estudiante Profesor Empleado
20
29/10/2018
 Indica que una subclase

hereda los métodos y
atributos especificados por
una super clase.
 La subclase además de
poseer sus propios
métodos y atributos, y
poseerá los atributos
visibles de la clase padre.
21
29/10/2018
 Dependiencia
 Un cambio en una clase puede afectar a otra clase
que la usa.
Clase_A Clase_B
Atributo1:int
Metodo
(b: Clase_B)
 Dependiencia
22
29/10/2018
 Interfaz
 Una interfaz es un “contrato,”
significa que cualquier clase
que realice dicha interfaz está
obligada a implementar los
métodos de la interfaz.
 A las clases abstractas puras, es
decir, a las clases que no
contienen ninguna
implementación, se les llama
interfaces.
 Una interfaz sólo contiene las
cabeceras de las operaciones,
no su implementación.
23
29/10/2018
 Ejercicio Universidad
 Ejercicio Biblioteca
24
29/10/2018
 Ejercicio Universidad
 Ejercicio Dieta
25
29/10/2018
 Ejercicio Empleado
 Ejercicio Empleado
26
29/10/2018
 Ejercicio Punto de Venta
 Ejercicio GUI
27
29/10/2018
28
29/10/2018
 Ejercicio Artista
 Ejercicio Redes de Ordenadores
29
29/10/2018
Un diagrama de secuencia muestra una

interacción, que representa la
secuencia de mensajes entre instancias
de clases, componentes, subsistemas o
actores
El tiempo fluye por el diagrama y muestra

Permite observar la el flujo de control de un participante a
perspectiva otro.
cronológica de las
interacciones. Es importante
recordar que el diagrama de se enfocan específicamente en las
secuencias se realiza a partir "líneas de vida" de un objeto y cómo se
de la descripción de un caso comunican con otros objetos para
de uso. realizar una función antes de que la
línea de vida termine.
30
29/10/2018
El rol de la clase describe la manera en

que un objeto se va a comportar en el
contexto. No se listan los atributos del
objeto.
Los cuadros de activación representan el tiempo que

un objeto necesita para completar una tarea.
31
29/10/2018
Los mensajes son flechas que representan comunicaciones

entre objetos. Las medias flechas
representan mensajes asincrónicos. Los mensajes asincrónicos son
enviados desde un objeto que no va a esperar una respuesta del
receptor para continuar con sus tareas.
Las líneas de vida son verticales y en línea de puntos, ellas indican

la presencia del objeto durante el tiempo.
32
29/10/2018
Los objetos pueden ser eliminados tempranamente usando una

flecha etiquetada “<<destruir>>” que apunta a una X.
Una repetición o loop en un diagrama de secuencias, es

representado como un rectángulo. La condición para abandonar
el loop se coloca en la parte inferior entre corchetes [ ].
33
29/10/2018
34
29/10/2018
35

Principos de Diseño de Clases: Phd. Ana María Zambrano V

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Principos de Diseño de Clases: Phd. Ana María Zambrano V

Cargado por

Copyright:

Formatos disponibles

29/10/2018

PhD. Ana María Zambrano V.