lunes, 16 de noviembre de 2015

Entrada para idesweb

Tim Bernes Lee - Padre de la web


Ver en wikipedia

Corría 1989. El físico Tim Berners-Lee (1955) propuso conectar documentos para aprovechar mejor la información científica del CERN (Organización Europea para la Investigación Nuclear) donde trabajaba. Sin darse cuenta inventó a la vez un sistema para gestionar la información de manera más inteligente y una herramienta que hoy nos lleva a pensar y relacionarnos de otra manera. Le dio forma en un artículo que denominó "Manejo de la información" publicado el 12 de marzo, hace hoy 25 años. 

Para desarrollar el sistema, combinó dos tecnologías ya existentes (el hipertexto y el protocolo de comunicaciones de Internet), creando un nuevo modelo de acceso a la información intuitivo e igualitario: las famosas tres W.

Historia del Servidor Web



domingo, 3 de junio de 2012

Arquitectura Orientada a Servicios


Esta basada en la implementación de Servicios de Negocio, esto es; bloques funcionales de negocio que se pueden integrar, y compartir en distintas aplicaciones. La principal tecnología para implementar servicios SOA es WebServices, y es la que se recomienda, se promueve y exige, pero hay que tener cuidado, porque fácilmente se puede cometer errores, sino se asumen los siguientes principios:

·         Un Webservice no necesariamente es un Servicio SOA.
·         Un Servicio SOA no necesariamente tiene que ser implementado como WebService.

Para que un WebService se considere un Servicio SOA, debe cumplir con los estándares SOA, a grandes rasgos: debe corresponder a una funcionalidad del Negocio bien acotada (self cointained), independiente de la implementación tecnológica e independiente de los sistemas operacionales que lo soportan (loose coupling), y además debe poder ser compartido y reutilizado por otros procesos o sistemas (reuse). Por otro lado, un servicio SOA podría ser implementado con otras tecnologías, como HttpService, Mensajería, Ajax (DWR), etc, pero nuevamente para ser considerado como tal, debe cumplir los estándares SOA.

En la Arquitectura Orientada a Servicios, se puede reemplazar un servicio sin tener que preocuparse por la tecnología fundamental; la interfase es lo que importa, y está definida en un estándar universal en servicios Web y XML. Esto es flexibilidad a través de la interoperabilidad. También es la habilidad de asegurar los activos existentes, aplicaciones y bases de datos legales y hacerlos parte de las soluciones empresariales extendiéndolos al SOA en vez de reemplazarlos. El resultado en la red es la habilidad de evolucionar rápida y eficientemente, en otras palabras, adaptarse “orgánicamente” de acuerdo a la demanda del negocio. Esto es realmente nuevo.

En segundo lugar está la relevancia para el negocio. SOA es TI expresada a un nivel que tiene un significado importante para la colaboración del negocio y profesionales del área. Sus servicios actuales pueden coordinar unidades de trabajo muy cercanas a las actividades del negocio; piense, por ejemplo, en un servicio llamado “Actualización de órdenes de trabajo”. Éstos son inmediatamente relevantes para los analistas de la empresa que participan en la creación y definición de nuevos procesos permitiendo el “Servicio Dirigido Empresarial”.




sábado, 19 de mayo de 2012

Arquitectura Cliente-Servidor


Se  basa en un sistema distribuido entre múltiples procesadores donde hay clientes que solicitan servicios y servidores que los proporcionan. Separa los servicios situando cada uno en su plataforma respectiva ó más adecuada.
La arquitectura Cliente/Servidor agrupa conjuntos de elementos que efectúan procesos distribuidos y computo cooperativo. 




Desde el ámbito funcional, se puede definir la arquitectura Cliente/Servidor como una arquitectura distribuida que permite a los usuarios obtener acceso a la información de forma transparente aún en entornos multiplataforma.


Un sistema basado en Cliente/Servidor es un Sistema de Información distribuido el cual consta de las siguientes características:


-Servicio: unidad básica de diseño. El servidor lo(s) proporciona y el cliente lo(s) utiliza.
-Recursos compartidos: Muchos clientes utilizan los mismos servidores y, a través de ellos, comparten tanto recursos lógicos como físicos.
-Protocolos asimétricos: Los clientes inician “conversaciones”. Los servidores esperan su establecimiento pasivamente.
-Transparencia de localización física de los servidores y clientes: El cliente no tiene por qué saber dónde se encuentra situado el recurso que desea utilizar.
-Independencia de la plataforma HW y SW que se emplee.
-Sistemas débilmente acoplados. Interacción basada en envío de mensajes.
-Encapsulamiento de servicios. Los detalles de la implementación de un servicio son transparentes al cliente.
-Escalabilidad horizontal (añadir clientes) y vertical (ampliar potencia de los servidores).
-Integridad: Datos y programas centralizados en servidores facilitan su integridad y mantenimiento.



Para entender en forma más ordenada y clara los conceptos y elementos involucrados en esta Arquitectura se puede aplicar una descomposición por niveles. Esta descomposición principalmente consiste en separar los elementos estructurales de esta arquitectura en función de aspectos más funcionales de la misma:


-Nivel de Presentación: Agrupa a todos los elementos asociados al componente Cliente.
-Nivel de Aplicación: Agrupa a todos los elementos asociados al componente Servidor.
-Nivel de comunicación: Agrupa a todos los elementos que hacen posible la comunicación entre los componentes Cliente y servidor.
-Nivel de base de datos: Agrupa a todas las actividades asociadas al acceso de los datos.







MIDDLEWARE
El middleware es un módulo intermedio que actúa como conductor entre sistemas permitiendo a cualquier usuario de sistemas de información comunicarse con varias fuentes de información que se encuentran conectadas por una red. En el caso que nos concierne, es el intermediario entre el cliente y el servidor y se ejecuta en ambas partes.

viernes, 11 de mayo de 2012

Arquitectura de Software

Según la IEEE 1471-2000: 
La Arquitectura de Software es la organización fundamental de un sistema encarnada en sus componentes, las relaciones entre ellos y el ambiente y los principios que orientan su diseño y evolución.





La Arquitectura de Software es el diseño de nivel mas alto de la estructura del sistema organizacional.
Es la consecuencia de armar cierto número de elementos ó componentes arquitectónicos de forma adecuada y así cumplir con los requerimientos de desempeño y funcionalidad  de un sistema, así como los requerimientos no funcionales, como la , escalabilidad, confiabilidad, portabilidad y disponibilidad.


En la Arquitectura de Software se dan los siguientes estilos de arquitectura:


-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 







jueves, 26 de abril de 2012

RUP




Proceso Unificado de Rational (Rational Unified Process).Es un proceso de desarrollo de software que junto con UML (Lenguaje Unificado de Modelado)
complementa la metodología estándar más utilizada para el análisis llamada implementación y documentación de sistemas orientados a objetos.

El RUP es un sistema con pasos establecidos parcialmente, es un conjunto de metodologías adaptables al contexto y necesidades de cada organización,
y está basado en 6 principios clave que son los siguientes:

Equilibrar prioridades
Adaptar el proceso
Colaboración entre equipos
Demostrar valor iterativamente
Enfocarse en la calidad
Elevar el nivel de abstracción


martes, 24 de abril de 2012

Diagrama de Secuencia

Es diagrama utilizado para modelar la interacción entre los objetos en un sistema. Según UML en él se
muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada respectivo caso de uso.
Se pueden usar de dos formas:
  • Genérico: Describe la interacción para un caso de uso; Utiliza ramificaciones ("Branches"), condiciones y bucles.
  • De instancia: Describe un escenario específico (un escenario es una instancia en la ejecución de un caso de uso).

miércoles, 11 de abril de 2012

Diagrama de Clases UML



Diagrama de clases:

·         Es el diagrama principal para el análisis y diseño.

·          Presenta las clases del sistema con sus relaciones asociativas, de herencia, de uso y de convencimiento.

·         Representa los objetos fundamentales del sistema, es decir, los que percibe el usuario y con los que espera tratar para completar su tarea en ves de objetos del sistema o de un modelo de programación.

*Clase: Es la Unidad básica que encapsula toda la información de un objeto (un objeto es una instancia de una clase). A través de ella podemos modelar el torno en estudio (una casa, un auto, una cuenta corriente, etc.).

Define el ámbito de definición de un conjunto de objetos. (cada objeto pertenece a una clase)

En UML, una clase es representada por un rectángulo que posee tres divisiones:

<Nombre clase> contiene el nombre de la clase;

 <Atributos> atributos o variables de instancia que caracterizan a la clase (pueden ser private, protected o public);  

<Operaciones o métodos> forma en como la clase interactúa con su entorno; (pueden ser de tres clases private, protected o public) Los parámetros van separados por comas y sólo se especifica el tipo.

*clase abstracta: se denota con el nombre de la clase y de los métodos con letra “itálica”. Esto indica que la clase definida no puede ser instanciada pues posee métodos abstractos (sin implementación). La única forma de utilizarlas es definiendo subclases, que implementan los métodos abstractos definidos.
Para indicar que una clase es abstracta o final se debe colocar un comentario en la parte superior del rectángulo, debajo del nombre de la clase. Este comentario va entre llaves.


Los métodos abstractos también llevan un comentario al final.



*clase parametrizada: se denota con un subcuadro en el extremo superior de la clase, en donde se especifican lo parámetros que deben ser pasados a la clase para que esta pueda ser instanciada.



·         El diagrama de clases está compuesto por:

1.    Elementos de clase:

a.    Atributo:
·         Es la expresión grafica que ilustra, con recuadros y fechas, los pasos que se deben seguir para producir algo.
·         Los recuadros los agentes encargados de ejecutar lo que señalan las flechas.
·         Las flechas a su vez representan las acciones o pasos.

·         Los atributos pueden ser, según su:
-tipo: puede llegar a depender del lenguaje de programación a utilizar

-valor inicial: valor que poseerá el atributo al crear un objeto

-visibilidad: está relacionado con el encapsulamiento

-multiplicidad: determinar si un atributo debe estar o no, y si posee un único valor o lista de valores.

-ordenamiento: especifica si el atributo determina alguna relación de orden dentro de la clase.

-capacidad de cambio: permite definir atributos con valores constantes

-modificadores: un atributo puede ser de clase, derivado, volátil, transitorio.

b.    Métodos: Una operación es el servicio que una instancia  de la clase puede realizar
·         Los métodos pueden ser:

-tipo devuelto: puede llegar a depender del lenguaje de programación a utilizar.
-parámetros: además del tipo puede especificarse si son In, out,  o inOut
-visibilidad: está relacionado con el encapsulamiento
-Modificadores: un atributo puede ser de clase, abstracta query o constructor.


c.    Visibilidad: La visibilidad, de atributos y métodos, puede ser:
- privado
+ público
# protegido
~ de paquete


2.    Elementos de relaciones:

*relaciones entre clases: (clases con características y objetivos diferentes)
cardinalidad de relaciones: en UML, indica el grado y nivel de dependencia; se anotan en cada extremo de la relación, pueden ser:

-ò uno ò muchos: 1…*
-ò 0 ò muchos: 0…* (0...n)
-ò número fijo: m (m denota el número)
Una asociación es una conexión estructural simple entre clases

a.     Herencia: (especialización/generalización):
·         Mecanismo que permite derivar una clase de otra, de manera que extienda su funcionalidad
·         Indica que una subclase hereda los métodos y atributos especificados por una Súper Clase, por ende la subclase además de poseer sus propios métodos y atributos, poseerá las características y atributos visibles de la Sùper Clase (protected y public)



b.   .Composición:
·         En referencia al lenguaje visual: supone la organización de los elementos que forman el conjunto de la imagen, con el fin de obtener un efecto de unidad y orden.

c.     Agregación:
Es una asociación especial, una relación del tipo “todo/parte”, dentro de la cual una o mas clases son partes de un conjunto.
Para modelar objetos complejos, no bastan los tipos de datos básicos que proveen lo lenguajes: enteros, reales y secuencias de caracteres.
Cuando se requiere componer objetos que son instancias de clases definidas por el desarrollo de la aplicación, tenemos dos posibilidades:
a.    Por valor: es un tipo de relación estática, en donde el tiempo de vida incluido está condicionado por el tiempo de vida del que lo incluye.
Este tipo de relación es llamada composición (el objeto base se construye a partir del objeto incluido)
b.    Por referencia: es un tipo de relación dinámica, en donde el tiempo de vida del objeto incluido es independiente de lo que incluye. Es llamada agregación (el objeto base utiliza al incluido para su funcionamiento)



d.     Asociación:
Permite asociar objetos que colaboran entre si. No es una relación fuerte, es decir, el tiempo de vida de un objeto no depende del otro.
La asociación expresa una conexión bidireccional entre objetos, es una abstracción de la relación existente en los enlaces entre los objetos.
Rol: identificado como un nombre a los finales de la asociación, describe la semántica de la relación en el sentido indicado; cada asociación tiene 2 roles y cada rol es una dirección de la asociación.
Las asociaciones pueden ser:
-asociación calificada: Un calificador es un atributo (o tupla de atributos) de la asociación cuyos valores sirven para particionar el conjunto de objetos enlazados a otro.
Un calificador se representa como un pequeño rectángulo conectado al final de una asociación y a la clase
El rectángulo del calificador es parte de la asociación, y no parte de la clase
-asociación n-arias: son asociaciones que se establecen entre mas de dos clases. Una clase puede aparecer varias veces desempeñando distintos roles.
Se representan a través de un rombo que se une con cada una de las clases; pueden ser usadas para impedir inconsistencias en el modelo.



e.    Dependencia o instanciación:

Es una relación de “uso” en la que un cambio en uno de los términos puede afectar a otro.
Una clase es instanciada (su instanciación es dependiente de otro objeto/clase). Se denota por una flecha punteada.
El uso mas particular de este tipo de relación es para denotar la dependencia que tiene una clase de otra.
El objeto creado no se no se almacena dentro del objeto que lo crea.
Posibles dependencias entre clases:
-use: el funcionamiento del origen depende de la presencia del destino
-instantiate: el origen crea las instancias del destino
-derive: el origen puede calcularse a partir del destino
-refine: el origen está un grado de abstracción mas detallado
-bind(): derivación genérica de un aplantilla
-friend: visibilidad característica de C++



·     ESTEREOTIPOS: Un estereotipo representa el principal mecanismo de extensión de UML. Ofrece una forma de extender una metaclase, creando un nuevo elemento metamodelo.


·        INTERFACES: es una colección de operaciones que representan servicios ofrecidos por una clase o componente. Por definición, todas estas operaciones tendrán una visibilidad pública.

La clase realiza una o varias interfaces; UML identifica 2 tipos de interfaces:
-interfaz suministrada: es aquella que una clase efectivamente implementa.
-interfaz requerida: son aquellas que necesita una clase para realizar su cometido. Se representa con un semicírculo.

Para mostrar que una clase implementa una interfaz, se utiliza una línea punteada desde la clase hacia la interfaz, que termina en un triángulo vacío.

Una interfaz se puede representar como una clase. En el primer compartimento del rectángulo debe ir la palabra “interfaz” encerrada en símbolos de << y >>. En los otros compartimientos, se trabaja igual que con las clases.
·        
     MODELO DE DOMINIO Y MODELO DE DISEÑO: El diagrama de clases puede utilizarse con distintos fines en distintas etapas del proceso de desarrollo.
Durante la etapa de análisis, el modelo de dominio es el encargado de mostrar el conjunto de clases conceptuales del problema y las relaciones presentes entre si.
Durante la etapa de diseño, el modelo de diseño determina las futuras componentes de software (clases) y sus relaciones entre si.

El modelo de dominio: es una representación de las cosas, entidades, idea, clases conceptuales u objetos del “mundo real” o dominio de interés, no de componentes de software.
Muestra clases conceptuales significativas en un dominio del problema; se usa como base para el diseño de los objetos de software.
Es el artefacto mas importante del análisis; podría ser considerado como un diccionario visual de abstracciones de clases conceptuales, vocabulario e información del dominio.
Su intención es ser útil como herramienta de comunicación.
Otros nombres: modelo conceptual, modelo de objetos de dominio y modelo de los objetos de análisis
Usando UML, el MD se representa con un conjunto de diagramas de clases, se puede mostrar objetos de domino o clases conceptuales, asociaciones entre clases conceptuales y atributos de las clases conceptuales.
No se define ninguna operación. La asignación de responsabilidades de los objetos no forma parte de este modelo

El modelo de diseño: a diferencia del de dominio, se encuentra mas cerca de la solución buscada.
Refleja decisiones en cuanto a la asignación de responsabilidades entre los objetos (Si tiene operaciones)
Toma como base el modelo de dominio, donde algunas entidades se promoverán a clases.
Muestran como se relacionan componentes de software para resolver el problema planteado; es el paso previo a la implementación.
Es posible aplicar patterns según el tipo de problema.

MODIFICADORES: Los atributos y métodos estáticos se subrayan, así: