Capítulo 22. Herramientas UML y UML como un plano.
|
|
|
- Eugenio Naranjo Olivares
- hace 6 años
- Vistas:
Transcripción
1 Capítulo 22. Herramientas UML y UML como un plano. Miguel RDZ. GUILLÉN CINVESTAV-Tamaulipas 22 de Oct del 2012 Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
2 1 Capítulo 22. Herramientas UML y UML como un plano Ingeniería directa, inversa, y de ida y vuelta Qué buscar en una herramienta? 2 Capítulo 23. Actualización rápida de análisis Caso de estudio: NextGen Caso de estudio: Monopoly 3 Capítulo 24. Iteración 2 - Más patrones Iteración 2 4 Capítulo 25. GRASP Más Objetos con responsabilidades 5 Capítulo 26. Aplicando diseño de patrones GoF Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
3 Capítulo 22. Herramientas UML y UML como un plano 1 Capítulo 22. Herramientas UML y UML como un plano Ingeniería directa, inversa, y de ida y vuelta Qué buscar en una herramienta? 2 Capítulo 23. Actualización rápida de análisis Caso de estudio: NextGen Caso de estudio: Monopoly 3 Capítulo 24. Iteración 2 - Más patrones Iteración 2 4 Capítulo 25. GRASP Más Objetos con responsabilidades 5 Capítulo 26. Aplicando diseño de patrones GoF Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
4 Capítulo 22. Herramientas UML y UML como un plano No es conveniente especificar las herramientas UML a detalle. Este capítulo apunta a algunas características comunes y al uso de herramientas para UML como un plano. Existen 3 maneras en cómo las personas desearían aplicar UML: Como un boceto. (generación de diagramas) Como un plano. (aplica a ambos: generación de código y diagramas) Como un lenguaje de programación. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
5 Capítulo 22. Herramientas UML y UML como un plano Ingeniería directa, inversa, y de ida y vuelta 1 Capítulo 22. Herramientas UML y UML como un plano Ingeniería directa, inversa, y de ida y vuelta Qué buscar en una herramienta? 2 Capítulo 23. Actualización rápida de análisis Caso de estudio: NextGen Caso de estudio: Monopoly 3 Capítulo 24. Iteración 2 - Más patrones Iteración 2 4 Capítulo 25. GRASP Más Objetos con responsabilidades 5 Capítulo 26. Aplicando diseño de patrones GoF Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
6 Capítulo 22. Herramientas UML y UML como un plano Ingeniería directa, inversa, y de ida y vuelta Ingeniería directa, inversa, y de ida y vuelta En la herramienta CASE (siglas en inglés para Computer Aided Software Engineering), la ingeniería directa se refiere a la generación de código a partir de diagramas; ingeniería inversa se refiere a la generación de diagramas desde código, y en la ingeniería de ida y vuelta existe una sincronización inmediata entre los diagramas UML y el código, cuando alguno de ellos es modificado. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
7 Capítulo 22. Herramientas UML y UML como un plano Qué buscar en una herramienta? 1 Capítulo 22. Herramientas UML y UML como un plano Ingeniería directa, inversa, y de ida y vuelta Qué buscar en una herramienta? 2 Capítulo 23. Actualización rápida de análisis Caso de estudio: NextGen Caso de estudio: Monopoly 3 Capítulo 24. Iteración 2 - Más patrones Iteración 2 4 Capítulo 25. GRASP Más Objetos con responsabilidades 5 Capítulo 26. Aplicando diseño de patrones GoF Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
8 Capítulo 22. Herramientas UML y UML como un plano Qué buscar en una herramienta? Qué buscar en una herramienta? Primero, prueba herramientas gratuitas, sólo compra una herramienta después de haber probado muchas opciones libres. Una vez que hayas elegido, pruébala en un proyecto real con varios desarrolladores antes de tomar una decisión. Decide en base a los desarrolladores que la hayan usado por un largo periodo. Escoge la herramienta UML que se integre a tu IDE favorita. Escoge una herramienta UML que soporte ingeniería inversa. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
9 Capítulo 23. Actualización rápida de análisis 1 Capítulo 22. Herramientas UML y UML como un plano Ingeniería directa, inversa, y de ida y vuelta Qué buscar en una herramienta? 2 Capítulo 23. Actualización rápida de análisis Caso de estudio: NextGen Caso de estudio: Monopoly 3 Capítulo 24. Iteración 2 - Más patrones Iteración 2 4 Capítulo 25. GRASP Más Objetos con responsabilidades 5 Capítulo 26. Aplicando diseño de patrones GoF Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
10 Capítulo 23. Actualización rápida de análisis En este capítulo se trata brevemente algunos de los cambios en los requerimientos y análisis de dominio. El modelado notable y algunos tips relacionados a los modelos de dominio Monopoly y NextGen. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
11 Capítulo 23. Actualización rápida de análisis Caso de estudio: NextGen 1 Capítulo 22. Herramientas UML y UML como un plano Ingeniería directa, inversa, y de ida y vuelta Qué buscar en una herramienta? 2 Capítulo 23. Actualización rápida de análisis Caso de estudio: NextGen Caso de estudio: Monopoly 3 Capítulo 24. Iteración 2 - Más patrones Iteración 2 4 Capítulo 25. GRASP Más Objetos con responsabilidades 5 Capítulo 26. Aplicando diseño de patrones GoF Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
12 Capítulo 23. Actualización rápida de análisis Caso de estudio: NextGen Caso de estudio: NextGen Casos de uso: No es necesario el refinamiento para los casos de uso en esta iteración. Sin embargo es recomendado un segundo taller breve (un día o dos) de requerimientos para esta iteración, cerca del final de la iteración 1 y nuevamente al final de la iteración 2. Diagramas de Secuencias del Sistema: Esta iteración agrega soporte para sistemas terceros con variedad de interfaces como el calculador de impuestos. El sistema se comunicará remotamente con sistemas externos. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
13 Capítulo 23. Actualización rápida de análisis Caso de estudio: NextGen Caso de estudio: NextGen Ejemplo: Se muestra un SSD para un escenario de pago por crédito, que requiere la colaboración de varios sistemas externos. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
14 Capítulo 23. Actualización rápida de análisis Caso de estudio: NextGen Caso de estudio: NextGen Modelo de dominio: el modelador puede estimar si un conjunto de nuevos requerimientos tendrán mayor o menor impacto en el modelo de dominio en términos de nuevos conceptos, asociaciones y atributos. En contraste con la iteración anterior, los requerimientos que se abordan en esta ocasión no implican muchos conceptos nuevos de dominio. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
15 Capítulo 23. Actualización rápida de análisis Caso de estudio: NextGen Caso de estudio: NextGen Contratos de operaciones del sistema: En esta iteración no son consideradas nuevas operaciones de sistema, y los contratos no son requeridos. En todo caso, los contratos son solo una opción a considerar cuando el detalle de precisión que ellos ofrecen representa una mejora sobre las descripciones de los casos de uso. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
16 Capítulo 23. Actualización rápida de análisis Caso de estudio: Monopoly 1 Capítulo 22. Herramientas UML y UML como un plano Ingeniería directa, inversa, y de ida y vuelta Qué buscar en una herramienta? 2 Capítulo 23. Actualización rápida de análisis Caso de estudio: NextGen Caso de estudio: Monopoly 3 Capítulo 24. Iteración 2 - Más patrones Iteración 2 4 Capítulo 25. GRASP Más Objetos con responsabilidades 5 Capítulo 26. Aplicando diseño de patrones GoF Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
17 Capítulo 23. Actualización rápida de análisis Caso de estudio: Monopoly Caso de estudio: Monopoly Casos de uso: son omitidos, por las reglas del juego, No se requiere actualización del SSD y no son escritos los contratos de operaciones. Modelo de dominio: Los conceptos Square, GoSquare, IncomeTaxSquare, y GoToJailSquare son todos variaciones de Square, en esta situación, es posible (y frecuentemente útil) organizarlos en herencia de clases en donde la superclase Square representa un concepto más general y las sub clases más especificas. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
18 Capítulo 23. Actualización rápida de análisis Caso de estudio: Monopoly Caso de estudio: Monopoly Herencia: Generalización: es la actividad de identificar concordancia entre conceptos y definir relaciones superclases (conceptos generales) y subclases (conceptos especializados). Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
19 Capítulo 23. Actualización rápida de análisis Caso de estudio: Monopoly Caso de estudio: Monopoly Cuándo mostrar subclases? Cree una subclase conceptual de una superclase cuando: La subclase tiene atributos adicionales de interés. La subclase tiene asociaciones adicionales de interés. La subclase está operando, manejado, reaccionó a, o manipulado de manera diferente que la superclase de otras subclases, de maneras notables. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
20 Capítulo 24. Iteración 2 - Más patrones 1 Capítulo 22. Herramientas UML y UML como un plano Ingeniería directa, inversa, y de ida y vuelta Qué buscar en una herramienta? 2 Capítulo 23. Actualización rápida de análisis Caso de estudio: NextGen Caso de estudio: Monopoly 3 Capítulo 24. Iteración 2 - Más patrones Iteración 2 4 Capítulo 25. GRASP Más Objetos con responsabilidades 5 Capítulo 26. Aplicando diseño de patrones GoF Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
21 Capítulo 24. Iteración 2 - Más patrones En esta iteración, los casos de estudio enfatizan: Diseño esencial de objetos. El uso de patrones para crear diseño sólidos. Aplicar UML para visualizar modelos. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
22 Capítulo 24. Iteración 2 - Más patrones Iteración 2 1 Capítulo 22. Herramientas UML y UML como un plano Ingeniería directa, inversa, y de ida y vuelta Qué buscar en una herramienta? 2 Capítulo 23. Actualización rápida de análisis Caso de estudio: NextGen Caso de estudio: Monopoly 3 Capítulo 24. Iteración 2 - Más patrones Iteración 2 4 Capítulo 25. GRASP Más Objetos con responsabilidades 5 Capítulo 26. Aplicando diseño de patrones GoF Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
23 Capítulo 24. Iteración 2 - Más patrones Iteración 2 Iteración 2 Cuando la iteración 1 termina, lo siguiente tiene que haberse cumplido: Todo el software ha sido rigorosamente probado. Los consumidores han evaluado el sistema parcial, para obtener retroalimentación para adaptaciones y clarificación de requerimientos. El sistema, a través de sus subsistemas, ha sido completamente integrado y estabilizado como una liberación base interna. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
24 Capítulo 24. Iteración 2 - Más patrones Iteración 2 Iteración 2 Para los casos de estudio en la iteración 2 en gran parte ignora los análisis de requerimientos y dominio y se enfoca al diseño de objetos con responsabilidades y GRASP. La aplicación NextGen POS maneja muchos requerimientos interesantes: Soporte a variaciones en servicios externos, por ejemplo diferentes calculadores de impuestos pueden ser conectados al sistema. Diferentes reglas de fijación de precios. Diseño para refrescar la ventana de interfaz cuando la venta total cambia. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
25 Capítulo 24. Iteración 2 - Más patrones Iteración 2 Iteración 2 Los requerimientos adicionales para la segunda iteración de la aplicación de Monopoly incluyen: Cada jugador recibe $1500 al inicio del juego. Considerando que el juego tiene una cantidad ilimitada de dinero. Cuando un jugador cae en el recuadro avanzar, Recibe $200. Cuando un jugador cae en el recuadro ir a prisión, se mueve al recuadro Prisión. Cuando un jugador cae en el recuadro impuesto, el jugador paga un mínimo de $200 o 10 % de su valor. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
26 Capítulo 25. GRASP Más Objetos con responsabilidades 1 Capítulo 22. Herramientas UML y UML como un plano Ingeniería directa, inversa, y de ida y vuelta Qué buscar en una herramienta? 2 Capítulo 23. Actualización rápida de análisis Caso de estudio: NextGen Caso de estudio: Monopoly 3 Capítulo 24. Iteración 2 - Más patrones Iteración 2 4 Capítulo 25. GRASP Más Objetos con responsabilidades 5 Capítulo 26. Aplicando diseño de patrones GoF Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
27 Capítulo 25. GRASP Más Objetos con responsabilidades 1 Capítulo 22. Herramientas UML y UML como un plano Ingeniería directa, inversa, y de ida y vuelta Qué buscar en una herramienta? 2 Capítulo 23. Actualización rápida de análisis Caso de estudio: NextGen Caso de estudio: Monopoly 3 Capítulo 24. Iteración 2 - Más patrones Iteración 2 4 Capítulo 25. GRASP Más Objetos con responsabilidades 5 Capítulo 26. Aplicando diseño de patrones GoF Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
28 Capítulo 25. GRASP Más Objetos con responsabilidades En capítulos anteriores, aplicamos 5 patrones GRASP; Información de experto, creador, alta cohesión, bajo acoplamiento y controlador. Los cuatro restantes se cubrirán en este capítulo y son: Polimorfismo Indirección Fabricación pura Variaciones protegidas Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
29 Capítulo 25. GRASP Más Objetos con responsabilidades Polimorfismo: Problema: Cómo controlar alternativas basadas en tipo? Cómo crear componentes de software conectables? Viendo componentes en relaciones cliente servidor, cómo puede reemplazar un componente servidor con otro, sin afectar al cliente? Solución: Polimorfismo: dar el mismo nombre a servicios en diferentes objetos. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
30 Capítulo 25. GRASP Más Objetos con responsabilidades Ejemplo: Cómo soportar Calculadores de impuestos terceros? En la aplicación NextGen hay múltiples calculadores de impuestos externos que deben de ser soportados. Qué objeto debería ser responsable de manejar las variaciones en las interfaces externas? Ya que el comportamiento de la calculadora varía según el tipo de calculador, por polimorfismo podemos asignar responsabilidades para adaptación a diferentes calculadores (o adaptadores calculadores). Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
31 Capítulo 25. GRASP Más Objetos con responsabilidades Cada método gettaxes toma un objeto Venta como parámetro, por lo que el calculador puede analizar la venta, la implementación de cada método gettaxex será diferente. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
32 Capítulo 25. GRASP Más Objetos con responsabilidades Problema Monopoly: Cómo diseñar acciones de Square diferentes? El principio nos aconseja crear una operación polimórfica para cada tipo en el que el comportamiento varíe. Esto varía en los tipos (clases) RegularSquare, GoSquare, etc. Cual es la operación que varía? Es la que sucede cuando un jugador cae en una casilla. Por polimorfismo, vamos a crear una clase separada para cada tipo de Square, e implementa al método landedon en cada uno. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
33 Capítulo 25. GRASP Más Objetos con responsabilidades Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
34 Capítulo 25. GRASP Más Objetos con responsabilidades El polimorfismo es un principio fundamental en el diseño de cómo un sistema está organizado para manejar variaciones similares. Un diseño basado en la asignación de responsabilidades por polimorfismo puede ser fácilmente ampliado para incluir las nuevas variaciones. Por ejemplo, la adición de una nueva clase adaptadora de calculador con su propio método polimórfico gettaxes tendrá un impacto menor sobre el diseño existente. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
35 Capítulo 25. GRASP Más Objetos con responsabilidades Fabricación pura Problema: Qué objeto debe tener la responsabilidad, cuando no se quiere violar la alta cohesión y el bajo acoplamiento, pero las soluciones ofrecidas por experto (por ejemplo) no son apropiadas? Solución: Asignar un conjunto altamente cohesivo de responsabilidades a una clase artificial que no represente un problema de dominio, para soportar alta cohesión, bajo acoplamiento y reutilización. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
36 Capítulo 25. GRASP Más Objetos con responsabilidades Problema NextGen: Guardar un objeto venta en la Base de Datos. Suponga que se necesita guardar instancias de venta en una base de datos relacional. Por información de experto, hay justificación para asignar la responsabilidad a la clase Venta, pero considere: Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
37 Capítulo 25. GRASP Más Objetos con responsabilidades La tarea requiere de un número relativamente grande de operaciones de base de datos, Lo que provoca que la clase Venta pierda cohesión. La clase venta tiene que estar acoplada a una interfaz de base de datos (como JDBC en java), por lo que su acoplamiento aumenta. Guardar objetos es una tarea general a la que muchas clases pudieran necesitar. Por lo que habrá poco reúso o mucha duplicidad en otras clases. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
38 Capítulo 25. GRASP Más Objetos con responsabilidades Una solución razonable es crear una nueva clase que sea responsable de guardar objetos en una base de datos; esta clase es Fabricación Pura. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
39 Capítulo 25. GRASP Más Objetos con responsabilidades La fabricación pura resuelve los problemas de diseño: La venta se mantiene bien diseñado, con alta cohesión y bajo acoplamiento. La clase PersistentStorage en sí es relativamente cohesiva, ya que tiene el único fin de almacenar o la inserción de objetos en un medio de almacenamiento persistente. La clase PersistentStorage es un objeto muy genérico y reutilizable. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
40 Capítulo 25. GRASP Más Objetos con responsabilidades Problema Monopoly: Manejo de los dados En el diseño actual, el jugador tira todos los dados y suma los totales. Dados son objetos muy generales, que puedan utilizarse en muchos juegos. Al poner esta responsabilidad de rodando y sumando en un jugador de Monopoly, el servicio de sumar no es generalizado para su uso en otros juegos. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
41 Capítulo 25. GRASP Más Objetos con responsabilidades Pero, la elección de cualquier otro objeto inspirado en el modelo de dominio de juego de Monopoly nos lleva a los mismos problemas. Y eso nos lleva a hacer fabricación pura para proporcionar convenientemente los servicios relacionados. Aunque no existe un vaso para dados de Monopoly, muchos juegos hacen uso de uno. Por lo tanto, se propone una fabricación pura denominada Cup. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
42 Capítulo 25. GRASP Más Objetos con responsabilidades Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
43 Capítulo 25. GRASP Más Objetos con responsabilidades Alta cohesión porque las responsabilidades se incluyen en una clase de grano fino que sólo se centra en un conjunto muy específico de tareas relacionadas. Potencial de reutilización puede aumentar debido a la presencia de clases de grano fino de fabricación pura cuyas responsabilidades tienen usos en otras aplicaciones. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
44 Capítulo 25. GRASP Más Objetos con responsabilidades Indirección Problema: Dónde asignar responsabilidad, para evitar acoplamiento directo entre dos o más cosas? Cómo desacoplar objetos de tal manera que exista un acoplamiento bajo y un alto potencial de reúso? Solución: Asignar la responsabilidad a un objeto intermediario para mediar entre otros componentes o servicios y no estén directamente acoplados. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
45 Capítulo 25. GRASP Más Objetos con responsabilidades Ejemplo: Adaptador- Calculador de impuestos, estos objetos actúan como intermediarios a clases externas de cálculo de impuestos. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
46 Capítulo 25. GRASP Más Objetos con responsabilidades En el ejemplo de fabricación pura para el desacoplamiento de la venta y los servicios de bases de datos mediante la introducción de una clase PersistentStorage es también un ejemplo de asignación de responsabilidades que apoya la indirección. La clase PersistentStorage actua como un intermediario entre la Venta y base de datos. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
47 Capítulo 25. GRASP Más Objetos con responsabilidades Variaciones Protegidas Problema: Cómo diseñar objetos, subsistemas y sistemas de tal manera que las variaciones en estos elementos no tengan un impacto indeseable en otros? Solución: Identificar los puntos de variación o inestabilidad; asignar responsabilidades para crear una interfaz estable alrededor de ellos. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
48 Capítulo 25. GRASP Más Objetos con responsabilidades Por ejemplo, el anterior problema de calculador de impuestos externo y su solución con polimorfismo ilustra las Variaciones Protegidas. El punto de inestabilidad o variación son las diferentes interfaces de calculadoras externas. El sistema de POS tiene que ser capaz de integrarse con muchos sistemas calculadores de impuestos existentes, y también con los futuros calculadores que no están aún en existencia. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
49 Capítulo 25. GRASP Más Objetos con responsabilidades Extensiones requeridas para las nuevas variaciones son fáciles de agregar. Nuevas implementaciones pueden ser introducidos sin afectar a los clientes. El acoplamiento se reduce. El impacto o el costo de los cambios se puede bajar. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
50 Capítulo 26. Aplicando diseño de patrones GoF 1 Capítulo 22. Herramientas UML y UML como un plano Ingeniería directa, inversa, y de ida y vuelta Qué buscar en una herramienta? 2 Capítulo 23. Actualización rápida de análisis Caso de estudio: NextGen Caso de estudio: Monopoly 3 Capítulo 24. Iteración 2 - Más patrones Iteración 2 4 Capítulo 25. GRASP Más Objetos con responsabilidades 5 Capítulo 26. Aplicando diseño de patrones GoF Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
51 Capítulo 26. Aplicando diseño de patrones GoF Este capítulo explora diseño orientado a objetos para la realización de casos de uso para el caso de estudio NextGen, proporcionando soporte para servicios externos de terceros cuyas interfaces pueden variar, las reglas de fijación de precios de productos más complejos, y las reglas de negocio adaptables. El énfasis es mostrar cómo aplicar el Gang-de-Four (GoF), y los patrones GRASP más básicos. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
52 Capítulo 26. Aplicando diseño de patrones GoF 1 Capítulo 22. Herramientas UML y UML como un plano Ingeniería directa, inversa, y de ida y vuelta Qué buscar en una herramienta? 2 Capítulo 23. Actualización rápida de análisis Caso de estudio: NextGen Caso de estudio: Monopoly 3 Capítulo 24. Iteración 2 - Más patrones Iteración 2 4 Capítulo 25. GRASP Más Objetos con responsabilidades 5 Capítulo 26. Aplicando diseño de patrones GoF Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
53 Capítulo 26. Aplicando diseño de patrones GoF Adaptador: El problema NextGen explorado en motivar al patrón de polimorfismo y su solución es más específicamente un ejemplo del modelo de adaptador GoF. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
54 Capítulo 26. Aplicando diseño de patrones GoF Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
55 Capítulo 26. Aplicando diseño de patrones GoF Fábrica: El adaptador plantea un nuevo problema en el diseño: En la solución anterior del patrón adaptador para los servicios externos con interfaces diferentes, Quién crea los adaptadores? Y cómo determinar qué clase de adaptador crear, como TaxMaster-Adapter o GoodAsGoldTaxProAdapter? Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
56 Capítulo 26. Aplicando diseño de patrones GoF Una alternativa común es aplicar el patrón de la fábrica, en la que se define un objeto de fabricación pura para crear objetos. Los objetos de fábrica tienen varias ventajas: Separar la responsabilidad de creaciones complejas en objetos de ayuda cohesivos. Ocultar lógica de creación potencialmente compleja. Permitir la introducción de estrategias para mejorar el rendimiento de gestión de memoria, como cacheo de objetos o reciclaje. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
57 Capítulo 26. Aplicando diseño de patrones GoF Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
58 Capítulo 26. Aplicando diseño de patrones GoF Singleton: El Factory plantea otro problema nuevo en el diseño: Quién crea la propia fábrica, y cómo se accede? Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
59 Capítulo 26. Aplicando diseño de patrones GoF El patrón Singleton se utiliza a menudo para los objetos y los objetos fábrica y facade (otro patrón GoF que será discutido). Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
60 Capítulo 26. Aplicando diseño de patrones GoF Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
61 Capítulo 26. Aplicando diseño de patrones GoF Estrategia: Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
62 Capítulo 26. Aplicando diseño de patrones GoF Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
63 Capítulo 26. Aplicando diseño de patrones GoF Facade: Una fachada es un objeto "front-end"que es el único punto de entrada para los servicios de un subsistema, la aplicación y otros componentes del subsistema son privados y no puede ser visto por los componentes externos. Fachada ofrece Variaciones protegidas de los cambios en la implementación de un subsistema. Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
64 Capítulo 26. Aplicando diseño de patrones GoF Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
65 Capítulo 26. Aplicando diseño de patrones GoF Gracias! Miguel RDZ. GUILLÉN (CINVESTAV) 22 de Oct del / 65
Capítulo 16. Diagrama de Clases UML
Capítulo 16. Diagrama de Clases UML Florentino TORRES M. CINVESTAV-Tamaulipas 15 de Oct del 2012 Florentino TORRES M. (CINVESTAV) 15 de Oct del 2012 1 / 70 1 Capítulo 16. Diagrama de Clases UML Aplicando
Tema 6. Patrones de diseño.
Ingeniería del Software II 2011 Tema 6. Patrones de diseño. Introducción. Durante el diseño Orientado a Objetos es frecuente encontrarse repetidamente con ciertos tipos de problemas, para analizar, compartir
Patrones. Patrones GRASP GRASP GRASP. Curso de Arquitecturas de Software. Programación Orientada a Objetos Patrones GRASP
Curso de Arquitecturas de Software Programación Orientada a Objetos Patrones GRASP Patrones Es una solución a un problema recurrente Capturan las mejores prácticas establecidas para diseño Describen un
Introducción a los patrones de Software
Introducción a los patrones de Software Dpto. de Ingeniería de Sistemas y Computación Universidad de los Andes Material de base: Gloria Cortés y Rubby Casallas Referencias LARMAN, Craig. Applying UML and
Ingeniería del Software de Gestión II 2 de febrero de 2005 Pág: 1/8. Apellidos: Nombre: Núm.:
Ingeniería del Software de Gestión II 2 de febrero de 2005 Pág: 1/8 Apellidos: Nombre: Núm.: PD1 (4 Ptos.): Responda razonadamente a las siguientes cuestiones: 1. Qué diferencia existe entre un diagrama
UNIVERSIDAD DE SAN CARLOS DE GUATEMALA FACULTAD DE INGENIERIA ESCUELA DE CIENCIAS Y SISTEMAS
UNIVERSIDAD DE SAN CARLOS DE GUATEMALA FACULTAD DE INGENIERIA ESCUELA DE CIENCIAS Y SISTEMAS PROGRAMA DEL CURSO DE INTRODUCCION A LA PROGRAMACION DE COMPUTACION 2 CODIGO: 771 CREDITOS: 5 ESCUELA: Ciencias
Programación Orientada a Objetos
Programación Orientada a Objetos PROGRAMACIÓN ORIENTADA A OBJETOS 1 Sesión No. 8 Nombre: El Modelo de diseño con UML Contextualización Los modelos que podemos crear con UML son varios, por lo que debemos
Programación bajo UML
Descripción y Contenido del Curso Programación bajo UML Capacity Academy Educación en Tecnología de la Información Online, Efectiva y Garantizada Qué aprenderá si toma este Curso? En este curso aprenderás
Tema: Herencia en C#.
Programación II. Guía No. 8 1 Facultad: Ingeniería Escuela: Computación Asignatura: Programación II Tema: Herencia en C#. Objetivos Crear clases a través de la herencia de clases existentes. Describir
Clasificación de las Herramientas CASE
Qué es una herramienta CASE? Las herramientas CASE (Computer Aided Software Engineering, Ingeniería de Software Asistida por Computadora) son diversas aplicaciones informáticas destinadas a aumentar la
Rational Unified Process
Rational Unified Process 1 Qué es un Proceso? Un proceso define Quién está haciendo Qué, Cuándo y Cómo para lograr un cierto objetivo. En la ingeniería de software el objetivo es construir un producto
UML (Lenguaje de Modelado Unificado) y Diagramas de Casos de Uso
UML (Lenguaje de Modelado Unificado) y Diagramas de Casos de Uso Los sistemas orientados a objetos describen las entidades como objetos. Los objetos son parte de un concepto general denominado clases.
Lenguaje de Modelamiento Unificado.
Lenguaje de Modelamiento Unificado. Pontificia Universidad Javeriana What can you Model with UML? 1. Structure Diagrams include: The Class Diagram Object Diagram Component Diagram Composite Structure Diagram
Horas Contacto. Modelar gráficamente la solución de problemas con un enfoque Orientado a Objetos, usando un lenguaje de modelado, en este caso UML.
FACULTAD DE INGENIERIA DEPARTAMENTO DE INGENIERIA DE SISTEMAS Nombre de la asignatura (Curso) Código de la asignatura (ID Curso) Análisis y Diseño Orientado a Objetos 4183 Fecha de Actualización Enero
CAPÍTULO 2: CARACTERÍSTICAS DE LA PROGRAMACIÓN ORIENTADA A OBJETOS. ABSTRACCIÓN. ENCAPSULAMIENTO. PRINCIPIO DE OCULTACIÓN. HERENCIA. POLIMORFISMO.
1 UNIDAD 1: ORIENTACIÓN A OBJETOS. CAPÍTULO 1: INTRODUCCIÓN. HISTORIA. ESPÍRITU DEL PARADIGMA ORIENTADO A OBJETOS. CONCEPTOS BÁSICOS: OBJETO, ATRIBUTO, MÉTODO, MIEMBRO, MENSAJE, CLASE, EVENTO. CAPÍTULO
CIDE, SA. RIF: J NIT: MODELO FUNCIONAL
MODELO FUNCIONAL SIGA C O NTE NlD O Introducción Aspectos Conceptuales Definición de modelo Requisitos de un Modelo Funcional Modelando la Funcionalidad del Sistema: Diagrama de Casos de Uso Definición
Los diagramas de clases y de objetos sirven para modelar diversos aspectos estructurales o estáticos de un sistema: Modelado - Vocabulario del Sistema
Modelado Los diagramas de clases y de objetos sirven para modelar diversos aspectos estructurales o estáticos de un sistema: Vocabulario del Sistema Distribución de Responsabilidades Semántica de una Clase
Propuestas del Cuerpo Académico de Ingeniería y Tecnologías de Software
Propuestas del Cuerpo Académico de Ingeniería y Tecnologías de Tecnologías de Trabajo Práctico-Técnico Herramienta de trazado de ejecución de programas Java Ingeniería de software, Programación Java Peña.
PATRONES. Experto. Solución:
PATRONES. Experto. Asignar una responsabilidad a la clase que tiene la información necesaria para cumplirla. Cuál es el principio fundamental en virtud del cual asignaremos las responsabilidades a los
Diseño Dirigido por Responsabilidades con los patrones GRASP. Pearson Educación, S.A. Todos los derechos reservados.
Diseño Dirigido por Responsabilidades con los patrones GRASP Experto (en información) Cómo asignar responsabilidades? Asignar una responsabilidad al objeto que tiene la información necesaria para realizarla:
Ingeniería del Software de Gestión II 26 de enero de 2005 Pág: 1/6. Apellidos: Nombre: Núm.:
Ingeniería del Software de Gestión II 26 de enero de 2005 Pág: 1/6 Apellidos: Nombre: Núm.: PD1 (5 Ptos.): Responda a las siguientes cuestiones de forma concisa y razonada: 1. Qué contraindicación tiene
1. Asignar Responsabilidades a componentes de software es la habilidad más importante del AOO. Porque:
Análisis y Diseño O.O. Preguntas del diseño : Cómo podrían asignarse responsabilidades a las clases de los objetos? Cómo podrían interactuar los objetos? Qué deberían hacer las clases? Patrones : Ciertas
Procesos del software
Procesos del software (selección de alguna de las trasparencias de Sommerville) Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1 Modelos de proceso del software genéricos El modelo
Crear diagramas basados en UML para la representación de la solución a un problema mediante el Paradigma Orientado a Objetos.
PROGRAMA DE CURSO Modelo 2009 DEPARTAMENTO: COMPUTACIÓN Y DISEÑO GRÁFICO NOMBRE DEL CURSO: Diseño de Software con Práctica Profesional CLAVE: 1013M ACADEMIA A LA QUE PERTENECE: Diseño de Software PROFESIONAL
Análisis y modelado de sistemas de software. Diseño Persistencia de objetos. Blanca A. Vargas Govea
Análisis y modelado de sistemas de software Diseño Persistencia de objetos Blanca A. Vargas Govea vargasgovea@itesm.mx Abril 23, 2013 Objetivo Conocer las reglas para mapeo de clases a tablas (RDBMS).
Capítulos 2 y 5: Modelación con UML y Modelo Objeto
Capítulos 2 y 5: Modelación con UML y Modelo Objeto Agenda Recordar: Modelo de Sistema: modelo objeto + modelo funcional + modelo dinámico Ultima Clase: Modelo Objeto Definir el concepto de Modelo de Clases
DIAGRAMAS DE UML DIAGRAMAS DE CASO DE USO
DIAGRAMAS DE UML DIAGRAMAS DE CASO DE USO Un diagrama de casos de uso es una especie de diagrama de comportamiento. Los diagramas de casos de uso son a menudo confundidos con los casos de uso. Mientras
Persistencia en Sistemas O.O.
Persistencia en Sistemas O.O. Taller de Programación Instituto de Computación Facultad de Ingeniería Universidad de la República Contenido Conceptos básicos Definición y motivación de persistencia Mecanismo
Fábricas de Software y Líneas de Producto: del Estado de la Práctica al Estado del Arte. Jorge A. Villalobos.
Fábricas de Software y Líneas de Producto: del Estado de la Práctica al Estado del Arte Jorge A. Villalobos jvillalo@uniandes.edu.co 1 Agenda Cuál es la situación actual? Por qué el problema es tan complejo?
UML: INTRODUCCIÓN, ORIENTACIÓN a Objetos
1Diseño y Modelado UML UML: INTRODUCCIÓN, ORIENTACIÓN a Objetos - Por qué es necesario el UML - La concepción del UML - Diagramas del UML - Diagrama de clases - Diagrama de objetos - Diagrama de casos
Prof. Mariano Mancuso. Sistemas de información y control diagrama de clases
Prof. Mariano Mancuso Sistemas de información y control diagrama de clases UML Qué son los modelos? Para qué sirven los modelos? Cuáles son los modelos de UML? Se usan todos...? Qué son los modelos? Un
Oracle Fusion Middleware 11g: Creación de Aplicaciones ADF - Acelerado
Oracle University Contacte con nosotros: 902 302 302 Oracle Fusion Middleware 11g: Creación de Aplicaciones ADF - Acelerado Duración: 5 Días Lo que aprenderá Este curso enlazado comprende los cursos Oracle
Contenido. 1. El proceso 2. Los modelos 3. Los diagramas 4. Ejemplo
Tutorial Contenido 1. El proceso 2. Los modelos 3. Los diagramas 4. Ejemplo 1. El proceso Fases soportadas por UML Análisis de requisitos de usuario Análisis de requisitos de software Diseño de la plataforma
Capítulo 5. Desarrollo del Sistema
Capítulo 5. Desarrollo del Sistema En este capítulo se describe el desarrollo del sistema, que incluye el análisis, diseño e implementación. La implementación de éste sistema se llevó acabo junto con el
Evolución de la Programación Orientada a Objetos
Evolución de la Programación Orientada a Objetos Dr. Luis Gerardo de la Fraga Departamento de Computación Cinvestav Correo-e: fraga@cs.cinvestav.mx 7 de diciembre de 2006 Dr. Luis Gerardo de la Fraga Cinvestav
Applying UML and Patterns Capítulos 18, 19, 20 y 21
Applying UML and Patterns Capítulos 18, 19, 20 y 21 ALEJANDRO ZAPATA SÁNCHEZ CINVESTAV-Tamaulipas 17 de Octubre del 2012 ALEJANDRO ZAPATA SÁNCHEZ (CINVESTAV) Capítulos 18, 19, 20 y 21 17 de Octubre del
UNT INGENIERIA INDUSTRIAL INGENIERIA DE SOFTWARE
UNT INGENIERIA INDUSTRIAL INGENIERIA DE SOFTWARE Ing. Francisco Rodríguez Novoa Tema 7 Modelo de Análisis Ing. Francisco Rodríguez Rational Unified Process (RUP) 3 OBJETIVOS Conocer que el Análisis ve
<NOMBRE DE LA UNIVERSIDAD, Y NOMBRE DE LA COMUNIDAD>. <TITULO PROYECTO>
. Autores: CI Historia de Revisiones Versión Fecha Revisado por
SERVICIO NACIONAL DE APRENDIZAJE SENA SISTEMA INTEGRADO DE GESTIÓN Procedimiento Ejecución de la Formación Profesional Integral GUÍA DE APRENDIZAJE
Nº 1 1. IDENTIFICACIÓN DE LA GUIA DE APRENDIZAJE Programa de Formación: Técnico en programación de software Nombre del Proyecto: Sistema de información para la gestión empresarial Fase del proyecto: FASE
09/01/2008. Nombre de la clase. Atributos. Métodos/Operaciones
Diagramas de Clase Angela Carrillo R. Clase Descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica Implementa una o más interfaces Nombre de la clase
INTRODUCCIÓN AL PARADIGMA DE LA PROGRAMACIÓN ORIENTADA A OBJETOS CON JAVA
Objetivo: Identificar los concentos principales en java POO, que es una clase, un objeto así como sus características principales abstracción, modularidad, encapsulamiento, herencia, polimorfismo. INTRODUCCIÓN
Guía del Curso Analista Programador Java: Business Apps Expert
Guía del Curso Analista Programador Java: Business Apps Expert Modalidad de realización del curso: Número de Horas: Titulación: Online 600 Horas Diploma acreditativo con las horas del curso OBJETIVOS UML
De Desempeño De Conocimiento SABERES ESENCIALES CONTENIDOS RUTA FORMATIVA Saber Conocer Nociones, Proposiciones, Conceptos Categorías
Facultad Programa Académico Nombre Del Curso Administración e Ingenierias Ingenieria De Sistemas ANÁLISIS DE SISTEMAS Problema? Competencia específica Criterios de Desempeño Saber conocer Saber Ser Saber
TEMA 4. PROCESO UNIFICADO
TEMA 4. PROCESO UNIFICADO Definición El Proceso Unificado de Desarrollo Software es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura
DIAGRAMAS DE CLASES. Clases, asociaciones y atributos. Interfaces con sus operaciones y constantes. Información acerca del tipo de los atributos.
Completando los diagramas de interacción, es posible identificar la especificación de las clases que participarán en la solución indicando detalles de su implementación, como por ejemplo los métodos. Entradas
Principios de Diseño Orientado a Objetos
Principios de Diseño Orientado a Objetos PRINCIPIOS DE DISEÑO DE CLASES PRINCIPIO ABIERTO-CERRADO (OCP): Un módulo debe ser abierto para extensión pero cerrado para modificación. Wikipidia: La noción de
UNIVERSIDAD AUTÓNOMA DE CHIAPAS LICENCIATURA EN SISTEMAS COMPUTACIONALES
UNIVERSIDAD AUTÓNOMA DE CHIAPAS LICENCIATURA EN SISTEMAS COMPUTACIONALES Área de formación: Disciplinaria Unidad académica: Programación Orientada a Objetos Ubicación: Cuarto Semestre Clave: 2087 Horas
Requisitos. tiempo. Integración Pruebas de sistema. 4 semana (por ejemplo) El sistema crece en cada iteración
6 Diseño orientado a objetos En las etapas de captura de los requisitos y del análisis orientado a objetos se han centrado en aprender a realizar la definición del proyecto sin decir cómo. En esta otra
METODOLOGÍAS ÁGILES. Proceso Unificado Ágil (AUP) Ingeniería del Software II Análisis de Sistemas
METODOLOGÍAS ÁGILES Proceso Unificado Ágil (AUP) Docentes: Titular: Ing. Ivaniszyn Selva Nieves Rambo, Alice Sueldo, Roberto Integrantes: Osuna, Jessica Marianela Rougoski, Santiago José Ingeniería del
PATRONES DE DISEÑO DE CREACIÓN. Abstract Factory Builder Factory Method Prototype
PATRONES DE DISEÑO DE CREACIÓN Abstract Factory Builder Factory Method Prototype Patrones de diseño de creación Abstraen el proceso de creación de instancias Encapsulan el conocimiento sobre las clases
ZCBC. ECBTI. Programa Ingeniería de Sistemas. Curso Académico de Programación Orientada a Objetos. Código José Acevedo y Gómez
ZCBC. ECBTI. Programa Ingeniería de Sistemas Curso Académico de Programación Orientada a Objetos Código 301403 José Acevedo y Gómez Programación Orientada a Objetos Unidad II Requisitos y Análisis Unidad
20483 Programación en C#
20483B 20483 Programación en C# Fabricante: Microsoft Grupo: Desarrollo Subgrupo: Microsoft Visual Studio 2012 Formación: Presencial Horas: 25 Introducción Este curso enseña a los desarrolladores las habilidades
1. Preparar al estudiante para desarrollar aplicaciones de software utilizando un enfoque orientado a objetos.
UNIVERSIDAD DE SAN CARLOS DE GUATEMALA FACULTAD DE INGENIERIA ESCUELA DE CIENCIAS NOMBRE DEL CURSO: Computación y Programación 2 CODIGO: 771 CREDITOS: 5 ESCUELA: Ciencias y Sistemas AREA A LA QUE PERTENECE:
A. Goñi, J. Ibáñez, J. Iturrioz, J.A. Vadillo OCW 2013
Tema 3: Diseño A. Goñi, J. Ibáñez, J. Iturrioz, J.A. Vadillo OCW 2013 Índice 1.- Introducción El rol del diseño en el CV Artefactos a conseguir durante el flujo de trabajo del diseño Decisiones de diseño
Programación en Java. Horario: 3:00 PM 7:00PM
Horario: 3:00 PM 7:00PM Temario Lección 1: Orientación a objetos Lección 2: Creando una aplicación Java Lección 3: Creando Clases Lección 4: Programando en OO Lección 5: Manejo de excepciones Lección 6:
TÉCNICO SUPERIOR UNIVERSITARIO EN TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN
TÉCNICO SUPERIOR UNIVERSITARIO EN TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN HOJA DE ASIGNATURA CON DESGLOSE DE UNIDADES TEMÁTICAS 1. Nombre de la asignatura Introducción al análisis y diseño de sistemas.
Para esta práctica usaremos los diagramas de casos de uso, diagramas de secuencia, y los diagramas de clase.
Programación II, Guía #3 17 17 Facultad: Ingeniería Escuela: Computación Asignatura: Programación II GUÍA #3: Herramientas UML. Análisis y diseño UML. Objetivos Conocer una herramienta de modelado para
PROGRAMA DE CURSO. Metodologías de Diseño y Programación. Nombre en Inglés. Design and Programming Methodologies.
Código CC3002 Nombre Nombre en Inglés PROGRAMA DE CURSO Metodologías de Diseño y Programación Design and Programming Methodologies SCT es Docentes Horas de Cátedra Horas Docencia Auxiliar Horas de Trabajo
Registrar información o datos de una persona REQUERIMIENTO QUE LO UTILIZA O ESPECIALIZA:
1 REQUERIMIENTOS FUNCIONALES INTIFICADOR: R1 Registrar información o datos de una persona Si Alta Número y tipo de documento Apellidos y Nombres completos Dirección Teléfono Firma DOCUMENTOS VISUALIZACIÓN
Introducción a la Ingeniería de Software
Introducción a la Ingeniería de Software Diseño Software Engineering 7ed Addison Wesley Ian Sommerville Diseño Durante el diseño se refina la arquitectura El diseño es un plano de una solución para el
Universidad Salesiana de Bolivia
Universidad Salesiana de Bolivia Ingeniería de Sistemas I DATOS DE IDENTIFICACIÓN PLAN DE DISCIPLINA GESTIÓN II - 2015 INSTITUCIÓN UNIVERSITARIA: Universidad Salesiana de Bolivia RECTOR: Dr. Rvdo. P. Thelian
DIAGRAMAS DE CASOS DE USO. Prof. Hooberth Chávez Bedoya
DIAGRAMAS DE CASOS DE USO Prof. Hooberth Chávez Bedoya 1 Definir el comportamiento del sistema El comportamiento de un sistema es cómo un sistema actúa y reacciona El comportamiento del sistema es capturado
Ingeniería a de Software CC51A
Ingeniería a de Software CC51A Clase Auxiliar Auxiliar: Andrés s Neyem Oficina 418 de Doctorado aneyem@dcc.uchile.cl 19 de Marzo de 2007 Aspectos Generales Grupo CC51A Diseño Cliente Requisitos Usuario
Introducción a la certificación
Introducción a la certificación El Programa de certificación de LabVIEW de National Instruments consta de los tres siguientes niveles de certificación: - Desarrollador Asociado Certificado de NI - Desarrollador
Diagramas De Casos De Uso
Estáticos Diagramas De Casos De Uso Los diagramas de casos de uso documentan el comportamiento de un sistema desde el punto de vista del usuario.. Por lo tanto los casos de uso determinan los requisitos
Descripción del Curso
Curso Práctico de Modelado de Negocios BPMN con UML Descripción del Curso Durante este curso aprenderás de forma práctica el estándar BPMN (Business Process Management Notation) y las extensiones de UML
UMLGEC ++: Una Herramienta CASE para la Generación de Código a partir de Diagramas de Clase UML
UMLGEC ++: Una Herramienta CASE para la Generación de Código a partir de Diagramas de Clase UML Irving Alberto Cruz Matías 1 y Carlos Alberto Fernández y Fernández 2 1 Universidad Tecnológica de la Mixteca
Modelo de Casos de Uso y Representación en UML. Análisis y Diseño de Sistemas de Información UNIDAD 5
Modelo de Casos de Uso y Representación en UML Análisis y Diseño de Sistemas de Información UNIDAD 5 Modelo de Casos de Uso El modelo de Casos de Uso es una colección de escenarios de éxito y errores que
MOO - Metodología y Programación Orientada a Objetos
Unidad responsable: Unidad que imparte: Curso: Titulación: Créditos ECTS: 2015 230 - ETSETB - Escuela Técnica Superior de Ingeniería de Telecomunicación de Barcelona 701 - AC - Departamento de Arquitectura
Desarrollo Orientado a Objetos basado en UML
Desarrollo Orientado a Objetos basado en UML Proceso de Desarrollo Qué es? Un proceso de desarrollo de software describe un enfoque para construir, instalar y mantener sistemas de software Por qué necesitamos
Ingeniería del Software Herramientas CASE Que es CASE? Ingeniería de sistemas asistida por computadoras (Computer-aised system engineering, o CASE)
Que es CASE? Ingeniería de sistemas asistida por computadoras (Computer-aised system engineering, o CASE) es la aplicación de la tecnología de la información a las actividades, técnicas y a las metodologías
DESCRIPCIÓN PROJECT PRO FOR OFFICE 365
DESCRIPCIÓN PROJECT PRO FOR OFFICE 365 Project para Office 365 Obtén el control y las capacidades de Project Professional 2016 desde prácticamente cualquier lugar en forma de suscripción de escritorio
Metodologías en la Ingeniería del Software Métodos Orientados a Objetos
Metodologías en la Ingeniería del Software Métodos Orientados a Objetos García Departamento de Ciencias de la Computación Universidad de Alcalá Contenidos Historia Orientación a Objetos (OO) Problemas
PROGRAMA DE CURSO. Horas de Trabajo Personal Horas de Cátedra
PROGRAMA DE CURSO Código Nombre CC3002 Metodologías de Diseño y Programación Nombre en Inglés Design and programming methodologies SCT Unidades Docentes Horas de Cátedra Horas Docencia Auxiliar Horas de
PA JOSÉ MANUEL BURBANO CARVAJAL
PA121-01 SISTEMA DE GESTIÓN DEL CONOCIMIENTO PARA LA DEFINICIÓN DE ESTRATEGIAS QUE EVITEN LA DESERCIÓN ESCOLAR EN LOS COLEGIOS DE MOCOA PUTUMAYO EN EL NIVEL DE EDUCACIÓN BÁSICA SECUNDARIA JOSÉ MANUEL BURBANO
La Herencia: Teoría (1)
Introducción a la Herencia Presentación basada en: 1. Construcción de Software Orientado a Objetos. Bertrand Meyer.1998. 2. Java 2., Curso de programación. Fco. Javier Ceballos. Ed. Alfoomega&RA-MA, 2003.
Introducción a la Orientación a Objetos
Introducción a la Orientación a Objetos Breve historia de la OO 1960s. Simula incorpora características propias de la OO. 1970s. Smalltalk. Lenguaje totalmente OO. 1990s. Boom de la OO. 2000-Hoy. Época
Resultado de Aprendizaje:
10. Matriz de Valoración o Rúbrica MATRIZ DE VALORACIÓN O RÚBRICA Siglema: PROO-02 Nombre del Módulo: Nombre del Alumno: Docente evaluador: Grupo: Fecha: Resultado de Aprendizaje: 1.1 Diseña modelos bajo
LENGUAJE UNIFICADO UML _6 TRABAJO COLABORATIVO_1 AGENCIA DE VIAJES ASTROS TRABAJO PRESENTADO:
1 LENGUAJE UNIFICADO UML 200609_6 TRABAJO COLABORATIVO_1 AGENCIA DE VIAJES ASTROS TRABAJO PRESENTADO: LEYDY SUSANA VALENCIA RINCÓN CÓDIGO: 38682020 YUDIS MENDOZA FLOREZ CODIGO: 50879536 FLOR ERNILDA AMARILES
TEMA 6: INTRODUCCIÓN A UML
TEMA 6: INTRODUCCIÓN A UML Por qué modelamos? El modelado es una parte central de todas las actividades que conducen a la producción de un software de calidad. Como tal la ingeniería software debe basarse
Tecnología para la. Web (MVC)
Tecnología para la Construcción de Aplicaciones Web (MVC) Dr. Víctor J. Sosa vjsosa@tamps.cinvestav.mx Información sintetizada del curso: Introducción a los servicios y servidores de información en Internet
Nombre de la asignatura: Calidad de Software II Carrera: Lic. en Informática Clave de la asignatura: AWC Horas teoría-horas prácticacréditos:
.-DATOS DE LA ASIGNATURA Nombre de la asignatura: Calidad de Software II Carrera: Lic. en Informática Clave de la asignatura: AWC - 0705 Horas teoría-horas prácticacréditos: 4 2-0 2.-HISTORIA DEL PROGRAMA
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA PROYECTO CURRICULAR DE INGENIERÍA INDUSTRIAL
I. IDENTIFICACIÓN DE LA ASIGNATURA PROGRAMACIÓN ORIENTADA A OBJETOS CÓDIGO DE LA ASIGNATURA 00 ÁREA ACADÉMICA Informática y Electivas Libres SEMESTRE Segundo PLAN DE ESTUDIOS 00 - I TIPO DE ASIGNATURA
Diseño de Base de Datos
Diseño de Base de Datos DISEÑO DE BASE DE DATOS 1 Lectura No. 4 Nombre: Modelo entidad-relacional extendido Contextualización La creación de una base de datos hoy en día es parte fundamental dentro de
UNIVERSIDAD DE CIENCIAS EMPRESARIALES Y SOCIALES FACULTAD DE CIENCIAS EMPRESARIALES
UNIVERSIDAD DE CIENCIAS EMPRESARIALES Y SOCIALES FACULTAD DE CIENCIAS EMPRESARIALES Carrera: Tecnicatura universitaria en programación de sistemas Materia: Programación III Curso: 2 año Curso lectivo:
Diplomado Programación orientada a objetos con C++ y UML. Las empresas necesitan contar con sistemas de información modernos, ágiles y de calidad para alcanzar sus objetivos y ser cada vez más competitivos
METODOLOGÍAS PARA EL DESARROLLO DE SISTEMAS
!387" APÉNDICE A, APARTADO 1 METODOLOGÍAS PARA EL DESARROLLO DE SISTEMAS DOCUMENTACIÓN 1. La necesidad de los diagramas Los diagramas o representaciones gráficas representan una parte fundamental en el
Diagramas de Casos de Uso. Ingeniería del Sw-II, José Merseguer
Diagramas de Casos de Uso 19 Diagramas de Casos de Uso Casos de Uso es una técnica para capturar información de cómo un sistema o negocio trabaja actualmente, o de cómo se desea que trabaje. No pertenece
PERSISTENCIA DE OBJETOS EN BASE DE DATOS RELACIONALES FRANCISCO LEÓN NAJERA CÓDIGO: CEDULA:
PERSISTENCIA DE OBJETOS EN BASE DE DATOS RELACIONALES FRANCISCO LEÓN NAJERA CÓDIGO: 20092295009 CEDULA: 80087371 UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS BELTRÁN FACULTAD DE INGENIERÍA MAESTRIA EN
Tema 13 Modelos de Representación de Diagramas
Tema 13 Modelos de Representación de Diagramas En este tema haremos una revisión rápida de los modelos de representación de diagramas, y su utilidad en la Expresión Gráfica. 13.1 Introducción y Definición
Proceso Unificado (Iterativo e incremental)
Proceso Unificado (Iterativo e incremental) Proceso Unificado de Desarrollo de Software, I. Jacobson, J. Rumbaugh y G. Booch, Addison-Wesley, 1999 Fases y Flujos de trabajo de los ciclos de vida. Disciplinas
Ingeniería del Software 2
Análisis de requisitos es la 1ª fase técnica del proceso de ing. del SW Éxito -> Comprensión total de los requisitos Análisis de requisitos -> Tarea de descubrimiento, refinamiento, modelado y especificación
Programación orientada a objetos. Capítulo 8 Mejora de las estructuras mediante herencia
Programación orientada a objetos Capítulo 8 Mejora de las estructuras mediante herencia Clases y objetos de DoME Modelo de objetos Modelo de clases Crítica de la v1 de DoME - Duplicación de código - Las
Programación Orientada a Objetos
Universidad de Carabobo Facultad Experimental de Ciencias y Tecnología Departamento de Computación Programación Orientada a Objetos Algoritmos y Programación II Junio, 2004 Las tecnologías de objetos hoy
El ciclo de vida de un sistema de información
El ciclo de vida de un sistema de información 1. Las etapas del proceso de desarrollo de software Planificación Análisis Diseño Implementación Pruebas Instalación / Despliegue Uso y mantenimiento 2. Modelos
Capítulo 17 Modelo de Diseño: realización de los casos de uso con los patrones GRASP
Capítulo 17 Modelo de Diseño: realización de los casos de uso con los patrones GRASP UML y Patrones Una introducción al análisis y diseño orientado a objetos y al proceso unificado Craig Larman 2ª Edición
CAPÍTULO 7. El motivo de la realización del tutorial métricas de software fue para
CAPÍTULO 7 Tutorial de Métricas de Software El motivo de la realización del tutorial métricas de software fue para promocionar el uso y conocimiento de las métricas en México. El sitio de métricas se presenta
DISEÑO Y CONSTRUCCION DE MODELOS WEB
DISEÑO Y CONSTRUCCION DE MODELOS WEB UNIDAD II Politécnicos 2.1 DISEÑO DE SITIOS WEB El diseño se desarrollaba de manera ad- hoc y por lo general se efectuaba a medida que se generaba HTML. Después evolucionó
INGENIERÍA DEL SOFTWARE
INGENIERÍA DEL SOFTWARE Sesión No. 11 INGENIERÍA DEL SOFTWARE 1 Nombre: Estereotipos y valores etiquetados de los paquetes Contextualización Los estereotipos dentro de los medios de programación son más
Ciudad Guayana, Febrero de 2011
REPÚBLICA BOLIVARIANA DE VENEZUELA UNIVERSIDAD NACIONAL EXPERIMENTAL POLITÉCNICA ANTONIO JOSÉ DE SUCRE INGENIERÍA INDUSTRIAL CÁTEDRA: SISTEMAS DE INFORMACIÓN Profesor: Turmero, Iván Ciudad Guayana, Febrero