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.

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.

caso de uso

Casos de Uso (Use Case)

El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el sistema en desarrollo, además de la forma, tipo y orden en como los elementos interactuan (operaciones o casos de uso).

Un diagrama de casos de uso consta de los siguientes elementos:

• actor 
• caso de uso
• relaciones de uso, herencia y comunicación.

Elementos

• Actor:
  
  
  Una definición previa, es que un Actor es un rol que un usuario juega con respecto al sistema. Es importante destacar el uso de la palabra rol, pues con esto se especifica que un Actor no necesariamente representa a una persona en particular, sino más bien la labor que realiza frente al sistema.
  Como ejemplo a la definición anterior, tenemos el caso de un sistema de ventas en que el rol de Vendedor con respecto al sistema puede ser realizado por un Vendedor o bien por el Jefe de Local.
• Caso de Uso:
  
  
  Es una operación/tarea específica que se realiza tras una orden de algún agente externo, sea desde una petición de un actor o bien desde la invocación desde otro caso de uso.
• Relaciones:
  
  • Asociación 
    Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple.
  • Dependencia o Instanciación 
    Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha relación se denota con una flecha punteada.
  • Generalización 
    Este tipo de relación es uno de los más utilizados, cumple una doble función dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o deHerencia (<<extends>>).
    Este tipo de relación esta orientado exclusivamente para casos de uso (y no para actores).
    extends: Se recomienda utilizar cuando un caso de uso es similar a otro (características).
    uses: Se recomienda utilizar cuando se tiene un conjunto de características que
    son similares en más de un caso de uso y no se desea mantener copiada la descripción de la característica.
    
    De lo anterior cabe mencionar que tiene el mismo paradigma en diseño y modelamiento de clases, en donde esta la duda clásica de usar o heredar.

NOTA: Los Casos de Uso no son parte del diseño (cómo), sino parte del análisis (qué). De forma que al ser parte del análisis nos ayudan a describir qué es lo que es sistema debe hacer. Los Casos de Uso son qué hace el sistema desde el punto de vista del usuario. Es decir, describen un uso del sistema y cómo este interactúa con el usuario.