El Diagrama de Despliegue es un tipo de diagrama del Lenguaje Unificado de Modelado que se utiliza para modelar el hardware utilizado en las

implementaciones de sistemas y las relaciones entre sus componentes. Los elementos usados por este tipo de diagrama son nodos (representados como un prisma), componentes (representados como una caja rectangular con dos protuberancias del lado izquierdo) y asociaciones. En el UML 2.0 los componentes ya no estn dentro de nodos. En cambio, puede haber artefactos u otros nodos dentro de un nodo. Este tipo de diagrama debemos tambin aadir que no van a existir actores para relacionarse con los nodos (no es un diagrama de casos de uso) si no que las relaciones que pueda haber siempre seran entre los nodos y por ejemplo con una base de datos. Un artefacto puede ser algo como un archivo, un programa, una biblioteca, o una base de datos construida o modificada en un proyecto. Estos artefactos implementan colecciones de componentes. Los nodos internos indican ambientes, un concepto ms amplio que el hardware propiamente dicho, ya que un ambiente puede incluir al lenguaje de programacin, a un sistema operativo, un ordenador o un cluster de terminales. La mayora de las veces el modelado de la vista de despliegue implica modelar la topologa del hardware sobre el que se ejecuta el sistema. Aunque UML no es un lenguaje de especificacin hardware de propsito general, se ha diseado para modelar muchos de los aspectos hardware de un sistema a un nivel suficiente para que un ingeniero software pueda especificar la plataforma sobre la que se ejecuta el software del sistema. Usos Algunos de los usos que se les da a los diagramas de despliegue son para modelar: Sistemas empotrados: Un sistema empotrado es una coleccin de hardware con una gran cantidad de software que interacta con el mundo fsico. Sistemas cliente-servidor: Los sistemas cliente-servidor son un extremo del espectro de los sistemas distribuidos y requieren tomar decisiones sobre la conectividad de red de los clientes a los servidores y sobre la distribucin fsica de los componentes software del sistema a travs de nodos.

Sistemas completamente distribuidos: En el otro extremo encontramos aquellos sistemas que son ampliamente o totalmente distribuidos y que normalmente incluyen varios niveles de servidores. Tales sistemas contienen a menudo varias versiones de componentes software, alguno de los cuales pueden incluso migrar de un nodo a otro. El diseo de tales sistemas requiere tomar decisiones que permitan un cambio continuo de la topologa del sistema.

Un diagrama de clases es un tipo de diagrama esttico que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de clases son utilizados durante el proceso de anlisis y diseo de los sistemas, donde se crea el diseo conceptual de la informacin que se manejar en el sistema, y los componentes que se encargaran del funcionamiento y la relacin entre uno y otro. Representacin de: - Requerimientos en entidades y actuaciones. - La arquitectura conceptual de un dominio - Soluciones de diseo en una arquitectura - Componentes de software orientados a objetos

Propiedades tambin llamados atributos o caractersticas, son valores que corresponden a un objeto, como color, material, cantidad, ubicacin. Generalmente se conoce como la informacin detallada del objeto. Suponiendo que el objeto es una puerta, sus propiedades seran: la marca, tamao, color y peso.

Operaciones comnmente llamados mtodos, son aquellas actividades o verbos que se pueden realizar con/para este objeto, como por ejemplo abrir, cerrar, buscar, cancelar, acreditar, cargar. De la misma manera que el nombre de un atributo, el nombre de una operacin se escribe con minsculas si consta de una sola palabra. Si el nombre contiene ms de una palabra, cada palabra ser unida a la anterior y comenzar con una letra mayscula, a excepcin de la primera palabra que comenzar en minscula. Por ejemplo: abrirPuerta, cerrarPuerta, buscarPuerta, etc.

Interfaz es un conjunto de operaciones que permiten a un objeto comportarse de cierta manera, por lo que define los requerimientos mnimos del objeto. Hace referencia a polimorfismo.

Herencia se define como la reutilizacin de un objeto padre ya definido para poder extender la funcionalidad en un objeto hijo. Los objetos hijos heredan todas las operaciones y/o propiedades de un objeto padre. Por ejemplo: Una persona puede especializarse en Proveedores, Acreedores, Clientes, Accionistas, Empleados; todos comparten datos bsicos como una persona,

pero adems cada uno tendr informacin adicional que depende del tipo de persona, como saldo del cliente, total de inversin del accionista, salario del empleado, etc. El diagrama de secuencia es un tipo de diagrama usado para modelar interaccin entre objetos en un sistema segn UML. En ingls se pueden encontrar como "sequence diagram", "event-trace diagrams", "event scenarios" o "timing diagrams Un diagrama de secuencia muestra la interaccin de un conjunto de objetos en una aplicacin a travs del tiempo y se modela para cada caso de uso. Mientras que eldiagrama de casos de uso permite el modelado de una vista business del escenario, el diagrama de secuencia contiene detalles de implementacin del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes intercambiados entre los objetos. Tpicamente se examina la descripcin de un caso de uso para determinar qu objetos son necesarios para la implementacin del escenario. Si se dispone de la descripcin de cada caso de uso como una secuencia de varios pasos, entonces se puede "caminar sobre" esos pasos para descubrir qu objetos son necesarios para que se puedan seguir los pasos. Un diagrama de secuencia muestra los objetos que intervienen en el escenario con lneas discontinuas verticales, y los mensajes pasados entre los objetos como flechas horizontales. Pueden ser usados en dos formas: De instancia: describe un escenario especfico (un escenario es una instancia de la ejecucin de un caso de uso). Genrico: describe la interaccin para un caso de uso; Utiliza ramificaciones ("Branches"), condiciones y bucles.

diagrama de casos de uso es una especie de diagrama de comportamiento. UML mejorado El Lenguaje de Modelado Unificado define una notacin grfica para representar casos de uso llamada modelo de casos de uso. UML no define estndares para que el formato escrito describa los casos de uso, y as mucha gente no entiende que esta notacin grfica define la naturaleza de un caso de uso; sin embargo una notacin grfica puede solo dar una vista general simple de un caso de uso o un conjunto de casos de uso. Los diagramas de casos de uso son a menudo confundidos con los casos de uso. Mientras los dos conceptos estn relacionados, los casos de uso son mucho ms detallados que los diagramas de casos de uso.

Diagramas de Casos de Uso UML La descripcin escrita del comportamiento del sistema al afrontar una tarea de negocio o un requisito de negocio. Esta descripcin se enfoca en el valor suministrado por el sistema a entidades externas tales como usuarios humanos u otros sistemas.

La posicin o contexto del caso de uso entre otros casos de uso. Dado que es un mecanismo de organizacin, un conjunto de casos de uso coherentes y consistentes promueven una imagen fcil de comprender del comportamiento del sistema, un entendimiento comn entre el cliente/propietario/usuario y el equipo de desarrollo.

Es prctica comn crear especificaciones suplementarias para capturar detalles de requisitos que caen fuera del mbito de las descripciones de los casos de uso. Ejemplos de esos temas incluyen restricciones de diseo como: rendimiento, temas de escalabilidad/gestin, o cumplimiento de estndares. El diagrama de la derecha describe la funcionalidad de un Sistema Restaurante muy simple. Los casos de uso estn representados por elipses y los actores estn, por ejemplo, los casos de uso se muestran como parte del sistema que est siendo modelado, los actores no. Relaciones de Casos de Uso Las tres relaciones principales entre los casos de uso son soportadas por el estndar UML, el cual describe notacin grfica para esas relaciones. Veamos una revisin de ellas a continuacin: ]Inclusin (include o use) Es una forma de interaccin o creacin, un caso de uso dado puede "incluir" otro caso de uso. El primer caso de uso a menudo depende del resultado del caso de uso incluido. Esto es til para extraer comportamientos verdaderamente comunes desde mltiples casos de uso a una descripcin individual, desde el caso de uso. El estndar de Lenguaje de Modelado Unificado de OMG define una notacin grfica para realizar diagramas de casos de uso, pero no el formato para describir casos de uso. Mucha gente sufre la equivocacin pensando que un caso de uso es una notacin grfica (o es su descripcin). Mientras la notacin grfica y las descripciones esto no sirve.. Extensin (Extend) Es otra forma de interaccin, un caso de uso dado (la extensin) puede extender a otro. Esta relacin indica que el comportamiento del caso de la extensin se utiliza en casos de uso, un caso de uso a otro caso siempre debe tener extensin o inclusin. El caso de uso extensin puede ser insertado en el caso de uso extendido bajo ciertas condiciones. La notacin, es una flecha de punta abierta con lnea discontinua, desde el caso de uso extensin al caso de uso extendido,

con la etiqueta extend. Esto puede ser til para lidiar con casos especiales, o para acomodar nuevos requisitos durante el mantenimiento del sistema y su extensin . "La extensin, es el conjunto de objetos a los que se aplica un concepto. Los objetos de la extensin son los ejemplos o instancias de los conceptos." Generalizacin "Entonces la Generalizacin es la actividad de identificar elementos en comn entre conceptos y definir las relaciones de una superclase (concepto general) y subclase (concepto especializado). Es una manera de construir clasificaciones taxonmicas entre conceptos que entonces se representan en jerarquas de clases. Las subclases conceptuales son conformes con las superclases conceptuales en cuanto a la intencin y extensin." En la tercera forma de relaciones entre casos de uso, existe una relacin generalizacin/especializacin. Un caso de uso dado puede estar en una forma especializada de un caso de uso existente. La notacin es una lnea slida terminada en un tringulo dibujado desde el caso de uso especializado al caso de uso general. Esto se asemeja al concepto orientado a objetos de sub-clases, en la prctica puede ser til factorizar comportamientos comunes, restricciones al caso de uso general, describirlos una vez, y enfrentarse a los detalles excepcionales en los casos de uso especializados.

Ingeniera de software es la aplicacin de un enfoque sistemtico, disciplinado y cuantificable al desarrollo, operacin y mantenimiento de software, y el estudio de estos enfoques, es decir, la aplicacin de la ingeniera al software.1 Es la aplicacin de la ingeniera al software, ya que integra matemticas, ciencias de la computacin y prcticas cuyos orgenes se encuentran en la ingeniera.2 Se pueden citar otras definiciones enunciadas por prestigiosos autores: Ingeniera de software es el estudio de los principios y metodologas para el desarrollo y mantenimiento de sistemas software (Zelkovitz, 1978) Ingeniera de software es la aplicacin prctica del conocimiento cientfico al diseo y construccin de programas de computadora y a la documentacin asociada requerida para desarrollar, operar y mantenerlos. Se conoce tambin como desarrollo de software o produccin de software (Bohem, 1976). Ingeniera de software trata del establecimiento de los principios y mtodos de la ingeniera a fin de obtener software de modo rentable, que sea fiable y trabaje en mquinas reales (Bauer, 1972).

En el 2004, en los Estados Unidos, la Oficina de Estadsticas del Trabajo (U. S. Bureau of Labor Statistics) cont 760.840 ingenieros de software de computadora.3 El trmino "ingeniero de software", sin embargo, se utiliza en forma

genrica en el ambiente empresarial, y no todos los ingenieros de software poseen realmente ttulos de ingeniera de universidades reconocidas. Algunos autores consideran que "desarrollo de software" es un trmino ms apropiado que "ingeniera de software" para el proceso de crear software. Personas como Pete McBreen (autor de "Software Craftmanship") cree que el trmino IS implica niveles de rigor y prueba de procesos que no son apropiados para todo tipo de desarrollo de software. Indistintamente se utilizan los trminos "ingeniera de software" o "ingeniera del software". En Hispanoamrica el trmino usado normalmente es el primero de ellos. La creacin del software es un proceso intrnsecamente creativo y la ingeniera del software trata de sistematizar este proceso con el fin de acotar el riesgo del fracaso en la consecucin del objetivo creativo por medio de diversas tcnicas que se han demostrado adecuadas en base a la experiencia previa. La IS se puede considerar como la ingeniera aplicada al software, esto es, por medios sistematizados y con herramientas preestablecidas, la aplicacin de ellos de la forma ms eficiente para la obtencin de resultados ptimos; objetivos que siempre busca la ingeniera. No es slo de la resolucin de problemas, sino ms bien teniendo en cuenta las diferentes soluciones, elegir la ms apropiada. Arquitectura La integracin de infraestructura, desarrollo de aplicaciones, bases de datos y herramientas gerenciales, requieren de capacidad y liderazgo para poder ser conceptualizados y proyectados a futuro, solucionando los problemas de hoy. El rol en el cual se delegan todas estas actividades es el del Arquitecto. El arquitecto de software es la persona que aade valor a los procesos de negocios gracias a su valioso aporte de soluciones tecnolgicas. La arquitectura de sistemas en general, es una actividad de planeacin, ya sea a nivel de infraestructura de red y hardware, o de software. La arquitectura de software consiste en el diseo de componentes de una aplicacin (entidades del negocio), generalmente utilizando patrones de arquitectura. El diseo arquitectnico debe permitir visualizar la interaccin entre las entidades del negocio y adems poder ser validado, por ejemplo por medio de diagramas de secuencia. Un diseo arquitectnico describe en general el cmo se construir una aplicacin de software. Para ello se documenta utilizando diagramas, por ejemplo:

Diagramas de clases Diagramas de base de datos Diagrama de despliegue Diagrama de secuencia