jueves

Puntos Extras


Ligas  puntos extras


Casos de Sistemas Fallidos
Metodología de Análisis y Diseño de Software
Ejercicio # 2: Conceptos

Casos de Usos

Casos de Uso:
  • Jugar: Permite iniciar juego seleccionando una casilla, ademas de reiniciar el juego y la opción salir.
  • Ayuda: Permite mostrar información acerca del Buscaminas, unas breves instrucciones ademas de opciones de juego en Internet.
  • Opciones: Permite elegir el tipo de dificultad


Casos de uso:
  • Seleccionar carrera: Permite elegir una carrera al usuario
  • Correo Universitario: Permite ingresar al correo  universitario


miércoles

Antipatrones


Antipatrones

Los antipatrones son soluciones negativas que presentan más problemas que los que solucionan. Son una extensión natural a los patrones de diseño. Comprender los antipatrones provee el conocimiento para intentar evitarlos o recuperarse de ellos. El estudio de los antipatrones permite conocer los errores más comunes relacionados con la industria del software. La obra de referencia en este campo es AntiPatterns: Refactoring Software , Architectures and Projects in Crisis [BMMM98], publicada en 1998.
Los antipatrones se documentan con cierto cinismo, lo cual los hace bastante graciosos y fáciles de recordar. Los nombres siempre aluden al problema que tratan con humor. Se documentan mediante una plantilla (como los patrones de diseño) que incluye secciones para documentar la solución orígen (que es la causa del problema), el contexto, las fuerzas en conflicto y las soluciones correctas propuestas (para más detalles sobre la plantilla, ver el Capítulo 3 de Antipatterns). Un buen antipatrón explica por qué la solución original parece atractiva, por qué se vuelve negativa y cómo recuperarse de los problemas que ésta genera.

Por qué estudiar antipatrones

Un antipatrón (antipattern, en inglés) es una forma literaria que describe una solución común a un problema que genera decididamente consecuencias negativas. Según el libroAntiPatterns: Refactoring Software , Architectures and Projects in Crisis, los antipatrones...:
  • Son un método eficiente para vincular una situación general a una clase de solución específica.
  • Proveen experiencia del mundo real para reconocer problemas recurrentes en la industria del software, ofreciendo también una solución para sus implicaciones más comunes.
  • Establecen un vocabulario común para identificar problemas y discutir soluciones.
  • Soportan la resolución holística de conflictos, utilizando recursos organizacionales a diferentes niveles.

Categorías de antipatrones

En el libro de antipatrones, éstos se dividen en 3 grandes categorías a las cuales se denominan “puntos de vista”:
  • Desarrollo de Software: Se centran en problemas asociados al desarrollo de software a nivel de aplicación.
  • Arquitectura de Software: Se centran en la estructura de las aplicaciones y componentes a nivel de sistema y empresa.
  • Gestión de Proyectos de Software: En la ingeniería del software, más de la mitad del trabajo consiste en comunicación entre personas y resolver problemas relacionados con éstas. Los antipatrones de gestión de proyectos de software identifican algunos de los escenarios clave donde estos temas son destructivos para el proceso de software.


//Bibliografias
1

Diagramas UML



UML es un conjunto de herramientas, que permite modelar (analizar y diseñar) sistemas orientados a objetos.

Historia

Durante los ochenta y principios de los noventa Grady Booch, James Rumbaugh, e Ivar Jacobson trabajaban por separado en desarrollo de notaciones para el análisis y diseño de sistemas orientados a objetos. Los tres llegaron por separado a obtener bastante reconocimiento.
Booch había escrito "Object-Oriented Analysis and Design with ApplicationsDescripción: http://www.assoc-amazon.com/e/ir?t=webestilo05&l=as2&o=1&a=020189551X" un libro de referencia en el análisis y diseño orientado a objetos desarrollando su propia notación.
Por su parte James Rumbaugh había desarrollado su propia notación de diseño orientado a objetos llamada OMT (Object Modeling Technique) en su libro "Object-Oriented Modeling and DesignDescripción: http://www.assoc-amazon.com/e/ir?t=webestilo05&l=as2&o=1&a=0136298419".
Por otro lado Jacobson se había revelado como un visionario del análisis (padre de los casos de uso) y sobre todo del diseño orientado a objetos, sorprendiendo a todo el mundo en "Object-Oriented Software Engineering: A Use Case Driven ApproachDescripción: http://www.assoc-amazon.com/e/ir?t=webestilo05&l=as2&o=1&a=0201544350".
A mediados de los noventa empezaron a intercambiar documentos y trabajar en conjunto produciendo grandes avances en el modelado de sistemas orientados a objetos.
En 1994 Rational contrató a Rumbaugh en donde ya trabajaba Booch, un año después Jacobson se unía a ellos en Rational.
En 1997 salió a la luz la versión 1.0 de UML.



Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.
Se puede aplicar en el desarrollo de software entregando gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar.
//Bibliografias
1
2
3

Presentacion Proyecto Final

martes

Patrones de Diseño

Un patrón de diseño es una solución a un problema de diseño. Para que una solución sea considerada un patrón debe poseer ciertas características. Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reutilizable, lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias.
Los patrones de diseño son el esqueleto de las soluciones a problemas comunes en el desarrollo de software.


Los cuales se clasifican como se muestra a continuación:

  1. Patrones Creacionales: Inicialización y configuración de objetos.
  2. Patrones Estructurales: Separan la interfaz de la implementación. Se ocupan de cómo las clases y objetos se agrupan, para formar estructuras más grandes.
  3. Patrones de Comportamiento: Más que describir objetos o clases, describen la comunicación entre ellos.

Además de su aplicación directa en la construcción de software en general, y derivado precisamente del gran éxito que han tenido, los patrones de diseño han sido aplicados a múltiples ámbitos concretos produciéndose "lenguajes de patrones" y extensos "catálogos" de la mano de diversos autores.
En particular son notorios los esfuerzos en los siguientes ámbitos:
  • Patrones de interfaces de usuario, esto es, aquellos que intentan definir las mejores formas de construir interfaces hombre-máquina (véase Interacción persona-computador, Interfaz gráfica de usuario).
  • Patrones para la construcción de sistemas empresariales, en donde se requieren especiales esfuerzos en infraestructuras de software y un nivel de abstracción importante para maximizar factores como la escalabilidad o el mantenimiento del sistema.
  • Patrones para la integración de sistemas (véase Integración de aplicaciones empresariales), es decir, para la intercomunicación y coordinación de sistemas heterogéneos.
  • Patrones de flujos de trabajo, esto es para la definición, construcción e integración de sistemas abstractos de gestión de flujos de trabajo y procesos con sistemas empresariales. Véase también BPM.


Patron de comportamiento: Este patrón permite solicitar una operación a un objeto sin conocer realmente el contenido de esta operación, ni el receptor real de la misma. Para ello se encapsula la petición como un objeto, con lo que además se facilita la parametrización de los métodos.


Aplicaciones:

  • Facilitar la parametrización de las acciones a realizar.
  • Independizar el momento de petición del de ejecución.
  • Implementar CallBacks, especificando que órdenes queremos que se ejecuten en ciertas situaciones de otras órdenes. Es decir, un parámetro de una orden puede ser otra orden a ejecutar.
  • Soportar el "deshacer".
  • Desarrollar sistemas utilizando órdenes de alto nivel que se construyen con operaciones sencillas (primitivas).


Bibliografias
1
2
3

Sistemas Distribuidos


Los Sistemas Distribuidos sin sistemas cuyos componentes hardware y software, que están en ordenadores conectados en red, se comunican y coordinan sus acciones mediante el paso de mensajes, para el logro de un objetivo. Se establece la comunicación mediante un protocolo prefijado por un esquema cliente-servidor".
·         Concurrencia.- Esta característica de los sistemas distribuidos permite que los recursos disponibles en   puedan ser utilizados simultáneamente por los usuarios y/o agentes que interactúan en la red.
·         Carencia de reloj global.- Las coordinaciones para la transferencia de mensajes entre los diferentes componentes para la realización de una tarea, no tienen una temporización general, esta más bien distribuida a los componentes.
·         Fallos independientes de los componentes.- Cada componente del sistema puede fallar independientemente, con lo cual los demás pueden continuar ejecutando sus acciones. Esto permite el logro de las tareas con mayor efectividad, pues el sistema en su conjunto continua trabajando.

El tamaño de un sistema distribuido puede ser muy variado, ya sean decenas de hosts 
red de área local), centenas de hosts (red de área metropolitana), y miles o millones de
hosts (Internet); esto se denomina escalabilidad.

Ventajas:
·        Mejor aprovechamiento de los recursos.
·        Mayor poder de cómputo a más bajo costo.
·        En teoría, mayor confiablidad, si se maneja suficiente redundancia.
·        Crecimiento incremental.
Desventajas:
·        El software es mucho más complejo.
·        Muchos usuarios desde muchas partes: problemas de seguridad.



Bibliografias
1
2
3