ANLISIS ESTRUCTURADO de Sistema. Conceptos generales Cuando los analistas comienzan a trabajar sobre un proyecto de sistemas de informacin, a menudo tienen que profundizar en un rea de la organizacin con la que tienen poca familiaridad. A pesar de esto, futuros usuarios - de esa rea. Cualquier nuevo sistema o conjunto de recomendaciones para cambios en el sistema existente, ya sea ste manual o automatizado, debe conducir hacia una mejora. Para alcanzar este resultado, se espera que los analistas de sistemas hagan lo siguiente:

aprendan los detalles y procedimientos del sistema en uso. Obtengan una idea de las demandas futuras de la organizacin como resultado del crecimiento, del aumento de la competencia en el mercado, de los cambios en las necesidades de los consumidores, de la evolucin de las estructuras financieras, de la introduccin de la nueva tecnologa y cambios en las polticas del gobierno entre otros. Documentar detalles del sistema actual para su revisin y discusin por otros. Evaluar la eficiencia y efectividad del sistema actual y sus procedimientos, tomando en cuenta el impacto sobre las demandas anticipadas para el futuro. Fomentar la participacin de gerentes y empleados en todo el proceso, tanto para aprovechar su experiencia y conocimiento del sistema actual, como para conocer sus ideas, sentimientos y opiniones relacionadas con los requerimientos de un nuevo sistema o de los cambios para la cual.

Qu es el anlisis estructurado? El anlisis estructurado es un mtodo para el anlisis de sistemas manuales o automatizados, que conduce al desarrollo de especificaciones para sistemas nuevos o para efectuar modificaciones a los ya existentes. Cuando los analistas de sistemas abordan una situacin poco familiar, siempre existe una pregunta sobre donde comenzar el anlisis. Una situacin dinmica siempre puede ser vista como abrumadora debido a que muchas de las actividades se llevan a cabo constantemente, como sealo MARY HELEN es su seminario. El anlisis estructurado permite el analista conocer un sistema o proceso (actividad) en una forma lgica y manejable el mismo tiempo que proporciona la base para asegurar que no se omite ningn detalle pertinente. Sisgnificado de estructurado qu es lo que desea estructurar? que significa estructurar? El objetivo que persigue el anlisis estructurado es organizar las tareas asociada con la determinacin de requerimientos para obtener la comprensin completa y exacta de una situacin dada. A partir de aqu determina los requerimientos que sern la base de un sistema nuevo o modificado. En el anlisis estructurado la palabra estructura significa qu: 1) el mtodo intenta estructurar el proceso de determinacin de los requerimientos comenzando con la documentacin del sistema existente; 2) el proceso est organizado de tal forma que intenta incluir todos los detalles relevante que describe al sistema en uso; 3) es fcil verificar cuando se han omitido detalles relevantes; 4) la identificacin de los requerimientos ser similar entre varios analistas e incluir las mejora soluciones y estrategias para las oportunidades para de desarrollo de sistemas; y 5) los documentos de trabajo generados para documentar los sistemas existente o propuesto son dispositivos de comunicacin eficientes. Componentes del anlisis estructurado El anlisis estructurado hace uso de los siguientes componentes. 1. 2. 3. 4. smbolos grficos diccionario de datos descripciones de procesos y procedimientos reglas

Que es el anlisis de flujo de datos? Los analistas desean conocer las respuestas a cuatro preguntas especificas: Que procesos integran el sistema? ?que datos emplea cada proceso? ?qu datos son almacenado? ?que datos ingresan y abandonan el sistema? De lo anterior es claro que se da gran importancia al anlisis de los datos. Los datos son la gua de las actividades de la empresa. Ellos pueden iniciar eventos (por ejemplo, los datos sobre nuevos pedidos) y ser procesados para dar informacin til al personal que desea saber qu tambin se han manejado los eventos (al medir la calidad y tasa de trabajo, rentabilidad, etc.). el anlisis de sistemas conoce el papel central que tienen los datos de la empresa en las organizaciones. Seguir el flujo de datos por todos los procesos de la empresa, que es la finalidad del anlisis de flujo de datos, les dice mucho a los analistas sobre como se alcanza los objetivos de la organizacin. En el transcurso del manejo de transacciones y terminacin de tareas los datos entran, son procesados, almacenados, recuperados, analizados, utilizados, cambiados y presentados como salidas. El anlisis de flujo de datos estudia el empleo de los datos en cada actividad. Documento a los hallazgos con diagramas de flujo de datos que muestran en forma grfica la relacin entre procesos y datos, en los diccionarios de datos que describe de manera formal los datos del sistema y los sitios donde son utilizados. CARACTERISTICAS DE LA ESTRATEGIA DE FLUJOS DE DATOS

El anlisis de flujo de datos examina el empleo de los datos para llevar a cabo procesos especficos de la empresa dentro del mbito de una investigacin de sistemas. El anlisis puede pensarse de tal manera que se estudia actividades del sistema desde el punto de vista de los datos: donde se originan, como se utilizan o cambian, hacia donde van, incluyendo las paradas a los largo del camino que siguen desde sus origen hasta sus destino. Los componentes de la estrategia de flujo de datos abarcan tanto la determinacin de los requerimientos como el diseo de sistemas. Una notacin bien establecida facilita la documentacin del sistemas actual y su anlisis por todos los participantes en el proceso de determinacin de requerimientos. Herramientas de la estrategia de flujo de datos La estrategia de flujo de datos muestra el empleo de estos en forma grfica. Las herramientas utilizadas al seguir esta estrategia muestran todas las caractersticas esenciales del sistema y la forma en que se ajustan entre s. Puede ser difcil comprender en su totalidad un proceso de la empresa si se emplea para ello una descripcin verbal; Las herramientas para el flujo de datos ayuda a mostrar los componentes esenciales de un sistema junto con sus interacciones. El anlisis de flujo de datos utiliza la sguie. Herramientas. 1. Diagrama de flujo de datos

Una herramienta grfica se emplea para describir y analizar el movimiento de datos a travs de un sistema, ya sea que este fuera manual o automatizado, incluyendo procesos, lugares para almacenar datos y retrasos en el sistema. Estos diagramas reciben el nombre de diagramas lgicos de flujo de datos 2. Diccionario de datos

el diccionario contiene las caractersticas lgicas de los sitios donde se almacenan los datos del sistema, incluyendo nombre, descripcin, alias, contenidos y organizacin. Tambin identifica los procesos donde se emplea los datos y los sitios de donde se necesitan el acceso inmediato a la informacin. Sirve como puerto de partida para identificar los requerimientos de las bases de datos durante el diseo del sistema. 3. Diagrama de estructura de datos

Este diagrama es una descripcin de la relacin entre entidades (personas, lugares, eventos y objetos) de un sistema y el conjunto de informacin relacionada con la entidad. No considera el almacenamiento fsico de los datos. 4. grfica de estructura

Herramienta de diseo que muestra con smbolos la relacin entre los mdulos de procesamiento y el software de la computadora describe la jerarqua de los mdulos componentes y los datos que sern transmitidos entre ellos. Incluye el anlisis de las transformaciones entrada - salida y el anlisis de transaccin. DESARROLLO DE DIARAMAS DE FLUJO DE DATOS Para que de utilidad y proporcionan informacin los diagramas de flujo de datos deben dibujarse en forma adecuada. Esta seccin muestra como dibujarlos: donde comenzar, como aadir detalles a las descripciones, cuando incorporar la informacin sobre el control y como mantener la consistencia al asignar los nombre s de los objetos incluidos en los diagramas. La presentacin seala tambin errores comunes que deben evitarse. Diagramas fsicos de flujo de datos Los diagramas de flujo de datos son de dos tipos:

Diagramas fsicos de datos

Proporciona un panorama del sistema en uso, que es dependiente de la implantacin, que muestra qu tareas se llevan a cabo y cmo. Las caractersticas fsicas incluyen: Nombres de personas Nombre de nmeros de formatos y documentos Nombres de departamentos Archivos maestros y de transacciones Equipo y dispositivos utilizados

Ubicaciones Nombre de procedimientos

Diagramas lgicos de flujo de datos

Proporcionan un panorama del sistema independiente de la implantacin, que se centra en el flujo de datos entre los procesos sin considerar los dispositivos especficos y la localizacin de almacenes de datos o personas en el sistema. En este tipo de diagramas no se indican las caractersticas fsicas, lo cual si sucede con los diagramas fsicos de flujo. El enfoque ms amplio y til para desarrollar una descripcin exacta y completa del sistema en uso, comienza con el desarrollo del diagrama fsico de flujo de datos. El empleo de estos diagramas es deseable por tres razones. Primera, es comn que los analistas de sistemas encuentren mucho ms fcil describir la interaccin entre los componentes fsicos que comprender las polticas empleadas para administrar la aplicacin. Segunda, los diagramas fsicos de flujo de datos son de utilidad para comunicarse con los usuarios. stos relacionan con facilidad a las personas, las localidades y los documentos ya que trabajan todos los das con cada entidad. (Es usual que los analistas de sistemas encuentren que los usuarios consideran "abstractos" los diagramas lgicos de flujo de datos porque no contienen componentes que les sean familiares.) Tercera, los diagramas fsicos de flujo de datos proporcionan un camino para validar o verificar el punto de vista del usuario sobre la forma en que opera el sistema en uso. Si existen diferencias, stas son anotadas y discutidas. No es poco usual encontrar que lo que un usuario piensa que est sucediendo difiere de forma importante de lo que en realidad est ocurriendo. Son estas diferencias las que probablemente expliquen los problemas o ineficiencias quiz la razn por la que se propone un nuevo sistema. Dibujo de diagramas fsicos de flujo La siguiente descripcin sobre la forma como maneja una compaa su sistema de cuentas por pagar, ser utilizada para el desarrollo de diagramas de flujo de datos: Dibujo del diagrama de contexto Como ya se indic, los primeros pasos para determinar los requerimientos tienen como finalidad conocer las caractersticas generales del proceso bajo investigacin. Para decirlo de algn modo, primero se estudian los detalles de la capa superior. Conforme los analistas comprenden mejor los detalles, ahondan con mayor profundidad para recopilar informacin ms precisa y destellada. Cada vez se formulan preguntas ms especificas utilizando para ello el anlisis descendente (top-down). A menudo el diagrama de alto nivel se denomina diagrama de contexto. Contiene un solo proceso pero juega un papel muy importante en el estudio del sistema en uso. El diagrama de contexto define el sistema que va ha ser estudiado en el sentido de que determina las fronteras. Todo los que no se encuentre dentro de las fronteras identificadas en el diagrama de contexto del proceso no forma parte del estudio de sistemas. La forma en que funcionan las otras organizaciones o elementos externos (las fuentes y destinos) no est fuera de nuestro control y no ser estudiada con detalle. No obstante, si afectan el proceso porque son fuentes o destinos, debe tener una interface, o medios para interactuar, con los elementos que estn fuera de l. Desarrollo de grficas de procesos Un sistema est formado por varias actividades o procesos. Usted ha aprendido en forma gradual aspectos pertinentes a la relacin entre procesos; tambin ha descubierto que un proceso contiene varios pasos (procesos en pequea escala). El la programacin de computadoras, los programadores con frecuencia desarrollan el software como una coleccin de mdulos independientes pero que interactuan entre s. A menudo estos mdulos se muestran en los diagramas de jerarqua. Estos diagramas son similares a los desaprobadores por los programadores. ///////////////////////////////////////////////////////////////////////////////////////////////////// Panorama. El desarrollo de sistemas esta formado por dos componentes: El Anlisis de sistemas y el Diseo de sistemas. Diseo de sistemas. Es el proceso de planificar, reemplazar o complementar un sistema existente. Pero es necesario comprender el viejo. Utilizar las compu para hacer el trabajo mas eficiente.

Anlisis de sistemas. Es el proceso de clasificacion e interpretacin de hechos, diagnostico de problemas y empleo de la informacin para recomendar mejoras al sistema. Cual es el flujo de informacin en todo el sistema.

Estudio del sistema. Esta acumulacin de informacin es la que precede a todas las demas actividades del anlisis. El plan. Incluye. Caractersticas del diseo del sistema, necesidades de captura de nuevos datos, especificaciones de archivo, procedimientos de operacin y necesidades de equepo y y personal. El diseo. Especifica las caractersticas del producto terminado. Que trabajos por personas y cuales por la maquina. Como alcanzar el objetivo. Los analistas. Deciden que salida utilizar y como generarla. Que es lo que se debe hacer. Las personas. Son los elementos mas importantes para que una organizacin trabaje. Comunicacin. Importancia del Anlisis de Sistemas. Solo despus de un buen estudio del sistema es posible llegar a proponer los cambios que lo haran mas util y no produciran efectos imprevistos. El analista utiliza el conocimiento del sistema existente y sus problemas para disear y construir un sistema mejor. Qu hace un analista de sistemas?. Recopila los datos necesarios del sistema actual y lleva a cabo el desarrollo de planes para nuevos sistemas. Pasa mucho tiempo con los usuarios para descubrir como utilizan el sistema, los problemas que tienen y lo que esperan de el. Debe comprender como funciona el sistema mismo. Utilizara formularios, contenido de ficheros, informacin utilizada por los usuarios entrada y salida. Satisfacer a todos dentro de las reglas de direccin. Diagramas de Flujo de Datos. Tienen la misin de : Mostrar las fuentes y destinos de los datos. Identificar y dar nombre a los procesos. Dar nombre a los grupos de datos que relacionan una funcion con otra. Sealar los almacenes de datos a los que se tiene acceso.

Descripcin Descendente TOP DOWN, Diccionario de datos. Se definen flujo de datos, procesos y almacenes de datos. Diseo Estructurado. Es la especificacin de modulos del programa que son funcionalmente independientes. La principal herramienta es el DIAGRAMA ESTRUCTURADO. Diagrama de Flujo de Datos Un diagrama de flujo de datos (DFD por sus siglas en espaol e ingls) es una representacin grfica para la maceta del "flujo" de datos a travs de un sistema de informacin. Un diagrama de flujo de datos tambin se puede utilizar para la visualizacin de procesamiento de datos (diseo estructurado). Es una prctica comn para un diseador dibujar un contexto a nivel de DFD que primero muestra la interaccin entre el sistema y las entidades externas. Este contexto a nivel de DFD se "explot" para mostrar ms detalles del sistema que se est modelando. Los diagramas de flujo de datos fueron inventados por Larry Constantine, el desarrollador original del diseo estructurado, basado en el modelo de computacin de Martin y Estrin: "flujo grfico de datos" . Los diagramas de flujo de datos (DFD) son una de las tres perspectivas esenciales de Anlisis de Sistemas Estructurados y Diseo por Mtodo SSADM. El patrocinador de un proyecto y los usuarios finales tendrn que ser informados y consultados en todas las etapas de una evolucin del sistema. Con un diagrama de flujo de datos, los usuarios van a poder visualizar la forma en que el sistema funcione, lo que el sistema va a lograr, y cmo el sistema se pondr en prctica.

DIRECCIONARIO DE DATOS Un diccionario de datos es un conjunto de metadatos que contiene las caractersticas lgicas de los datos que se van a utilizar en el sistema que se programa, incluyendo nombre, descripcin, alias, contenido y organizacin. Estos diccionarios se desarrollan durante el anlisis de flujo de datos y ayuda a los analistas que participan en la determinacin de los requerimientos del sistema, su contenido tambin se emplea durante el diseo del proyecto. En un diccionario de datos se encuentra la lista de todos los elementos que forman parte del flujo de datos de todo el sistema. Los elementos mas importantes son flujos de datos, almacenes de datos y procesos. El diccionario de datos guarda los detalles y descripcin de todos estos elementos. Ejemplos Nombre = Ttulo + Primer-nombre + Apellido-paterno + Apellido-materno Ttulo = [ Sr | Sra | Dr | Ing] Primer-nombre = {caracter} Apellido-paterno = {caracter} Apellido-materno = {caracter} caracter = [A-Z|a-z| |] a Descripcin de un proceso De algn modo, debemos hacer una pregunta fundamental: cul es la manifestacin fsica de un proceso? Como mnimo debe incluir un programa o conjunto de programas que sean ejecutados. Asociados a estos programas hay un conjunto de ubicaciones de datos para las variables locales y globales, y las constantes definidas. As pues, un proceso constar, al menos, de la memoria suficiente para albergar los programas y los datos del proceso. Adems, en la ejecucin de un programa entra en juego normalmente una pila, que se utiliza para llevar la cuenta de las llamadas a procedimientos y de los parmetros que se pasan entre los procedimientos. Por ltimo, asociado a cada proceso hay una serie de atributos que utiliza el sistema operativo para el control del proceso. Estos atributos se recogen en una estructura de datos que se conoce como bloque de control de proceso (Process Control Block, PCB) o descriptor de proceso. A esta coleccin de programa, datos, pila y atributos se le llama imagen o entorno del proceso. Herramientas Case De acuerdo con Kendall y Kendall la ingeniera de sistemas asistida por ordenador es la aplicacin de tecnologa informtica a las actividades, las tcnicas y las metodologas propias de desarrollo, su objetivo es acelerar el proceso para el que han sido diseadas, en el caso de CASE para automatizar o apoyar una o mas fases del ciclo de vida del desarrollo de sistemas.

Cuando se hace la planificacin de la base de datos, la primera etapa del ciclo de vida de las aplicaciones de bases de datos, tambin se puede escoger una herramienta CASE (Computer-Aided Software Engineering) que permita llevar a cabo el resto de tareas del modo ms eficiente y efectivo posible. Una herramienta CASE suele incluir:

Un diccionario de datos para almacenar informacin sobre los datos de la aplicacin de bases de datos. Herramientas de diseo para dar apoyo al anlisis de datos. Herramientas que permitan desarrollar el modelo de datos corporativo, as como los esquemas conceptual y lgico. Herramientas para desarrollar los prototipos de las aplicaciones.

El uso de las herramientas CASE puede mejorar la productividad en el desarrollo de una aplicacin de bases de datos. Estructura general de una herramienta case La estructura CASE se basa en la siguiente terminologa:

CASE de alto nivel son aquellas herramientas que automatizan o apoyan las fases finales o superiores del ciclo de vida del desarrollo de sistemas como la planificacin de sistemas, el anlisis de sistemas y el diseo de sistemas. CASE de bajo nivel son aquellas herramientas que automatizan o apoyan las fases finales o inferiores del ciclo de vida como el diseo detallado de sistemas, la implantacin de sistemas y el soporte de sistemas. CASE cruzado de ciclo de vida se aplica a aquellas herramientas que apoyan actividades que tienen lugar a lo largo de todo el ciclo de vida, se incluyen actividades como la gestin de proyectos y la estimacin.

Sintaxis del Pseudocdigo CEE (C En Espaol) Inicio > Sintaxis del Pseudocdigo CEE > Estructura de un Algoritmo Estructura de un algoritmo La sintaxis para escribir un algoritmo en pseudocdigo es:

algoritmo [ constantes ] [ tipos_de_datos ] [ variables ] inicio fin

Sintaxis de los Ordinogramas Inicio > Sintaxis de los Ordinogramas > Estructura de un Algoritmo Estructura de un algoritmo En un ordinograma, el inicio y fin del cuerpo de un algoritmo se escriben dentro de un valo de la siguiente manera:

Por medio de las flechas se indica el orden de las acciones (instrucciones) del algoritmo. (Vase el apartado 8.3 Inicio y fin del Curso de Diseo de Algoritmos).

MODELO DE DATOS Un modelo de datos es un lenguaje orientado a describir una Base de Datos. Tpicamente un modelo de datos permite describir:

Las estructuras de datos de la base: El tipo de los datos que hay en la base y la forma en que se relacionan. Las restricciones de integridad: Un conjunto de condiciones que deben cumplir los datos para reflejar correctamente la realidad deseada. Operaciones de manipulacin de los datos: tpicamente, operaciones de agregado, borrado, modificacin y recuperacin de los datos de la base.

Otro enfoque es pensar que un modelo de datos permite describir los elementos de la realidad que intervienen en un problema dado y la forma en que se relacionan esos elementos entre s. No hay que perder de vista que una Base de Datos siempre est orientada a resolver un problema determinado, por lo que los dos enfoques propuestos son necesarios en cualquier desarrollo de software.

Metodologa OMT. La metodologa de modelado de objetos OMT (object Modeling Technique) descrito por [Rumbaugh]. Modelo: Del modelo espiral o un proceso evolutivo con una separacin no rgida entre las fases del desarrollo. Enfasis:

En el anlisis no en la implementacin, En los datos mas que en las funciones lo que da estabilidad al proceso de desarrollo. Notacin comn a todas las fases a travs de tres modelos que capturan los aspectos estticos, dinmicos y funcionales que combinados proveen una descripcin completa del software.

Fases de la metodologa OMT: Anlisis Su objetivo es desarrollar un modelo de lo que va a hacer el sistema. El modelo se expresa en trminos de objetos y de relaciones entre ellos, flujo dinmico de control y las transformaciones funcionales.

Los pasos a seguir en el anlisis son: 1. Se escribe u obtiene una descripcin inicial del problema. Se concentra en entender el problema y modelar en el dominio del problema. Se inicia con un texto que describe el problema. Se construye el modelo de objetos y sus relaciones. Su objetivo es describir la estructura esttica del software.

1.

Se abstraen los conceptos de los datos que son mas importantes para la aplicacin. Se describen grficamente por los diagramas de objetos que definen las clases y sus relaciones

Los pasos que se llevan a cabo para el modelo de objetos son: 1. Identificar las clases Se seleccionan los sustantivos de la descripcin del problema como posibles clases candidatas. Se construye una lista. Se eliminan las clases redundantes, irrelevantes o vagas o bien por ser atributos, operaciones o construcciones de implementacin. Las clases se representan por rectngulos con tres compartimientos, en el primero se pone el nombre de la clase, en el segundo los atributos y en el tercero las operaciones o mtodos.

o o

1.

Preparar un diccionario de clases (datos) Es muy importante definir que se entiende con mayor detalle por cada clase que qued en la lista anterior.

2.

Identificar las asociaciones entre objetos. Una asociacin es una dependencia entre dos o ms clases. Las asociaciones, se representan por lneas que unen a las clases sobre las cuales se puede escribir el nombre de la asociacin.

A estos diagramas se les agrega la multiplicidad correcta. Puede ser "uno a uno"; "uno a muchos" representada por una bolita rellena del lado de los "muchos"; o "muchos a muchos" representada por bolitas rellenas a ambos extremos de la lnea.

Tambin se puede representar la relacin " es parte de" o agregacin que indica que el objeto est compuesto por objetos de las clases asociadas. Se denota un pequeo diamante del lado de la clase que agrega y puede incluir multiplicidades.

3.

Identificar atributos. Los atributos son propiedades de los objetos tales como nombre, peso, velocidad, etc.

4.

Organizar y simplificar clases usando herencia. La herencia se puede usar para generalizar los aspectos comunes de las clases existentes construyendo una superclase, o para refinar una clase en subclases especializadas. La notacin de OMT para la herencia es un tringulo debajo de la superclase.

5.

Verificar que existan trayectorias en el modelo de objetos para preguntas probables. En los pasos anteriores se construy un diagrama de objetos, ahora se hace una revisin verificando que estn representadas todas las relaciones siguindolo para preguntas probables.

6.

Iterar y refinar el modelo.

El documento que genera el modelo de objetos es el siguiente: Modelo de objetos = diagrama del modelo de objetos + diccionario de datos 1. Se desarrolla el modelo dinmico. Se captura el aspecto concerniente a la secuencia de las operaciones en el tiempo. Se muestra el control sin importar que hacen exactamente las operaciones. Se representa por un diagrama de estados. El estado de un objeto es un conjunto de valores para sus atributos, en un cierto momento, el cual cambia al recibir un estmulo llamado evento.

Un diagrama de estados es una grfica de estados representados por crculos y eventos representados por flechas. Los pasos que se siguen en el modelo dinmico son: 1. 2. 3. 4. Preparar escenarios de una interaccin tpica. Identificar eventos entre objetos preparando un trazado de eventos para cada escenario. Construir los diagramas de estados. Revisar los eventos entre los objetos para verificar su consistencia. El documento que genera el modelo dinmico es:

Modelo dinmico = diagramas de estados + diagrama global de trazado de eventos 1. Se construye el modelo funcional. Especifica el significado de las operaciones o mtodos en el modelo de objetos y de las acciones en el modelo dinmico. Muestra como se calculan los valores sin importar la secuencia, las decisiones ni la estructura de los objetos. Se utilizan diagramas de flujo de datos para mostrar las dependencias funcionales.

El documento que genera el modelo funcional es: Modelo funcional = diagramas de flujo de datos + restricciones 1. Se verifican, iteran y refinan los tres modelos.

El documento que genera el anlisis contiene: Documento de anlisis = definicin del problema + modelo de objetos + modelo dinmico + modelo funcional. Diseo del sistema Se define la arquitectura del sistema y se toman las decisiones estratgicas. Los pasos que se llevan acabo son: 1. Se organiza el sistema en subsistemas. Cada subsistema comparte alguna propiedad en comn. Las relaciones entre los subsistemas pueden ser: cliente servidor o punto a punto. La descomposicin se puede organizar por capas horizontales o particiones verticales( cada uno proporciona un servicio). 2. Se identifica la concurrencia inherente en el problema. El modelo dinmico nos permite identificar la concurrencia en el sistema. 3. Se asignan los subsistemas a procesadores y a tareas. Cada subsistema se asigna a un procesador buscando satisfacer necesidades de rendimiento y minimizando la comunicacin de los procesadores. 4. 5. Se selecciona la estrategia para implementar y administrar los almacenes de datos(archivos o bases de datos). Seleccin de la implementacin del control del software. Existen dos tipos de control:

1.

El control interno. Esta dado por el flujo de control en el programa o proceso. El control externo. Esta dado por sucesos externos, los cuales pueden ser: Control por procedimientos. Control por sucesos. Concurrentes Se consideran las condiciones de contorno. Se trata de considerar como se hace la iniciacin, terminacin y como responder a las fallas.

2.

Se establecen prioridades de compensacin.

El documento que nos proporciona el diseo del sistema es: Documento de diseo del sistema = estructura de la arquitectura bsica del sistema + decisiones estratgicas de alto nivel.

Diseo de objetos Su objetivo es refinar el modelo del anlisis y proporcionar una base detallada para la implementacin tomando en cuenta el ambiente en que se implementar. Los pasos que se realizan en el diseo de objetos son los siguientes: 1. Se refinan las operaciones para el modelo de objetos a partir de los dems modelos:

o o1. 2. 3.

Se busca una operacin para cada proceso del modelo funcional. Se define una operacin para cada suceso del modelo dinmico.

Se disean algoritmos para implementar las operaciones y las estructuras de datos Se optimizan las vas de acceso a los datos. Se implementa el control del software completando la aproximacin propuesta en el diseo del sistema. Existen tres estrategias bsicas para implementar el control: 1. 2. 3. Construir un sistema controlado por procedimientos. Crear un motor de mquina de estados que responde a una tabla de transiciones y acciones. (Se recomienda para ambientes dirigidos por eventos) Establecer un control como tareas concurrentes. (Se requiere de un lenguaje que soporte la concurrencia)

1. 2.

Se ajusta la estructura de clases incrementando la herencia. Se disea la implementacin de las asociaciones. Las asociaciones conforman el pegamento en el modelo de objetos y proporcionan las vas de acceso entre los objetos. La implementacin se hace dependiendo del tipo de asociacin:

o o1. 2. 3. 1. 2.

Asociaciones unarias. Estas asociaciones se establecen solamente en una sola direccin y se pueden implementar por medio de apuntadores y si la mutiplicidad es de "muchos", por medio de un conjunto de apuntadores. Asociaciones bidireccionales. Este tipo de asociaciones se pueden implementar de diferentes maneras: Atributos en una direccin. Como atributos en ambas direcciones. Implementar como un objeto separado por medio de diccionarios.

Se determina la representacin exacta de los atributos de los objetos. Se empaquetan las clases y las asociaciones en mdulos. El empaquetamiento implica: Ocultar la informacin interna a los ojos externos (construir cajas negras con interfaces claras). Determinar la coherencia de entidades, es decir, que cada clase o mdulo debe de hacer una cosa y bien. Construccin de los mdulos. Cada mdulo debe de tener una cohesin funcional, esto es, un propsito bien definido.

El documento que se genera el diseo de objetos es: Documento de diseo de objetos = modelo de objetos detallado + modelo dinmico detallado + modelo funcional detallado. Ejemplo de la metodologa OMT Descripcin del problema El problema consiste en crear un sistema computarizado de registro de calificaciones para una liga infantil de nado sincronizado. Los nios participan en dos clases de eventos llamados: figuras y rutinas. Las figuras, se ejecutan de manera individual y son maniobras de ballet acutico tales como nadar sobre la espalda con una pierna levantada recta. Las rutinas se realizan por el equipo completo y son un ballet acutico, El sistema slo tiene que tomar en cuenta las figuras. Durante el encuentro, los eventos de figura se llevan simultneamente en varias estaciones situadas alrededor de la alberca, usualmente en cada esquina. En una estacin se pueden realizar varios eventos de figura en el curso de un encuentro. Los concursantes se dividen en grupos; cada grupo inicia en diferentes estaciones. Cada competidor tiene un intento en cada evento.

Se asignan varios jueces y anotadores a cada estacin durante el encuentro. Cada juez indica la calificacin para cada prueba observada mostrandoi unas tarjetas numeradas. Las calificaciones son ledas por los anotadores que las registran y calculan la calificacin neta para cada prueba. La calificacin ms alta y ms baja se eliminan por el grado de dificultad de la figura. Lista de candidatos a objetos Sistema computarizado rergistro Calificacin atr. liga infantil de nado Nio evento Figura rutina Ballet acutico espalda Pierna equipo Encuentro estacin Alberca esquina Concursante grupo Evento competidor Intento atr. juez Anotador tarjetas numeradas Promedio atr. grado de dificultad atr. Diagrama de instancias. Diagramas de clases e instancias. Diccionario de datos. Anotador: es la persona que lleva el registro de las calificaciones que asignan los jueces a cada competidor. Calcula la calificacin final de cada competidor. Concursante: es un nio que participa en la competencia. Equipo: es un conjunto de nios que participan en una competencia. Todos los participantes es un equipo realizan juntos el ballet acutico. Estacin: es el lugar donde se lleva a cabo un evento de competencia. Hay varias estaciones simultneas, usualmente es las esquinas de la alberca. En una estacin se pueden efectuar varios eventos. Evento: son las competencias o pruebas llevadas a cabo en las estaciones. Hay varios eventos en que pueden participar los competidores en una competencia. Figura: es un tipo de evento en que se compite individualmente, es una maniobra de ballet acutico como nadar de espalda con una pierna levantada. Juez: persona que asigana una calificacin a cada competidor para cada prueba. Varios jueces se asignan a una estacin. Una figura es calificada por los mismos jueces. Rutina: es otro tipo de evento, se compite en equipos completos realizando un ballet acutico.

Ingenieria de SoftwareUML Enviado por gmoreno

Ingenieria de SoftwareUML

Indice 1. Introduccin 2. Modelado de objetos 3. Artefactos para el Desarrollo de Proyectos 4. Diagramas de componentes 5. Diagramas de Clases 6. Relacin de Refinamiento 7. El Proceso de Desarrollo Para ver la versn en Power point, haga clik en el men superior "Bajar trabajo" 1. Introduccin Unified Modeling Languaje UML [UML] es un lenguaje para especificar, construir, visualizar y documentar los artefactos de un sistema de software orientado a objetos (OO). Un artefacto es una informacin que es utilizada o producida mediante un proceso de desarrollo de software. UML se quiere convertir en un lenguaje estndar con el que sea posible modelar todos los componentes del proceso de desarrollo de aplicaciones. Sin embargo, hay que tener en cuenta un aspecto importante del modelo: no pretende definir un modelo estndar de desarrollo, sino nicamente un lenguaje de modelado. Otros mtodos de modelaje como OMT (Object Modeling Technique) o Booch s definen procesos concretos. En UML los procesos de desarrollo son diferentes segn los distintos dominios de trabajo; no puede ser el mismo el proceso para crear una aplicacin en tiempo real, que el proceso de desarrollo de una aplicacin orientada a gestin, por poner un ejemplo. Las diferencias son muy marcadas y afectan a todas las faces del proceso. El mtodo del UML recomienda utilizar los procesos que otras metodologas tienen definidos. Los Inicios A partir del ao 1994, Grady Booch [Booch96](precursor de Booch '93) y Jim Rumbaugh (creador de OMT) se unen en una empresa comn, Rational Software Corporation, y comienzan a unificar sus dos mtodos. Un ao ms tarde, en octubre de 1995, aparece UML (Unified Modeling Language) 0.8, la que se considera como la primera versin del UML. A finales de ese mismo ao, Ivan Jacobson, creador de OOSE (Object Oriented Software Engineer) se aade al grupo. Como objetivos principales de la consecucin de un nuevo mtodo que aunara los mejores aspectos de sus predecesores, sus protagonistas se propusieron lo siguiente:

El mtodo deba ser capaz de modelar no slo sistemas de software sino otro tipo de sistemas reales de la empresa, siempre utilizando los conceptos de la orientacin a objetos (OO). Crear un lenguaje para modelado utilizable a la vez por mquinas y por personas. Establecer un acoplamiento explcito de los conceptos y los artefactos ejecutables. Manejar los problemas tpicos de los sistemas complejos de misin crtica.

Lo que se intenta es lograr con esto que los lenguajes que se aplican siguiendo los mtodos ms utilizados sigan evolucionando en conjunto y no por separado. Y adems, unificar las perspectivas entre diferentes tipos de sistemas (no slo software, sino tambin en el mbito de los negocios), al aclarar las fases de desarrollo, los requerimientos de anlisis, el diseo, la implementacin y los conceptos internos de la OO. 2. Modelado de objetos En la especificacin del UML podemos comprobar que una de las partes que lo componen es un metamodelo formal. Un metamodelo 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 descripto 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 tal supone 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 modelos OO: 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 que ser 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. 3. Artefactos para el Desarrollo de Proyectos Un artefacto es una informacin que es utilizada o producida mediante un proceso de desarrollo de software. Pueden ser artefactos un modelo, una descripcin o un software. Los artefactos de UML se especifican en forma de diagramas, stos, junto con la documentacin sobre el sistema constituyen los artefactos principales que el modelador puede observar. Se necesita ms de un punto de vista para llegar a representar un sistema. UML utiliza los diagramas grficos para obtener estos distintos puntos de vista de un sistema:

Diagramas de Implementacin. Diagramas de Comportamiento o Interaccin. Diagramas de Casos de uso. Diagramas de Clases.

Ejemplo de algunos de los diagramas que utiliza UML. Diagramas de Implementacin Se derivan de los diagramas de proceso y mdulos de la metodologa de Booch, aunque presentan algunas modificaciones. Los diagramas de implementacin muestran los aspectos fsicos del sistema. Incluyen la estructura del cdigo fuente y la implementacin, en tiempo de implementacin. Existen dos tipos: Diagramas de componentes Diagrama de plataformas despliegue 4. Diagramas de componentes Muestra la dependencia entre los distintos componentes de software, incluyendo componentes de cdigo fuente, binario y ejecutable. Un componente es un fragmento de cdigo software (un fuente, binario o ejecutable) que se utiliza para mostrar dependencias en tiempo de compilacin. Diagrama de plataformas o despliegue Muestra la configuracin de los componentes hardware, los procesos, los elementos de procesamiento en tiempo de ejecucin y los objetos que existen en tiempo de ejecucin. En este tipo de diagramas intervienen nodos, asociaciones de comunicacin, componentes dentro de los nodos y objetos que se encuentran a su vez dentro de los componentes. Un nodo es un objeto fsico en tiempo de ejecucin, es decir una mquina que se compone habitualmente de, por lo menos, memoria y capacidad de procesamiento, a su vez puede estar formado por otros componentes.

Diagramas de Interaccin o Comportamiento Muestran las interacciones entre objetos ocurridas en un escenario (parte) del sistema. Hay varios tipos: Diagrama de secuencia. Diagrama de colaboracin. Diagrama de estado. Diagrama de actividad. Diagrama de secuencia Muestran las interacciones entre un conjunto de objetos, ordenadas segn el tiempo en que tienen lugar. En los diagramas de este tipo intervienen objetos, que tienen un significado parecido al de los objetos representados en los diagramas de colaboracin, es decir son instancias concretas de una clase que participa en la interaccin. El objeto puede existir slo durante la ejecucin de la interaccin, se puede crear o puede ser destruido durante la ejecucin de la interaccin. Un diagrama de secuencia representa una forma de indicar el perodo durante el que un objeto est desarrollando una accin directamente o a travs de un procedimiento. En este tipo de diagramas tambin intervienen los mensajes, que son la forma en que se comunican los objetos: el objeto origen solicita (llama a) una operacin del objeto destino. Existen distintos tipos de mensajes segn cmo se producen en el tiempo: simples, sncronos, y asncronos. Los diagrama de secuencia permiten indicar cul es el momento en el que se enva o se completa un mensaje mediante el tiempo de transicin, que se especifica en el diagrama. Diagrama de colaboracin Muestra la interaccin entre varios objetos y los enlaces que existen entre ellos. Representa las interacciones entre objetos organizadas alrededor de los objetos y sus vinculaciones. A diferencia de un diagrama de secuencias, un diagrama de colaboraciones muestra las relaciones entre los objetos, no la secuencia en el tiempo en que se producen los mensajes. Los diagramas de secuencias y los diagramas de colaboraciones expresan informacin similar, pero en una forma diferente. Formando parte de los diagramas de colaboracin nos encontramos con objetos, enlaces y mensajes. Un objeto es una instancia de una clase que participa como una interaccin, existen objetos simples y complejos. Un objeto es activo si posee un thread o hilo de control y es capaz de iniciar la actividad de control, mientras que un objeto es pasivo si mantiene datos pero no inicia la actividad. Un enlace es una instancia de una asociacin que conecta dos objetos de un diagrama de colaboracin. El enlace puede ser reflexivo si conecta a un elemento consigo mismo. La existencia de un enlace entre dos objetos indica que puede existir un intercambio de mensajes entre los objetos conectados. Los diagramas de interaccin indican el flujo de mensajes entre elementos del modelo, el flujo de mensajes representa el envo de un mensaje desde un objeto a otro si entre ellos existe un enlace. Los mensajes que se envan entre objetos pueden ser de distintos tipos, tambin segn como se producen en el tiempo; existen mensajes simples, sincrnicos, balking, timeout y asncronos. Durante la ejecucin de un diagrama de colaboracin se crean y destruyen objetos y enlaces. Diagramas de actividad Son similares a los diagramas de flujo de otras metodologas OO. En realidad se corresponden con un caso especial de los diagramas de estado donde los estados son estados de accin (estados con una accin interna y una o ms transiciones que suceden al finalizar esta accin, o lo que es lo mismo, un paso en la ejecucin de lo que ser un procedimiento) y las transiciones vienen provocadas por la finalizacin de las acciones que tienen lugar en los estados de origen. Siempre van unidos a una clase o a la implementacin de un caso de uso o de un mtodo (que tiene el mismo significado que en cualquier otra metodologa OO). Los diagramas de actividad se utilizan para mostrar el flujo de operaciones que se desencadenan en un procedimiento interno del sistema. Diagramas de estado Representan la secuencia de estados por los que un objeto o una interaccin entre objetos pasa durante su tiempo de vida en respuesta a estmulos (eventos) recibidos. Representa lo que podemos denominar en conjunto una mquina de estados. Un estado en UML es cuando un objeto o una interaccin satisface una condicin, desarrolla alguna accin o se encuentra esperando un evento. Cuando un objeto o una interaccin pasa de un estado a otro por la ocurrencia de un evento se dice que ha sufrido una transicin, existen varios tipos de transiciones entre objetos: simples (normales y reflexivas) y complejas. Adems una transicin puede ser interna si el estado del que parte el objeto o interaccin es el mismo que al que llega, no se provoca un cambio de estado y se representan dentro del estado, no de la transicin. Como en todas las metodologas OO se envan mensajes, en este caso es la accin de la que puede enviar mensajes a uno o varios objetos destino

Diagramas de Casos de Uso Unos casos de uso es una secuencia de transacciones que son desarrolladas por un sistema en respuesta a un evento que inicia un actor sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la funcionalidad y el comportamiento de un sistema mediante su interaccin con los usuarios y/o otros sistemas. O lo que es igual, un diagrama que muestra la relacin entre los actores y los casos de uso en un sistema. Una relacin es una conexin entre los elementos del modelo, por ejemplo la relacin y la generalizacin son relaciones. Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar como reacciona una respuesta a eventos que se producen en el mismo. En este tipo de diagrama intervienen algunos conceptos nuevos: un actor es una entidad externa al sistema que se modela y que puede interactuar con l; un ejemplo de actor podra ser un usuario o cualquier otro sistema. Las relaciones entre casos de uso y actores pueden ser las siguientes:

Un actor se comunica con un caso de uso. Un caso de uso extiende otro caso de uso. Un caso de uso usa otro caso de uso

5. Diagramas de Clases Los diagramas de clases representan un conjunto de elementos del modelo que son estticos, como las clases y los tipos, sus contenidos y las relaciones que se establecen entre ellos. Algunos de los elementos que se pueden clasificar como estticos son los siguientes: Paquete: Es el mecanismo de que dispone UML para organizar sus elementos en grupos, se representa un grupo de elementos del modelo. Un sistema es un nico paquete que contiene el resto del sistema, por lo tanto, un paquete debe poder anidarse, permitindose que un paquete contenga otro paquete. Clases: Una clase representa un conjunto de objetos que tienen una estructura, un comportamiento y unas relaciones con propiedades parecidas. Describe un conjunto de objetos que comparte los mismos atributos, operaciones, mtodos, relaciones y significado. En UML una clase es una implementacin de un tipo. Los componentes de una clase son: Atributo. Se corresponde con las propiedades de una clase o un tipo. Se identifica mediante un nombre. Existen atributos simples y complejos. Operacin. Tambin conocido como mtodo, es un servicio proporcionado por la clase que puede ser solicitado por otras clases y que produce un comportamiento en ellas cuando se realiza. Las clases pueden tener varios parmetros formales, son las clases denominadas plantillas. Sus atributos y operaciones vendrn definidas segn sus parmetros formales. Las plantillas pueden tener especificados los valores reales para los parmetros formales, entonces reciben el nombre de clase parametrizada instanciada. Se puede usar en cualquier lugar en el que se podra aparecer su plantilla. Relacionando con las clases nos encontramos con el trmino utilidad, que se corresponde con una agrupacin de variables y procedimientos globales en forma de declaracin de clase, tambin puede definirse como un estereotipo (o nueva clase generada a partir de otra ya existente) de un tipo que agrupa variables globales y procedimientos en una declaracin de clase. Los atributos y operaciones que se agrupan en una utilidad se convierten en variables y operaciones globales. Una utilidad no es fundamental para el modelado, pero puede ser conveniente durante la programacin. Metaclase: Es una clase cuyas instancias son clases. Sirven como depsito para mantener las variables de clase y proporcionan operaciones (mtodo de clase) para inicializar estas variables. Se utilizan para construir metamodelos (modelos que se utilizan para definir otros modelos). Tipos: Es un descriptor de objetos que tiene un estado abstracto y especificaciones de operaciones pero no su implementacin. Un tipo establece una especificacin de comportamiento para las clases. Interfaz: Representa el uso de un tipo para describir el comportamiento visible externamente de cualquier elemento del modelo. Relacin entre clases: Las clases se relacionan entre s de distintas formas, que marcan los tipos de relaciones existentes: Asociacin: Es una relacin que describe un conjunto de vnculos entre clases. Pueden ser binarias o n-arias, segn se implican a dos clases o ms. Las relaciones de asociacin vienen identificadas por los roles, que son los nombres que indican el comportamiento que tienen los tipos o las clases, en el caso del rol de asociacin (existen otros tipos de roles segn la relacin a la que identifiquen). Indican la informacin ms importante de las asociaciones. Es posible indicar el nmero de instancias de una clase que participan en una relacin mediante la llamada multiplicidad. Cuando la multiplicidad de un rol es mayor que 1, el conjunto de elementos que se relacionan puede estar ordenado. Las relaciones de asociacin permiten especificar qu objetos van a estar asociados con otro objeto mediante un calificador. El calificador es un atributo o conjunto de atributos de una asociacin que determina los valores que indican cuales son los valores que se asociarn. Una asociacin se dirige desde una clase a otra (o un objeto a otro), el concepto de navegabilidad se refiere al sentido en el que se recorre la asociacin. Existe una forma especial de asociacin, la agregacin, que especifica una relacin entre las clases donde el llamado "agregado" indica l todo y el "componente" es una parte del mismo. Composicin: Es un tipo de agregacin donde la relacin de posesin es tan fuerte como para marcar otro tipo de relacin. Las clases en UML tienen un tiempo de vida determinado, en las relaciones de composicin, el tiempo de vida de la clase que es parte del todo (o agregado) viene determinado por el tiempo de vida de la clase que representa el todo, por tanto es equivalente a un atributo, aunque no lo es porque es una clase y puede funcionar como tal en otros casos. Generalizacin: Cuando se establece una relacin de este tipo entre dos clases, una es una Superclase y la otra es una Subclase. La subclase comparte la estructura y el comportamiento de la superclase. Puede haber ms de una clase que se comporte como subclase. Dependencia: Una relacin de dependencia se establece entre clases (u objetos) cuando un cambio en el elemento independiente del modelo puede requerir un cambio en el elemento dependiente. 6. Relacin de Refinamiento Es una relacin entre dos elementos donde uno de ellos especifica de forma completa al otro que ya ha sido especificado con cierto detalle. Nuevas caractersticas del UML Adems de los conceptos extrados de mtodos anteriores, se han aadido otros nuevos que vienen a suplir carencias antiguas de la metodologa de modelado. Estos nuevos conceptos son los siguientes:

Definicin de estereotipos: un estereotipo es una nueva clase de elemento de modelado que debe basarse en ciertas clases ya existentes en el metamodelo y constituye un mecanismo de extensin del modelo. Responsabilidades.

Mecanismos de extensibilidad: estereotipos, valores etiquetados y restricciones. Tareas y procesos. Distribucin y concurrencia (para modelar por ejemplo ActiveX/DCOM y CORBA). Patrones/Colaboraciones. Diagramas de actividad (para reingeniera de proceso de negocios) Clara separacin de tipo, clase e instancia. Refinamiento (para manejar relaciones entre niveles de abstraccin). Interfaces y componentes.

7. El Proceso de Desarrollo UML no define un proceso concreto que determine las fases de desarrollo de un sistema, las empresas pueden utilizar UML como el lenguaje para definir sus propios procesos y lo nico que tendrn en comn con otras organizaciones que utilicen UML sern los tipos de diagramas. UML es un mtodo independiente del proceso. Los procesos de desarrollo deben ser definidos dentro del contexto donde se van a implementar los sistemas. Herramientas CASE Rational Rose es la herramienta CASE que comercializan los desarrolladores de UML y que soporta de forma completa la especificacin del UML 1.1. Esta herramienta propone la utilizacin de cuatro tipos de modelo para realizar un diseo del sistema, utilizando una vista esttica y otra dinmica de los modelos del sistema, uno lgico y otro fsico. Permite crear y refinar estas vistas creando de esta forma un modelo completo que representa el dominio del problema y el sistema de software. Desarrollo Iterativo Rational Rose utiliza un proceso de desarrollo iterativo controlado (controlled iterative process development), donde el desarrollo se lleva a cabo en una secuencia de iteraciones. Cada iteracin comienza con una primera aproximacin del anlisis, diseo e implementacin para identificar los riesgos del diseo, los cuales se utilizan para conducir la iteracin, primero se identifican los riesgos y despus se prueba la aplicacin para que stos se hagan mnimos. Cuando la implementacin pasa todas las pruebas que se determinan en el proceso, sta se revisa y se aaden los elementos modificados al modelo de anlisis y diseo. Una vez que la actualizacin del modelo se ha modificado, se realiza la siguiente iteracin. Trabajo en Grupo Rose permite que haya varias personas trabajando a la vez en el proceso iterativo controlado, para ello posibilita que cada desarrollador opere en un espacio de trabajo privado que contiene el modelo completo y tenga un control exclusivo sobre la propagacin de los cambios en ese espacio de trabajo. Tambin es posible descomponer el modelo en unidades controladas e integrarlas con un sistema para realizar el control de proyectos que permite mantener la integridad de dichas unidades. Generador de Cdigo Se puede generar cdigo en distintos lenguajes de programacin a partir de un diseo en UML. Ingeniera Inversa Rational Rose proporciona mecanismos para realizar la denominada Ingeniera Inversa, es decir, a partir del cdigo de un programa, se puede obtener informacin sobre su diseo.

Lenguaje Unificado de Modelado De Wikipedia, la enciclopedia libre Saltar a: navegacin, bsqueda Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en ingls, Unified Modeling Language) es el lenguaje de modelado de sistemas de software ms conocido y utilizado en la actualidad; est respaldado por el OMG (Object Management Group). Es un lenguaje grfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estndar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programacin, esquemas de bases de datos y componentes reutilizables.

Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir mtodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que est descrito el modelo.

Se puede aplicar en el desarrollo de software entregando gran variedad de formas para dar soporte a una metodologa de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en s mismo qu metodologa o proceso usar. UML no puede compararse con la programacin estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programacin, solo se diagrama la realidad de una utilizacin en un requerimiento. Mientras que, programacin estructurada, es una forma de programar como lo es la orientacin a objetos, sin embargo, la programacin orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML slo para lenguajes orientados a objetos. UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas. ==

Contenido [ocultar]

1 Estandarizacin de UML 2 Crticas a UML 3 Historia o 3.1 Antes de UML 1.x o 3.2 UML 1.x 4 Referencias 5 Enlaces externos

[editar] Estandarizacin de UML Desde el ao 1995, UML es un estndar aprobado por la ISO como ISO/IEC 19501:2005 Information technology Open Distributed Processing Unified Modeling Language (UML) Version 1.4.2. Uno de los diagramas ms conocidos es el diagrama del tipo arcano y el del sistema fotovoltaico; el cual esta compuesto por interaciones arcaicas moderadamente complejas en talentos de ramas logisticas que abarcan el emparejamiento estatico irreversible. [editar] Crticas a UML A pesar de su status de estndar ampliamente reconocido y utilizado, UML siempre ha sido muy criticado por su carencia de una semntica precisa, lo que ha dado lugar a que la interpretacin de un modelo UML no pueda ser objetiva. Otro problema de UML es que no se presta con facilidad al diseo de sistemas distribuidos. En tales sistemas cobran importancia factores como transmisin, serializacin, persistencia, etc. UML no cuenta con maneras de describir tales factores. No se puede, por ejemplo, usar UML para sealar que un objeto es persistente o remoto, o que existe en un servidor que corre continuamente y que es compartido entre varias instancias de ejecucin del sistema analizado. Sin embargo, UML s acepta la creacin de nuestros propios componentes para este tipo de modelado.

Entorno de desarrollo integrado Herramienta CASE Tcnica de Modelado a Objetos Programacin orientada a objetos XMI, un formato estndar basado en XML para el intercambio de modelos UML. OCL, Lenguaje de especificacin para los diferentes modelos en UML.

EEYORE

Webml, Metodologa para el diseo de Sistemas de Informacin Web. Categora:Herramientas UML

[editar] Historia [editar] Antes de UML 1.x Despus de que la Rational Software Corporation contratara a James Rumbaugh de General Electric en 1994, la compa se convirti en la fuente de los dos esquemas de modelado orientado a objetos ms populares de la poca: el OMT (Object-modeling technique) de Rumbaugh, que era mejor para

anlisis orientado a objetos, y el Mtodo Booch de Grady Booch, que era mejor para el diseo orientado a objetos. Poco despus se les uni Ivar Jacobson, el creador del mtodo de ingenier de software orientado a objetos. Jacobson se uni a Rational en 1995, despus de que su compaa Objectory AB fuera comprada por Rational. Los tres metodologistas eran conocidos como los Tres Amigos, porque se sabia de sus constantes argumentos sobre las prcticas metodolgicas. En 1996 Rational concluy que la abundancia de lenguajes de modelado estaba alentando la adopcin de la tecnologa de objetos, y para orientarse hacia un mtodo unificado, encargaron a los Tres Amigos que desarrollaran un Lenguaje Unificado de Modelado abierto. Se consult con representantes de compaas competidoras en el rea de la tecnologa de objetos durante la OOPSLA '96; eligieron cajas para representar clases en lugar de la notacin de Booch que utilizaba simbolos de nubes. Bajo la direccin tcnica de los Tres Amigos fue organizado un consorcio internacional llamado UML Partners en 1996 para completar las especificaciones del Lenguaje Unificado de Modelado (UML), y para proponerlo como una respuesta al OMG RFP. El borrador de la especificacin UML 1.0 de UML Partners fue propuesto a la OMG en enero de 1997. Durante el mismo mes la UML Partners form una Fuerza de Tarea Semntica, encabezada por Cris Kobryn y administrada por Ed Eykholt, para finalizar las semnticas de la especificacin y para integrarla con otros esfuerzos de estandarizacin. El resultado de este trabajo, el UML 1.1, fue presentado ante la OMG en agosto de 1997 y adoptado por la OMG en noviembre de 1997. [editar] UML 1.x Como notacin de modelado, la influencia de la OMT domina UML (por ejemplo el uso de rectngulos para clases y objetos). Aunque se quit la notacin de "nubes" de Booch, si se adopt la capacidad de Booch para especificar detalles de diseo en los niveles inferiores. La notacin de Casos de Uso del Objectory y la notacin de componentes de Booch fueron integrados al resto de la notacin, pero la integracin semntica era relativamente dbil en UML 1.1, y no se arregl realmente hasta la revisin mayor de UML 2.0. Conceptos de muchos otros mtodos OO fueron integrados superficialmente en UML con el propsito de hacerlo compatible con todos los mtodos OO. Adems el grupo tom en cuenta muchos otros mtodos de la poca, con el objetivo de asegurar amplia cobertura en el dominio de los sistemas en tiempo real. Como resultado, UML es til en una variedad de problemas de ingeniera, desde procesos sencillos y aplicaciones de un slo usuario a sistemas concurrentes y distribuidos.

RMM (Metodologa de Administracin de Relaciones) - RMDM (Modelo de Datos de Administracin de Relaciones) La RMM o Relationship Management Methodology se define como un proceso de anlisis, diseo y desarrollo de aplicaciones hipermedia. Los elementos principales de este mtodo son el modelo E-R (Entidad-Relacin) y el modelo RMDM (Relationship Management Data Model) basado en el modelo HDM. La metodologa fue creada por Isakowitz, Stohr y Balasubramanian. Esta metodologa es apropiada para dominios con estructuras regulares (es decir, con clases de objetos bien definidas, y con claras relaciones entre esas clases). Por ejemplo, catlogos o "frentes" de bases de datos tradicionales. Segn sus autores, est orientada a problemas con datos dinmicos que cambian con mucha frecuencia, ms que a entornos estticos. El modelo propone un lenguaje que permite describir los objetos del dominio, sus interrelaciones y los mecanismos de navegacin hipermedia de la aplicacin. Los objetos del dominio se definen con la ayuda de entidades, atributos y relaciones asociativas. El modelo introduce el concepto de slice (trozo) con el fin de modelizar los aspectos unidos a la presentacin de las entidades. Un slice corresponde a un subconjunto de atributos de una misma entidad destinados a ser presentados de forma agrupada. La navegacin se modeliza con la ayuda de primitivas de acceso, enlaces estructurales (unidireccional y bidireccional) que permiten especificar la navegacin entre slices, y visita guiada condicional, ndice condicional y agrupacin, que permiten especificar la navegacin entre entidades. El esquema completo del dominio y de la navegacin de la aplicacin se denomina esquema RMDM y se obtiene como resultado de las tres primeras etapas del mtodo. Las etapas son:

Primera etapa: representar los objetos del dominio con la ayuda del modelo Entidad-Relacin ampliado con relaciones asociativas (aqullas que permiten representar caminos navegacionales entre entidades puestos en evidencia en la fase de anlisis). Segunda etapa: determinar la presentacin del contenido de las entidades de la aplicacin as como su modo de acceso. El esquema obtenido como resultado de esta etapa se denomina esquema E.R+. Se trata de un esquema Entidad-Relacin en el

que cada entidad ha sido reemplazada por su esquema de entidad. Un esquema de entidad est constituido por nodos (los trozos o slides) unidos por relaciones estructurales. Tercera etapa: definir los caminos de navegacin inducidos por las relaciones asociativas del esquema E-R+. A continuacin, es posible definir estructuras de acceso de alto nivel (agrupaciones), lo que permite dotar a la aplicacin de accesos jerrquicos a niveles diferentes de los trozos de informacin. El esquema RMDM resultante se obtiene aadiendo al esquema E-R+ las agrupaciones y caminos navegacionales definidos en esta etapa.

Las cuatro etapas restantes consisten en:

definicin del protocolo de conversin de elementos del diagrama RMDM en objetos de la plataforma de desarrollo concepcin del interfaz usuario concepcin del comportamiento en ejecucin construccin del sistema y test

Muestra de un diagrama entidad-relacin (las entidades se representan con un recuadro y las relaciones mediante un smbolo en forma de tridente) Veamos con ms detalle algunos ejemplos del modelo de datos RMDM (Relationship Management Data Model), que se genera a partir de un diagrama entidad-relacin. Con l se describir no slo la informacin referente a las clases de objetos, sino tambin a la navegacin entre ellos. As, hay definidas unas primitivas para modelar los dominios o datos (clases de objetos) y otras para el acceso a tales objetos. De entre las primeras, la ms tpica es la entidad (se representa mediante un recuadro y su nombre). Como en la teora relacional una entidad est compuesta por varios atributos. Adems, en RMDM se incorpora una nueva primitiva denominada "slice", que define conjuntos de atributos de una entidad que se agrupan de forma lgica. La figura de la izquierda muestra las principales primitivas y la figura de la derecha es un diagrama RMDM. Estos diagramas especifican la navegacin en el sistema:

De acuerdo con HDM, RMM define correspondencias tipo. Propone el modelo Entidad-Relacin para especificar el dominio y lo enriquece introduciendo los conceptos de slice ( trozo) y de relacin estructural para los cuales se preestablece una metfora hipermedia. Los slices y las entidades se asocian con nodos y las relaciones asociativas (entre entidades) y las relaciones estructurales (entre trozos) se asocian con enlaces. El modelo del dominio se enriquece, por lo tanto, con dos tipos de elementos preestablecidos que tienen una correspondencia clara en trminos hipermedia. En RMM, el modelo hipermedia retoma los elementos enlace, ndice y visitas guiadas de HDM enriquecindolos con capacidades condicionales. Sin embargo, el mtodo no permite al diseador definir elementos hipermedia propios que tengan capacidades especficas ya que impone la utilizacin de metforas preestablecidas. Ante las limitaciones que ofreca RMM, sus autores Balasubramanian, Bieber e Isakowitz, analizaron la estructura de navegacin en RMM y propusieron aadir 2 nuevos tipos de slices: los slices hbridos (que permiten combinar atributos de diferentes entidades y estructuras

de acceso), los slices mnimos (la mnima parte de una entidad que es necesaria para identificar uno de sus elementos y que se utilizar como ancla) y los m-slices (que permiten combinar primitivas de acceso con otros slices de otras entidades para crear un m-slice). Se propone crear la estructura de la navegacin no en base a las entidades sino a los slices, es decir a conjuntos de atributos. A partir de las carencias de RMM e incorporando la novedad de los slices mnimos e hbridos, Lopistguy, Losada y Dagorret analizan el modelo RMM y encuentran algunas carencias, por lo que proponen la creacin de unas nuevas estructuras de navegacin que doten de una mayor flexibilidad al modelo RMM, a la vez que crean unas serie de primitivas de acceso nuevas. Estas son las estructuras que introducen:

navegacin jerrquica: al tener varias relaciones 1:N encadenadas, se permite navegar desde cualquier entidad a otra que est por debajo de ella en la jerarqua. Estos enlaces inferidos, no extrados directamente de una relacin 1:N, se representarn con trazo discontinuo. navegacin en relaciones N:M: se permite navegar de un extremo al otro de la relacin, pero teniendo en cuenta la entidad intermedia, cuyos atributos debern incluirse en un slice hbrido. Para representar un enlace de este tipo, uniremos la primitiva de acceso (ndice, visita guiada, ...) con la entidad intermedia. navegacin mltiple: se crean unas nuevas primitivas que permiten el acceso mltiple de una entidad a otra, seleccionando un elemento de una tercera entidad de la que la entidad destino es parte. En el enlace quedar especificado qu entidad es la origen, cul la destino y cul la tercera. Recordar que esta navegacin es especialmente apropiada en estructuras todo-parte. acceso aleatorio: permite acceder a un elemento de forma aleatoria, sin saber exactamente a cul. acceso simultneo: permite representar el acceso a todos los elementos de una entidad a la vez. Por ejemplo, si estamos en un Seminario, con esta primitiva accedemos a todos sus ponentes simultneamente, todos a la vez, y no mediante un ndice o uno tras otro en una visita guiada

Y as quedar la lista de primitivas con la inclusin de las nuevas primitivas de acceso:

La metodologa RMM permite hacer explcita la navegacin al hacer el anlisis, lo que permite, tericamente, obtener una navegacin ms estructurada e intuitiva, y lo hace de una forma muy sencilla, como es aadir unas primitivas a un modelo entidad-relacin tradicional. El concepto de slice es muy til, ya que permite agrupar datos de una entidad en diferentes pantallas. Se utilizara, por ejemplo, para mostrar dos vdeos en dos pantallas diferentes sobre un mismo fenmeno. Tambin es interesante la primitiva de grupo, que permite mostrar la jerarqua de mens. RMM representa el primer caso en el que se crea una metodologa completa definiendo las distintas fases y no nicamente un modelo de datos. Adems, se basa en un modelo de datos relacional, ajustndose as a la gran mayora de las aplicaciones existentes. Sin embargo, los mecanismos de acceso a la informacin son excesivamente simples y valen para un problema con pocas entidades, pero el modelo se queda corto si hay gran nmero de ellas.

Diagrama Entidad-Relacin

Jerarqua de mens con detalle

Para ver un ejemplo de diseo hipermedia usando la metodologa RMM, es decir, siguiendo el modelo RMDM, se puede consultar: Antonio Navarrete Terrasa: "Una metodologa relacional hipermedia. Estudio de casos prcticos. CD-ROM del Parc Natural de S'albufera". http://www.iua.upf.es/~jblat/material/albu/albu.pdf, de donde se han extrado muchos de los ejemplos aqu expuestos.

Diagrama RMDM