UNIDAD II:INTRODUCCIN AL UML

a)Presentacin y contextualizacin

Los modelos sistmicos son diseos que nos permiten crear de manera general los comportamientos o sucesos que rodean al hombre. Importantes porque sirven para transmitir la relacin que tienen los usuarios con su entorno o todo aquello que lo rodea , el estudiante puede crear elementos o diseos que le permitan plasmarbajo un anlisis preliminar y bajo el uso correcto de la notacin UML a estos comportamientos yrepresentarlos correctamente.

b)Competencia

Aplica, crea elementos y diagramas validos en el diseo de un modelo sistmico.

c)Capacidades

1.Identifica y diferencia los elementos de modelos o diagramas existentes en UML.2.Conoce las representaciones graficas de los elementos encontrados.3.Identifica y diferencia a los diagramas UML.4.Disea modelos a travs de los diagramas de UML como componentes del desarrollo de un proyecto de software.

d)Actitudes

Valora el uso de los modelos como medio de desarrollo y solucin analtica.Cumple con puntualidad la entrega de sus trabajos.Presente responsabilidad con la presentacin de sus actividades.

e)Presentacin de Ideas bsicas y contenidos esenciales de la Unidad:

La Unidad de Aprendizaje 02: Introduccin al UML,comprende el desarrollo de los siguientes temas:

TEMA 01:Lenguaje de Modelado Unificado.TEMA 02:Modelado de Objetos (Meta Modelos) y reglas UML.TEMA 03:Ciclo de Vida de un Proceso Unificado.TEMA 04:Diagramas y Elementos de UML.

UNIDAD II:INTRODUCCIN AL UML

Tema 01: Lenguaje de Modelado Unificado

El Lenguaje Unificado de Modelado prescribe un conjuntode notaciones y diagramas estndar para modelar sistemas orientados a objetos, y describe la semntica esencial de lo que estos diagramas y smbolos significan. Mientras que ha habido muchas notaciones y mtodos usados para el diseo orientado a objetos, ahora los modeladores slo tienen que aprender una nica notacin.

UML se puede usar para modelar distintos tipos de sistemas: sistemas de software, sistemas de hardware, y organizaciones del mundo real. UML ofrece nueve diagramas en los cuales modelar sistemas.

Diagramas de Casos de Uso para modelar los procesos business.Diagramas de Secuencia para modelar el paso de mensajes entre objetos.Diagramas de Colaboracin para modelar interacciones entre objetos.Diagramas de Estado para modelar el comportamiento de los objetos en el sistema.Diagramas de Actividad para modelar el comportamiento de los Casos de Uso, objetos u operaciones.Diagramas de Clases para modelar la estructura esttica de las clases en el sistema.Diagramas de Objetos para modelar la estructura esttica de los objetos en el sistema.Diagramas de Componentes para modelar componentes.Diagramas de Implementacin para modelar la distribucin del sistema.

UML es una consolidacin de muchas de las notaciones y conceptos ms usados orientados a objetos. Empez como una consolidacin del trabajo de Grade Booch, James Rumbaugh, e Ivar Jacobson, creadores de tres de las metodologas orientadas a objetos ms populares.

En 1996, el Object Management Group (OMG), un pilar estndar para la comunidad del diseo orientado a objetos, public una peticin con propsito de un metamodelo orientado a objetos de semntica y notacin estndares. UML, en su versin 1.0, fue propuesto como una respuesta a esta peticin en enero de 1997. Hubo otras cinco propuestas rivales.

Durante el transcurso de 1997, los seis promotores de las propuestas, unieron su trabajo y presentaron alOMGun documento revisado de UML, llamado UML versin 1.1. Este documento fue aprobado por elOMGen Noviembre de 1997. El OMG llama a este documento OMG UML versin 1.1. El OMG est actualmente en proceso de mejorar una edicin tcnica de esta especificacin, prevista su finalizacin para el 1 de abril de 1999.

UML es ante todo unlenguaje. Unlenguaje proporciona un vocabulario y unas reglasparapermitir una comunicacin. En este caso, este lenguaje se centra en la representacin grfica de un sistema. Este lenguaje nos indica cmo crear y leer los modelos, pero no dicecmo crearlos. Esto ltimo es el objetivo de las metodologas de desarrollo.

Los objetivos de UML son muchos, pero se pueden sintetizar sus funciones:

Visualizar:UML permite expresar de una formagrfica un sistema de forma que otro lo puede entender.Especificar:UML permite especificarcules son las caractersticas de un sistema antes de su construccin.

UNIDAD II:INTRODUCCIN AL UML

Tema 02: Modelado de Objetos (Meta Modelos) y Reglas UML

MODELO CONCEPTUALSe trata de obtener el esquema conceptual de la base de datos a partir de la listadescriptiva de objetos y asociaciones identificadas enla organizacin durante el anlisis

MODELO DE OBJETOSSe basa en un conjunto de conceptos que definen que es Orientacin a Objetos y una notacin grficaindependiente. El Modelado y Diseo Orientado a Objetos se fundamentaen pensar acerca deproblemas a resolver empleando modelos que se han organizado tomando como base conceptos del mundo real.

En la especificacin del UML podemos comprobar que una de las partes que lo componen es un Meta modelo formal. Un meta model es un modelo que define el lenguaje para expresar otros modelos. Un modelo en OO es una abstraccin cerrada semnticamente de un sistema y un sistema es una coleccin de unidades conectadas que son organizadas para realizar un propsito especfico. Un sistema puede ser descrito por uno o ms modelos, posiblemente desde distintos puntos de vista.

Una parte del UML define, entonces, una abstraccin con significado de un lenguaje para expresar otros modelos (es decir, otras abstracciones de un sistema, o conjunto de unidades conectadas que se organizan para conseguir un propsito). Lo que en principio puede parecer complicado no lo es tanto si pensamos que uno de los objetivos del UML es llegar a convertirse en una manera de definir modelos, no slo establecer una forma de modelo, de esta forma simplemente estamos diciendo que UML, adems, define un lenguaje con el que podemos abstraer cualquier tipo de modelo.

El UML es una tcnica de modelado de objetos y como talsupone una abstraccin de un sistema para llegar a construirlo en trminos concretos. El modelado no es ms que la construccin de un modelo a partir de una especificacin.Un modelo es una abstraccin de algo, que se elabora para comprender ese algo antes de construirlo. El modelo omite detalles que no resultan esenciales para la comprensin del original y por lo tanto facilita dicha comprensin.

Los modelos se utilizan en muchas actividades de la vida humana: antes de construir una casa el arquitecto utiliza un plano, los msicos representan la msica en forma de notas musicales, los artistas pintan sobre el lienzo con carboncillos antes de empezar a utilizar los leos, etc. Unos y otros abstraen una realidad compleja sobre unos bocetos, modelos al fin y al cabo. La OMT, por ejemplo, intenta abstraer la realidad utilizando tres clases de modelosOO: el modelo de objetos, que describe la estructura esttica; el modelo dinmico, con el que describe las relaciones temporales entre objetos; y el modelo funcional que describe las relaciones funcionales entre valores. Mediante estas tres fases de construccin de modelos, se consigue una abstraccin de la realidad que tiene en s misma informacin sobre las principales caractersticas de sta.

Los modelos adems, al no ser una representacin que incluya todos los detalles de los originales, permiten probar ms fcilmente los sistemas que modelan y determinar los errores. Segn se indica en la Metodologa OMT (Rumbaugh), los modelos permiten una mejor comunicacin con el cliente por distintas razones:

Es posible ensear al cliente una posible aproximacin de lo queser el producto final.Proporcionan una primera aproximacin al problema que permite visualizar cmo quedar el resultado.Reducen la complejidad del original en subconjuntos que son fcilmente tratables por separado.

Se consigue un modelo completo de la realidad cuando el modelo captura los aspectos importantes del problema y omite el resto. Los lenguajes de programacin que estamos acostumbrados a utilizar no son adecuados para realizar modelos completos de sistemas reales porque necesitan una especificacin total con detalles que no son importantes para el algoritmo que estn implementando. En OMT se modela un sistema desde tres puntos de vista diferentes donde cada uno representa una parte del sistema y una unin lo describe de forma completa. En esta tcnica de modelado se utiliz una aproximacin al proceso de implementacin de software habitual donde se utilizan estructuras de datos (modelo de objetos), las operaciones que se realizan con ellos tienen una secuencia en el tiempo (modelo dinmico) y se realiza una transformacin sobre sus valores (modelo funcional).

UML utiliza parte de este planteamiento obteniendo distintos puntos de vista de la realidad que modela mediante los distintos tipos de diagramas que posee. Con la creacin del UML se persigue obtener un lenguaje que sea capaz de abstraer cualquier tipo de sistema, sea informtico o no, mediante los diagramas, es decir, mediante representaciones grficas que contienen toda la informacin relevante del sistema. Un diagrama es una representacin grfica de una coleccin de elementos del modelo, que habitualmente toma forma de grafo donde los arcos que conectan sus vrtices son las relaciones entre los objetos y los vrtices se corresponden con los elementos del modelo. Los distintos puntos de vista de un sistema real que se quieren representar para obtener el modelo se dibuja d forma que se resaltan los detalles necesarios para entender el sistema.

REGLAS UMLSon Reglas Sintcticas y Semnticas:Nombres:cmo llamar a los elementos, relaciones y diagramas.Alcance:el contexto que da un significado especfico a un nombre.Visibilidad:cmo se pueden ver y utilizar esos nombres por otros.Integridad:cmo se relacionan apropiada y consistentemente unos elementos con otros.Ejecucin:qu significa ejecutar simular un modelo dinmico.

Los modelos construidos durante el desarrollo de un sistema con gran cantidad de software tiende a evolucionar por lo que adems de modelos bien formados hay otros que pueden ser:Abreviados.Incompletos.Inconsistentes.

Su solucin es considerar las cuestiones ms importantes de anlisis, diseo e implementacin.Mecanismos comunes en UMLSe aplican en forma consistente a travs de todo el lenguaje.1.Especificaciones.2.Adornos.3.Divisiones comunes.4.Mecanismos de extensibilidad.

Especificaciones:detrs de un icono de clase hay una especificacin que proporciona el conjunto completo de atributos, operaciones y comportamiento que incluye la clase. La notacin grfica de UML se utiliza para visualizar un sistema, la especificacin de UML se utiliza para expresar los detalles del sistema. Proporcionar una base semntica que incluye a todos los modelos de un sistema y cada parte est relacionado con las otras de manera consistente.

Adornos:se pueden incluir detalles como abstraccin, visibilidad de sus atributos y operaciones.

Divisiones Comunes

Divisin Entre Clase y Objeto: una clase es una abstraccin, un objeto es una manifestacin concreta de esa abstraccin.Ejemplo. La clase cliente y el Objeto nombre, Direccin y Telfono.Divisin Entre Interfaz e Implementacin: una interfaz declara un contrato representa el medio y una implementacin representa una realizacin concreta o resultado.Nota. Unknow: desconocidoDivisin Entre Tipo y Rol: el tipo declara la clase de una entidad como un objeto, un atributo, un parmetro. Un rol describe el significado de una entidad o clase en un contexto, como una clase, un componente una colaboracin.Rol seria Cliente con la clase o entidad PersonaTipo: solicita Ticket pedido

DiferenciandoEl termino entidad corresponde al modelo Conceptual del modelo Entidad / RelacinEl termino Clase corresponde al modelo Lgico de UMLAmbos tienen mucho en relacin o comn

MECANISMOS DE EXTENSIBILIDAD1.Estereotipos.2.Valores etiquetados.3.Restricciones.Estereotipo: extiende el vocabulario UML.Valor Etiquetado: extiende las propiedades de un estereotipo permitiendo aadir nueva informacin en la especificacin de ese estereotipo.Restriccin: extiende la semntica de un bloque de construccin.

UNIDAD II:INTRODUCCIN AL UML

Tema 03: Ciclo de Vida de un Proceso Unificado

EL PROCESO UNIFICADOEs un proceso de desarrollo de software configurable que se adapta a travs de los proyectos variados en tamaos y complejidad. Se basa en muchos aos de experiencia en el uso de la tecnologa orientada a objetos en el desarrollo de software de misin crtica en una variedad de industrias por la compaa Rational, donde confluyen los tres amigos como se llaman a s mismos o los tres grandes OO(Orientados a objetos) : Grady Booch, James Rumbaugh e Ivar Jacobson.

El Proceso Unificado gua a los equipos de proyecto en cmo administrar el desarrollo iterativo (repetitivo) de un modo controlado mientras se balancean los requerimientos del negocio, el tiempo al mercado y los riesgos del proyecto. El proceso describe los diversos pasos involucrados en la captura de los requerimientos y en el establecimiento de una gua arquitectnica lo ms pronto, para disear y probar el sistema hecho de acuerdo a los requerimientos y a la arquitectura. El proceso describe qu entregables producir, cmo desarrollarlos y tambin provee patrones. El proceso unificado es soportado por herramientas que automatizan entre otras cosas, el modelado visual, la administracin de cambios y las pruebas.

Proceso Unificado y MSF; Complementos TecnolgicosSegn [M&R 1998], ms que una metodologa, Microsoft Solutions Framework (MSF) es una serie de modelos flexibles interrelacionados que guan a una organizacin sobre como ensamblar los recursos, el personal y las tcnicas necesaria para asegurar que su infraestructura tecnolgica y sus soluciones cumplan los objetivos de negocio. MSF mantiene una relacin clara entre los objetivos de negocio y las implementaciones tecnolgicas.

MSF se puede utilizar por s mismo o con otras herramientas y tcnicas como el Proceso Rational [Proceso Unificado] para planear, construir y administrar el desarrollo de soluciones de negocio a la medida [M&R 1998]. El proceso Unificado es un proceso de desarrollo de software configurable que se adapta a proyectos que varan en tamao y complejidad. Se basa en muchos aos de experiencia en el uso de la tecnologa de objetos en el desarrollo de software de misin crtica en una variedad de industrias. Uno de los componentes clave es el UML [M&R 1998].

MSF proporciona las tcnicas ligadas a la tecnologa y el Proceso Unificado la gua detallada para el desarrollo de software minimizando los riesgos.El Proceso Unificado ha adoptado un enfoque que se caracteriza por:1)Interaccin con el usuario contina desde un inicio.2)Mitigacin de riesgos antes de que ocurran.3)Liberaciones frecuentes.4)Aseguramiento de la calidad.5)Involucramiento del equipo en todas las decisiones del proyecto.6)Anticiparse al cambio de requerimientos.

El Proceso Unificado y MSF se enfocan en la arquitectura como el centro del desarrollo para asegurar que el desarrollo basado en componentes sea clave para un alto nivel de reutilizacin. MSF considera que hay cuatro perspectivas de arquitectura que cumplen los requerimientos de una empresa [M&R 1998]:

Arquitectura de Negocios -Describe como opera un negocio.Desarrollauna imagen clara de los procesos de flujo de trabajo de la organizacin y de cmo son apoyados por una infraestructura tecnolgica basada en servicios.Arquitectura de Aplicacin Adopta un modelo de aplicacin de toda la empresa para disear y desarrollar sistemas de negocios que puedan compartir un conjunto de componentes back-end de alto valor.

Arquitectura de Informacin Define qu informacin es necesaria para apoyar el proceso de negocios y como poner esa informacin eficientemente en manos de quienes que la necesitan sin crear islas de datos inaccesibles ni sistemas redundantes.Arquitectura Tecnolgica Define los estndares y guas para la adquisicin y despliegue de herramientas, bloques de construccin de aplicaciones, servicios de infraestructura, componentes de conectividad de red y plataformas cliente servidor.

El Modelo de Equipo de MSF se basa en las formas de organizar equipos para crear los propios productos de Microsoft. Hace nfasis en las comunicaciones claras y en un equipo de iguales con papeles y responsabilidades claras en todo el proyecto. La calidad del producto se asegura por cada miembro del equipo. El Proceso Unificado proporciona ms detalle y gua para algunos de los roles en el proyecto.Una vista arquitectnica es una descripcin simplificada (una abstraccin) de un sistema desde una perspectiva particular o punto de vista, que cubre particularidades y omite entidades que no son relevantes a esta perspectiva [Booch 1998].

Segn el mismo autor, las caractersticas primordiales del Proceso Unificado son:1.Iterativo e incremental2.Centrado en la arquitectura3.Guiado por casos de uso4.Confrontacin de riesgos

El Proceso Unificado es un proceso porque define quin est haciendo qu, cundo lo hacer y cmo alcanzar cierto objetivo, en este caso el desarrollo de software [Jacobson 1998]. Segn [Booch 1998], los conceptos clave del Proceso Unificado son:Fase e iteraciones Cundo se hace?Flujos de trabajo de procesos (actividades y pasos) Qu se est haciendo?Artefactos (modelos, reportes, documentos) Qu se produjo?Trabajador: un arquitecto Quin lo hace?)

El Ciclo de Vida del Software en el Proceso UnificadoLas fases del ciclo de vida del software son:

1.Concepcin2.Elaboracin3.Construccin4.Transicin.

La concepcin es definir el alcance del proyecto y definir el caso de uso. La elaboracin es proyectar un plan, definir las caractersticas y cimentar la arquitectura. La construccin es crear el producto y la transicin es transferir el producto a sus usuarios [Booch 1998].

ESTRUCTURA DEL PROCESO UNIFICADOSegn [Microsoft 1997], el diseo de software se realiza a tres niveles:Conceptual, Lgico y FsicoArquitectura Lgica de Tres Capas de Una Aplicacin Cliente/Servidor

Herramientas de Ingeniera de SoftwareAqu encontrars informacin sobre las herramientas lderes que implementan la ingeniera de software, desde el modelado de sistemas con UML hasta el proceso unificado que tiene que ver con la administracin de proyectos. Source Forge.net Es una base de datos de proyectos de software de cdigo abierto u open source software.Un ingeniero de software necesita de herramientas, entre ellas las herramientas de Rational son las ms avanzadas, pero son muy costosas. Tambin puede utilizar las herramientas de oficina como un editor de textos, un modelador de datos, etc., muchas de ellas son de cdigo abierto y an estn de desarrollo. Utiliza las que ms te sean de utilidad.

Diseo ConceptualEl diseo conceptual se considera como un anlisis de actividades y consiste en la solucin de negocios para el usuario y se expresa con los casos de uso. El diseo lgico es la solucin del equipo de proyecto del negocio y consiste de las siguientes tareas:

1.Identificar los usuarios y sus roles.2.Obtener datos de los usuarios.3.Evaluar la informacin.4.Documentar los escenarios de uso.5.Validar con los usuarios.6.Validar contra la arquitectura de la empresa.

Una forma de obtener estos requerimientos es construir una matriz usuarios-actividades de negocios, realizar entrevistas, encuestas y/o visitas a los usuarios, de tal manera que se obtenga quin, qu, cundo, dnde y por qu de la solucin.

Diseo LgicoEl diseo lgico traduce los escenarios de uso creados en el diseo conceptual en un conjunto de objetos de negocio y sus servicios. El diseo lgico se convierte en parte en la especificacin funcional que se usa en el diseo fsico. El diseo lgico es independiente de la tecnologa. El diseo lgico refina, organiza y detalla la solucin de negocios y define formalmente las reglas y polticas especficas de negocios. Un objeto de negocios es la encapsulacin de un servicio que abstrae las cualidades esenciales de algo de inters.

Un servicio es una unidad con capacidad de cmputo. Un servicio debe satisfacer lo siguiente:

Ser seguro, lo que equivale a un uso correcto y con autorizacinSer vlido, qu tareas o reglas se pueden aplicarManejar excepciones, informando al clienteContar con un catlogo de servicios que constituye un repositorio de servicios.

Los objetos de negocio deben verificarse y probarse de tal manera que asegure que los mdulos operen como unidades completas de trabajo. Las tareas de verificacin incluyen:

Una verificacin independiente:Pre y post condiciones.Lgica y funcionalidad individual.Una verificacin dependiente:Verificacin de dependencias.Que operan como una unidad especfica de trabajo.El diseo lgico comprende las siguientes tareas:Identificar y definir los objetos de negocio y sus servicios.Definir las interfaces.Identificar las dependencias entre objetosValidar contra los escenarios de uso.Comparar con la arquitectura de la empresa.Revisar y refinar tanto como sea necesario.

Para definir los objetos de negocios y sus servicios se puede usar la tcnica de anlisis nombre-verbo de los escenarios de uso. Tambin se puede emplear la tcnica sujeto-verbo-objeto directo. En estas tcnicas los sujetos y el objeto directo son los candidatos a objetos de negocio y los verbos activos son los candidatos a servicios.

DependenciasLa tarea de identificar las dependencias entre objetos permite identificar eventos, sucesos o condiciones que permitan la realizacin de tareas de negocios coordinadamente o transaccionalmente. Para ello se debe considerar lo siguiente:Identificar los eventos disparadores (triggers)Determinar cualquier dependencia (existencial o funcional)Determinar cualquier problema de consistencia o secuencia.Identificar cualquier regulacin de tiempo crtica.Considerar algn problema organizacional (transacciones)Identificar y auditar los requerimientos de control.Determinar lugares y dependencias a travs de la ubicacin.Determinar cuando el servicio que controla la transaccin es dependiente de los servicios contenidos en otros objetos de negocioLa validacin del modelo lgico debe ser tal que ste sea:Completo debe representar todos los escenarios de uso,Correcto el comportamiento lgico debe corresponder con el comportamiento conceptual.Claro los objetos de negocio y servicios no deben ser ambiguos.

En el diseo lgico conceptualmente se divide en tres niveles de servicios con el fin de que la aplicacin resulte flexible ante los cambios de requerimientos y/o de tecnologa cambiando nicamente la capa o capas necesarias. Los tres niveles son: servicios de usuario, servicios de negocio y servicios de datos.

Los servicios de usuario (user services) controlan la interaccin. Un servicio de usuario son personas, aplicaciones, otros servicios o la combinacin de stos. Generalmente involucra una interfase grfica de usuario (GUI) o pude ser no visual (mensajes o funciones), maneja todos los aspectos de la interaccin con la aplicacin. El objetivo central es minimizar el esfuerzo de conocimiento requerido para interpretar la informacin. Un servicio de usuario incluye un contenido (qu se necesita comunicar al usuario) y una forma (cmo se comunica el contenido) cuando es necesaria la comunicacin.

Los servicios de negocio (bussines services) convierten datos recibidos de los servicios de datos y de usuario en informacin (datos + regla de negocio) y pueden usar otros servicios de negocio para completar su tarea.

Las tareas de los servicios de negocio son:Dar formato a los datos.Obtener y mover datos desde y hasta los servicios de datos.Transformar los datos en informacin.

Validar los datos inmediatamente en el contexto o en forma diferida una vez terminada la transaccin.

Los servicios de datos (data services)son los servicios de bajo nivel que apoyan los servicios de negocio y son de una amplia gama de categoras como las siguientes:Declaracin del esquema y su evolucin (estructuras de datos, tipos, acceso indexado, SQL, APIs) Respaldo y recuperacin (recuperacin de datos si un evento falla)Bsqueda y Lectura (bsquedas, compilacin, optimizacin y ejecucin de solicitudes, formacin de un conjunto de resultados)

Insercin, actualizacin y borrado (procesar modificaciones consistentemente transaccional). Una transaccin es atmica (ocurre o no), consistente (preserva integridad), aislada (otras transacciones ocurren antes o despus) y durable (una vez completada, sta sobrevive).

Bloqueo (permite al acceso concurrente a los datos)Validacin de datos (verifica la integridad del dominio, triggers y gateways para verificar el estado de los datos antes de aceptarlos, manejo de errores)Seguridad (acceso seguro a los objetos, operaciones, permisos a usuario y grupos y servicios)

Administracin de la conexin (mecanismos bsicos para establecer una sesin de los servicios de datos). Establecer una conexin involucra: una identificacin, la colocacin y provisin de datos, tiempo de sesin, el tipo de interaccin (conversacional, transaccional, multiusuario, monousuario). Distribucin de datos (Distribuye informacin, a mltiples unidades de recuperacin, bases de datos heterogneas, segn la topologas de la red).

Diseo FsicoEl diseo fsico traduce el diseo lgico en una solucin implementable y costo-efectiva o econmica. El componente es la unidad de construccin elemental del diseo fsico. Las caractersticas de un componente son:

Se define segn cmo interacta con otros.Encapsula sus funciones y sus datos.Es reusable a travs de las aplicaciones.Puede verse como una caja negra.Puede contener otros componentes.El diseo fsico debe involucrar:El diseo para distribucin debe minimizar la cantidad de datos que pasan como parmetros entre los componentes y stos deben enviarse de manera segura por la red.El diseo para multitarea debe disearse en trminos de la administracin concurrente de dos o ms tareas distintas por una computadora y el multithreading o mltiples hilos de un mismo proceso)El diseo para uso concurrente el desempeo de un componente remoto depende de si est corriendo mientras recibe una solicitud.El diseo con el manejo de errores y prueba de eventos:Validando los parmetros- a la entrada antes de continuar con cualquier proceso.Protegiendo recursos crticos manejar excepciones para evitar la falla o terminacin sin cerrar archivos, liberar objetos sincronizados o memoria.Protegiendo datos importantes contar con una excepcin a la mitad de la actuacin en las bases de datos.Proteccin integral de transacciones de negocios los errores deben regresarse al componente que llama.Arquitectura fsica de tres capas de la aplicacin cliente/servidor

El Diseo Fsico comprende las siguientes tareas:

1.Definir los componentes.2.Refinar el empaquetamiento y distribucin de componentes.3.Especificar las interfaces de los componentes.4.Distribuir los componentes en la red.5.Distribuir los repositorios fsicos de datos.6.Examinar la tolerancia a fallas y la recuperacin de errores.7.Validar el diseo fsico.

De las tareas anteriores la ms importante es ladistribucin de los datos que pueden ser centralizados, una particin, un extracto o una rplica. Los datos centralizados equivalen a una base de datos maestra ubicada en un lugar central. No hay copias de los datos.

Una particin de datos es una segmentacin de la base de datos maestra. Es til cuando los datos se pueden fragmentar fcilmente y actualizarse en un sitio local con cambios frecuentes. No hay sobre posicin entre particiones. En una particin horizontal cada hilera existe en una sola base de datos. En una particin vertical cada columna es contenida en una y solo una base de datos.

El diseo fsico est ntimamente ligado a una alternativa tecnolgica. Ante la acelerada evolucin tecnolgica es importante considerar los estndares del momento y las tendencias ya que una mala decisin implicar un costo enorme (en dinero y en tiempo) al actualizarse a otra plataforma distinta. La tendencia actual en la arquitectura cliente/servidor es crear el back-end como un servidor robusto multitareas y multithreading y el front-end como un cliente muy delgado que no acapare al servidor comunicndose entre s en una plataforma internet con protocolos estndar en redes heterogneas.

UNIDAD II:INTRODUCCIN AL UML

Tema 04: Diagramas y Elementos de UML

1.Elementos estructurales.2.Elementos de comportamiento.3.Elementos de agrupacin.4.Elementos de anotacin.

Estos son los bloques bsicos de construccin orientados a objetos.

ELEMENTOS ESTRUCTURALESSon los nombres de los modelos UML. Son las partes estticas de un modelo, representan conceptos cosas materiales de un modelo. Se lo denomina

CLASIFICADORESClase:es una descripcin de un conjunto de mtodos que comparten os mismos atributos, operaciones, relaciones y semntica. Implementa una ms interfaces.

Interfaz:es una coleccin de operaciones que especifican un servicio de una clase o componente. Describe el comportamiento visible externamente de ese elemento.

Colaboracin:define una interaccin y es una sociedad de rolesy otros elementos que colaboran para proporcionar un comportamiento cooperativo mayor que la suma de los comportamientos de sus elementos. Tiene una dimensin estructural y otra de comportamiento.

Caso de Uso:es una descripcin de un conjunto de secuencias de acciones que ejecuta unsistema y que produce un resultado observable de inters para un actor particular. Se utiliza para estructurar los aspectos de comportamiento de un modelo. Es realizado por una colaboracin.

Clase Activa:es una clase cuyos objetos tienen uno msprocesos hilos de ejecucin y, por lo tanto, pueden dar orgenes a actividades de control. Es igual que una clase, excepto en que sus objetos representan elementos cuyo comportamiento es concurrente con otros elementos.

Componentes:es un parte modular del diseo del sistema que oculta su implicacin tras un conjunto de interfaces externas.

Los elementos artefactosy nodos representan elementosfsicos mientras que los seis elementos anteriores representan cosas conceptuales lgicas.Artefacto:es una parte fsica y reemplazable de un sistema que tiene informacin fsica.

Nodo:es un elemento fsico que existe en tiempo de ejecucin y representa un recurso computacional, que por lo general dispone de algo de memoria y, con frecuencia capacidad de almacenamiento.

ELEMENTOS DE COMPORTAMIENTO

Interaccin:comprende un conjunto de mensajes intercambiados entre un conjunto deobjetos, dentro de un contexto particular, para alcanzar un propsito especfico.

Mquina de Estados:es un comportamiento que especificalassecuencias de estados por las que pasa un objeto una interaccin durante su vida en respuesta a eventos, junto con sus reacciones a estos eventos.

Actividad:es un comportamiento que especifica la secuencia de pasos que ejecuta un proceso computacional.Semnticamente, estos elementos estn conectados normalmente a diversos elementos estructurales, principalmente clases, colaboraciones y objetos.

ELEMENTOS DE AGRUPACINSon las partes organizativas de los modelos UML. Son cajas en las que puede descomponerse un modelo.

Paquetes:es un mecanismo de propsito general para organizar el propio diseo. Un paquete es puramente conceptual, slo existe en tiempo de desarrollo.

ELEMENTOS DE ANOTACIN

Son las partes explicativas de un modelo UML. Soncomentariosque se pueden aplicar para describir, clarificar y hacer observaciones sobre cualquier elemento de un modelo.

RELACIONES EN UML

1.Dependencia.2.Asociacin.3.Generalizacin.4.Realizacin.

Son los bloques bsicos de construccin para relaciones en UML.

Dependencia:es una relacin semntica entre dos elementos, en la cual un cambio a un elemento puede afectar a la semntica del otro elemento.

Asociacin:es una relacin estructural entre clasesquedescribe un conjunto de enlaces, los cuales son conexiones entre objetosque son instancias de clases.

Generalizacin:es una relacin de especializacin de especializacin / generalizacin en la cual el elemento especializado (el hijo) se basa en la especificacin del elemento generalizado (el padre).

Realizacin:es una relacin semntica entre clasificadores, en donde un clasificador especifica un contrato que otro clasificador cumplir.