UTN-FRT. Cátedra de Diseño de Sistemas. 3K1. 2011. Unidad III. Del Análisis al Diseño. Conclusión de la Fase de Análisis. Casos Reales de Uso. Diagramas de Colaboración. Notación
Modelos de Dominio Específico. Sistemas de Procesamiento de Datos. Transacciones. Eventos y Lenguajes. U.T.N. - F.R.T. - Diseño de Sistemas - 3K1 - 2011
Modelos de Dominio Específico. Sistemas de Procesamiento de Datos. Transacciones. Eventos y Lenguajes. U.T.N. - F.R.T. - Diseño de Sistemas - 3K1 - 2011
Descripción general de los 13 diagramas UML así como sus componentes y principales funciones, es útil para exponer o dar una clase introductoria de este tema.
Descripción general de los 13 diagramas UML así como sus componentes y principales funciones, es útil para exponer o dar una clase introductoria de este tema.
UTN - FRT. Cátedra de Diseño de Sistemas. 3K1. 2011. Unidad I. Craig Larman. Primeros Artefactos de Análisis. Análisis de los Requerimientos. Casos de Uso
Gran compendio de los modelos de UML, que incluye todos los diagramas asociados , sus representaciones, componentes y ejemplos. Los diagramas de casos de uso, de clases, de distribución, de componentes, de colaboración , de objetos, de actividades , de secuencia, de estados y de colaboración son considerados en este gran compendio. Al finalizar la presentación se tendrá una idea general de los elementos fundamentales del diseño de sistemas empleando UML.
U.T.N. - F.R.T. Cátedra de Diseño de Sistemas. 3K1. 2011. Unidad VI. Verificación y Validación del Diseño. Pruebas del Software. Ian Sommerville, Cap. 23
U.T.N. - F.R.T. Cátedra de Diseño de Sistemas. 3K1. 2011. Unidad V. Diseño de Interfaces de Usuario. El Proceso de Diseño de Interfaces por Ian Sommerville.
U.T.N. - F.R.T. Cátedra de Diseño de Sistemas. 3K1. 2011. Unidad V. Diseño de Interfaces. El Proceso de Diseño de Interfaces del Usuario. Roger Pressman
Índice del libro "Big Data: Tecnologías para arquitecturas Data-Centric" de 0...Telefónica
Índice del libro "Big Data: Tecnologías para arquitecturas Data-Centric" de 0xWord escrito por Ibón Reinoso ( https://mypublicinbox.com/IBhone ) con Prólogo de Chema Alonso ( https://mypublicinbox.com/ChemaAlonso ). Puedes comprarlo aquí: https://0xword.com/es/libros/233-big-data-tecnologias-para-arquitecturas-data-centric.html
(PROYECTO) Límites entre el Arte, los Medios de Comunicación y la Informáticavazquezgarciajesusma
En este proyecto de investigación nos adentraremos en el fascinante mundo de la intersección entre el arte y los medios de comunicación en el campo de la informática.
La rápida evolución de la tecnología ha llevado a una fusión cada vez más estrecha entre el arte y los medios digitales, generando nuevas formas de expresión y comunicación.
Continuando con el desarrollo de nuestro proyecto haremos uso del método inductivo porque organizamos nuestra investigación a la particular a lo general. El diseño metodológico del trabajo es no experimental y transversal ya que no existe manipulación deliberada de las variables ni de la situación, si no que se observa los fundamental y como se dan en su contestó natural para después analizarlos.
El diseño es transversal porque los datos se recolectan en un solo momento y su propósito es describir variables y analizar su interrelación, solo se desea saber la incidencia y el valor de uno o más variables, el diseño será descriptivo porque se requiere establecer relación entre dos o más de estás.
Mediante una encuesta recopilamos la información de este proyecto los alumnos tengan conocimiento de la evolución del arte y los medios de comunicación en la información y su importancia para la institución.
Actualmente, y debido al desarrollo tecnológico de campos como la informática y la electrónica, la mayoría de las bases de datos están en formato digital, siendo este un componente electrónico, por tanto se ha desarrollado y se ofrece un amplio rango de soluciones al problema del almacenamiento de datos.
Es un diagrama para La asistencia técnica o apoyo técnico es brindada por las compañías para que sus clientes puedan hacer uso de sus productos o servicios de la manera en que fueron puestos a la venta.
3Redu: Responsabilidad, Resiliencia y Respetocdraco
¡Hola! Somos 3Redu, conformados por Juan Camilo y Cristian. Entendemos las dificultades que enfrentan muchos estudiantes al tratar de comprender conceptos matemáticos. Nuestro objetivo es brindar una solución inclusiva y accesible para todos.
3. DEL ANÁLISIS AL DISEÑO CONCLUSIÓN DE LA FASE DE ANÁLISIS Craig Larman, Caps. 15 y 16 Ingeniería en Sistemas de Información
4. DISEÑO DE SISTEMAS En la fase de análisis se da prioridad al conocimiento de los requerimientos , los conceptos y las operaciones relacionadas con el sistema. Nos centramos en cuestiones concernientes al qué : cuáles son los procesos, los conceptos , etc. En UML, los artefactos que sirven para capturar los resultados de una investigación en la fase de Análisis son:
5. DISEÑO DE SISTEMAS Transición del Análisis al Diseño INICIO DE LA FASE DE DISEÑO Se pasa a la fase del diseño, una vez terminados estos documentos del análisis. Su esencia es la elaboración de diagramas de interacción , que muestran gráficamente cómo los objetos se comunicarán entre ellos a fin de cumplir con los requerimientos. Luego, los diagramas de interacción nos permitirán dibujar Diagramas de Diseño de Clases que definen las clases (e interfaces) implementables en software. Para preparar los Diagramas de Interacción hay que aplicar Principios de Asignación de Responsabilidades (usar los Patrones de Diseño ) .
6. DISEÑO DE SISTEMAS Transición del Análisis al Diseño Casos Reales de Uso Los Casos Reales de Uso presentan un diseño concreto del Caso de Uso. Es una de las primeras actividades en el ciclo de desarrollo. Su creación depende de los Casos Esenciales de Uso generados en el Análisis. Un Caso Real de Uso describe el diseño concreto del caso de uso a partir de una tecnología particular de entrada y salida, y su implementación global. Por ejemplo, si hay una interfaz gráfica para el usuario, el caso de uso real incluirá diagramas de las ventanas en cuestión y una explicación de la interacción.
9. DISEÑO DE SISTEMAS Diagramas de Colaboración DIAGRAMAS DE COLABORACIÓN Diagramas de Interacción => explican gráficamente cómo los objetos interactúan a través de mensajes para realizar las tareas.
10. Un Diagrama de Interacción explica gráficamente las interacciones existentes entre las instancias. Su punto de partida es el cumplimiento de las postcondiciones de los contratos de una operación. Hay dos tipos de estos diagramas: ambos sirven para expresar interacciones semejantes : 1. - Diagramas de Colaboración. 2. - Diagramas de Secuencia . DISEÑO DE SISTEMAS Diagramas de Colaboración
11. DISEÑO DE SISTEMAS Diagramas de Colaboración Diagramas de Colaboración => describen las interacciones entre los objetos en un formato de grafo o red:
12. DISEÑO DE SISTEMAS Diagramas de Colaboración Diagramas de Secuencia => describen las interacciones en una especie de formato de cerca o muro: :ClaseAInstancia :ClaseBInstancia mensaje1() mensaje2() mensaje3()
13. DISEÑO DE SISTEMAS Diagramas de Colaboración Preferimos los Diagramas de Colaboración => Son más expresivos, comunican más información en menos espacio. Ejemplo de un diagrama de colaboración: efectuarPago. instancia parámetro :CAJA :Venta efectuarPago(efectivoOfrecido) 1: efectuarPago(efectivoOfrecido) :Pago 1.1: crear(efectivoOfrecido) primer mensaje línea de enlace dirección del mensaje primer mensaje interno
14.
15.
16.
17. DISEÑO DE SISTEMAS Diagramas de Colaboración Los diagramas de colaboración y otros artefactos efectuarPago(monto ) Cajero Sistemaa IntroducirProducto (cup, cantidad) terminarVenta() Diagrama de la Secuencia del Sistema Operación: introducirProducto Poscondiciones: 1. Si se trata de una nueva venta, se creo una nueva Venta... Operación: efectuarPago Poscondiciones: 1. ... Contratos :CAJA :CAJA introducirProducto (cup, cantidad) efectuarPago(monto) Diagrama de Colaboración
18.
19. DISEÑO DE SISTEMAS Diagramas de Colaboración Notación básica de los diagramas de colaboración Un nombre de una instancia sirve para identificarla de modo inequívoco.
21. DISEÑO DE SISTEMAS Diagramas de Colaboración 3. Representación gráfica de los mensajes Los mensajes entre objetos pueden representarse por medio de una flecha con un nombre y situada sobre una línea de vínculo. Por un vínculo puede fluir un número indefinido de mensajes. Se agrega un número de secuencia que indique el orden consecutivo de los mensajes. : CAJA : Venta mensaje1() 1: mensaje1 () 2: mensaje2 () 3: mensaje3 () Todos los mensajes fluyen sobre un mismo vínculo
22. DISEÑO DE SISTEMAS Diagramas de Colaboración 4.Representación gráfica de los parámetros Los parámetros de un mensaje van dentro de un paréntesis después del nombre del mensaje. Es opcional incluir el tipo de parámetro. : CAJA :Venta 1: agregarPago (monto: Dinero) parámetros mensaje1()
23. DISEÑO DE SISTEMAS Diagramas de Colaboración 5.Representación gráfica del mensaje de devolver valor. Puede incluirse un valor de retorno anteponiendo al mensaje un nombre de variable de esa instrucción y un operador de asignación (“:=”). Es opcional mostrar el tipo del valor de retorno. : CAJA :Venta 1: tot := total () : Entero tipo del valor de retorno nombre del valor de retorno mensaje1()
24. DISEÑO DE SISTEMAS Diagramas de Colaboración 6. Sintaxis de los mensajes: El lenguaje UML cuenta con una sintaxis estándar para los mensajes: Retorno : mensaje (parametro : tipoparametro) : tiporetorno Pueden usarse sintaxis de Java o Smalltalk. 7. Representación gráfica de los mensajes al “emisor”: Puede enviarse un mensaje de un objeto a sí mismo. 1: limpiar() : CAJA mensaje1()
25. DISEÑO DE SISTEMAS Diagramas de Colaboración 8. Representación gráfica de la iteración: La iteración se indica posponiendo un asterisco (*) al número de secuencia. Ese símbolo significa que, dentro de un ciclo, el mensaje va a ser enviado repetidamente al receptor. : CAJA :Venta 1*: li := siguienteLineadeProducto ():VentasLineadeProducto Iteración omitiendo los valores de recurrencia mensaje1()
26. DISEÑO DE SISTEMAS Diagramas de Colaboración También se puede incluir una cláusula de iteración con los valores de recurrencia : Si más de un mensaje ocurre dentro de la misma cláusula de iteración (por ejemplo, varios mensajes en un ciclo for ), se repetirá la cláusula con cada mensaje: : CAJA :Venta cláusula de iteración 1*:[ i :=1..10] li := siguientelineadeproducto ():VentasLineadeProducto mensaje1()
27. DISEÑO DE SISTEMAS Diagramas de Colaboración :A miB :B miC :C mensaje1() 1 * :[i:=1..10] mensaje2() 2 * :[i:=1..10] mensaje3() Las cláusulas de iteración (i) son iguales msg1() { for i:=1 to 10 { miB.mensaje2() miC.mensaje3() } }
28. DISEÑO DE SISTEMAS Diagramas de Colaboración 9.Representación gráfica de la creación de instancias: El mensaje de creación es “ crear” , que se muestra en el momento de ser enviado a la instancia que vamos a generar. Es opcional que la nueva instancia contenga un símbolo «nuevo» . El mensaje crear puede contener parámetros, que indica la transferencia de valores iniciales. 1 : crear (cajero) «new» :Venta crear mensaje, con parámetros opcionales de iniacialización nueva instancia creada “ nuevo” o “new” se permite opcionalmente para dar énfasis mensaje1() : CAJA :Venta
29. DISEÑO DE SISTEMAS Diagramas de Colaboración 10.Representación gráfica de la secuencia de número de los mensajes: El orden de los mensajes se indica con un número de secuencia . Reglas: El primer mensaje no se numera. El orden y el anidamiento de los mensajes siguientes se indican con un esquema legal de numeración .
30. DISEÑO DE SISTEMAS Diagramas de Colaboración :ClaseA :ClaseB :ClaseC :ClaseD mensaje1() 1: mensaje2() 1.1: mensaje3() 2.1: mensaje5() 2: mensaje4() 2.2: mensaje6() primera segunda tercera cuarta quinta sexta
31. DISEÑO DE SISTEMAS Diagramas de Colaboración 11. Representación gráfica de los mensajes condicionales: Un mensaje condicional se indica posponiendo al número de la secuencia una cláusula condicional entre corchetes (parecido a como se hace con una cláusula de iteración). El mensaje se envía sólo si la cláusula se evalúa como verdadera . :CAJA :ClaseB :VentaslineadeProducto 1: [nueva venta] crear() 1.1: crear() mensaje condicional, con prueba mensaje1()
32. DISEÑO DE SISTEMAS Diagramas de Colaboración 12. Representación gráfica de trayectorias condicionales mutuamente excluyentes: Trayectorias que se excluyen mutuamente :ClaseA :ClaseB mensaje1() 1a : [prueb1] mens2() 1a.1: mens3() :ClaseC :ClaseD 2: mens6() 1b.1 : mens5() 1b: [no prueb1] mens4() :ClaseE incondicional tras mens2 o mens4 1a y 1b son trayectorias condicionales mutuamente excluyentes
33. DISEÑO DE SISTEMAS Diagramas de Colaboración En este caso es necesario agregar una letra en la trayectoria condicional. Por convención, la primera letra en usarse es a. Tanto 1a como 1b podrían ejecutarse después de mens1() . Ambas tienen el número de secuencia 1 porque pueden ser el primer mensaje interno . Observe los subsecuentes mensajes anidados. 1b.1 es un mensaje anidado dentro de 1b .
34. DISEÑO DE SISTEMAS Diagramas de Colaboración 13. Representación gráfica de las colecciones: Un multiobjeto , o conjunto de instancias, se dibuja como un icono de pila. Un multiobjeto se implementa como un grupo de instancias guardadas en un contenedor u objeto colección. Representa tan sólo un conjunto lógico de instancias. Ventas: Venta
35. DISEÑO DE SISTEMAS Diagramas de Colaboración 14.Representación gráfica de mensajes dirigidos a multiobjetos: Un mensaje dirigido a un icono de multiobjetos indica que se envía al objeto colección. No a todos sus elementos. :Venta :VentasLinea deProducto mensaje1() 1: s := tamaño():ent mensaje enviado al objeto colección
36. DISEÑO DE SISTEMAS Diagramas de Colaboración 15. Representación gráfica de los mensajes dirigidos a un objeto «Clase»: Los mensajes pueden también ser dirigidos a una clase y no únicamente a una instancia: :Venta Fecha mensaje1() 1: d1 := hoy():Fecha mensaje a clase