análisis de sistemasDiagramasOO_Errores_Patrones_Reglas_v2

Vista previa del material en texto

Diagramas OO - Errores - versión 2 - 2016 Página 1 
 
ERRORES EN DIAGRAMAS OO 
E: error 
T: TEORIA -- explicación del por qué esa situación enunciada es un error. 
 
DIAGRAMA DE CASOS DE USO 
E1: la cantidad de Requisitos Funcionales es diferente a la cantidad de CU ppales del Diagrama de 
CU. 
T: la cantidad de Requisitos Funcionales DEBE SER IGUAL a la cantidad de CU ppales del 
Diagrama de CU. 
 
E2: el Diagrama de CU NO tiene todos los CU correspondientes a la Gestión de las clases 
parámetro. 
T: el Diagrama de CU debe tener todos los CU correspondientes la Gestión de las clases 
parámetro. 
Ej: PersonaTipo, DocumentoTipo, Producto. 
 
 
E3: Actor con nombre de empresa / organización. 
Ej: ministerio de educación--- correcto: ministro de educación o responsable del ministerio; 
T: El nombre de actor debe ser un rol. 
 
E4: NO colocar al cliente dentro del Modelo del Negocio (es decir, cuando claramente es actor del 
negocio) 
 
E5: Colocar el actor RELOJ junto a los CU que inicia dentro del Modelo de Negocio. 
T: El actor RELOJ junto a los CU que inicia, no forman parte del Modelo del Negocio. 
 
E6: hacer CU atómicos. 
Ej: “leer estado cliente” y hacer inclusiones a ese Caso de uso atómico. 
Diagramas OO - Errores - versión 2 - 2016 Página 2 
 
T: Un CU es una funcionalidad, es decir, un conjunto de actividades relacionadas lógicamente con 
un objetivo. Un CU no es una sola actividad. 
 
E7: inclusiones a 1 solo caso de uso, es decir, un CU que es incluido por un solo CU. 
T: El objetivo de la inclusión es compartir funcionalidad entre dos o más CU. 
 
E8: nombres de CU ambiguos o incompletos como: “informar”, “datos cliente” 
T: los nombres de los CU deben ser lo suficientemente representativos de la funcionalidad que se 
inicia. 
 
E9: actor sin nombre. 
 
E10: Nombre de Actor que no coincida con actor de la Especificación de ese CU o con el 
correspondiente actor de Diagrama de Clases de la Realización de CU o Diagrama de Colaboración 
o Diagrama de Secuencia o con el Requisito Funcional. 
 
E11: crear una extensión que corresponda a un mensaje de error de una validación 
ej: “error: monto insuficiente” 
T: las extensiones son funcionalidades que se agregan a la funcionalidad del CU llamador cuando 
se cumple una condición excepcional. Las extensiones NO son resultados de condiciones de error 
de validaciones simples que se ejecutan en el CU llamador. 
 
E12: CU iniciado por mas de 1 actor. 
T: Se debe usar generalización de actores o crear un actor abstracto 
 
Diagramas OO - Errores - versión 2 - 2016 Página 3 
 
 
E13: poner como CU una acción que hace un actor. 
ej: inspector verifica vehículo para luego informar el resultado al sistema. 
T: El nombre del CU representa la funcionalidad que inicia el actor con el sistema. 
 MAL 
 bien 
Diagramas OO - Errores - versión 2 - 2016 Página 4 
 
DIAGRAMA DE CLASES 
E1: colocar clases que son Clases de Interfaz o de Control del Diagrama de Clases de la 
Realización de CU. 
T: el Diagrama de Clases está formado por todas las clases ENTIDAD de todos los Diagramas de 
Clases de la Realización de todos los CU. Sin repetir clases. 
 
E2: Colocar clases que no correspondan a ninguna Clase Entidad de ningún Diagrama de Clases 
de la Realización de CU. 
 
E3: colocar como clase un atributo de una clase. 
Ej: clase con nombre ExamenFecha 
 
E4: colocar un atributo que contiene varios valores. 
Ej: precios, vigencia (que tiene inicio y fin) 
 
E5: asociaciones entre clases sin cardinalidad. 
 
E6: asociaciones entre clases con cardinalidad 1:1 
ATENCION: revisar si es correcta esta cardinalidad, revisando los atributos de las clases. 
 
E7: que falten 2 o más clases importantes para el dominio del problema. 
 
E8: Herencia: subclases con = atributos; subclases vacías o con solo el atributo Nro… o repetir 
atributo tanto en superclase como en subclase. 
 
E9: colocar una clase con nombre INFORME / LISTADO / CONSULTA / REPORTE; donde 
claramente ese INFORME es la salida de una funcionalidad que lee datos de objetos guardados y 
produce información con algún formato determinado como salida. 
 
E10: colocar métodos con nombre de atributos: Multa(), Total(), … correcto: CalcularMulta() 
 
E11: colocar una clase con el objeto de armar un HISTORIAL, pero sin el atributo fecha (que es 
fundamental) 
 
E12: colocar una clase llamada HISTORIAL… 
ej: HISTORIAL PEDIDOS incorrecto, lo correcto es PEDIDO. 
 
E13: nombre de una clase en plural. 
T: Correcto: en singular. 
Diagramas OO - Errores - versión 2 - 2016 Página 5 
 
 
E14: atributo llamado “datos”, “detalles”, “información”… datos de qué??? Nombre 
ambiguo/incompleto. 
 
E15: poner como atributos de una clase los valores de un atributo de esa clase. 
Ej clase EstadoContrato con atributos: “Pendiente”, “Aprobado”, “Liquidado”. 
 incorrecto 
 correcto 
 
E16: poner composición / agregación cuando solo es asociación simple. 
 
E17: poner como atributo un dato calculado: atributo SubTotal en clase FacturaDetalle 
T: los Datos Calculados son atributos que pueden ser obtenidos en base al valor de otros atributos 
que sí están guardados, y pueden recalcularse en cualquier momento. En Analisis OO estos datos 
no son atributos de clases. 
 
E18: no completar los métodos de las clases una vez ya finalizados los Diagramas de Colaboración 
(o Diagramas de Secuencia), es decir, no balancear los Diagramas. 
T: los métodos de una clase son los mensajes entrantes a ese objeto dentro de los Diagramas de 
Colaboración / Secuencia. 
 
E19: no implementar correctamente generalización-especialización. 
 MAL 
 
Diagramas OO - Errores - versión 2 - 2016 Página 6 
 
 BIEN 
 
E20: colocar cardinalidad en un solo extremo de una asociación entre clases. 
T: En una asociación entre clases, ambos extremos deben tener cardinalidad. 
 
E21: colocar cardinalidad a asociaciones de tipo Herencia entre clases. 
T: Las asociaciones entre clases de tipo Herencia, no poseen cardinalidad. 
 
E22: No colocar correctamente la cardinalidad de asociaciones entre clases, con minimo y máximo 
en ambos extremos, cuando el dominio del problema claramente lo especifica. 
 Ejemplos de multiplicidades: 1..* 2..4 1, 3-7, 25 
 
Determinación de la multiplicidad 
Siempre se debe tomar un objeto de la clase de un extremo y preguntarse con cuántos objetos 
se relaciona en cada uno de los otros extremos, como mínimo y como máximo. Después se 
repite el procedimiento para cada extremo 
 
UN vendedor realiza 0..* ventas 
Diagramas OO - Errores - versión 2 - 2016 Página 7 
 
 
 
 
 
 
 
 
UNA venta es realizada por 1..1 vendedores 
 
• Cuando el mínimo no sea cero (por ejemplo, 1..*) o cuando el máximo no sea muchos (por 
ejemplo, 0..1), se debe intentar extender la multiplicidad 
• En el caso del mínimo se debe preguntar si existen casos especiales que exijan cero 
• En el caso del máximo se debe preguntar si es necesario recordar la historia de las 
asociaciones 
 
Diagramas OO - Errores - versión 2 - 2016 Página 8 
 
ESPECIFICACIÓN DE CASO DE USO 
E1: no decir a cuál CU corresponde la Especificación. 
 
E2: no completar actor iniciador o CU que lo invoca (inclusión / extensión ) 
 
E3: no completar la precondición (si la tuviera) / postcondición. 
 
E4: poner en columna del actor estructuras repetitivas o condicionales o alternativas…. 
T: Eso lo ejecuta el sistema. 
 
E5: no completar el punto Consideración de Diseño con el Requisito no Funcional correspondiente 
(si lo tuviera). 
 
E6: no estar balanceado con Colaboración, clases, diagrama de CU, DTE 
 
E7: hacer referencia a objetos de una clase que no esté en Diagrama de Clases. 
 
E8: hacer referencia a ARCHIVO…. O la palabra ARCHIVAR… 
T: En OO no hay archivos. Correcto: GUARDAR, actualizar, .. 
 
E9: incluir acciones físicas como: alumno presenta papeles, gerente entregamercaderia 
 
E10: actor. Verbos: solicitar…, seleccionar alguna opción, ingresar datos de …., cancelar, elegir 
opción, informar … 
 
E11: no terminar adecuadamente un camino básico (en SISTEMA): 
- Guardar info de …… o Crear objeto ……. 
- Cambiar estado del objeto ….. al valor …… (balanceado con DTE) 
- Mostrar mensaje “operación exitosa” (al actor) 
- Imprimir comprobante de la transacción realizada [ej: inscripción, venta, entrega, etc ] 
- ………. 
- Fin caso de uso. 
 
 
Diagramas OO - Errores - versión 2 - 2016 Página 9 
 
DIAGRAMA DE TRANSICIÓN DE ESTADOS ( D.T.E. ) o 
MÁQUINA DE ESTADOS 
E1: no colocar como título de este diagrama a cuál objeto corresponde. 
 
E2: Estado sin transiciones entrantes. 
 
E3: Estado sin transiciones salientes. 
 
E4: Estado con nombre como “Realizar Pedido”, que es el nombre de algún Caso de Uso 
 
E5: bifurcaciones en las transiciones 
T: no existen las bifurcaciones sobre las Transiciones. 
 
 MAL 
 
 
 Bien 
 
E6: Transiciones vacías. 
T: Deben tener: evento-disparador / [condición-de-guarda] / acción del sistema … o 1 o 2 o los 3. 
 
E7: no indicar el estado inicial. 
 
E8: tener mas de 1 estado inicial. 
T: El Estado inicial es uno. 
 
E9: Estados que no son mutuamente excluyentes. 
 
E10: no estar balanceado con diagrama de CU. 
ej: que haya una transición de un estado a otro, pero que no exista el CU que tiene la actividad que 
realiza ese cambio de estado. 
 
E11: no estar balanceado con el DClases. 
T: El DTE debe hacer referencia a un objeto de una clase que está en el DClases. 
 
E12: no estar balanceado con Especificación de CU. 
T: Cada transición del DTE debe poder ser localizada como una actividad dentro de la 
Especificación de algún CU. 
Diagramas OO - Errores - versión 2 - 2016 Página 10 
 
DIAGRAMA DE COLABORACIÓN 
E1: No colocar como título de este diagrama a cuál CU corresponde. 
 
E2: la cantidad de Diagramas de Colaboración es diferente a la cantidad de Diagramas de Clases 
de la Realización de CU. 
T: la cantidad de Diagramas de Colaboración DEBE SER igual a la cantidad de Diagramas de 
Clases de la Realización de CU. (y también igual a la cantidad de Diagramas de Secuencia) 
 
E3: poner un atributo de una clase como objeto. 
ej: objeto llamado DNI (es atributo de clase Persona, no es clase en sí mismo) 
T: se deben dibujar los objetos, no los atributos de esos objetos. 
 
E4: Enlaces sin mensajes entre 2 objetos. 
T: Un enlace debe tener al menos 1 mensaje de un objeto a otro. Si no ocurre esto, el enlace no es 
necesario, debe ser eliminado. 
 
E5: bifurcaciones en los enlaces entre objetos. (Idem a E5 en DTE) 
T: un enlace une 1 objeto con 1 objeto. 
 
E6: ausencia de objeto Interfaz entre actor y objeto Gestor o Control, es decir, enlace directo entre 
actor y objeto Gestor / Entidad. 
T: no puede estar ausente el objeto Interfaz. 
 
E7: no estar balanceado con Diagrama de CU. 
T: llamadas a extensiones / inclusiones deben estar presentes. 
 
E8: no estar balanceado con Especificación de ese CU. 
T: la secuencia de mensajes debe ser coincidente con la secuencia de actividades de la 
Especificación de ese CU. 
 
E9: poner un objeto (Entidad) que no se encuentre en Diagrama de Clases. 
 
E10: no colocar objeto Gestor (Control) en caso de uso de complejidad media o alta. 
 
E11: colocar objeto llamado “sistema”, es decir, el mismo sistema que está siendo analizado. 
 
E12: colocar objeto RELOJ (actor) como objeto Entidad. 
 
E13: colocar objeto Entidad GERENTE. 
Diagramas OO - Errores - versión 2 - 2016 Página 11 
 
ej, cuando GERENTE es solo un cargo, un actor. 
 
E14: que falten más de 2 objetos principales (que sí estén en Diagrama de Clases y Diagrama de 
clases de la realización de CU de ese caso de uso) 
 
E15: que falte la extensión (si ese CU la tuviese en Diagrama de CU) 
 
E16: mensaje sin numeración / sentido de la flecha / sin nombre / sin parentesis () 
 
E17: Los objetos se representan con un rectángulo con el nombre después de : y subrayado. 
 
 
 
E18: que no esté balanceado con Diagrama de Realización, en cuanto a los objetos Interfaz, Gestor 
y Entidad. 
 
 
DIAGRAMA DE PAQUETES 
E1: no poner algunos CU / clases / GUI que están presentes en las otras herramientas. 
E2: poner clases con las relaciones entre ellas. 
E3: poner actores, es decir, el símbolo hombrecito. 
E4: no estar balanceado con Diagrama de Clases ni con el Diagrama de CU. 
E5: no poner la dirección de la flecha que representa la relación de dependencia. 
E6: poner un CU / clase en más de un paquete 
E7: que algún CU / clase no esté presente en ningún paquete 
 
 
: Alumno 
Diagramas OO - Errores - versión 2 - 2016 Página 12 
 
DIAGRAMA DE CLASES DE LA REALIZACIÓN DE CASOS DE 
USO 
E1: No colocar como título de este diagrama a cuál CU corresponde. 
 
E2: la cantidad de Diagramas de Clases de la Realización de CU es diferente a la cantidad de 
Diagramas de Colaboración. 
T: la cantidad de Diagramas de Clases de la Realización de CU DEBE SER igual a la cantidad de 
Diagramas de Colaboración. (y también igual a la cantidad de Diagramas de Secuencia) 
 
E3: colocar un atributo de una clase como objeto Entidad. 
ej: objeto Entidad llamado ClienteNombre ( que es atributo de clase Cliente, no es clase en sí 
mismo) 
 
E4: colocar un estereotipo (Interfaz, Control, Entidad) sin su nombre correspondiente. 
 
E5: bifurcaciones en los enlaces entre objetos. (Idem a E5 en DTE) 
T: un enlace une 1 objeto con 1 objeto. 
 
E6: ausencia de objeto Interfaz entre actor y objeto Gestor / Entidad, es decir, enlace directo entre 
actor y objeto Gestor / Entidad. 
T: no puede estar ausente el objeto Interfaz. 
 
E7: no estar balanceado con Diagrama de CU. 
T: llamadas a extensiones / inclusiones deben estar presentes. 
 
E8: colocar un objeto (Entidad) que no se encuentre en Diagrama de Clases. 
 
E9: no colocar objeto Gestor (Control) en caso de uso de complejidad media o alta. 
E10: colocar objeto llamado “sistema”, cuando ese “sistema” es el mismo sistema que está siendo 
analizado. 
E11: colocar objeto RELOJ (actor) como objeto Entidad. 
E12: colocar objeto Entidad GERENTE. 
ej, cuando GERENTE es solo un cargo, un actor. 
 
E13: que falte la extensión (si ese CU la tuviese en Diagrama de CU) 
 
E14: que no esté balanceado con Diagrama de Colaboración, en cuanto a los objetos Interfaz, 
Gestor y Entidad. 
Diagramas OO - Errores - versión 2 - 2016 Página 13 
 
ALGUNOS PATRONES: 
1- Para modelar transacciones de negocio, el modelo generalmente se presenta así: 
 
2- Para modelar stock hay tres posibilidades de modelado; 
a. la primera es cuando no es necesario diferenciar un elemento del otro 
ej: lata de tomate perita de 200gr, 30 $, 318 unidades 
 
b. la segunda es cuando es necesario diferenciar unívocamente cada elemento: 
ej: biblioteca: tengo 5 libros de Análisis Matemático del autor Lopez, 345 $. 
 
c. la tercera es cuando es necesario diferenciar los elementos en grupos de elementos: 
ej: farmacia: leche en polvo, lata de 1kg, 120 $; del lote AAD tengo 17 latas; del lote 
BBF tengo 25 latas. 
Diagramas OO - Errores - versión 2 - 2016 Página 14 
 
 
3- Eliminación de redundancias 
 
 
4- Criterios para generalizar 
 
Diagramas OO - Errores - versión 2 - 2016 Página 15 
 
 
5- Generalización a entidades 
 
Método: “Todas las clases” 
 
Método: “Sólo las superclases” 
 
 
Diagramas OO - Errores - versión 2 - 2016 Página 16 
 
Método: “Sólo las subclases” 
 
Diagramas OO - Errores - versión 2 - 2016 Página 17 
 
ALGUNAS REGLAS PARA LOS DIAGRAMAS DE CLASES 
1- Determinar el nivel de abstracción 
 
2- Regla de Atributos como clases: todo atributo que pueda ser modelado como clase, DEBE 
ser modelado como clase 
 
3- Regla de “atributo de clase”: los atributos pertenecen naturalmente a las clases que 
respondena la estructura “atributo DE clase” 
Diagramas OO - Errores - versión 2 - 2016 Página 18 
 
 
4- Regla de “tipo de”: los tipos de instancias que no poseen comportamientos diferentes se 
deben modelar como “tipos de”, caso contrario se debe emplear generalización (o 
posiblemente agregación en el diseño físico) 
 
 
 
 
5- Regla de identificadores: no se deben incluir atributos identificadores, a menos que existan 
en la realidad. Algunos identificadores que existen en la realidad son: número de documento 
(id. de una persona), número de teléfono (id. de una línea telefónica), patente (id. de un 
auto), etc. 
Sólo se pueden tener identificadores no existentes en la realidad en los casos en que lo 
exija el cliente de la aplicación como requisito explícito (por ejemplo: “quiero tener un 
número de proveedor”) 
 
 
 
 
 
Una clase asociación es una asociación que se modela como clase 
Objetos Con comportamientos diferentes 
Objetos Sin comportamiento diferente 
Diagramas OO - Errores - versión 2 - 2016 Página 19