Analisis y Diseño de Sistemas Orientada A Objetos - Semana 9v2

Análisis y Diseño de Sistemas Orientado a
Objetos
Mg. Daniel Arias, PMP™ y Scaled Scrum Master™

Analizar la Arquitectura como parte de
la Disciplina de Análisis & Diseño
Semana 9
Semana 9: Analizar la Arquitectura como parte de la Disciplina de Análisis & Diseño
Logro de aprendizaje Actividades
• Artefactos de Entrada Actividad 09:

• Modelo de Diseño • Elabora y presenta las Clases de
• Glosario análisis y la realización de casos de
• Especificaciones usos.
complementarias
• Modelo de Caso de Uso
• Realización de caso de uso
• Artefacto de Salida
• Realización de casos de Uso
(Diagrama de clases de análisis)
• Rol Diseñador
Aprendemos:
¿Qué aprendimos la clase pasada?
• Arquitecturas de Software
• Monolítico
• Cliente-Servidor
• Peer-to-peer (P2P)
• Arquitectura en Capas
• Microkernel
• Service-Oriented Architecture (SOA)
• Microservicios
Conversemos
http://www.menti.com
Aprendemos:
Actores de Sistemas
Un actor es una entidad externa al sistema que se modela

y que puede interactuar con el.
Puede ser una persona -o un grupo de personas
homogéneas-, otro sistema u otra máquina.
Los actores son externos al sistema que vamos a
desarrollar. Por lo tanto, estamos comenzando a delimitar
el sistema y a definir su alcance.
Los actores se representan con dibujos llamados “stick
man” (hombres de palo)
Aprendemos:
Actores de Sistemas (Cont.)
El actor existe fuera del Sistema e interactúa con

éste de manera específica.
Un actor puede ser un humano, otro Sistema o un
dispositivo como un teclado o una conexión Web.
Los actores pueden iniciar una instancia de un
Caso de Uso.
Un actor puede interactuar con uno o más Casos
de Uso; un Caso de Uso puede involucrar a uno o
mas actores.
Aprendemos:
Casos de Uso del Sistema
Establece un acuerdo entre clientes y desarrolladores sobre

las condiciones y posibilidades (requisitos) que debe cumplir
el sistema.
Artefacto narrativo que describe, bajo la forma de acciones y reacciones,
el comportamiento del sistema desde el punto de vista del usuario
(Jacobson).
Descripciones de la funcionalidad del sistema independientes

de la implementación.
Aprendemos:
Definición de Requisitos
Es el proceso de averiguar, por lo general en circunstancias difíciles, lo
que se debe construir.
Los usuarios deben
saber lo que quieren
• Cada uno sabe lo que hace, pero ninguno tiene una visión global
• No saben cómo puede hacerse más eficiente la operación en su
conjunto.
• No saben qué parte de su trabajo puede transformarse en software.
Aprendemos:
Requisito funcional
“Una capacidad o condición que el sistema cumplirá”
Desarrolladores Clientes y Usuarios
Requisitos
Aprendemos:
Relaciones entre Casos de Uso
Para empezar, diremos que los Casos de Uso fueron ideados por Jacobson a
principios de los noventa y están inspirados en el concepto de escenario, el
cual previamente había sido utilizado para describir procesos. Los Casos de
Uso especifican un comportamiento deseado del sistema, representan
requisitos funcionales del mismo. Es importante resaltar que describen qué
hace el sistema, no cómo lo hace. UML nos dice que: “Un caso de uso
especifica un conjunto de secuencias de acciones, incluyendo variantes, que
el sistema puede ejecutar y que produce un resultado observable de valor
para un particular actor”. Los Casos de Uso nos sirven de base para elaborar
los aspectos funcionales del pliego de condiciones y nos dan soporte en las
etapas de modelado, desarrollo y validación de software.
Aprendemos:
Relaciones entre Casos de Uso (Cont.)
Como veremos, en los diagramas de CU se muestran: CU (representados en

forma de elipses), actores (en forma de personajes) y relaciones (en forma de
líneas y/o flechas). UML define cuatro tipos de relaciones:
• Comunicación: Relación (asociación) entre un actor y un caso de uso. El
estereotipo de la relación de comunicación es: <<communicate>> aunque
generalmente no se estipula ningún nombre, como podemos apreciar en el
siguiente ejemplo de comunicación:
Aprendemos:
• Inclusión: Un CU base incorpora explícitamente el comportamiento

de otro en algún lugar de su secuencia. La relación de inclusión sirve
para enriquecer un CU con otro y compartir una funcionalidad común
entre varios casos de uso, también puede utilizarse para estructurar
un CU describiendo sus subfunciones. El CU incluido existe
únicamente con ese propósito, ya que no responde a un objetivo de
un actor.
Estas relaciones se representan mediante una flecha discontinua con
el estereotipo <<include>>. Algunos casos de uso típicos de inclusión
son: comprobar, verificar, buscar, validar, autentificar o login…
Aprendemos:
En principio, no deberíamos abusar de este tipo de relación, para no

hacer una descomposición funcional del sistema.
Veamos un ejemplo de inclusión entre CU:
Aprendemos:
• Extensión: Un CU base incorpora implícitamente el comportamiento

de otro CU en el lugar especificado indirectamente por este otro CU.
En el CU base, la extensión se hace en una serie de puntos concretos
y previstos en el momento del diseño, llamados puntos de extensión,
los cuáles no son parte del flujo principal. La relación de extensión
sirve para modelar: la parte opcional del sistema, un subflujo que
sólo se ejecuta bajo ciertas condiciones o varios flujos que se pueden
insertar en un punto determinado. Este tipo de relación produce
confusión y no debería utilizarse en exceso. Conviene su uso sólo para
insertar un nuevo comportamiento no previsto en un CU existente.
Aprendemos:
Estas relaciones se representan mediante una flecha discontinua con

el estereotipo <<extend>>.
Veamos un ejemplo de extensión:
Aprendemos:
• Especialización y generalización de los CU: Un CU (subcaso) hereda

el comportamiento y significado de otro, es decir las relaciones de
comunicación, inclusión y extensión del super-caso de uso. En
muchas ocasiones este super-caso de uso es abstracto y corresponde
a un comportamiento parcial completado en el subcaso de uso. O
dicho de otra manera, Los CU “hijo” son una especialización del CU
“padre”. En la medida de lo posible debería evitarse puesto que
produce cierta confusión en algunas ocasiones.
Aprendemos:
Veamos un ejemplo de generalización:

super-caso de uso abstracto
Resolver Consulta
Profesional
especializa generaliza
Herencia
entre actores
Resolver Consulta
Jurídica
Abogado subcaso de uso
Resolver Consulta
Psicológica
Psicólogo
subcaso de uso
Aprendemos:
Como vemos en este último ejemplo también pueden existir vínculos

de generalización o herencia entre actores. Los actores especializados
(Abogado y Psicólogo) heredan los CU del actor general (Profesional).
La punta de flecha apunta al actor más general. Hay que reseñar que
los actores especializados pueden tener otros CU propios que no
estarán disponibles para los demás actores. Este tipo de herencia
entre actores si que se usa frecuentemente puesto que nos simplifica
considerablemente el diagrama, nos ahorra un número importante
de relaciones de comunicación entre actores y CU y sirve para
esclarecer visualmente la jerarquía entre actores del sistema.
Aprendemos:
Guía para ser exitoso con los casos de uso
Caso de Uso: Un CU expresa todas las formas de usar un sistema para

alcanzar una meta particular para un usuario. En conjunto, los CU le
proporcionan todos los caminos útiles de usar el sistema e ilustran el
valor que este provee.
Casos de Uso 2.0: Es una práctica escalable y ágil que emplea los CU
para capturar un conjunto de requisitos y conducir el desarrollo
incremental de un sistema que los realice.
Los CU 2.0 conducen el desarrollo de un sistema ayudándole, en
principio, a entender cómo se empleará el sistema y luego ayudándole a
evolucionar un sistema apropiado que apoye a los usuarios.
Aprendemos:
Esta técnica se puede usar junto con prácticas administrativas y técnicas

seleccionadas para apoyar el desarrollo exitoso de software y otras formas
de sistemas. Cómo se verá más adelante, los CU 2.0 son:
• Livianos
• Escalables
• Versátiles
• Fáciles de usar
Los CU dejan claro lo que hará un sistema y, por omisión intencional, lo que
no hará. Estos posibilitan una visión efectiva, el manejo del alcance y el
desarrollo incremental de sistemas de cualquier tipo y cualquier tamaño
Primeros Principios
Hay seis principios básicos en el corazón de cualquier aplicación exitosa de

los CU:
1. Mantenerlos simples al narrar historias
2. Entender el panorama general
3. Enfocarse en el valor
4. Construir el sistema por partes
5. Entregar el sistema en incrementos
6. Adaptarse para cubrir las necesidades del equipo
Primeros Principios

La narración de historias permite a las culturas sobrevivir y
progresar; es el camino más simple y más efectivo para pasar el
conocimiento de una persona a otra. Es la mejor manera de
comunicar lo que un sistema debe hacer y hacer que todo el mundo
trabaje en el sistema sobre los mismos objetivos.
Los CU capturan las metas del sistema. Para entender un CU
narramos historias. Las historias cubren la manera de alcanzar una
meta exitosamente y la manera de manejar cualquier problema que
ocurra en el camino.
Los CU proporcionan una forma de identificar y capturar todas las

historias diferentes, pero relacionadas de una manera simple,
aunque detallada. Esto posibilita que los requisitos del sistema se
capturen, compartan y entiendan fácilmente.
Como un CU se enfoca en el logro de una meta particular, este
proporciona un medio para narrar historias. En vez de intentar
describir el sistema de una sola vez, podemos hacerlo un CU a la vez.
Los resultados de la narración de historias se capturan y presentan
como parte de la narrativa del caso de uso, que acompaña a cada
caso de uso.
Cuando usamos la técnica de la narración de historias para

comunicar los requisitos, es esencial asegurarnos que las
historias se capturen de una forma que las haga accionables
y verificables. Un conjunto de casos de prueba acompaña
cada narrativa de casos de uso para completar la descripción
del CU. Los casos de prueba son la parte más importante de
la descripción de un CU, más importante aún que la narrativa
del CU. Esto es así porque los casos de prueba hacen
realidad las historias y su uso puede demostrar sin
ambigüedad que el sistema hace lo que se supone que haga.
Primeros Principios

Sin importar si el sistema que está desarrollando es grande o
pequeño, o si es un sistema de software, uno de hardware o un
nuevo negocio, es esencial que se entienda el panorama general. Sin
entender el sistema como un todo, será imposible tomar las
decisiones correctas acerca de lo que incluye el sistema, lo que
estará por fuera, lo que costará y el beneficio que proporcionará.
Esto no significa capturar todos los requisitos de una sola vez. Tan
solo es necesario crear algo que resuma el sistema deseado y
permita entender el alcance y el progreso a nivel del sistema.
El diagrama de casos de uso para un sistema telefónico simple
Recuperar
Hacer información
llamada local de
facturación
Sistema de
Facturación
Hacer
Suscriptor que llama Suscriptor al Consultar
llamada de
que llaman historial de
larga
llamadas
distancia
Cliente
Un diagrama de CU es una forma simple de presentar una visión

general de los requisitos de un sistema. En el ejemplo anterior se
pueden ver todas las formas en las que el sistema se puede usar, quién
inicia la interacción y todas las partes involucradas. Por ejemplo, un
Suscriptor que llama puede hacer una llamada local o una llamada de
larga distancia a cualquiera de los Suscriptores a los que se llaman en el
sistema. También es posible ver que los usuarios no tienen que ser
personas sino que también pueden ser otros sistemas y, en algunos
casos, ambos (por ejemplo, una máquina contestadora, y no una
persona, podría desempeñar el rol de Suscriptor que llama).
Primeros Principios
Cuando intentamos entender cómo se empleará un sistema, siempre
es importante enfocarse en el valor que este prestará a sus usuarios
y a otros interesados. Solo se genera valor si el sistema se usa
realmente; así, es mejor enfocarse en cómo se empleará el sistema
que en las largas listas de funciones o características que ofrecerá.
La estructura de la narrativa de un caso de uso
FLUJO BÁSICO FLUJOS ALTERNATIVOS
1. Insertar Tarjeta A1 Tarjeta Inválida
2. Validar Tarjeta A2 Cantidad No-estándar
3. Seleccionar retiro de efectivo A3 Recibo Requerido
4. Seleccionar cuenta A4 Fondos insuficientes en ATM
5. Confirmar disponibilidad de fondos A5 Fondos insuficientes en cuenta
6. Retornar Tarjeta A6 Causaría sobregiro
7. Entregar efectivo A7 Tarjeta atascada
A8 Efectivo dejado atrás
etc…
Los CU proporcionan este enfoque concentrándose en cómo se

empleará el sistema para alcanzar las metas específicas de un usuario
particular. Estos CU encierran muchas formas de usar el sistema:
aquellas que alcanzan exitosamente las metas del sistema y aquellas
que manejan los problemas que pueden ocurrir. Para cuantificar,
identificar y entregar fácilmente el valor, es necesario estructurar la
narrativa del CU. Para mantener las cosas simples, inicie con el camino
más fácil para conseguir la meta. Luego, capture todas las formas
alternativas de alcanzar la meta y cómo manejar cualquier problema
que pueda ocurrir mientras trata de lograr el objetivo. Esto hará que las
relaciones entre las formas de emplear el sistema estén claras.
Además, permitirá que se identifiquen y evolucionen las formas de más

valor y también que las de menos valor se adicionen posteriormente sin
estropear o cambiar lo que ya se hizo.
No es necesario capturar todos los flujos al mismo tiempo. Mientras se
registra el flujo básico, es natural pensar en las otras formas de
conseguir el objetivo y en lo que puede resultar mal en cada paso.
Usted captura esto como Flujos Alternativos, pero se concentra en el
Flujo Básico. Siempre es posible regresar a completar los flujos
alternativos a medida que se necesiten.
Primeros Principios

La mayoría de los sistemas requieren mucho trabajo antes de que sean
usables y estén listos para uso operacional. Tienen muchos requisitos, la
mayoría de los cuales dependen de otros requisitos que se están
implementando antes de que se puedan
satisfacer y entregar con valor. Siempre
es un error intentar construir un sistema
de una sola vez. El sistema se debería
construir por partes, cada una de las
cuales tiene un valor claro para sus
usuarios.
La receta es bien simple. Primero, identifique el aspecto más útil que el

sistema debe hacer y enfóquese en eso. Luego, tome ese aspecto y
divídalo en porciones más pequeñas. Defina los casos de prueba que
representen la aceptación de cada una de esas porciones. Hágalos a un
lado por el momento. Seleccione la porción más importante que viaje por
todo el concepto de principio a fin, o lo más cercano a eso que se pueda.
Estime el desarrollo en equipo (las estimaciones no tienen que estar
“correctas”, son simples estimados) y comience a construir.
Esta es la estrategia que siguen CU 2.0, donde los CU se dividen para
proveer elementos de trabajo de tamaño adecuado y donde el sistema
mismo evoluciona porción por porción.
Dividir los casos de uso

La mejor forma de encontrar las porciones correctas es pensar en las
historias y en cómo las capturamos. Cada historia es una buena
porción candidata. Cada historia se define con una parte de la
narrativa del CU y uno o más de los casos
de prueba acompañantes. Son los casos
de prueba la parte más importante de la
descripción de esta porción del CU,
porque son los que hacen reales las
historias.
4. Construir el sistema por partes - Dividir los casos de uso
Aplicando nuestra receta de arriba, los CU identifican las cosas útiles

que el sistema hará. Seleccione el CU más útil para encontrar la cosa
más útil que el sistema hace. Para encontrar la porción más útil usted
necesitará hacer a un lado todas las formas menos importantes de
lograr el objetivo y de manejar los problemas. Esto se puede hacer
enfocándose en la historia que describe el flujo básico. Una porción
basada en el flujo básico se garantiza que viaja por todo el concepto,
de principio a fin, puesto que este será el camino más simple para el
usuario de alcanzar su meta.
4. Construir el sistema por partes - Dividir los casos de uso
Estime la porción y comience a construirla. Las porciones adicionales se

pueden tomar del CU hasta que haya suficientes porciones para entregar
una solución usable a este usuario en particular. Lo mismo se puede hacer
para cualquier otro CU que sea necesario para completar un sistema
usable.
Una porción de CU no necesariamente contiene un flujo completo y todos
sus casos de prueba: la primera porción puede ser tan solo el flujo básico y
un caso de prueba. Porciones adicionales se pueden agregar luego para
completar el flujo y cubrir todos los casos de prueba. El mecanismo de
partición es muy flexible, permitiendo que se creen porciones tan grandes
o tan pequeñas como sea necesario para conducir el desarrollo.
Las porciones son más que solo requisitos y casos de prueba

Cuando construimos el sistema por partes, no es suficiente con solo
dividir los requisitos. Aunque tradicionalmente los CU se usan para
ayudar a entender y a capturar los requisitos, siempre fueron más
que esto.
4. Construir el sistema por partes - Las porciones son más que solo requisitos y casos de prueba
Como vimos en el ejemplo, las porciones de casos de uso dividen más

que los requisitos, también dividen todos los otros aspectos del sistema
y su documentación.
En el lado izquierdo se puede ver la porción del CU, que se tomó de uno
de los CU que se muestran en la siguiente columna. La porción luego
continúa hacia el diseño, mostrando los elementos de diseño
involucrados, y hacia la implementación, donde se puede ver cuales
piezas del código realmente implementan la porción. Finalmente, la
porción se corta en activos de prueba, no solo abarcando los casos de
prueba, sino también los guiones de prueba usados para ejecutar los
casos de prueba y los resultados de prueba generados.
4. Construir el sistema por partes - Las porciones son más que solo requisitos y casos de prueba
Tratando cada aspecto del sistema porción por porción, los CU

ayudan en todas las áreas del sistema, incluyendo la experiencia de
usuario (interfaz de usuario), arquitectura, pruebas y planeación. Las
porciones proporcionan una forma de vincular los requisitos con las
partes del sistema que los implementan, las pruebas se emplean
para verificar que los requisitos se implementen exitosamente, al
igual que la versión y los planes de proyecto que conducen el trabajo
de desarrollo. En los CU 2.0 hay una construcción especial, llamada la
realización del CU, la cual se adiciona a cada CU para registrar su
impacto en los demás aspectos del sistema.
Porciones de Casos de Uso: La parte más importante de los CU 2.0

El concepto de una porción de CU es tan integral a los CU 2.0 como el CU
mismo. Son las porciones las que posibilitan que los CU se dividan en piezas
de tamaño apropiado para que las atienda el equipo de desarrollo. Imagine
que usted hace parte de un equipo pequeño que está produciendo software
funcional cada dos semanas. Un CU completo es probablemente mucho
para completar en un período de dos semanas. Sin embargo, una porción de
CU es otra cosa, porque se puede dividir en una parte tan pequeña como el
equipo requiera. Las porciones de CU también permiten que el equipo se
enfoque en entregar un sistema usable, con valor, tan pronto como sea
posible, dejando en el camino todos los requisitos innecesarios.
Primeros Principios

La mayoría de los sistemas de software evolucionan a lo largo de
muchas generaciones. No se producen de una sola vez, sino que se
construyen como una serie de versiones, cada una de las cuales se
implementa sobre la anterior. Aun las versiones mismas no se producen
de una sola vez, sino que evolucionan luego de una serie de
incrementos. Cada incremento arroja una versión demostrable o usable
del sistema. Cada incremento se construye sobre el incremento previo
para adicionar más funcionalidad o mejorar la calidad de lo que se hizo
antes. Esta es la forma en que se deberían producir todos los sistemas.
Casos de Uso, Porciones de Casos de Uso, Incrementos y Versiones

Primeros Principios

Desafortunadamente, no hay una solución “única” para todos los
desafíos del desarrollo de software: equipos diferentes y situaciones
diferentes requieren estilos diferentes y niveles diferentes de detalle.
Sin importar cuales prácticas y
técnicas se seleccionan, es necesario
asegurarse de que estas son lo
suficientemente adaptables para
cubrir las necesidades actuales del
equipo.
Los CU 2.0 se diseñaron con esto en mente y son tan livianos como
se requiera que sean. Equipos pequeños y colaborativos pueden
tener narrativas de CU muy livianas que capturen lo estrictamente
necesario de las historias. Estas se pueden escribir a mano en
simples tarjetas indexadas.
Equipos distribuidos grandes pueden tener narrativas de CU más
detalladas y que se presenten como documentos. Depende del
equipo decidir si es necesario ir más allá de lo esencial, adicionando
detalles de una manera natural a medida que se encuentren
problemas que lo esencial no pueda cubrir.
Aprendemos:
Contenido de los Casos de Uso 2.0
Los Casos de Uso 2.0 constan de un conjunto de cosas con las cuales
trabajar y un conjunto de cosas por hacer.
Cosas con las cuales trabajar
El asunto de los CU 2.0 lo constituyen: los requisitos, el sistema que se
construya para satisfacer los requisitos y las pruebas usadas para demostrar
que el sistema satisface los requisitos. En el corazón de los CU 2.0 están el
CU, la historia y la porción de CU. Estos elementos capturan los requisitos y
conducen el desarrollo del sistema.
Aprendemos:
Mapa Conceptual de
Casos de Uso 2.0
Aprendemos:
Los interesados –o stakeholders- son las personas, grupos u

organizaciones que impactan o se impactan con un sistema de software.
Los requisitos constituyen lo que el sistema debe hacer para satisfacer a
los interesados. Es importante descubrir lo que es necesario del sistema
de software, compartir este entendimiento con los interesados y con los
miembros del equipo y usarlo para conducir el desarrollo del nuevo
sistema. En los CU 2.0, los requisitos se capturan como un conjunto de
CU, los cuales se manejan y se atienden como un conjunto de porciones
de CU. Cualquier cambio que requieran los interesados genera adiciones
o cambios al conjunto de CU y a las porciones de los CU.
Aprendemos:
Casos de uso
Un CU se materializa con todas las formas de emplear un sistema para
alcanzar una meta particular para un usuario particular. El conjunto de todos
los CU nos da todas las formas útiles de emplear el sistema.
Un caso de uso es:
• Una secuencia de acciones que un sistema ejecuta y que arroja un
resultado observable de valor para un usuario particular.
• Ese comportamiento específico de un sistema, que participa en una
colaboración con un usuario para entregar algo de valor para ese usuario.
Aprendemos:
Cosas con las cuales trabajar - Casos de uso
• La unidad más pequeña de actividad que proporciona un resultado

significativo para el usuario.
• El contexto para un conjunto de requisitos relacionados.
Para entender un CU narramos historias. Las historias cubren tanto la
forma como se alcanza la meta de manera exitosa y la forma como se
maneja cualquier problema que ocurre en el camino. Las historias nos
ayudan a entender el caso de uso y lo implementan porción por porción.
Aprendemos: El Ciclo de Vida de un Caso de Uso

1. Meta Establecida: cuando se establece la meta del CU.
2. Estructura de la Historia Entendida: cuando el equipo
entiende la estructura de la narrativa del CU lo suficiente
para empezar el trabajo de identificar e implementar las
porciones de los CU.
3. La Historia Más Simple Cumplida: cuando el sistema
cumple la historia más simple que permita al usuario
alcanzar la meta.
4. Suficientes Historias Cumplidas: cuando el sistema
cumple suficientes historias para proporcionar una
solución usable.
5. Todas las Historias Cumplidas: cuando el sistema cumple
todas las historias que narra el CU.
Aprendemos:
Porciones de Casos de uso

Los CU cubren muchas historias relacionadas de importancia y prioridad
variada. Muchas veces hay demasiadas historias para entregar en una sola
liberación y, generalmente, son muchas para trabajar en un solo
incremento. Debido a esto, necesitamos una forma de dividir los CU en
piezas más pequeñas que nos permitan: 1) seleccionar las piezas del CU a
entregar, 2) proporcionar una unidad adecuada para el desarrollo y las
pruebas del equipo de desarrollo y 3) tener piezas de trabajo pequeñas y
de tamaño similar que fluyan rápidamente a lo largo del desarrollo.
Aprendemos:
Cosas con las cuales trabajar - Porciones de Casos de uso
La porción de CU es el elemento más importante de CU 2.0, puesto que no

solo se usa para ayudar con los requisitos, sino también para conducir el
desarrollo de un sistema que los satisfaga.
Las porciones de casos de uso:
• Posibilitan que los CU se dividan en unidades de trabajo más pequeñas,
entregables independientemente.
• Posibilitan que los requisitos contenidos en un conjunto de CU se
ordenen, prioricen y traten en paralelo.
• Vinculan los distintos modelos del sistema (requisitos, análisis, diseño,
implementación y pruebas) usados en el desarrollo dirigido por CU.
Aprendemos: El Ciclo de Vida de una
Porción de Caso de Uso
1. Alcance definido: cuando se define el alcance y se clarifica
la extensión de las historias cubiertas.
2. Preparada: cuando se prepara la porción, ampliando la
narrativa y los casos de prueba para definir claramente lo
que significa la implementación exitosa de la porción.
3. Analizada: cuando se analiza la porción de tal forma que se
entiende su impacto en los componentes del sistema y las
piezas afectadas están listas para codificación y pruebas del
desarrollador (unitarias).
4. Implementada: cuando se mejora el sistema de software
para implementar la porción, que queda lista para pruebas.
5. Verificada: finalmente, cuando se verifica la porción y
queda lista para su inclusión en una versión.
Aprendemos:
Productos de Trabajo
El equipo emplea varios productos
para ayudar a compartir, entender y
documentar los CU y las porciones
de los CU. La imagen muestra los
cinco productos de trabajo de los
CU 2.0 (en azul) y sus relaciones
con los requisitos, casos de uso,
porciones de casos de uso,
historias, pruebas y el sistema (en
amarillo).
Aprendemos:
Modelo lógico
Para conseguir la independencia, robustez y escalabilidad de los
sistemas, y en base a las pautas generales del modelado y diseño de
los sistemas de información, las aplicaciones desarrolladas deben ser
diseñadas como aplicaciones Web siguiendo un modelo
arquitectónico basado en el principio de Separación
de Problemas (SoC, Separation of Concerns). Este
principio permite el estudio de cada uno de los
componentes de un sistema de forma aislada. Es un
principio fundamental en el diseño de sistemas complejos
empresariales y de la programación Orientada a Objetos.
Aprendemos:
Modelo lógico (Cont.)
Este principio aplicado al desarrollo de aplicaciones resulta en la

siguiente separación lógica:
• Presentación y Control.
• Negocio.
• Integración.
Aprendemos:
Modelo lógico (Cont.)
• Esta separación permite dividir

el aplicativo en módulos mas
mantenibles y sencillos de
evolucionar.
• La arquitectura propuesta es
independiente de la tecnología
a usar, siendo válida tanto para
los desarrollos realizados en
Java como .NET.
Pautas de diseño
Presentación y control
La Presentación muestra el sistema al usuario, presentándole la información y
capturando aquella proporcionada por el usuario en un mínimo proceso de
filtrado. Esta modulo se debe comunicar únicamente con el modulo de negocio.
Se hará uso principalmente del patrón MVC.
Controlador
Modelo Vista
MVC
Pautas de diseño
Presentación y control (Cont.)
Las pautas de diseño generales a adoptar en este modulo son:

• Separación de la lógica de negocio y presentación. La vista debe
limitarse únicamente a la presentación de la información al
usuario o a solicitársela, nunca a procesarla ni tomar decisiones
sobre ella. Tales tareas serán competencia del negocio.
• Desacoplamiento entre módulos. La vista sólo debe contener
lógica de visualización, nunca de tratamiento de la información,
evitando de esta forma el acoplamiento entre módulos.
Pautas de diseño
• Aspecto gráfico externo. Todos los sistemas deben tener el mismo

aspecto gráfico externo a nivel de proyecto, corporativo y/o de
función de negocio.
• Modularidad. Las vistas deben diseñarse de forma modular, evitando
que cada módulo haga referencia a otros de la misma o de otras
vistas. Es el caso, por ejemplo, de los módulos correspondientes a la
cabecera, el cuerpo, el menú o pie de las vistas, que deberán
integrarse dinámicamente. El grado de reusabilidad de los módulos
así como el encapsulamiento de la funcionalidad en cada caso debe
de ser muy elevado.
Pautas de diseño
• Internacionalización. Las vistas y por extensión las aplicaciones

deben permitir su adaptación a diferentes idiomas y convenciones
(formatos de fecha, moneda, etc.) sin necesidad de realizar cambios
en su código.
• Validaciones. Deben de realizarse las validaciones formales de los
datos introducidos en las vistas, así como las correspondientes a
campos obligatorios.
Pautas de diseño
• Elaborar un catálogo de controles. Es recomendable elaborar un

catálogo con la lista de controles oficiales en la que se especifique la
función de cada control, los posibles validadores/conversores que se
le puedan asociar, los eventos que pueda lanzar y los atributos que
puedan cambiarse para manipular su aspecto externo. Este catálogo
de controles facilitará la creación de las vistas de forma estándar e
independiente de los componentes del modulo de negocio. De forma
generalizada, no se recomienda la inclusión en este catálogo de
controles desarrollados por terceros.
Pautas de diseño
• Gestión de los mensajes de interfaz de usuario. Los mensajes que las

aplicaciones devuelvan deben proceder de los controles, del
procesado de los datos de la vista (el resultado) o del negocio.
Pautas de diseño
Negocio
El Negocio ocupa un lugar angular en la definición de una infraestructura
de software base que permita el crecimiento y la extensibilidad de
servicios para todas las aplicaciones existentes y futuras.
La definición de los límites de cada modulo permite definir
correctamente la colaboración que proveerá cada una de ellas.
Las principales pautas para el diseño de esta modulo son:
• Elementos constitutivos. El negocio engloba toda la lógica de
negocio: reglas, workflow y operaciones no persistentes. Aunque no
son parte del negocio como tal las operaciones persistentes deben
ser ubicadas junto al negocio.
Pautas de diseño
Negocio (Cont.)
• Reglas de negocio. El negocio debe ser visto como el punto de acceso
único y centralizado al conjunto de servicios expuestos.
• Validaciones de datos. Los servicios de negocio deben realizar las
comprobaciones necesarias sobre los datos proporcionados para
garantizar su validación previa al inicio de los procesos de negocio.
• Comunicación entre módulos. La definición de la estrategia de
negocio, basada en la creación de las entidades del negocio o los
objetos del modelo, se presenta como una fase fundamental en el
desarrollo. La comunicación entre modulos se establece mediante
estos objetos.
Pautas de diseño
Negocio (Cont.)
• Transacciones. El manejo de transacciones debe realizarse desde el
negocio.
• Tratamiento de excepciones. Debe establecerse una gestión de
excepciones según la cuál las mismas se propaguen hacia los módulos
que usen el negocio. Las excepciones generadas desde la capa de
integración o persistencia deben ser encapsuladas en esta capa para
ser trasladadas de forma correcta a la capa superior. Debe evitarse,
además, el uso de métodos genéricos para la captura de las
excepciones, empleando métodos específicos relativos al objeto en
cuestión.
Pautas de diseño
Negocio (Cont.)
• Encapsular los servicios de negocio. Los servicios de negocio son el "puente"
entre el usuario y los servicios de datos. Responden ante peticiones del
usuario (u otros servicios de negocios) para ejecutar una tarea de este tipo
aplicando procedimientos formales y reglas de negocio a los datos relevantes.
Cuando los datos necesarios residen en un servidor de bases de datos,
garantizan los servicios de datos indispensables para cumplir con la tarea de
negocios o aplicar su regla. Esto aísla al usuario de la interacción directa con la
base de datos.
Métodos
Clase
Variables
Pautas de diseño
Negocio (Cont.)
• Control sobre el uso de servicios. El control del acceso a los servicios
de negocio debe hacerse en el negocio, bien a nivel de servicio
vertical (cada Fachada) o a nivel de método dentro de cada servicio.
• Persistencia. Aunque no suele incluirse en el negocio, la persistencia
para la mayoría de los desarrollos estará modularizada junto con el
negocio, aplicando junto con el, el patrón BCE.
• Mapeo Objeto-Relacional (ORM). La implementación debe
realizarse en base a un mapeo Objeto-Relacional, empleando un
motor de persistencia que asegure el correcto funcionamiento.
Pautas de diseño
Negocio (Cont.)
• Persistencia. (Cont.)
• Cada objeto debe ser creado en la base de datos para que sea
persistente. El patrón CRUD1 indica que cualquier objeto debe
de ser creado como un elemento persistente en la base de
datos. Es necesario asegurar que existen operaciones que
permitan leer, actualizar o simplemente borrar. Para ello, debe
implementarse un DAO2 distinto por cada objeto de negocio en
el sistema.
1 CRUD es el acrónimo de "Crear, Leer, Actualizar y Borrar" (del original en inglés: Create, Read, Update and Delete)
2 Data Access Object (DAO)
Pautas de diseño
Negocio (Cont.)
• Manejo del Cache. El uso de cachés en el acceso a datos debe
realizarse siempre teniendo en cuenta las características del
sistema y las necesidades de sincronización. No hay que olvidar
el costo de rendimiento derivado de su uso, por lo que el manejo
de cachés deberá estar siempre justificado.
• Permitir la concurrencia de usuarios. Debe permitir que
múltiples usuarios trabajen en la misma BD protegiendo los
datos de ser escritos equivocadamente, minimizando las
restricciones en su capacidad concurrente para lectura y
escritura.
Pautas de diseño
Negocio (Cont.)
• Evitar las referencias circulares entre objetos. En la medida de lo
posible, se deben evitar las referencias circulares, facilitando la
localización de los objetos, proporcionando un acceso más efectivo a
la información.
• Buen uso de la información oculta. Existen numerosas columnas de
tablas que no necesitan ser mapeadas a una propiedad del objeto,
conteniendo información oculta para el modelo de objetos pero
necesaria para el modelo relacional. En esta categoría entran los
mecanismos de auditoría. Al leer el objeto, se lee esta información,
que es ocultada al objeto pero mantenida por el framework de
persistencia.
Pautas de diseño
Negocio (Cont.)
• Actualización en cascada. Debe utilizarse la posibilidad que
ofrecen los frameworks para la actualización en cascada de
objetos. Esta característica permite que las modificaciones
hechas a un objeto se repliquen en los objetos relacionados,
mejorándose su mantenimiento, la replicación eficiente de los
cambios y la integridad de los datos.
• Operaciones en masa. Se deben de permitir las operaciones en
masa sobre los datos almacenados, lo que mejora de forma
sensible el rendimiento de las operaciones.
Pautas de diseño
Integración
El modulo de integración permite tener separado del negocio todas las
necesidades de datos de servicios externos a la aplicación.
Las pautas de diseño generales a adoptar en este modulo son:
• Integraciones con terceros. En este modulo se deben de englobar
todas las integraciones con los sistemas externos, exponiendo al
negocio una fachada adaptada a las necesidades del propio negocio.
Pautas de diseño
Integración (Cont.)
• Adaptadores o mapeadores. Se debe evitar el uso de clases de
librerías de integración de terceros, para ello se propone el uso de
adaptadores o mapeadores que faciliten la conversión de los
documentos externos a internos.
• Librerías de terceros. Las dependencias con librerías de terceros
deben estar contenidas en este modulo. Evitando que el negocio
dependa directamente con estas librerías.
Modelado basado en Clases
Identificación de clases de análisis

Examinar el enunciado del problema (“análisis gramatical”) sobre las
narrativas desarrolladas para el sistema que se va a construir o de los
CU.
Las clases se determinan al reconocer cada sustantivo.
Las clases se manifiestan en una de las siguientes formas:
• Entidades externas (como, otros sistemas, dispositivos, personas)
que producen o consumen información que usará un sistema.
• Cosas (por ejemplo, reportes, despliegues, letras, señales) que son
parte del dominio de la información para el problema.
Identificación de clases de análisis (Cont.)

• Sucesos o eventos (como, una transferencia de propiedad) que
ocurren dentro del contexto de la operación del sistema.
• Roles que desempeñan personas que interactúan con el sistema.
• Unidades organizacionales relevantes para alguna aplicación.
• Sitios (como, el piso de manufactura o el puerto de carga) que
establecen el contexto del problema y la función global del sistema.
• Estructuras (por ejemplo, sensores, vehículos de cuatro ruedas o
computadoras) que definen una clase de objetos o clases de objetos
relacionadas.
Características de selección
Coad y Yourdon sugieren seis que se deben usar cuando un analista

considera cada clase potencial para incluirlas en el modelo de
análisis:
1. Información referida. La clase potencial será útil durante el
análisis sólo si la información acerca de ella debe recordarse
para que el sistema pueda funcionar.
2. Servicios requeridos. La clase potencial debe tener un conjunto
de operaciones identificables que puedan cambiar el valor de
sus atributos de alguna manera.
Características de selección (Cont.)
3. Atributos múltiples. Durante el análisis de requisitos el enfoque

debe estar en la información “importante”; una clase con un
solo atributo puede, de hecho, ser útil durante el diseño, pero
probablemente es mejor representarla como un atributo de otra
clase durante la actividad de análisis.
4. Atributos comunes. Es posible definir un conjunto de atributos
para la clase potencial, y estos atributos pueden aplicarse en
toda las instancias de la clase.
Características de selección (Cont.)
5. Operaciones comunes. Es posible definir un conjunto de

operaciones para la clase potencial, y estas operaciones pueden
aplicarse en todas las instancias de la clase.
6. Requisitos esenciales. Las entidades externas que aparecen en
el espacio del problema, y que producen o consumen
información esencial para la operación de cualquier solución
para el sistema, se definirán casi siempre como clases en el
modelo de requisitos
Especificación de atributos
Los atributos describen una clase que ha

sido seleccionada para incluirla en el
modelo de análisis.
En esencia, los atributos son los que
definen la clase, lo cual clarifica qué
significa la clase en el contexto del espacio
del problema.
Categorías de clases
Entidad (Entity), Frontera (Border) y Control (Control)
Clase Entidad Clase Frontera Clase Control

(Entity) o (Control)
Interfaz
(Border)
Frontera o Interfaz
Interactúan con actores del sistema o con otros sistemas.
• Las clases de interfaz se utilizan para modelar la interacción entre el
sistema y los actores.
• Las clases de interfaz modelan las partes del sistema que dependen
de sus actores, lo cual implica que clasifican y reúnen los requisitos
en los límites del sistema.
• Las clases de interfaz representan a menudo abstracciones de
ventanas, formularios, paneles, interfaces de comunicaciones.
Frontera o Interfaz (Cont.)

Ejemplo
Entidad
Representan datos del sistema, a menudo del modelo de dominio.
• Las clases de entidad modelan información y el comportamiento
asociado de algún fenómeno o concepto, como persona o un objeto.
• Las clases de entidad reflejan la información de un modo que
beneficia a los desarrolladores al diseñar e implementar el sistema,
incluyendo su soporte de persistencia.
• Las clases de entidad suelen mostrar una estructura de datos lógica y
contribuyen a comprender de qué información depende el sistema.
Entidad (Cont.)
• Permiten capturar aquellos datos que nos

interesa mantener de la entidad
• Representan la estructura interna de los
objetos de la entidad
• Se vinculan con la información de negocio.
• Determinan el estado interno del objeto
• Sirven de base para el desarrollo de las
responsabilidades adquiridas por los
objetos de la entidad
Entidad (Cont.)
Ejemplo
Control
Median entre frontera y entidades. Estos sirven como el pegamento

entre los elementos delimitadores y los elementos de la entidad,
implementando la lógica necesaria para gestionar los diversos
elementos y sus interacciones. Es importante comprender que
puede decidir implementar controladores dentro de su diseño
como algo diferente a los objetos; muchos controladores son lo
suficientemente simples como para ser implementados como un
método de una entidad o clase frontera, por ejemplo.
Control (Cont.)
• Las clases de control representan coordinación, secuencia,

transacciones y control de otros objetos y se usan con frecuencia
para encapsular el control de un caso de uso en concreto.
• Los aspectos dinámicos del sistema se modelan con clases de
control, debido a que ellas manejan y coordinan las acciones y
los flujos de control principales, y delegan trabajo a otros
objetos.
Control (Cont.)
Ejemplo
Reglas de comunicación
Se aplican cuatro reglas a su comunicación:

1. Los actores solo pueden hablar con objetos de contorno.
2. Los objetos de frontera solo pueden hablar con los
controladores y actores.
3. Los objetos de entidad solo pueden hablar con los
controladores.
4. Los controladores pueden hablar con objetos de contorno y
objetos de entidad, y con otros controladores, pero no con
actores
Reglas de comunicación (Cont.)
Comunicación permitida:
Entidad Frontera Control

Entidad X X
Frontera X
Control X X X
Diagrama de Clases
• Un diagrama de clases representa las clases y sus interrelaciones.

• Una clase representa un concepto discreto dentro de la
aplicación que se está modelando:
una cosa física, de negocios,
lógica, de una aplicación, del
computador, o una cosa del
comportamiento.
Diagramas de Colaboraciones
Las colaboraciones identifican las relaciones entre clases.
Para ayudarse en la identificación de los colaboradores, el analista puede
examinar tres relaciones genéricas diferentes entre las clases :
1. la relación es-parte-de,
2. la relación tiene-conocimiento-de, y
3. la relación depende-de.
Todas las clases que son parte de una clase agregada se conectan a ésta
a través de una relación del tipo es-parte-de.
Diagramas de Colaboraciones (Cont.)

1. la relación es-parte-de: Todas las clases que son parte de una clase
agregada se conectan a ésta a través de una relación del tipo es-
parte-de.
2. la relación tiene-conocimiento-de: Cuando una clase debe obtener
información de otra clase se establece la relación tiene-
conocimiento-de.
3. la relación depende-de: La relación depende-de implica que dos
clases tienen una dependencia que no se logra mediante las
relaciones tiene-conocimiento-de o es-parte-de.
Relaciones entre Clases

Asociaciones y dependencias
• En muchos casos, dos clases de análisis se relacionan entre si de alguna manera
parecida a la forma en que se relacionan dos objetos de datos. En UML, estas
relaciones se llaman asociaciones.
• En algunos casos, una asociación se puede definir en forma más extensa al indicar
multiplicidad.
• En muchos casos existe una relación cliente-servidor entre dos clases de análisis. En
tales casos, una clase de cliente depende de alguna manera de la clase de servidor y
se establece una relación dependencia. Las dependencias se definen mediante un
estereotipo.
• Un estereotipo es un “mecanismo de extensibilidad” dentro del UML que permite a
un ingeniero de software definir un elemento de modelado especial cuya semántica
define el cliente.
Diagramas de Colaboraciones
Agregación
• La agregación es el término del UML para la relación parte-todo. En la notación
gráfica, el diamante se coloca en el extremo del todo.
Clase Automóvil
Clase Chasis Clase Motor Clase Llantas Clase Asientos
“Un automóvil se compone de un chasis, un motor, llantas y asientos”


Multiplicidad
• La agregación es el término del UML para la relación parte-todo. En la notación
gráfica, el diamante se coloca en el extremo del todo.
Clase Automóvil
1 1 1 1
1 1 4..5 2..*
Clase Chasis Clase Motor Clase Llantas Clase Asientos
“Un automóvil se compone de un chasis, un motor, 4 ó 5 llantas y 2 ó más asientos”


Composición
• La composición es una extensión de la agregación, pero más marcada.
• Cuando hay composición, es posible que cada parte pertenezca a un solo todo, y
si el todo se borra entonces las partes también se borran.
Clase Tablero de Clase Casilla

Ajedrez
1 64
Generalización
• Permite gestionar la complejidad mediante un ordenamiento
taxonómico de clases
• Se obtiene usando los mecanismos de abstracción de Generalización
y/o Especialización
• La Generalización consiste en factorizar las propiedades comunes de
un conjunto de clases en una clase más general

Generalización (Cont.)
• Nombres usados: clase padre - clase hija. Otros nombres: superclase - subclase,
clase base - clase derivada
• Las subclases heredan propiedades de sus clases padre, es decir, atributos y
operaciones (y asociaciones) de la clase padre están disponibles en sus clases
hijas
• La Generalización y Especialización son equivalentes en cuanto al resultado: la
jerarquía y herencia establecidas
• Generalización y Especialización no son operaciones reflexivas ni simétricas pero
sí transitivas
Vehículo
Veihículo Terrestre Vehículo Aéreo
Coche Camión Avión Helicóptero

• La especialización es una técnica

muy eficaz para la extensión y
Coche
reutilización
• Restricciones predefinidas en
UML:
• disjunta - no disjunta
Funcionando Estropeado
• total (completa) - parcial
(incompleta)
Asociación
Hay casos donde la asociación entre dos clases puede por si misma requerir que se modele como una
clase.
Ejm. Un cantante es atendido por un odontólogo en varias ocasiones, en cada una de ellas la atención
es por diferentes servicios (curaciones, extracciones, implantes, otros). El modelamiento de la
facturación por cada servicio requiere que la asociación servicios se convierta en una clase, la Clase
Servicios, que es identificada como una clase de asociación, porque es tanto una asociación como una
clase. Clase Clase
Cantante Odontólogo Clase
servicio Clase
Cantante servicio Odontólogo
Ejm. Una asociación

Clase Servicios
fechaDeServicio
tipoDeServicio
Ejm. Una clase de asociación
Concepto y justificación de la herencia
• La clase que hereda se denomina subclase o clase derivada.

• La clase de la cual se hereda se denomina superclase, clase
padre o clase base.
• Todo objeto de una subclase es un objeto de la

superclase de la cual deriva.
• Las subclases pueden redefinir los métodos y

atributos de la clase padre y añadir otros nuevos
es un es un ¿el Auto es un vehículo? SI
¿el Vehículo es un Auto? A veces

Herencia en Java
Manos a la Obra
• Ingresar a
• Creamos 2 paquetes
• principal
• clases
Herencia en Java
Manos a la Obra
• Creamos 3 clases en el
paquete clases
• animal
• perro
• Vaca
• Creamos 1 clase en el
paquete principal
• AnimalTest
Herencia en Java
Manos a la Obra
• La clase animal
• será una clase abstracta
• creamos 2 atributos:
• nombre y
• color
• creamos el constructor
• creamos 2 métodos abstractos:
• comer y
• sonido
Herencia en Java
Manos a la Obra
public abstract class animal {

private String nombre;
private String color;
public animal(String nombre, String color) {

this.nombre = nombre;
this.color = color;
}
public abstract void comer();

public abstract void sonido();
}
Herencia en Java
Manos a la Obra
• La clase perro
• hereda de animal
• implementamos los métodos abstractos
• codificamos el método comer
• muestra el mensaje “El perro es carnívoro”
• codificamos el método sonido
• muestra el mensaje “El perro ladra”
Herencia en Java
Manos a la Obra
public class perro extends animal {
public perro(String nombre, String color) {

super(nombre, color);
}
@Override
public void comer() {
System.out.println("El perro es carnívoro");
}
@Override
public void sonido() {
System.out.println("El perro ladra");
}
}
Herencia en Java
Manos a la Obra
• La clase vaca
• hereda de animal
• implementamos los métodos abstractos
• codificamos el método comer
• muestra el mensaje “La vaca es herbívora”
• codificamos el método sonido
• muestra el mensaje “La vaca muge”
Herencia en Java
Manos a la Obra
public class vaca extends animal {
public vaca(String nombre, String color) {

super(nombre, color);
}
@Override
public void comer() {
System.out.println("La vaca es herbívora");
}
@Override
public void sonido() {
System.out.println("La vaca muge");
}
}
Herencia en Java
Manos a la Obra
• La clase AnimalTest
• instanciamos la clase perro
• usamos sus métodos
• comer
• sonido
• instanciamos la clase vaca
• comer
• sonido
Herencia en Java
Manos a la Obra
• La clase AnimalTest
• instanciamos la clase perro
• comer
• sonido
• instanciamos la clase vaca
• comer
• sonido
Herencia en Java
Manos a la Obra
public static void main(String[] args) {

perro Perro = new perro("Firulais","Café");
Perro.comer();
Perro.sonido();
vaca Vaca = new vaca("Florencia","Negro");

Vaca.comer();
Vaca.sonido();
}
Herencia en Java
Manos a la Obra
• ¿puedo instanciar la clase animal?

• crear un método respirar en la clase
animal.
• creamos 2 métodos en la clase animal:
• nombre y
• color
Polimorfismo en Java
Manos a la Obra
• ¿Cómo puedo hacer el mismo ejercicio

utilizando Polimorfismo?
Herencia en Java
Manos a la Obra
• Escriba el código de una calculadora

utilizando Herencia
Herencia en Java
Manos a la Obra
public class Operacion {
double n1;
double n2;
double res;
char operacion;
public Operacion(double n1, double n2, char operacion) {

this.n1 = n1;
this.n2 = n2;
this.operacion = operacion;
}
public void mostrarResultado() {

System.out.println(this.n1+" "+this.operacion+" "+this.n2+" = "+this.res);
}
}
Herencia en Java
Manos a la Obra
public class Suma extends Operacion{
double suma;
public Suma(double n1, double n2) {
super(n1, n2, '+');

this.suma = n1 + n2;
this.setRes(this.suma);
}
}
Herencia en Java
Manos a la Obra
public class Resta extends Operacion{
double resta;
public Resta(double n1, double n2) {
super(n1, n2, '-');

this.resta = n1 - n2;
this.setRes(this.resta);
}
}
Herencia en Java
Manos a la Obra
public class Multiplicacion extends Operacion{
double multi;
public Multiplicacion(double n1, double n2) {
super(n1, n2, '*');

this.multi = n1 * n2;
this.setRes(this.multi);
}
}
Herencia en Java
Manos a la Obra
public class Division extends Operacion{
double div = 0;
public Division(double n1, double n2) {
super(n1, n2, '/');

if(n2==0) System.out.println("No se puede dividir entre cero");
else this.div = n1 / n2;
this.setRes(this.div);
}
}
Verificamos lo aprendido:
http://www.kahoot.it/
Verificamos lo aprendido:
• Absolución de Preguntas.
• Conclusiones y Recomendaciones.
Aplicamos lo aprendido: Asignación para la clase siguiente
• Comentar en el Foro
Gracias

Analisis y Diseño de Sistemas Orientada A Objetos - Semana 9v2

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

Analisis y Diseño de Sistemas Orientada A Objetos - Semana 9v2

Cargado por

Copyright:

Formatos disponibles

Análisis y Diseño de Sistemas Orientado a

Mg. Daniel Arias, PMP™ y Scaled Scrum Master™

Logro de aprendizaje Actividades

• Artefactos de Entrada Actividad 09:

¿Qué aprendimos la clase pasada?

Un actor es una entidad externa al sistema que se modela

Actores de Sistemas (Cont.)

El actor existe fuera del Sistema e interactúa con

Casos de Uso del Sistema

Establece un acuerdo entre clientes y desarrolladores sobre

Descripciones de la funcionalidad del sistema independientes

“Una capacidad o condición que el sistema cumplirá”

Desarrolladores Clientes y Usuarios

Relaciones entre Casos de Uso

Relaciones entre Casos de Uso (Cont.)

Como veremos, en los diagramas de CU se muestran: CU (representados en

Relaciones entre Casos de Uso (Cont.)

• Inclusión: Un CU base incorpora explícitamente el comportamiento

Relaciones entre Casos de Uso (Cont.)

En principio, no deberíamos abusar de este tipo de relación, para no

Relaciones entre Casos de Uso (Cont.)

• Extensión: Un CU base incorpora implícitamente el comportamiento

Relaciones entre Casos de Uso (Cont.)

Estas relaciones se representan mediante una flecha discontinua con

Relaciones entre Casos de Uso (Cont.)

• Especialización y generalización de los CU: Un CU (subcaso) hereda

Relaciones entre Casos de Uso (Cont.)

Veamos un ejemplo de generalización:

Relaciones entre Casos de Uso (Cont.)

Como vemos en este último ejemplo también pueden existir vínculos

Guía para ser exitoso con los casos de uso

Caso de Uso: Un CU expresa todas las formas de usar un sistema para

Guía para ser exitoso con los casos de uso

Esta técnica se puede usar junto con prácticas administrativas y técnicas

Hay seis principios básicos en el corazón de cualquier aplicación exitosa de

1. Mantenerlos simples al narrar historias

1. Mantenerlos simples al narrar historias

Los CU proporcionan una forma de identificar y capturar todas las

1. Mantenerlos simples al narrar historias

Cuando usamos la técnica de la narración de historias para

2. Entender el panorama general

2. Entender el panorama general

El diagrama de casos de uso para un sistema telefónico simple

2. Entender el panorama general

Un diagrama de CU es una forma simple de presentar una visión

Los CU proporcionan este enfoque concentrándose en cómo se

Además, permitirá que se identifiquen y evolucionen las formas de más

4. Construir el sistema por partes

4. Construir el sistema por partes

La receta es bien simple. Primero, identifique el aspecto más útil que el

4. Construir el sistema por partes

Dividir los casos de uso

4. Construir el sistema por partes - Dividir los casos de uso

Aplicando nuestra receta de arriba, los CU identifican las cosas útiles

4. Construir el sistema por partes - Dividir los casos de uso

Estime la porción y comience a construirla. Las porciones adicionales se

4. Construir el sistema por partes

Las porciones son más que solo requisitos y casos de prueba

Como vimos en el ejemplo, las porciones de casos de uso dividen más

Tratando cada aspecto del sistema porción por porción, los CU

4. Construir el sistema por partes

Porciones de Casos de Uso: La parte más importante de los CU 2.0

5. Entregar el sistema en incrementos