martes, 4 de junio de 2013

Arquitectura cliente - servidor 

La arquitectura cliente-servidor es un modelo de aplicación distribuida en el que las tareas se reparten entre los proveedores de recursos o servicios, llamados servidores, y los demandantes, llamados clientes.

Un cliente realiza peticiones a otro programa, el servidor, que le da respuesta. Esta idea también se puede aplicar a programas que se ejecutan sobre una sola computadora, aunque es más ventajosa en un sistema operativo multiusuario distribuido a través de una red de computadoras.

En esta arquitectura la capacidad de proceso está repartida entre los clientes y los servidores, aunque son más importantes las ventajas de tipo organizativo debidas a la centralización de la gestión de la información y la separación de responsabilidades, lo que facilita y clarifica el diseño del sistema.
La separación entre cliente y servidor es una separación de tipo lógico, donde el servidor no se ejecuta necesariamente sobre una sola máquina ni es necesariamente un sólo programa. Los tipos específicos de servidores incluyen los servidores web, los servidores de archivo, los servidores del correo, etc. Mientras que sus propósitos varían de unos servicios a otros, la arquitectura básica seguirá siendo la misma.

Una disposición muy común son los sistemas multicapa en los que el servidor se descompone en diferentes programas que pueden ser ejecutados por diferentes computadoras aumentando así el grado de distribución del sistema.

Arquitectura de software



El concepto de arquitectura de software se refiere a la estructuración del sistema que, idealmente, se crea en etapas tempranas del desarrollo. Esta estructuración representa un diseño de alto nivel del sistema que tiene dos propósitos primarios: satisfacer los atributos de calidad (desempeño, seguridad, modificabilidad), y servir como guía en el desarrollo.

Los atributos de calidad son parte de los requerimientos (no funcionales) del sistema y son características que deben expresarse de forma cuantitativa. No tiene sentido, por ejemplo, decir que el sistema debe devolver una petición “de manera rápida”, o presentar una página “ligera”, ya que no es posible evaluar objetivamente si el sistema cubre o no esos requerimientos.

La arquitectura de software es de especial importancia ya que la manera en que se estructura un sistema tiene un impacto directo sobre la capacidad de este para satisfacer lo que se conoce como los atributos de calidad del sistema. Ejemplos de atributos de calidad son el desempeño, que tiene que ver con el tiempo de respuesta del sistema a las peticiones que se le hacen, la usabilidad, que tiene que ver con qué tan sencillo les resulta a los usuarios realizar operaciones con el sistema, o bien la modificabilidad, que tiene que ver con qué tan simple resulta introducir cambios en el sistema.
Diagrama de clases

Un diagrama de clases es un tipo de diagrama estático que describe la estatura de un sistema mostrando sus clases y atributos y las relaciones entre ellos. Los diagramas de clases son utilizados durante el proceso de análisis y diseño de los sistemas, donde se crea el diseño conceptual de la información que se manejara que el sistema, y los elementos se encargaran del funcionamiento y la relación entre uno y otro.
Un diagrama de clases esta compuesto por los siguientes elementos:

Clases: atributos, métodos, visibilidad.
Relaciones: herencia, composición, agregación, asociación  y uso

Atributos:
Los atributos y características  de una clase pueden ser de tres tipos,  los que definen el grado de comunicación y visibilidad de ellos con el entorno, estas son:

Public: indica que el atributo será visible tanto dentro  como fuera de la clase, es decir, que es accesible desde todos lados.

Private: indica que el atributo solo será accesible desde dentro de la clase  (solo sus métodos pueden accesar).

Protected: indica que el atributo no será accesible desde  fuera de la clase, pero si podrá ser accesado por métodos de la clase además de las subclases que se deriven(herencia).

Relaciones entre las clases:
Bueno ya definido el concepto de clase,  es necesario explicar  como se pueden interrelacionar dos o mas clases (cada uno con características y objetivos diferentes).
Antes es necesario el concepto de cardinalidad de las relaciones: En UML la cardinalidad de las relaciones indica el grado y el nivel  de dependencia se anotan en cada extremo de la relación y  estas pueden ser: 

Uno a muchos: 1..*(n..1).
 0 o muchos:0..(0..n).
Numero fijo: m (m denota el numero). 

Agregación: Para modelar objetos completos, no bastan los tipos de datos básicos que proveen de lenguajes: enteros, reales y secuencia de caracteres. Cuando se requiere componer objetos que son instancias de clases definidas por el desarrollador de la aplicación tenemos do posibilidade.

Por valor: es un tipo de relación estática, en donde el tiempo  de vida del objeto esta condicionado por  el  tiempo de vida del que lo incluye. este tipo de relación es comúnmente  llamada  composición  (el objeto base se construye a partir de objeto incluido, es decir, “parte/todo”).

 Por referencia: es un tipo de relación dinámica, en donde el tiempo de vida del objeto es independiente del que lo incluye.

Agregación: (el objeto base  utiliza al incluido por funcionamiento).

lunes, 13 de mayo de 2013

DIAGRAMA DE SECUENCIA


El Diagrama de Secuencia es uno de los diagramas más efectivos para modelar interacción entre objetos en un sistema. Un diagrama de secuencia se modela para cada caso de uso. Mientras que el diagrama de

caso de uso permite el modelado de una vista ’business’ del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar
el escenario, y mensajes pasados entre los objetos.

Típicamente uno examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si tienes modelada la descripción de cada caso de uso como una Un estudio a fondo de UML secuencia de varios pasos, entonces puedes "caminar sobre" esos pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos.

domingo, 28 de abril de 2013

CERTIFICADO MICROSOFT


¿Qué son las certificaciones oficiales de Microsoft?

Consisten en exámenes exigentes orientados a las necesidades reales de los diversos puestos de trabajo que te certifican de forma oficial para casi cualquier área de especialización TI dentro de las tecnologías Microsoft, tanto para desarrolladores como para profesionales de sistemas. Toda la información sobre las certificaciones de desarrollo en nuestra página específica de certificación.


¿Cuáles son los exámenes que tengo que aprobar para conseguir una certificación?
Cada especialidad exige el aprobado de unos exámenes concretos. En esta página puedes ver toda la información sobre los exámenes que tienes que aprobar si quieres ser MCTS y MCPD en el área de desarrollo.


¿Qué es un MCTS?
MCTS es el acrónimo de Microsoft Certified Technology Specialist. Puedes ser MCTS en cualquiera de estas áreas:

Windows Applications (examen 70-511)
Service Communication Applications (examen 70-513)
Web Applications (examen 70-515)
Data Access (examen 70-516)
Silverlight (examen 70-506)


¿Qué es un MCPD?
MCPD es el acrónimo de Microsoft Certified Professional Developer. Puedes ser MCPD en cualquiera de estas áreas:

Windows Developer (examen 70-518)
Web Developer (examen 70-519)
Windows Azure Platform (examen 70-583)
Para ser MCPD primero has de aprobar los exámenes que te certifiquen como MCTS y luego aprobar los propios para ser Professional Developer.



sábado, 13 de abril de 2013

Diagrama de Casos de Uso

Otras de las formas mas rapida y sencilla de aprender algo es viendo por videos, por si aun no entienden muy bien el tema dejo dos vídeos en donde explican los diagramas de casos de uso utilizando el programa Rational Software. otro video de ayuda para compartir :)

Herramientas UML


El lenguaje Unificado de Modelado, son un conjunto de herramientas gráficas que permiten: visualizar, especificar, construir y documentar un sistema de información. UML ofrece un estándar para el modelado de un sistema con tres características fundamentales:

- Es gráfico, todas las herramientas tienen su propia representación gráfica, con sus propias reglas de uso, lo que estandariza el lenguaje de representación e interpretación, tanto para los usuarios como para el equipo de desarrollo, y algo muy fundamental - evita la ambiguedad del lenguaje natural.

- Es particionable, UML aborda el problema en fases o etapas y para cada una dispone de las herramientas adecuadas. Permite modelar el sistema desde varias perspectivas, por componentes o subsistemas, simplificando la complejidad de un proyecto en unidades más fáciles de gestionar.

- De lo general a lo específico, es decir nos permite ver el proyecto desde una concepción global y general, y gradualmente adentrarnos en los detalles del proyecto, sin perder el control de la correspondencia de un modelo con otro.

De las herramientas más usuales que hacen a UML, tenemos:

a. Diagrama de Casos de Uso
b. Diagrama de Clases
c. Diagrama de Secuencia
d. Diagrama de Colaboración
e. Diagrama de Estados
f. Diagrama de Actividades
g. Diagrama de Implementación
h. Diagrama de Componentes

Algo que es importante señalar, UML no es una metodología de análisis y diseño de sistemas de información, son un conjunto de herramientas que ayudan al modelado de sistemas.

Para las personas que le llaman mucho la atención aprender como hacer diagramas de clases, pongo un vídeo donde explica como hacerlo.