*****MANIFIESTO AGIL: Su objetivo fue el de establecer principios y valores que permitirían al equipo desarrollar el software mas rápidamente y que diera respuesta a los cambios que se puedan presentar en el transcurso del proyecto.
LOS VALORES QUE ENCONTRAMOS SON LOS SIGUIENTES.
- Valorar mas a los individuos que los procesos y herramientas.
- Valorar mas el software que funciona que la documentación.
- Valorar mas la colaboración con el cliente que la negociación contractual.
- Valorar mas la respuesta al cambio que el seguimiento de un plan.
*****XP: Esta metodología tiene como objetivo la satisfacion del cliente; por esta razón trata de dar a este el software que necesita y cuando lo necesita,ademas pretende potencializar el trabajo en grupo de las personas que están involucradas en el desarrollo del proyecto.
Muchos pensadores consideran que el XP es mas una filosofía que una metodología.
*****PMBOK: Es un estándar reconocido por la (IEEE std 1490-2003) y es la encargada de surtir de los fundamentos de la gestión de proyectos que se pueden aplicar aun rango amplio de proyectos.
Este estándar es ademas el mas ampliamente reconocido para manejar y administrar proyectos.
La finalidad del PMBOK, entonces, no es la de exponer disciplinas, técnicas y experiencias aplicables a la dirección de proyectos,sino la de identificar el subconjunto de estas.
PMBOK divide el conjunto de conocimientos para la dirección de proyectos en cuatro grupos de procesos:
todo proyecto(así como sus distintas fases e iteraciones) tiene que transitar por una serie de actividades de
INICIO,PLANEACION, EJECUCIÓN Y CIERRE,bajo el gobierno de u grupo de procesos mas general de supervision y cierre
área de conocimiento son:
*****PRINCE2: Es un método estructurado de gestión de proyectos. en este los proyectos son divididos en fases manejables que permitan controlar de manera eficiente los recursos y el control periódico de su evolución.
BENEFICIOS DE PRINCE2
- Comienzo organizado y controlado .
- Desarrollo organizado y controlado.
- Final organizado y controlado.
- Revisiones periódicas de los progresos.
- Flexibilidad en las decisiones.
- Buena comunicación etc.
ELEMENTOS DE PRINCE2
- 7 proyectos que forman la gestión de proyectos.
- 7 principios que forman la base de un buen método de gestión de proyecto.
- 7 temáticas o áreas de conocimiento que apoyan determinadas áreas claves en la gestión de proyecto.
*****CRISIS DEL SOFTWARE: Se refiere a un conjunto de problemas encontrados en el desarrollo del software de computadoras. los problemas no solo están relacionados con el que el software no funcione adecuadamente sino que la crisis también abarca los problemas relacionados con como desarrollar el software,como mantener un volumen creciente de software existente y como podemos podemos esperar satisfacer la demanda creciente de software.
PROBLEMAS
Son muchos los problemas que encontramos pero los responsables del desarrollo del software se concentrar sobre los aspectos de "fondo":
a) planificación.
b)productividad.
c) la calidad del software.
SÍNTOMAS
- El software no es fiable y necesita de un mantenimiento permanente,
- El software se entrega muy a menudo con retrasos y con unos costes superiores a los presupuestados,
- A menudo el software es imposible de mantener, carece de transparencia y no se puede modificar ni mejorar.
*****CHAOS REPORT: El informe chaos que realiza el Standish group es el mas importante sobre el fracaso de los proyectos en el sector de las tecnologías de la información(TI) .suele realizarse cada 2 años y su ultima edición fue en abril del 2009
******ARQUITECTURA DEL SOFTWARE: Según pressman la arquitectura de software no es mas que una descripción de los subsistemas y componentes y su relación entre ellos.
***** PATRÓN: Es una solución reutilizable de problemas que se presentan durante el desarrollo del software.
Ayudan a entender las soluciones del problema con un vocabulario igual lo que permite un mejor entendimiento.
Introducción a los Patrones
Características
***** PATRÓN: Es una solución reutilizable de problemas que se presentan durante el desarrollo del software.
Ayudan a entender las soluciones del problema con un vocabulario igual lo que permite un mejor entendimiento.
Introducción a los Patrones
Características
- Tiene un nombre
- Tiene un contexto o problema a resolver
- Tiene una solución
- Tiene unas consecuencias al utilizarlo
Características de un buen patrón
Documentar buenos patrones puede ser una tarea muy difícil. Citando a James Coplien en [Hillside03], un buen patrón:
- Resuelve un problema: Los patrones capturan soluciones, no principios o estrategias abstractas.
- Es un concepto probado: Capturan soluciones, no teorías o especulaciones. En el caso del “Design Patterns”, el criterio para decidir si algo era un patrón o no, era que éste debía tener al menos 3 implementaciones reales.
- La solución no es obvia: Muchas técnicas de resolución de problemas (como los paradigmas o métodos de diseño de software) intentan derivar soluciones desde principios básicos. Los mejores patrones generan una solución a un problema indirectamente (un enfoque necesario para los problemas de diseño más difíciles).
- Describe una relación: Los patrones no describen módulos sino estructuras y mecanismos.
5.Tiene un componente humano significante: El software sirve a las personas. Los mejores patrones aplican a la estética y a las utilidades (de hecho, no es casual que varios de los primeros lenguajes de patrones tengan que ver con temas estéticos y utilidades como Hot Draw ó ET++ ).
*****ROL DEL ARQUITECTO DE SOFTWARE: Para definir que es un arquitecto de software se debe tener en cuenta el escenario y contexto en particular ,ademas depende de la organización, el negocio,sus objetivos ,la importancia y tamaño del proyecto.
En base a esto el arquitecto de software puede ser categorizado de esta manera:
1. Arquitecto técnico.
2.Arquitecto funcional.
3.Arquitecto corporativo.
El rol de los arquitectos suele comprender las siguientes tareas:
- definición
de las vistas de la arquitectura de una aplicación (o sea, CREAR la
arquitectura, ya que la arquitectura, en pocas palabras es un conjunto de
vistas de alto nivel);
- dar
soporte técnico-tecnológico a desarrolladores, clientes y expertos en
negocios;
- conceptualizar
y experimentar con distintos enfoques arquitectónicos;
- crear
documentos de modelos y componentes y especificaciones de interfaces;
- validar la arquitectura contra requerimientos, suposiciones.
*****REFACTORIZACION: Refactorizar (o Refactoring) es realizar una transformación al software manteniendo su comportamiento, modificando sólo su estructura interna para mejorarlo.
Refactorizar Es el proceso de modificar el código de un desarrollo para mejorar su estructura interna sin alterar la funcionalidad que ofrece el desarrollo externamente.
La refactorización es una de las prácticas que se incluyen en Extreme Programming.
Para comenzar a Refactorizar es imprescindible que exista un desarrollo y que ese desarrollo tenga asociado código de prueba que nos permita saber en cualquier momento, pasando las pruebas automáticas, si el desarrollo sigue cumpliendo los requisitos que implementaba.
Si no existen estas pruebas será realmente complicado llevar a cabo refactorizaciones, dado que no podremos conocer si nuestras modificaciones han hecho que el desarrollo deje de funcionar. Pero eso no solo nos afectara a la hora de Refactorizar, sino también a la hora de intentar modificar nuestro desarrollo para añadir una nueva funcionalidad, dado que no sabremos si el nuevo código añadido ha podido influir en que el desarrollo deje de funcionar en otros casos.
*****PATRONES DE ARQUITECTURA: Los patrones de arquitectura expresan un esquema organizativo estructural fundamental para sistema de software.
patrón de arquitectura MVC.
El patrón de arquitectura MVC, conocido por sus siglas en inglés Model View Controller,que significa Modelo Vista Controlador, permite realizar la programación multicapa, separando en tres componentes distintos los datos de una aplicación, la interfaz del usuario y la lógica de control. Este patrón se ve usualmente en aplicaciones web, donde la vista es la página y el código que provee de datos dinámicos a la página, el modelo es el sistema de gestión de base de datos y el controlador representa la lógica del negocio, que está formado por tres niveles:
*****PATRONES DE ARQUITECTURA: Los patrones de arquitectura expresan un esquema organizativo estructural fundamental para sistema de software.
patrón de arquitectura MVC.
El patrón de arquitectura MVC, conocido por sus siglas en inglés Model View Controller,que significa Modelo Vista Controlador, permite realizar la programación multicapa, separando en tres componentes distintos los datos de una aplicación, la interfaz del usuario y la lógica de control. Este patrón se ve usualmente en aplicaciones web, donde la vista es la página y el código que provee de datos dinámicos a la página, el modelo es el sistema de gestión de base de datos y el controlador representa la lógica del negocio, que está formado por tres niveles:
§ Modelo: representa la
información con la que trabaja la aplicación, o sea, su lógica de negocio.
- Vista: convierte el modelo en una página web que facilita al usuario interactuar con ella.
Patrones de diseño y arquitectura.
*****PATRONES DE DISEÑO: Los patrones de diseño expresan esquemas para definir estructuras de diseño (o sus relaciones) con las que construir sistemas de software.
*****PATRONES DE DISEÑO GRASP: Estos patrones representan los principios básicos de la asignación de responsabilidades a objetos, expresados en forma de patrones. GRASP es el acrónimo para General Responsibility Assignment Software Patterns (Patrones Generales de Software para Asignar Responsabilidades).
patrones de asignación de responsabilidades
Experto: Se encarga de asignar una responsabilidad al experto en información, o sea, aquella clase que cuenta con la información necesaria para cumplir la responsabilidad.
Creador: Este patrón es el responsable de asignarle a la clase B la responsabilidad de crear una instancia de clase A. B es un creador de los objetos A.
Alta Cohesión: Asigna una responsabilidad de forma tal que la cohesión siga siendo alta.
Bajo Acoplamiento: Este patrón es el encargado de asignar una responsabilidad para conservar bajo acoplamiento.
Controlador: Asigna la responsabilidad del manejo de un mensaje de los eventos de un sistema a una clase.
link:
*****TDD: son las siglas de un proceso de desarrollo de software que se basa en la idea de desarrollar pruebas, codificar y refactorizar el codigo construido.
El procedimiento que hay que seguir para desarrollar aplicando TDD, Test Driver Development, es muy sencillo, a continuacion veremos como usar esta metodologia, o procedimiento de desarrollo, muy comun entre los seguidores de las metodologias agiles.
TDD se basa en la idea de realizar para el codigo que debemos construir. A diferencia del procedimiento que usamos habitualmente, construir el codigo y despues realizar las pruebas unitarias, TDD establece que primero hay que realizar una prueba y a continuación desarrollar el codigo que la resuelve.
*****PATRONES DE DISEÑO GOF:Los patrones GoF (Gang of Four, en español Pandilla de los Cuatro, formada por Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides) se clasifican en 3 categorías basadas en su propósito: creacionales, estructurales y de comportamiento.
Creacionales: Los patrones creacionales abstraen el proceso de creación de instancias y ocultan los detalles de cómo los objetos son creados o inicializados.
Estructurales: Los patrones estructurales se ocupan de cómo las clases y objetos se combinan para formar grandes estructuras y proporcionar nuevas funcionalidades.
Comportamiento: Los patrones de comportamiento están relacionadas con los algoritmos y la asignación de responsabilidades entre los objetos. Son utilizados para organizar, manejar y combinar comportamientos.
*****HERRAMIENTAS CASE:VENTAJAS Y DESVENTAJAS
VENTAJAS
Entre los beneficios ofrecidos por la tecnología CASE se encuentran los siguientes:
Facilidad para la revisión de aplicaciones
La experiencia muestra que una vez que las aplicaciones se implementan, se emplean por mucho tiempo. Las herramientas CASE proporcionan un beneficio substancial para las organizaciones al facilitar la revisión de las aplicaciones. Contar con un depósito central agiliza el proceso de revisión ya que éste proporciona bases para las definiciones y estándares para los datos. Las capacidades de generación interna, si se encuentran presentes, contribuyen a modificar el sistema por medio de las especificaciones más que por los ajustes al código fuente.
Soporte para el desarrollo de prototipos de sistemas
En general, el desarrollo de prototipos de aplicaciones toma varias formas. En ocasiones se desarrollan diseños para pantallas y reportes con la finalidad de mostrar la organización y composición de los datos, encabezados y mensajes. Los ajustes necesarios al diseño se hacen con rapidez para alterar la presentación y las características de la interface. Sin embargo, no se prepara el código fuente, de naturaleza orientada hacia procedimientos, como una parte del prototipo.
Como disyuntiva, el desarrollo de prototipos puede producir un sistema que funcione. Las características de entrada y salida son desarrolladas junto con el código orientado hacia los procedimientos y archivos de datos.
Muchas herramientas CASE soportan las primeras etapas del desarrollo del prototipo. Muy pocas brindan apoyo durante todo el proceso de desarrollo del prototipo. Las que proporcionan la capacidad para generar código soportan de hecho todo proceso, ya que el código puede ser generado al inducir la actividad de generación después de cambiar las especificaciones o requerimientos.
Generación de código
Como ya se mencionó, algunas herramientas CASE tienen la capacidad de producir el código fuente. La ventaja más visible de esta característica es la disminución del tiempo necesario para preparar un programa. Sin embargo, la generación del código también asegura una estructura estándar y consistente para el programa (lo que tiene gran influencia en el mantenimiento) y disminuye la ocurrencia de varios tipos de errores, mejorando de esta manera la calidad. Las características de la generación del código permiten volver a utilizar el software y las estructuras estándares para generar dicho código, así como el cambio de una especificación modular, lo que significa volver a generar el código y los enlaces con otros módulos. Ninguna de las herramientas que existen en el presente es capaz de generar un código completo en los dominios.
Mejora en la habilidad para satisfacer los requerimientos del usuario
Es bien conocida la importancia de satisfacer los requerimientos del usuario, ya que esto guarda relación con el éxito del sistema. De manera similar, tener los requerimientos correctos mejora la calidad de las prácticas de desarrollo. Parece ser que las herramientas CASE disminuyen el tiempo de desarrollo, una característica que es importante para los usuarios. Las herramientas afectan la naturaleza y cantidad de interacción entre los encargados del desarrollo y el usuario. Las descripciones gráficas y los diagramas, así como los prototipos de reportes y la composición de las pantallas, contribuyen a un intercambio de ideas más efectivo.
Soporte interactivo para el proceso de desarrollo
La experiencia ha demostrado que el desarrollo de sistemas es un proceso interactivo. Las herramientas CASE soportan pasos interactivos al eliminar el tedio manual de dibujar diagramas, elaborar catálogos y clasificar. Como resultado de esto, se anticipa que los analistas repasarán y revisarán los detalles del sistema con mayor frecuencia y en forma más consistente.
DESVENTAJAS
Las herramientas CASE tienen puntos débiles significativos, que van desde la confiabilidad en los métodos estructurados hasta su alcance limitado, los cuales amenazan con minar los beneficios potenciales descritos con anterioridad.
Confiabilidad en los métodos estructurados
Muchas herramientas CASE están construidas teniendo como base las metodologías del análisis estructurado y del ciclo de vida de desarrollo de sistemas. Por si sola, esta característica puede convertirse en la principal limitante ya que no todas las organizaciones emplean métodos de análisis estructurado.
Los métodos estructurados, introducidos en la década de los setenta, fueron muy elogiados por su habilidad para mejorar la exactitud de los requerimientos específicos de las aplicaciones. El nivel de conocimiento de los métodos estructurados es lato entre los profesionales de sistemas de información – de acuerdo con algunas estimaciones (Yourdon), casi el 90% de todos los analistas esta familiarizado con estos métodos -. Aproximadamente la mitad de todas las organizaciones en Estados Unidos han utilizado alguna vez estos métodos. A pesar de lo anterior, si la organización o el analista no utilizan los métodos propios del análisis estructurado y tampoco desean considerar su uso, entonces el valor del CASE disminuye. En algunos casos, los analistas evitan del todo emplear herramientas CASE.
Falta de niveles estándar para el soporte de la metodología
Aún no aparece un conjunto “estándar” de herramientas CASE. Por tanto, debe tener precaución al seleccionar una herramienta de este tipo.
Existen dos significados para las palabras “soporte de la metodología”. Una herramienta puede: 1) dar soporte a los diagramas que emplea una metodología o 2) soportarlos e imponer la metodología, sus reglas y procesos.
Las herramientas CASE que existen en el presente, tienen una de las siguientes características:
* Son independientes de la metodología.
* Permiten que los usuarios definan sus propias metodologías.
* Soportan una metodología.
* Soportan las metodologías más diseminadas.
En todas ellas existen ciertos compromisos. Las herramientas que son independientes de la metodología, no pueden fomentar el uso de las reglas y estándares de la misma. Estas herramientas quizá proporcionen los componentes de una metodología (por ejemplo: diagramas de flujos de datos, un diccionario de datos y facilidades para la descripción de procesos), pero no el marco de referencia, reglas y procedimientos que en realidad constituyen el núcleo de la metodología. Aunque se puede llevar a cabo acciones básicas para la validación de diseños y diagramas para detectar componentes faltantes, éstas son sólo funciones mecánicas. Por otra parte, esta clase de herramientas no puede proporcionar ayuda metodológica o pedir al usuario que realice tareas necesarias para la metodología que aún esta sin terminar.
Estas herramientas mejoran la productividad al efectuar tareas tediosas y de documentación, aunque ellas no puedan asegurar buenos resultados. Desde el punto de vista funcional, las capacidades que brindan para garantizar la calidad son mínimas.
Conflictos en el uso de los diagramas
Las herramientas difieren en el uso que hacen los diagramas. Algunas son herramientas exclusivamente para gráficas, que se abocan al dibujo de diagramas para el análisis de entrada y salida de datos. Este tipo de herramientas puede restringir ya sea el proceso de desarrollo normal seguido por una organización o el estilo particular de trabajo de los analistas.
Otros vendedores de herramientas consideran los diagramas como documentación y aceptan entradas por medio de formas o lenguajes de especificación y, en ocasiones, en forma gráfica. Por tanto, se debe tener cuidado cuando se selecciona una herramienta para apoyar los métodos existentes en una organización.
Diagramas no utilizados
En general, los productos CASE emplean gráficas para modelar y generar informes sobre el análisis y desarrollo de sistemas. Una de las afirmaciones de los vendedores de herramientas es que las presentaciones gráficas y la documentación mejoran la comunicación entre los miembros del equipo de desarrollo, propician una calidad mayor de la entrada proporcionada por el cliente y mejoran la productividad de desarrollo de software. Sin embargo, los investigadores han encontrado que, en algunos casos, las herramientas gráficas, automatizadas o manuales, no se emplean del todo. O tal vez no se utilicen en la forma que deberían emplearse. Por otra parte, algunos analistas prefieren para algunas tareas un lenguaje estructurado o descriptivo.
Muchos profesionales de los sistemas de información no hacen uso de herramientas gráficas en el desarrollo de software; más bien las emplean para automatizar la producción de informes y documentación del sistema, como los diagramas de flujo utilizados por los programadores para documentar un programa una vez terminado.
Función limitada
Aunque una herramienta puede apoyar varias fases del ciclo de vida de desarrollo de sistemas o adaptarse a diferentes metodologías de desarrollo, por lo general su enfoque primario está dirigido hacia una fase o método especifico. Por ejemplo, los encargados de desarrollar un nuevo producto pueden afirmar que éste apoya todo el proceso de análisis y diseño. Sin embargo, las capacidades de comprobación y verificación de errores del producto quizá sean más rigurosas ya sea en el área de análisis o en la de diseño, pero no en ambas. Algunos productos están dirigidos hacia el diseño de bases de datos para la organización y al desarrollo de aplicaciones que giren en torno a la base de datos, omitiendo el soporte para pantallas de presentación visual, los informes sobre requerimientos o las necesidades de seguridad. Algunos productos capaces de generar el código hacen mayor hincapié en el desarrollo de prototipos como el principal método de desarrollo de sistemas de información. Muchas herramientas para la fase de desarrollo recalcan el mantenimiento y la reestructuración del código, pero ofrecen un soporte débil durante la fase de análisis para la determinación y especificación de requerimientos.
Alcance limitado
Aunque muchas herramientas basadas en computadoras incluyen la capacidad de verificar las especificaciones para determinar su complementes o consistencia, virtualmente no llevan a cabo ningún análisis de los requerimientos de la aplicación. Por tanto, el alcance de las actividades de desarrollo asociado con las herramientas existentes es bastante limitado.
La mayor parte de productos CASE describe (documenta) pero no analiza. De poca ayuda es proporcionar una regla de inclusión en los mejores enfoques y una regla de exclusión para los que son poco satisfactorios. No ofrecen o evalúan, soluciones potenciales para los problemas relacionados con sistemas. Y tampoco existe una garantía clara para que dos analistas que utilicen los mismos métodos aplicados a información idéntica, formulen recomendaciones igualmente aceptables.
*****GENEXUS: Es una herramienta de desarrollo de software ágil, multiplataforma, basada en conocimiento, orientada principalmente a empresariales, plataformas y dispositivos móviles o inteligentes.
incluye un módulo de normalización de base de datos (En 3ª forma normal), que crea y mantiene la base de datos óptima (estructura y contenido) basada en las visiones de la realidad descritas por los usuarios utilizando un lenguaje declarativo.
GeneXus genera código para múltiples lenguajes para múltiples plataformas móviles.
GeneXus es muy rapido para el desarrollo de aplicaciones ABM (Alta Baja y Modificaciones) permitiendo en poco tiempo tener resultados a la vista. A su vez para realizar prototipos para un cliente antes de darle el producto final, lo cual no implica que lo ya generado no pueda ser usado como producto final. Estos prototipos permiten la localización temprana de errores y un mejor seguimiento a los requerimientos de los usuarios, así se logra implantar aplicaciones en el menor tiempo posible y con la mayor calidad posible.
Lo que si no esta pensado para aplicaciones donde la lógica cumple un rol muy importante en la aplicación, o aplicaciones muy especificas.
*****ENCAPSULACION:Consiste en crear objetos que funcionan como unidades completas con características y métodos (código y datos) en el mismo tipo de objeto.
*****POLIMORFISMO: Es cuando distintos objetos de distintas clases reciben un mismo mensaje.
*****OBJETO:Es un componente del mundo real que tiene un cierta estructura interna y un determinado comportamiento. Una entidad delimitada precisamente y con identidad, que encapsula estado y comportamiento. El estado es representado por sus atributos y relaciones, el comportamiento es representado por sus operaciones y métodos. Un objeto es una instancia de una clase.
*****INDICE BD:
Los índices pueden ser creados usando una o más columnas, proporcionando la base tanto para búsquedas rápidas al azar como de un ordenado acceso a registros eficiente.
El espacio en disco requerido para almacenar el índice es típicamente menor que el espacio de almacenamiento de la tabla (puesto que los índices generalmente contienen solamente los campos clave de acuerdo con los que la tabla será ordenada, y excluyen el resto de los detalles de la tabla), lo que da la posibilidad de almacenar en memoria los índices de tablas que no cabrían en ella. En una base de datos relacional un índice es una copia de una parte de la tabla.
*****ARQUITECTURA FÍSICA: La arquitectura física expresa cuáles son los componentes físicos (cliente, servidor, servidor web, BD, etc.) que participan en nuestra solución, así como la relación entre ellos.
*****ESTILOS ARQUITECTONICOS: Es la descripción de los tipos de componentes y un patrón de su control de ejecución y/o transferencia de datos
*****PATRONES DE DISEÑO GRASP: Estos patrones representan los principios básicos de la asignación de responsabilidades a objetos, expresados en forma de patrones. GRASP es el acrónimo para General Responsibility Assignment Software Patterns (Patrones Generales de Software para Asignar Responsabilidades).
patrones de asignación de responsabilidades
Experto: Se encarga de asignar una responsabilidad al experto en información, o sea, aquella clase que cuenta con la información necesaria para cumplir la responsabilidad.
Creador: Este patrón es el responsable de asignarle a la clase B la responsabilidad de crear una instancia de clase A. B es un creador de los objetos A.
Alta Cohesión: Asigna una responsabilidad de forma tal que la cohesión siga siendo alta.
Bajo Acoplamiento: Este patrón es el encargado de asignar una responsabilidad para conservar bajo acoplamiento.
Controlador: Asigna la responsabilidad del manejo de un mensaje de los eventos de un sistema a una clase.
*****TDD: son las siglas de un proceso de desarrollo de software que se basa en la idea de desarrollar pruebas, codificar y refactorizar el codigo construido.
El procedimiento que hay que seguir para desarrollar aplicando TDD, Test Driver Development, es muy sencillo, a continuacion veremos como usar esta metodologia, o procedimiento de desarrollo, muy comun entre los seguidores de las metodologias agiles.
TDD se basa en la idea de realizar para el codigo que debemos construir. A diferencia del procedimiento que usamos habitualmente, construir el codigo y despues realizar las pruebas unitarias, TDD establece que primero hay que realizar una prueba y a continuación desarrollar el codigo que la resuelve.
*****PATRONES DE DISEÑO GOF:Los patrones GoF (Gang of Four, en español Pandilla de los Cuatro, formada por Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides) se clasifican en 3 categorías basadas en su propósito: creacionales, estructurales y de comportamiento.
Creacionales: Los patrones creacionales abstraen el proceso de creación de instancias y ocultan los detalles de cómo los objetos son creados o inicializados.
Estructurales: Los patrones estructurales se ocupan de cómo las clases y objetos se combinan para formar grandes estructuras y proporcionar nuevas funcionalidades.
Comportamiento: Los patrones de comportamiento están relacionadas con los algoritmos y la asignación de responsabilidades entre los objetos. Son utilizados para organizar, manejar y combinar comportamientos.
*****HERRAMIENTAS CASE:VENTAJAS Y DESVENTAJAS
VENTAJAS
Entre los beneficios ofrecidos por la tecnología CASE se encuentran los siguientes:
Facilidad para la revisión de aplicaciones
La experiencia muestra que una vez que las aplicaciones se implementan, se emplean por mucho tiempo. Las herramientas CASE proporcionan un beneficio substancial para las organizaciones al facilitar la revisión de las aplicaciones. Contar con un depósito central agiliza el proceso de revisión ya que éste proporciona bases para las definiciones y estándares para los datos. Las capacidades de generación interna, si se encuentran presentes, contribuyen a modificar el sistema por medio de las especificaciones más que por los ajustes al código fuente.
Soporte para el desarrollo de prototipos de sistemas
En general, el desarrollo de prototipos de aplicaciones toma varias formas. En ocasiones se desarrollan diseños para pantallas y reportes con la finalidad de mostrar la organización y composición de los datos, encabezados y mensajes. Los ajustes necesarios al diseño se hacen con rapidez para alterar la presentación y las características de la interface. Sin embargo, no se prepara el código fuente, de naturaleza orientada hacia procedimientos, como una parte del prototipo.
Como disyuntiva, el desarrollo de prototipos puede producir un sistema que funcione. Las características de entrada y salida son desarrolladas junto con el código orientado hacia los procedimientos y archivos de datos.
Muchas herramientas CASE soportan las primeras etapas del desarrollo del prototipo. Muy pocas brindan apoyo durante todo el proceso de desarrollo del prototipo. Las que proporcionan la capacidad para generar código soportan de hecho todo proceso, ya que el código puede ser generado al inducir la actividad de generación después de cambiar las especificaciones o requerimientos.
Generación de código
Como ya se mencionó, algunas herramientas CASE tienen la capacidad de producir el código fuente. La ventaja más visible de esta característica es la disminución del tiempo necesario para preparar un programa. Sin embargo, la generación del código también asegura una estructura estándar y consistente para el programa (lo que tiene gran influencia en el mantenimiento) y disminuye la ocurrencia de varios tipos de errores, mejorando de esta manera la calidad. Las características de la generación del código permiten volver a utilizar el software y las estructuras estándares para generar dicho código, así como el cambio de una especificación modular, lo que significa volver a generar el código y los enlaces con otros módulos. Ninguna de las herramientas que existen en el presente es capaz de generar un código completo en los dominios.
Mejora en la habilidad para satisfacer los requerimientos del usuario
Es bien conocida la importancia de satisfacer los requerimientos del usuario, ya que esto guarda relación con el éxito del sistema. De manera similar, tener los requerimientos correctos mejora la calidad de las prácticas de desarrollo. Parece ser que las herramientas CASE disminuyen el tiempo de desarrollo, una característica que es importante para los usuarios. Las herramientas afectan la naturaleza y cantidad de interacción entre los encargados del desarrollo y el usuario. Las descripciones gráficas y los diagramas, así como los prototipos de reportes y la composición de las pantallas, contribuyen a un intercambio de ideas más efectivo.
Soporte interactivo para el proceso de desarrollo
La experiencia ha demostrado que el desarrollo de sistemas es un proceso interactivo. Las herramientas CASE soportan pasos interactivos al eliminar el tedio manual de dibujar diagramas, elaborar catálogos y clasificar. Como resultado de esto, se anticipa que los analistas repasarán y revisarán los detalles del sistema con mayor frecuencia y en forma más consistente.
DESVENTAJAS
Las herramientas CASE tienen puntos débiles significativos, que van desde la confiabilidad en los métodos estructurados hasta su alcance limitado, los cuales amenazan con minar los beneficios potenciales descritos con anterioridad.
Confiabilidad en los métodos estructurados
Muchas herramientas CASE están construidas teniendo como base las metodologías del análisis estructurado y del ciclo de vida de desarrollo de sistemas. Por si sola, esta característica puede convertirse en la principal limitante ya que no todas las organizaciones emplean métodos de análisis estructurado.
Los métodos estructurados, introducidos en la década de los setenta, fueron muy elogiados por su habilidad para mejorar la exactitud de los requerimientos específicos de las aplicaciones. El nivel de conocimiento de los métodos estructurados es lato entre los profesionales de sistemas de información – de acuerdo con algunas estimaciones (Yourdon), casi el 90% de todos los analistas esta familiarizado con estos métodos -. Aproximadamente la mitad de todas las organizaciones en Estados Unidos han utilizado alguna vez estos métodos. A pesar de lo anterior, si la organización o el analista no utilizan los métodos propios del análisis estructurado y tampoco desean considerar su uso, entonces el valor del CASE disminuye. En algunos casos, los analistas evitan del todo emplear herramientas CASE.
Falta de niveles estándar para el soporte de la metodología
Aún no aparece un conjunto “estándar” de herramientas CASE. Por tanto, debe tener precaución al seleccionar una herramienta de este tipo.
Existen dos significados para las palabras “soporte de la metodología”. Una herramienta puede: 1) dar soporte a los diagramas que emplea una metodología o 2) soportarlos e imponer la metodología, sus reglas y procesos.
Las herramientas CASE que existen en el presente, tienen una de las siguientes características:
* Son independientes de la metodología.
* Permiten que los usuarios definan sus propias metodologías.
* Soportan una metodología.
* Soportan las metodologías más diseminadas.
En todas ellas existen ciertos compromisos. Las herramientas que son independientes de la metodología, no pueden fomentar el uso de las reglas y estándares de la misma. Estas herramientas quizá proporcionen los componentes de una metodología (por ejemplo: diagramas de flujos de datos, un diccionario de datos y facilidades para la descripción de procesos), pero no el marco de referencia, reglas y procedimientos que en realidad constituyen el núcleo de la metodología. Aunque se puede llevar a cabo acciones básicas para la validación de diseños y diagramas para detectar componentes faltantes, éstas son sólo funciones mecánicas. Por otra parte, esta clase de herramientas no puede proporcionar ayuda metodológica o pedir al usuario que realice tareas necesarias para la metodología que aún esta sin terminar.
Estas herramientas mejoran la productividad al efectuar tareas tediosas y de documentación, aunque ellas no puedan asegurar buenos resultados. Desde el punto de vista funcional, las capacidades que brindan para garantizar la calidad son mínimas.
Conflictos en el uso de los diagramas
Las herramientas difieren en el uso que hacen los diagramas. Algunas son herramientas exclusivamente para gráficas, que se abocan al dibujo de diagramas para el análisis de entrada y salida de datos. Este tipo de herramientas puede restringir ya sea el proceso de desarrollo normal seguido por una organización o el estilo particular de trabajo de los analistas.
Otros vendedores de herramientas consideran los diagramas como documentación y aceptan entradas por medio de formas o lenguajes de especificación y, en ocasiones, en forma gráfica. Por tanto, se debe tener cuidado cuando se selecciona una herramienta para apoyar los métodos existentes en una organización.
Diagramas no utilizados
En general, los productos CASE emplean gráficas para modelar y generar informes sobre el análisis y desarrollo de sistemas. Una de las afirmaciones de los vendedores de herramientas es que las presentaciones gráficas y la documentación mejoran la comunicación entre los miembros del equipo de desarrollo, propician una calidad mayor de la entrada proporcionada por el cliente y mejoran la productividad de desarrollo de software. Sin embargo, los investigadores han encontrado que, en algunos casos, las herramientas gráficas, automatizadas o manuales, no se emplean del todo. O tal vez no se utilicen en la forma que deberían emplearse. Por otra parte, algunos analistas prefieren para algunas tareas un lenguaje estructurado o descriptivo.
Muchos profesionales de los sistemas de información no hacen uso de herramientas gráficas en el desarrollo de software; más bien las emplean para automatizar la producción de informes y documentación del sistema, como los diagramas de flujo utilizados por los programadores para documentar un programa una vez terminado.
Función limitada
Aunque una herramienta puede apoyar varias fases del ciclo de vida de desarrollo de sistemas o adaptarse a diferentes metodologías de desarrollo, por lo general su enfoque primario está dirigido hacia una fase o método especifico. Por ejemplo, los encargados de desarrollar un nuevo producto pueden afirmar que éste apoya todo el proceso de análisis y diseño. Sin embargo, las capacidades de comprobación y verificación de errores del producto quizá sean más rigurosas ya sea en el área de análisis o en la de diseño, pero no en ambas. Algunos productos están dirigidos hacia el diseño de bases de datos para la organización y al desarrollo de aplicaciones que giren en torno a la base de datos, omitiendo el soporte para pantallas de presentación visual, los informes sobre requerimientos o las necesidades de seguridad. Algunos productos capaces de generar el código hacen mayor hincapié en el desarrollo de prototipos como el principal método de desarrollo de sistemas de información. Muchas herramientas para la fase de desarrollo recalcan el mantenimiento y la reestructuración del código, pero ofrecen un soporte débil durante la fase de análisis para la determinación y especificación de requerimientos.
Alcance limitado
Aunque muchas herramientas basadas en computadoras incluyen la capacidad de verificar las especificaciones para determinar su complementes o consistencia, virtualmente no llevan a cabo ningún análisis de los requerimientos de la aplicación. Por tanto, el alcance de las actividades de desarrollo asociado con las herramientas existentes es bastante limitado.
La mayor parte de productos CASE describe (documenta) pero no analiza. De poca ayuda es proporcionar una regla de inclusión en los mejores enfoques y una regla de exclusión para los que son poco satisfactorios. No ofrecen o evalúan, soluciones potenciales para los problemas relacionados con sistemas. Y tampoco existe una garantía clara para que dos analistas que utilicen los mismos métodos aplicados a información idéntica, formulen recomendaciones igualmente aceptables.
*****GENEXUS: Es una herramienta de desarrollo de software ágil, multiplataforma, basada en conocimiento, orientada principalmente a empresariales, plataformas y dispositivos móviles o inteligentes.
incluye un módulo de normalización de base de datos (En 3ª forma normal), que crea y mantiene la base de datos óptima (estructura y contenido) basada en las visiones de la realidad descritas por los usuarios utilizando un lenguaje declarativo.
GeneXus genera código para múltiples lenguajes para múltiples plataformas móviles.
GeneXus es muy rapido para el desarrollo de aplicaciones ABM (Alta Baja y Modificaciones) permitiendo en poco tiempo tener resultados a la vista. A su vez para realizar prototipos para un cliente antes de darle el producto final, lo cual no implica que lo ya generado no pueda ser usado como producto final. Estos prototipos permiten la localización temprana de errores y un mejor seguimiento a los requerimientos de los usuarios, así se logra implantar aplicaciones en el menor tiempo posible y con la mayor calidad posible.
Lo que si no esta pensado para aplicaciones donde la lógica cumple un rol muy importante en la aplicación, o aplicaciones muy especificas.
*****ENCAPSULACION:Consiste en crear objetos que funcionan como unidades completas con características y métodos (código y datos) en el mismo tipo de objeto.
*****POLIMORFISMO: Es cuando distintos objetos de distintas clases reciben un mismo mensaje.
*****OBJETO:Es un componente del mundo real que tiene un cierta estructura interna y un determinado comportamiento. Una entidad delimitada precisamente y con identidad, que encapsula estado y comportamiento. El estado es representado por sus atributos y relaciones, el comportamiento es representado por sus operaciones y métodos. Un objeto es una instancia de una clase.
*****INDICE BD:
El índice de una base de datos es una estructura de datos que mejora la velocidad de las operaciones, permitiendo un rápido acceso a los registros de una en una tabla en una base de datos. Al aumentar drásticamente la velocidad de acceso, se suelen usar sobre aquellos campos sobre los cuales se hacen frecuentes búsquedas.
El índice tiene un funcionamiento similar al índice de un libro, guardando parejas de elementos: el elemento que se desea indexar y su posición en la base de datos. Para buscar un elemento que esté indexado, sólo hay que buscar en el índice dicho elemento para, una vez encontrado, devolver el registro que se encuentre en la posición marcada por el índice.Los índices pueden ser creados usando una o más columnas, proporcionando la base tanto para búsquedas rápidas al azar como de un ordenado acceso a registros eficiente.
El espacio en disco requerido para almacenar el índice es típicamente menor que el espacio de almacenamiento de la tabla (puesto que los índices generalmente contienen solamente los campos clave de acuerdo con los que la tabla será ordenada, y excluyen el resto de los detalles de la tabla), lo que da la posibilidad de almacenar en memoria los índices de tablas que no cabrían en ella. En una base de datos relacional un índice es una copia de una parte de la tabla.
*****ARQUITECTURA FÍSICA: La arquitectura física expresa cuáles son los componentes físicos (cliente, servidor, servidor web, BD, etc.) que participan en nuestra solución, así como la relación entre ellos.
La especificación de la arquitectura física normalmente
consta de uno o más diagramas, y la explicación de los mismos (actores y
relaciones entre ellos).
En la explicación de los diagramas se debe especificar el
nombre y la función de cada actor, y el tipo de relación que existe entre ellos
(si existe alguna). También se puede incluir ejemplo aclaratorios de puntos un
tanto abstractos.
*****ARQUITECTURA LÓGICA: La arquitectura lógica expresa cuáles son los componentes lógicos (subsistemas, o macro-funciones) que participan en nuestra solución, y la relación entre ellos.
*****ARQUITECTURA LÓGICA: La arquitectura lógica expresa cuáles son los componentes lógicos (subsistemas, o macro-funciones) que participan en nuestra solución, y la relación entre ellos.
La especificación de esta arquitectura es similar a la
arquitectura física. Se especifican los actores y las relaciones entre ellos,
sólo que los actores ahora son subsistemas de mi solución o macro-funciones de
la misma.
En los diagramas que expresan tanto la arquitectura lógica
como la física, se puede utilizar casi cualquier simbología que clarifique el
escenario (DFD, diagramas de clases, bloques, casos de uso, dibujo informal,
etc.), a menos que existan restricciones al respecto.
*****ESTILOS ARQUITECTONICOS: Es la descripción de los tipos de componentes y un patrón de su control de ejecución y/o transferencia de datos
Un estilo arquitectónico
es una transformación impuesta al diseño de todo un sistema. El objetivo es
establecer una estructura para todos los componentes del sistema.
Indican
Los tipos de
componentes y sus conectores involucrados
Patrones y
restricciones de interconexión o composición entre ellos
Invariantes del estilo
(restricciones)
Asociado a cada estilo
hay una serie de propiedades que lo caracterizan
Determinan sus ventajas
e inconvenientes
Condicionan la elección
de uno u otro estilo.
•
Cada
estilo describe una categoría de sistemas que abarca
1.
Un
conjunto de componentes (por ejemplo, una BD, módulos computacionales) que
realizan una función requerida por el sistema.
2.
Un
Conjunto de conectores que permiten la “comunicación, coordinación y
cooperación entre los componentes”
3.
Restricciones
que definen cómo se integran los componentes para formar el sistema.
Modelos semánticos que permiten a un diseñador,
mediante el análisis de las propiedades conocidas de las partes que lo
integran, comprender las propiedades generales de un sistema
Estilos de Flujo de Datos
*Tubería y filtros
Estilos Centrados en Datos
*Arquitecturas de Pizarra o Repositorio
Estilos de Llamada y Retorno
Model-View-Controller (MVC)
*Arquitecturas en Capas
*Arquitecturas Orientadas a Objetos
* Arquitecturas Basadas en Componentes
Estilos
de Código Móvil
–
Arquitectura
de Máquinas Virtuales
Estilos
heterogéneos
–
Sistemas
de control de procesos
–
Arquitecturas
Basadas en Atributos
Estilos
Peer-to-Peer
–
Arquitecturas
Basadas en Eventos
–
Arquitecturas
Orientadas a Servicios
–
Arquitecturas
Basadas en Recursos.
*****SOA: ¿Qué es SOA – Service Oriented Architecture?
*****SOA: ¿Qué es SOA – Service Oriented Architecture?
La palabra de
moda en los últimos años en el área de desarrollo de software ha sido SOA –
Arquitectura Orientada a Servicios. ¿Pero qué significa SOA en realidad?
Básicamente
SOA es un cambio significativo en la manera en que nosotros diseñamos y
construimos aplicaciones. Esta arquitectura toma la naturaleza abierta de la
Web y la convierte en una nueva manera de pensar acerca de las arquitecturas de
aplicaciones.
SOA significa
integración a través de sistemas diversos. SOA utiliza protocolos estándar e
interfaces convencionales – usualmente Web Services – para facilitar el acceso
a la lógica de negocios y la información entre diversos servicios. SOA nos
brinda los principios y la guía para transformar el conjunto de recursos de TI
de la compañía – los cuales son por lo general heterogéneos, distribuidos,
inflexibles y complejos - en recursos
flexibles, integrados y simplificados, que pueden ser cambiados y compuestos
para alinearse más fácilmente con los objetivos del negocio. Podemos decir
entonces, que SOA no es una herramienta, no más bien es un conjunto de patrones
de construcción de las nuevas aplicaciones de la empresa – más dinámicas y
menos dependientes.
SOA es la
evolución del modelo de programación orientado a componentes, ya que SOA agrega
herramientas de computación distribuida a estas tecnologías que hemos venido
utilizando por años. Podríamos decir que el cambio más grande es filosófico: en
lugar de pensar en el diseño de aplicaciones individuales para resolver
problemas especificos, SOA ve el software como un patrón que soporta todo el
proceso del negocio. Cada elemento de un servicio es un componente que puede
ser utilizado muchas veces a través de muchas funciones y procesos dentro y
fuera de la empresa. Los servicios se pueden actualizar y escalar conforme sea
requerido, o se pueden cambiar a una librería de terceros, sin afectar la
operación del negocio – esto se da por que el componente clave de SOA no es la
aplicación o el componente en uso si no más bien el contrato de uso, la
interface.
La idea detrás
de todo esto es que es más efectivo trabajar con servicios que con
aplicaciones.
*****SAAS: Es un modelo de distribución del software que proporciona a los clientes el acceso al mismo a través de la red (generalmente Internet), de manera que les libra del mantenimiento de las aplicaciones, de operaciones técnicas y de soporte. Las aplicaciones distribuidas en la modalidad SaaS pueden llegar a cualquier tipo de empresa sin importar su tamaño o su ubicación geográfica. Se trata de un modelo que une el producto (software) al servicio, para dotar a las empresas de una solución completa que permita optimizar sus costes y sus recursos.
*****DIAGRAMA DE COMPONENTE: Los Diagramas de Componentes ilustran las piezas del software, controladores embebidos, etc. que conformarán un sistema. Un diagrama de Componentes tiene un nivel más alto de abstracción que un diagrama de clase – usualmente un componente se implementa por una o más clases (u objetos) en tiempo de ejecución. Estos son bloques de construcción, como eventualmente un componente puede comprender una gran porción de un sistema. Estos Diagramas contienen:
• componentes
• interfaces
• Relaciones de dependencia, generalización, asociación y realización
• Paquetes o subsistemas
Los componentes se pueden agrupar en paquetes así como los objetos en clases, además pueden haber entre ellos relaciones de dependencia como:
• generalización
• asociación
• agregación
• realización
*****DIAGRAMA DE DESPLIEGUE: muestran las relaciones físicas de los distintos nodos que componen un sistema y el reparto de los componentes sobre dichos nodos. La vista de despliegue representa la disposición de las instancias de componentes de ejecución en instancias de nodos conectados por enlaces de comunicación. Un nodo es un recurso de ejecución tal como un computador, un dispositivo o memoria. Los estereotipos permiten precisar la naturaleza del equipo:
• Dispositivos
• Procesadores
• Memoria
Un diagrama de despliegue es un grafo de nodos unidos por conexiones de comunicación. Un nodo puede contener instancias de componentes software, objetos, procesos (caso particular de un objeto). En general un nodo será una unidad de computación de algún tipo, desde un sensor a un mainframe. Las instancias de componentes software pueden estar unidas por relaciones de dependencia, posiblemente a interfaces (ya que un componente puede tener más de una interfaz).
*****DIAGRAMA DE COLABORACIÓN: Un Diagrama de Colaboración muestra una interacción organizada basándose en los objetos que toman parte en la interacción y los enlaces entre los mismos (en cuanto a la interacción se refiere).
UML –Interacciones
Los objetos interactúan entre sí pasándose mensajes.
Los objetos se conectan a través de enlaces.
Mensaje: especifica transmisión de información entre objetos.
Enlace: especifica un camino a lo largo del cual un objeto puede enviar un mensaje a otro objeto.
Es una conexión semántica entre objetos.
Es una instancia de una relación.
Puede contener los adornos de la relación.
ELEMENTOS:
Objetos o Roles: nodos del grafo.
Enlaces o comunicaciones: arcos del grafo.
Mensajes: llevan número de secuencia y flecha dirigida.
Anidamiento: se utiliza la numeración decimal Ej: 1, 1.1, 1.1.1 ........
Iteración: colocar un * antes del número de secuencia y una cláusula de condición, si es necesario. ej. *[x>0].
Bifurcación: los caminos alternativos tendrán el mismo número de secuencia, seguido del número de subsecuencia, y se deben distinguir por una condición.
*****SERVICIO: Un servicio es el resultado de llevar a cabo necesariamente al menos una actividad en la interfaz entre el proveedor y el cliente y generalmente es intangible. La prestación de un servicio puede implicar:
una actividad realizada sobre un producto tangible suministrado por el cliente (por ejemplo, reparación de un automóvil);
una actividad realizada sobre un producto intangible suministrado por el cliente (por ejemplo, la declaración de ingresos necesaria para preparar la devolución de los impuestos);
la entrega de un producto intangible (por ejemplo, la entrega de información en el contexto de la transmisión de conocimiento);
la creación de una ambientación para el cliente (por ejemplo, en hoteles y restaurante)
*****WEB SERVER: Es el servidor que se conecta directamente a Internet y en la que físicamente se encuentran guardadas todas las páginas que componen nuestro sitio de Internet.
*****SAAS: Es un modelo de distribución del software que proporciona a los clientes el acceso al mismo a través de la red (generalmente Internet), de manera que les libra del mantenimiento de las aplicaciones, de operaciones técnicas y de soporte. Las aplicaciones distribuidas en la modalidad SaaS pueden llegar a cualquier tipo de empresa sin importar su tamaño o su ubicación geográfica. Se trata de un modelo que une el producto (software) al servicio, para dotar a las empresas de una solución completa que permita optimizar sus costes y sus recursos.
*****DIAGRAMA DE COMPONENTE: Los Diagramas de Componentes ilustran las piezas del software, controladores embebidos, etc. que conformarán un sistema. Un diagrama de Componentes tiene un nivel más alto de abstracción que un diagrama de clase – usualmente un componente se implementa por una o más clases (u objetos) en tiempo de ejecución. Estos son bloques de construcción, como eventualmente un componente puede comprender una gran porción de un sistema. Estos Diagramas contienen:
• componentes
• interfaces
• Relaciones de dependencia, generalización, asociación y realización
• Paquetes o subsistemas
Los componentes se pueden agrupar en paquetes así como los objetos en clases, además pueden haber entre ellos relaciones de dependencia como:
• generalización
• asociación
• agregación
• realización
*****DIAGRAMA DE DESPLIEGUE: muestran las relaciones físicas de los distintos nodos que componen un sistema y el reparto de los componentes sobre dichos nodos. La vista de despliegue representa la disposición de las instancias de componentes de ejecución en instancias de nodos conectados por enlaces de comunicación. Un nodo es un recurso de ejecución tal como un computador, un dispositivo o memoria. Los estereotipos permiten precisar la naturaleza del equipo:
• Procesadores
• Memoria
Un diagrama de despliegue es un grafo de nodos unidos por conexiones de comunicación. Un nodo puede contener instancias de componentes software, objetos, procesos (caso particular de un objeto). En general un nodo será una unidad de computación de algún tipo, desde un sensor a un mainframe. Las instancias de componentes software pueden estar unidas por relaciones de dependencia, posiblemente a interfaces (ya que un componente puede tener más de una interfaz).
UML –Interacciones
Los objetos interactúan entre sí pasándose mensajes.
Los objetos se conectan a través de enlaces.
Mensaje: especifica transmisión de información entre objetos.
Enlace: especifica un camino a lo largo del cual un objeto puede enviar un mensaje a otro objeto.
Es una conexión semántica entre objetos.
Es una instancia de una relación.
Puede contener los adornos de la relación.
ELEMENTOS:
Objetos o Roles: nodos del grafo.
Enlaces o comunicaciones: arcos del grafo.
Mensajes: llevan número de secuencia y flecha dirigida.
Anidamiento: se utiliza la numeración decimal Ej: 1, 1.1, 1.1.1 ........
Iteración: colocar un * antes del número de secuencia y una cláusula de condición, si es necesario. ej. *[x>0].
Bifurcación: los caminos alternativos tendrán el mismo número de secuencia, seguido del número de subsecuencia, y se deben distinguir por una condición.
*****SERVICIO: Un servicio es el resultado de llevar a cabo necesariamente al menos una actividad en la interfaz entre el proveedor y el cliente y generalmente es intangible. La prestación de un servicio puede implicar:
una actividad realizada sobre un producto tangible suministrado por el cliente (por ejemplo, reparación de un automóvil);
una actividad realizada sobre un producto intangible suministrado por el cliente (por ejemplo, la declaración de ingresos necesaria para preparar la devolución de los impuestos);
la entrega de un producto intangible (por ejemplo, la entrega de información en el contexto de la transmisión de conocimiento);
la creación de una ambientación para el cliente (por ejemplo, en hoteles y restaurante)
*****WEB SERVER: Es el servidor que se conecta directamente a Internet y en la que físicamente se encuentran guardadas todas las páginas que componen nuestro sitio de Internet.
Básicamente, un servidor web sirve contenido estático a un
navegador, carga un archivo y lo sirve a través de la red al navegador de un
usuario. Este intercambio es mediado por el navegador y el servidor que hablan
el uno con el otro mediante HTTP.
Se pueden utilizar varias tecnologías en el servidor para aumentar su potencia más allá de su capacidad de entregar páginas HTML; éstas incluyen scripts CGI, seguridad SSL y páginas activas del servidor (ASP).
