ANÁLISIS ESTRUCTURADO ESTRUCTURADO de Sistema. Sistema. Conceptos generales
Cuando los analistas comienzan a trabajar sobre un proyecto de sistemas de información, a menudo tienen que profundizar en un área de la organización 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, resultado, se espera que los analistas de sistemas hagan lo siguiente:
aprendan los detalles y pro cedimientos del sistema en uso. Obtengan una idea de las demandas futuras de la organización como resultado del crecimiento, del aumento de la competencia en el mercado, de los cambios en las necesidades de los consumidores, de la evolución de las estructuras financieras, de la introducción de la nueva tecnología y cambios en las políticas del gobierno entre otros. Documentar detalles del sistema actual actual para su revisión y discusión por po r 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 participación de gerentes y empleados en todo el proceso, tanto para aprovechar su experiencia y conocimiento del sistema actual, como como para conocer sus ideas, sentimientos y opiniones relacionadas con los requerimientos de un nuevo sistema o d e los cambios para la cual.
¿ Qué es el análisis estructurado?
El análisis estructurado es un método para el análisis de sistemas manuales o automatizados, que conduce al desarrollo de especificaciones especificaciones para sistemas nuevos o para efectuar modificaciones a los ya existentes. Cuando los analistas de sistemas abordan una situación poco familiar, siempre existe una pregunta sobre donde comenzar el análisis. Una situación dinámica siempre puede ser vista como abrumadora debido a que muchas de las actividades se llevan a cabo constantemente, como señalo MARY HELEN es su seminario. El análisis estructurado permite el analista conocer un sistema o proceso (actividad) en una forma lógica y manejable el mismo tiempo que proporciona la base para asegurar que no se omite ningún detalle pertinente. p ertinente. Sisgnificado de estructurado
¿qué es lo que desea estructurar? ¿ que significa estructurar? El objetivo que persigue el análisis estructurado es organizar las tareas asociada con la determinación de requerimientos para obtener la comprensión completa y exacta de una situación dada. A partir de aquí determina los requerimientos que serán la base de un sistema nuevo o modificado. En el análisis estructurado la palabra estructura significa qué: 1) el método intenta estructurar el proceso de determinación de los requerimientos comenzando con la documentación del sistema existente; existente; 2) el proceso está organizado de tal forma que intenta incluir todos los detalles relevante que describe al sistema en uso; 3) es fácil verificar cuando se han o mitido detalles relevantes; relevantes; 4) la identificación 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 comunicación eficientes. Componentes del análisis estructurado
El análisis estructurado hace uso de d e los siguientes componentes. 1. 2. 3. 4.
símbolos gráficos diccionario de datos descripciones de procesos y procedimientos pro cedimientos reglas
Que es el análisis 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 d a gran importancia al análisis de los datos. Los datos son la guía d e las actividades de la empresa. Ellos pueden iniciar eventos (por ejemplo, los datos sobre nuevos ped idos) y ser procesados para dar información útil al personal que desea saber qué también se han manejado los eventos (al medir la calidad y tasa de trabajo, rentabilidad, etc.). el análisis de sistemas conoce el papel central que tienen los datos de la empresa en las organizaciones. Seguir el flujo de dat os por todos los procesos de la empresa, que es la finalidad del análisis de flujo de datos, les dice mucho a los analistas sobre como se alcanza los objetivos de la organización. En el transcurso del manejo de transacciones y terminación de tareas los datos entran, son procesados, almacenados, recuperados, analizados, utilizados, cambiados y presentados como salidas. El análisis 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 for ma gráfica la relación entre procesos y datos, en los d iccionarios 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 análisis de flujo de datos examina el empleo de los datos para llevar a cabo procesos específicos de la empresa dentro del ámbito de una investigación de sistemas. El análisis puede pensarse de tal manera que se estudia actividades del sistema desde el punto de vista de los d atos: donde se originan, como se utilizan o cambian, hacia donde van, incluyendo las paradas a los largo d el camino que siguen desde sus origen hasta sus d estino. Los componentes de la estrategia de flujo de datos abarcan tanto la determinación de los requerimientos como el diseño de sis temas. Una notación bien establecida facilita facilita la documentación del sistemas actual y su análisis por todos los participantes en el proceso de determinación de requerimientos. Herramientas de la estrategia de flujo de datos
La estrategia de flujo de datos muestra el empleo de estos en forma gráfica. Las herramientas utilizadas al seguir esta estrategia muestran todas las características características esenciales del sistema y la forma en que se ajustan entre sí. Puede ser difícil comprender en su totalidad un proceso de la empresa si se emplea para ello una descripción verbal; Las herramientas para el flujo de datos ayuda a mostrar los componentes esenciales de u n sistema junto con sus interacciones. El análisis de flujo de datos utiliza la sguie. Herramientas. 1.
Diagrama de flujo de datos
Una herramienta gráfica se emplea para describir y analizar el movimiento de datos a través de un sistema, ya sea que este fu era manual o automatizado, incluyendo procesos, lugares para almacenar datos y retrasos en el sistema. Estos diagramas reciben el nombre de diagramas lógicos de flujo d e datos 2.
Diccionario de datos
el diccionario contiene las características lógicas de los sitios donde se almacenan los datos del sistema, incluyendo nombre, descripción, alias, contenidos y organización. También identifica los procesos donde se emplea los datos y los sitios de donde se necesitan el acceso inmediato a la información. Sirve como puerto de partida para identificar los requerimientos de las bases de datos durante el diseño d el sistema. 3.
Diagrama de estructura de datos
Este diagrama es una descripción de la relación entre entidades (personas, lugares, eventos y objetos) de un sistema y el conjunto de información relacionada con la entidad. No considera el almacenamiento físico de los datos. 4.
gráfica de estructura
Herramienta de diseño que muestra con símbolos la relación entre los módulos d e procesamiento y el software de la computadora describe la jerarquía de los módulos componentes y los datos que q ue serán transmitidos entre ellos. Incluye el análisis de las transformaciones transformaciones entrada - salida y el análisis de transacción. DESARROLLO DE DIARAMAS DE FLUJO DE DATOS Para que de utilidad y proporcionan información los diagramas de flujo de datos deben dibujarse en forma adecuada. Esta sección muestra como dibujarlos: donde comenzar, como añadir detalles a las descripciones, cuando incorporar la información sobre el control y como mantener la consistencia al asignar los nombre s de los objetos incluidos en los diagramas. La presentación señala también errores comunes que deben evitarse. Diagramas físicos de flujo de datos
Los diagramas de flujo de datos son de dos tipos:
Diagramas físicos de datos
Proporciona un panorama del sistema en uso, que es dependiente de la implantación, que muestra qué tareas se llevan a cabo y cómo. Las características características físicas incluyen: Nombres de personas Nombre de números de formatos y documentos d ocumentos Nombres de departamentos Archivos maestros y de transacciones Equipo y dispositivos utilizados
Ubicaciones Nombre de procedimientos
Diagramas lógicos de flujo de datos
Proporcionan un panorama del sistema independiente de la implantación, que se centra en el flujo de d atos entre los procesos sin considerar los dispositivos específicos y la localización de almacenes de datos o personas en el sistema. En este tipo de diagramas no se in dican las características físicas, lo cual si sucede con los diagramas físicos de flujo. El enfoque más amplio y útil para desarrollar una descripción exacta y completa del sistema en uso, comienza con el desarroll o del diagrama físico de flujo de datos. El empleo de estos diagramas es deseable por tres razones. Pr imera, es común que los analistas de sistemas encuentren mucho más fácil describir la interacción entre los componentes físicos q ue comprender las políticas empleadas para administrar la aplicación. Segunda, los diagramas físicos 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 días con cada entidad. (Es usual que los analistas de sistemas encuentren que los usuarios consideran "abstractos" los diagramas lógicos de flujo de datos porque no contienen componentes que les sean familiares.) Tercera, los diagramas físicos 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 razón por la que se propone un nuevo sistema. Dibujo de diagramas físicos de flujo
La siguiente descripción sobre la forma como maneja una compañía 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 características generales del proceso bajo investigación. Para decirlo de algún modo, primero se estudian los detalles de la capa superior. Conforme los analistas comprenden mejor los detalles, ahondan con mayor profundidad para recopilar información más precisa y destellada. Cada vez se formulan preguntas más especificas utilizando para ello el análisis descendente (top-down). A menudo el diagrama de alto nivel se denomina diagrama de contexto. Contiene un solo proceso pero juega un papel muy importa nte 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 l os que no se encuentre dentro de las fronteras identificadas en el diagrama de contexto del proceso no forma parte del estudio d e sistemas. La forma en que funcionan las otras organizaciones o elementos externos (las fuentes y destinos) no está fuera de nuestro control y n o 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 están fuera de él. Desarrollo de gráficas de procesos
Un sistema está formado por varias actividades o procesos. Usted ha aprendido en forma gradual aspectos pertinentes a la relación entre procesos; también ha descubierto que un proceso contiene varios pasos (p rocesos en pequeña escala). El la programación de computadoras, los programadores con frecuencia desarrollan el software como una colección de módulos independientes pero que interactuan entre sí. A menudo estos módulos se muestran en los diagramas de jerarquía. Estos diagramas son similares a los desaprobadores por los pro gramadores. ///////////////////////////////////////////////////////////////////////////////////////////////////// Panorama.
El desarrollo de sistemas esta formado por dos componentes: El Análisis de sistemas y el D iseño de sistemas. Diseño de sistemas. Es el proceso de planificar, reemplazar o complementar un sistema existente. Pero es necesario co mprender el viejo. Utilizar l as compu para hacer el trabajo mas eficiente.
Análisis de sistemas. Es el proceso de clasificacion e interpretació n de hechos, diagnostico de problemas y empleo de la información para recomendar mejoras al sistema. Cual es el flujo de información en todo el sistema.
Estudio del sistema. Esta acumulación de información es la que precede a todas las demas actividades del análisis. El plan. Incluye. Características del diseño del sistema, necesidades de captura de nuevos datos, especificaciones de archivo, procedi mientos de operación y necesidades de equepo y y personal. El diseño. Especifica las características 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 organización trabaje. Comunicación. Importancia del Análisis de Sistemas. Solo después 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 diseñar 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 fo rmularios, contenido de ficheros, información utilizada por l os usuarios entrada y salida. Satisfacer a todos dentro de las reglas de dirección. Diagramas de Flujo de Datos. Tienen la misión 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. Señalar los almacenes de datos a los que se t iene acceso.
Descripción Descendente TOP DOWN, Diccionario de datos. Se definen flujo de datos, procesos y almacenes de datos. Diseño Estructurado. Es la especificación 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
español e inglés) es una representación gráfica para la maceta del "flujo" de datos a través de un sistema de información. Un diagrama de flujo de datos también se puede utilizar para la visualización de procesamiento de datos (diseño estructurado). Es una práctica común para un diseñador dibujar un contexto a nivel de DFD que p rimero muestra la interacción entre el sistema y las entidades externas. Este contexto a nivel de DFD se "explotó" p ara mostrar más detalles del sistema que se está modelando. Los diagramas de flujo de datos fueron inventados por Larry Constantine, el desarrollador original del diseño estructurado, basado en el modelo de computación de Martin y Estrin: "flujo gráfico de datos" . Los diagramas de flujo de datos (DFD) son una de las tres perspectivas esenciales de Análisis de Sistemas Estructurados y Diseño por Método SSADM. El patrocinador de un proyecto y los usuarios finales tendrán que ser informados y consultados en todas las etapas de una evolución 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 cómo el sistema se pondrá en práctica.
DIRECCIONARIO DE DATOS
Un diccionario de datos es un conjunto de metadatos que contiene las características lógicas de los datos que se van a utilizar en el sistema que se programa, incluyendo nombre, descripción, alias, contenido y organización. Estos diccionarios se desarrollan durante el análisis de flujo de datos y ayuda a los analistas que participan en la determinación de los requerimientos del sistema, su contenido también se emplea durante el diseño 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 descripción de todos estos elementos. Ejemplos Nombre = Título + Primer-nombre + Apellido-paterno + Apellido-materno Título = [ Sr | Sra | Dr | Ing] Primer-nombre = {caracter} Apellido-paterno = {caracter} Apellido-materno = {caracter} caracter = [A-Z|a- z| |’] a Descripción de un proceso
De algún modo, debemos hacer una pregunta fundamental: ¿cuál es la manifestación física de un proceso? Como mínimo debe inclu ir 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. Además, en la ejecución de un programa entra en juego normalmente una pila, que se utiliza para llevar la cuenta de las llamadas a procedimientos y de los parámetros 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 colección de programa, datos, pila y atributos se le llama imagen o entorno del proceso. Herramientas Case
De acuerdo con Kendall y Kendall la ingeniería de sistemas asistida por ordenador es la aplicación de tecnología informática a las actividades, las técnicas y las metodologías propias de desarrollo, su objetivo es acelerar el proceso para el que han sido d iseñadas, 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 planificación de la base de datos, la primera etapa del ciclo de vida de las aplicaciones de bases de datos, también se puede escoger una herramienta CASE (Computer-Aided Software Engineering) que permita llevar a cabo el resto de tareas del modo más eficiente y efectivo posible. Una herramienta CASE suele incluir:
Un diccionario de datos para almacenar información sobre los datos de la aplicación de bases de datos. Herramientas de diseño para dar apoyo al análisis de datos. Herramientas que permitan desarrollar el modelo de datos corporativo, así como los esquemas conceptual y lógico. Herramientas para desarrollar los prototipos de las aplicaciones.
El uso de las herramientas CASE puede mejorar la productividad en el desarrollo de una aplicación de bases de datos. Estructura general de una herramienta case
La estructura CASE se basa en la siguiente terminología:
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 planificación de sistemas, el análisis de sistemas y el diseño de sistemas. CASE de bajo nivel son aquellas herramientas que automatizan o apoyan las fases finales o inferiores del ciclo de vida como el diseño detallado de sistemas, la implantación de sistemas y el sop orte 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 gestión de proyectos y la estimación.
Sintaxis del Pseudocódigo CEE (C En Español)
Inicio > Sintaxis del Pseudocódigo CEE > Estructura de un Algoritmo Estructura de un algoritmo
La sintaxis para escribir un algoritmo en pseudocódigo 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 u n óvalo de la siguiente manera:
Por medio de las flechas se indica el orden de las acciones (instrucciones) del algoritmo. (Véase el apartado 8.3 Inicio y fin del Curso de Diseño de Algoritmos). MODELO DE DATOS
Un modelo de datos es un lenguaje orientado a describir una Base de Datos. Típicamente 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 manipulación de los datos: típicamente, operaciones de agregado, borrado, modificación y recuperación 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 for ma 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.
Metodología OMT. La metodología de modelado de objetos OMT (object Modeling Technique) descrito por [Rumbaugh].
Modelo: Del modelo espiral o un proceso evolutivo con una separación no rígida entre las fases del desarrollo.
Enfasis:
En el análisis no en la implementación, En los datos mas que en las funciones lo que da es tabilidad al proceso de desarrollo. Notación común a todas las fases a través de tres modelos que capturan los aspectos estáticos, dinámicos y funcionales que combinados proveen una descripción completa del s oftware.
Fases de la metodología OMT: Análisis Su objetivo es desarrollar un modelo de lo que va a hacer el sistema. El modelo se expresa en términos de objetos y de relaciones entre ellos, flujo dinámico de control y las transformaciones funcionales.
Los pasos a seguir en el análisis son: 1.
Se escribe u obtiene una descripción 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.
1.
Se construye el modelo de objetos y sus relaciones.
Su objetivo es describir la es tructura estática del software.
Se abstraen los conceptos de los datos que son mas importantes para la aplicación. Se describen gráficamente 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
o o
Se seleccionan los sustantivos de la d escripción del problema como posibles clases candidatas. Se construye una lista. Se eliminan las clases r edundantes, irrelevantes o vagas o bien por ser atributos, operaciones o construcciones de implementación. Las clases se representan por rec tángulos 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 métodos.
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 asociación es una dependencia entre dos o más clases. Las asociaciones, se representan por líneas que unen a las clases sobre las cuales se puede escribir el nombre de la asociación.
A estos diagramas se les agrega la multiplicidad correcta. Puede ser "uno a uno"; "uno a muchos" representada por un a bolita rellena del lado de los "muchos"; o "muchos a muchos" representada por bolitas rellenas a amb os extremos de la línea.
También se puede representar la relación " es parte de" o agregación que indica que el objeto está compuesto por objetos de las clases asociadas. Se denota un pequeño 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 c lases existentes construyendo una superclase, o para refinar una clase en subclases especializadas. La notación de OMT para la herencia es un triángulo 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 revisión verificando que estén representadas todas las relaciones siguiéndolo 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 + dic cionario de datos 1.
Se desarrolla el modelo dinámico. 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 u n estímulo llamado evento.
Un diagrama de estados es una gráfica de estados representados por círculos y eventos representados por flechas. Los pasos que se siguen en el modelo dinámico son: 1. 2. 3. 4.
Preparar escenarios de una interacción típica. 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 dinámico es:
Modelo dinámico = diagramas de estados + diagrama global de trazado de eventos 1.
Se construye el modelo funcional. Especifica el significado de las operaciones o métodos en el modelo de objetos y de las acciones en el modelo dinámico. 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 análisis contiene:
Documento de análisis = definición del problema + modelo de objetos + modelo dinámico + modelo funcional. Diseño del sistema Se define la arquitectura del sistema y se toman las decisiones estratégicas. Los pasos que se llevan acabo son: 1.
Se organiza el sistema en subsistemas. Cada subsistema comparte alguna propiedad en común. Las relaciones entre los subsistemas pueden ser: cliente – servidor o punto a punto . La descomposición 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 dinámico 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 comunicación de los procesadores.
4. 5.
Se selecciona la estrategia para implementar y administrar los almacenes de datos(archivos o bases de datos). Selección de la implementación del control del software. Existen dos tipos de control:
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
1.
Se consideran las condiciones de contorno.
Se trata de considerar como se hace la iniciación, terminación y como responderá a las fallas. 2.
Se establecen prioridades de c ompensación.
El documento que nos proporciona el diseño del sistema es:
Documento de diseño del sistema = est ructura de la arquitectura básica del sistema + decisiones estratégicas de alto nivel.
Diseño de objetos Su objetivo es refinar el modelo d el análisis y proporcionar una base detallada para la implementación tomando en cuenta el a mbiente en que se implementará. Los pasos que se realizan en el diseño de objetos son los siguientes: 1.
Se refinan las operaciones para el modelo de objetos a partir de los demás modelos:
o o 1. 2. 3.
Se busca una operación para c ada proceso del modelo funcional. Se define una operación para cada suceso del modelo dinámico.
Se diseñan algoritmos para implementar las operaciones y las estructuras de datos Se optimizan las vías de acceso a los datos. Se implementa el control del software completando la aproximación propuesta en el diseño del sistema. Existen tres estrategias básicas para implementar el control: 1. 2. 3.
1. 2.
Construir un sistema controlado por procedimientos. Crear un motor de máquina 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)
Se ajusta la estructura de clases incrementando la herencia. Se diseña la implementación de l as asociaciones. Las asociaciones conforman el pegamento en el modelo de objetos y proporcionan las vías de acceso entre los objetos. La implementación se hace dependiendo del tipo de aso ciación:
o
Asociaciones unarias. Estas asociaciones se establecen solamente en una sola dirección 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 i mplementar de diferentes maneras:
1. 2. 3.
Atributos en una dirección. Como atributos en ambas direcciones. Implementar como un objeto separado por medio de diccionarios.
o
1. 2.
Se determina la representación exacta de los atributos de l os objetos. Se empaquetan las clases y las asociaciones en módulos. El empaquetamiento implica: Ocultar la información interna a los ojos externos (construir cajas negras con interfaces claras). Determinar la coherencia de entidades, es decir, que c ada clase o módulo debe de hacer una cosa y bien. Construcción de los módulos. Cada módulo debe d e tener una cohesión funcional, esto es, un propósito bien definido.
El documento que se genera el diseño de objetos es:
Documento de diseño de objetos = modelo de objetos detallado + modelo dinámico detall ado + modelo funcional detallado. Ejemplo de la metodología OMT Descripción del problema El problema consiste en crear u n sistema computarizado de registro de calificaciones para una liga infantil de nado sincronizado. Los niños participan en dos clases de eventos llamados: figuras y rutinas. Las figuras, se ejecutan de manera individual y son maniobras de ballet acuático tales como nadar sobre la espalda con una pierna levantada recta. Las rutinas se realizan por el equipo completo y son un ballet acuático, El sistema sólo tiene que tomar en cuenta las figuras. Durante el encuentro, los eventos de figura s e llevan simultáneamente en varias estaciones situadas alrededor de la alberca, usualmente en cada esquina. En una estación 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 estación durante el encuentro. Cada juez indica la calificación para cada prueba observada mostrandoi unas tarjetas numeradas. Las calificaciones son leídas por los anotadores que las registran y calculan la calificación neta para cada prueba. La calificación más alta y más baja se eliminan por el grado de dificultad de la figura. Lista de candidatos a objetos Sistema computarizado rergistro Calificación atr. liga infantil de nado Niño evento Figura rutina Ballet acuático espalda Pierna equipo Encuentro estación 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 cali ficación final de cada competidor. Concursante: es un niño que participa en la competencia. Equipo: es un conjunto de niños que participan en una competencia. Todos los participantes es un equipo rea lizan juntos el ballet ac uático. Estación: es el lugar donde s e lleva a cabo un evento de competencia. Hay varias estaciones simultáneas, usualmente es las es quinas de la alberca. En una estación 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 q ue se compite individualmente, es una maniobra de ballet acuático como nadar de espalda con una pierna levantada. Juez: persona que asigana una calificación a cada competidor para cada p rueba. Varios jueces se asignan a una e stación. Una figura es calificada por los mismos jueces. Rutina: es otro tipo de evento, se compite en equipos completos realizando un ballet acuático.
Ingenieria de SoftwareUML Enviado por gmoreno
Ingenieria de SoftwareUML
Indice 1. Introducción 2. Modelado de objetos 3. Artefactos para el Desarrollo de Proyectos 4. Diagramas de componentes 5. Diagramas de Clases 6. Relación de Refinamiento 7. El Proceso de Desarrollo Para ver la versón en Power point, haga clik en el menú superior "Bajar trabajo" 1. Introducción
Unified Modeling Languaje UML [UML] es un lenguaje para especificar, construir, visualizar y documentar los artefactos de u n sistema de software orientado a objetos (OO). Un artefacto es una información que es utilizada o producida mediante un proceso de desarrollo de software. UML se quiere convertir en un lenguaje estándar 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 estándar de desarrollo, sino únicamente un lenguaje de modelado. Otros métodos de modelaje como OMT (Object Modeling Technique) o Booch sí definen procesos concretos. En UML los procesos de desarrollo son diferentes según los distintos dominios de trabajo; no puede ser el mismo el proceso para crear una aplicación en tiempo real, que el proceso de desarrollo de una aplicación orientada a gestión, por poner un ejemplo. Las diferencias son muy marcadas y afectan a todas las faces del proceso. El método del UML recomienda utilizar los pro cesos que otras metodologías tienen definidos. Los Inicios A partir del año 1994, Grady Booch [Booch96](precursor de Booch '93) y Jim Rumbaugh (creador de OMT) se unen en una empresa común, Rational Software Corporation, y comienzan a unificar sus dos métodos. Un año más tarde, en octubre de 1995, aparece UML (Unified Modeling Language) 0.8, la que se considera como la primera versión del UML. A finales de ese mismo año, Ivan Jacobson, creador de OOSE (Object Oriented Software Engineer) se añade al grupo. Como objetivos principales de la consecución de un nuevo método que aunara los mejores aspectos de sus predecesores, sus protagonistas se propusieron lo siguiente:
El método debía ser capaz de modelar no sólo sistemas de software sino otro tipo de sistemas reales de la empresa, siempre utilizando los conceptos de la orientación a objetos (OO). Crear un lenguaje para modelado utilizable a la vez por máquinas y por personas. Establecer un acoplamiento explícito de los conceptos y los artefactos ejecutables. Manejar los problemas típicos de los sistemas complejos de misión crítica.
Lo que se intenta es lograr con esto que los lenguajes que se aplican siguiendo los métodos más utilizados sigan evolucionando en conjunto y n o por separado. Y además, unificar las perspectivas entre diferentes tipos de sistemas (no sólo software, sino también en el ámbito de lo s negocios), al aclarar las fases de desarrollo, los requerimientos de análisis, el diseño, la implementación y los conceptos internos de la OO. 2. Modelado de objetos
En la especificación 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 abstracción cerrada semánticamente de un sistema y un sistema es una colección de unidades conectadas que son organizadas para realizar un propósito específico. Un sistema puede ser descripto por u no o más modelos, posiblemente desde distintos puntos de vista. Una parte del UML define, entonces, una abstracción 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 propósito). 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 sólo establecer una forma de modelo, de esta forma simplemente estamos diciendo que UML, además, define un lenguaje con el que podemos abstraer cualquier tipo de modelo. El UML es una técnica de modelado de objetos y como tal supone una abstracción de un sistema para llegar a construirlo en tér minos concretos. El modelado no es más que la construcción de un modelo a partir de una especificación.
Un modelo es una abstracción de algo, que se elabora para comprender ese algo antes de construirlo. El modelo omite detalles que no resultan esenciales para la comprensión del original y por lo tanto facilita dicha comprensión. Los modelos se utilizan en muchas actividades de la vida humana: antes de construir una casa el arquitecto utiliza un plano, los músicos representan la música 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 estática; el modelo dinámico, 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 construcción de modelos, se consigue una abstracción de la realidad que tiene en sí misma información sobre las principales características de ésta. Los modelos además, al no ser una representación que incluya todos los detalles de los originales, permiten probar más fácilmente los sistemas que modelan y determinar los errores. Según se indica en la Metodología OMT (Rumbaugh), los modelos permiten una mejor comunicación con el cliente por distintas razones:
Es posible enseñar al cliente una posible aproximación de lo que será el producto final. Proporcionan una primera aproximación al problema que permite visualizar cómo quedará el resultado. Reducen la complejidad del original en subconjuntos que son fácilmente 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 programación que estamos acostumbrados a utilizar no son adecuados para realizar modelos completos de sistemas reales porque necesitan una especificación total con detalles que no son importantes para el algoritmo que están implementando. En OMT se modela un sistema desde tres puntos de vista diferentes donde cada uno representa una parte del sistema y una u nión lo describe de forma completa. En esta técnica de modelado se utilizó una aproximación al proceso de implementación 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 dinámico) y se realiza una transformación sobre sus valores (mod elo 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 creación del UML se persigue obtener un lenguaje que sea capaz de abstraer cualquier tipo de sistema, sea informático o no, mediante los diagramas, es decir, mediante representaciones gráficas que contienen toda la información relevante del sistema. Un diagrama es una representación gráfica de una colección de elementos del modelo, que habitualmente toma forma de grafo donde los arcos que conectan sus vértices son las relaciones entre los objetos y los vértices 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 q ue se resaltan los detalles necesarios para entender el sistema. 3. Artefactos para el Desarrollo de Proyectos
Un artefacto es una información que es utilizada o pro ducida mediante un proceso de desarrollo de software. Pueden ser artefactos un modelo, una descripción o un software. Los artefactos de UML se especifican en forma de d iagramas, éstos, junto con la documentación sobre el sistema constituyen los artefactos principales que el modelador puede observar. Se necesita más de un punto de vista para llegar a representar un sistema. UML utiliza los diagramas gráficos para obtener estos distintos puntos de vista de un sistema:
Diagramas de Implementación. Diagramas de Comportamiento o Interacción. Diagramas de Casos de uso. Diagramas de Clases.
Ejemplo de algunos de los diagramas que utiliza UML. Diagramas de Implementación Se derivan de los diagramas de proceso y módulos de la metodología de Booch, aunque presentan algunas modificaciones. Los diagramas de implementación muestran los aspectos físicos del sistema. Incluyen la estructura del código fuente y la implementación, en tiempo d e implementación. 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 código fuente, binario y ejecutable. Un componente es un fragmento de código software (un fuente, binario o ejecutable) que se utiliza para mostrar dependencias en tiempo de compilación. Diagrama de plataformas o despliegue Muestra la configuración de los componentes hardware, los procesos, los elementos de procesamiento en tiempo de ejecución y los objetos qu e existen en tiempo de ejecución. En este tipo de diagramas intervienen nodos, asociaciones de comunicación, componentes dentro de los nodos y objetos que se encuentran a su vez dentro de los componentes. Un nodo es un objeto físico en tiempo de ejecución, es decir una máquina que se compone habitualmente de, por lo menos, memoria y capacidad de procesamiento, a su vez puede estar formado por o tros componentes.
Diagramas de Interacción o Comportamiento Muestran las interacciones entre objetos ocurridas en un escenario (parte) del sistema. Hay varios tipos: Diagrama de secuencia. Diagrama de colaboración. Diagrama de estado. Diagrama de actividad. Diagrama de secuencia Muestran las interacciones entre un conjunto de objetos, ordenadas según el tiempo en que tienen lugar. En los diagramas de este tipo intervienen objetos, que tienen un significado parecido al de los ob jetos representados en los diagramas de colaboración, es decir son instancias concretas de una clase que participa en la interacción. El objeto puede existir sólo durante la ejecución de la interacción, se puede crear o puede ser destruido durante la ejecución de la interacción. Un diagrama de secuencia representa una forma de indicar el período durante el que un objeto está desarrollando una acción directamente o a través de un procedimiento. En este tipo de diagramas también intervienen los mensajes, que son la forma en que se comunican los objetos: el objeto origen solicita (llama a) una operación del objeto destino. Existen distintos tipos de mensajes según cómo se prod ucen en el tiempo: simples, síncronos, y asíncronos. Los diagrama de secuencia permiten indicar cuál es el momento en el que se envía o se completa un mensaje mediante el tiempo de transición, que se especifica en el diagrama. Diagrama de colaboración Muestra la interacción 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 información similar, pero en una forma diferente. Formando parte de los diagramas de colaboración nos encontramos con objetos, enlaces y mensajes. Un objeto es una instancia de una clase que participa como una interacción, 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 asociación que conecta dos o bjetos de un diagrama de colaboración. 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 interacción indican el flujo de mensajes entre elementos del modelo, el flujo de mensajes representa el envío de un mensaje desde u n objeto a otro si entre ellos existe un enlace. Los mensajes que se envían entre objetos pueden ser de distintos tipos, también según como se pro ducen en el tiempo; existen mensajes simples, sincrónicos, balking, timeout y asíncronos. Durante la ejecución de un diagrama de colabora ción se crean y destruyen objetos y enlaces. Diagramas de actividad Son similares a los diagramas de flujo de otras metodologías OO. En realidad se corresponden con un caso especial de los diagramas de estado donde los estados son estados de acción (estados con una acción interna y un a o más transiciones que suceden al finalizar esta acción, o lo que es lo mismo, un paso en la ejecución de lo que será un procedimiento) y las transiciones vienen provocadas por la finalización de las acciones que tienen lugar en los estados de origen. Siempre van unidos a una clase o a la implementación de un caso de uso o d e un método (que tiene el mismo significado que en cualquier otra metodología OO). Los diagramas de actividad se utilizan para mostrar el flujo de op eraciones que se desencadenan en un procedimiento interno del sistema. Diagramas de estado Representan la secuencia de estados por los que un objeto o una interacción entre objetos pasa durante su tiempo de vida en r espuesta a estímulos (eventos) recibidos. Representa lo que podemos denominar en conjunto una máquina de estados. Un estado en UML es cuando un objeto o una interacción satisface una condición, desarrolla alguna acción o se encuentra esperando un evento. Cuando un objeto o una interacción pasa de un estado a otro por la ocurrencia de un evento se dice que ha sufrido una transición, existen varios tipos de transiciones entre objetos: simples (normales y reflexivas) y complejas. Además una transición puede ser interna si el estado del que parte el objeto o interacción es el mismo que al que llega, no se provoca u n cambio de estado y se representan dentro del estado, no d e la transición. Como en todas las metodologías OO se envían mensajes, en este caso es la acción 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 interacción con los usuarios y/o otros sistemas. O lo que es igual, un diagrama que muestra la relación entre los actores y los casos de uso en un sistema. Una relación es una conexión entre los elementos del modelo, por ejemplo la relación y la generalización 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 pue de interactuar con él; un ejemplo de actor podría ser un u suario o cualquier otro sistema. Las relaciones entre casos de uso y actores p ueden 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 es táticos, 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 estáticos 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, permitiéndose que un paquete contenga otro paquete. Clases: Una clase representa un conjunto de objetos que tienen una estructura, un comportamiento y unas relaciones con propie dades parecidas. Describe un conjunto de objetos que comparte los mismos atributos, operaciones, métodos, relaciones y significado. En UML una clase es una implementación 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. Operación. También conocido como método, es un servicio proporcionado por la clase que puede ser solicitado por otras clases y qu e produce un comportamiento en ellas cuando se realiza. Las clases pueden tener varios parámetros formales, son las clases denominadas plantillas. Sus atributos y operaciones vendrán definidas según sus parámetros formales. Las plantillas pueden tener especificados los valores reales para los parámetros formales, entonces reciben el nombre de clase parametrizada instanciada. Se puede usar en cualquier lugar en el que se podría aparecer su plantilla. Relacionando con las clases nos encontramos con el término utilidad, que se corresponde con una agrupación de variables y procedimientos globales en forma de declaración de clase, también puede definirse como un estereotipo (o nueva clase generada a partir d e otra ya existente) de un tipo que agrupa variables globales y procedimientos en una declaración de clase. Los atributos y operaciones que se agrupan en una u tilidad se convierten en variables y operaciones globales. Una utilidad no es fundamental para el modelado, pero puede ser conveniente durante la programación. Metaclase: Es una clase cuyas instancias son clases. Sirven como depósito para mantener las variables de clase y proporcionan operaciones (método 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 implementación. Un tipo establece una especificación de comportamiento para las clases. Interfaz: Representa el uso de un tipo para describir el comportamiento visible externamente de cualquier elemento del modelo. Relación entre clases : Las clases se relacionan entre sí de distintas formas, que marcan los tipos de relaciones existentes: Asociación: Es una relación que describe un conjunto de vínculos entre clases. Pueden ser binarias o n-arias, según se implican a dos clases o más. Las relaciones de asociación 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 asociación (existen otros tipos de roles según la relación a la que identifiquen). Indican la información más importante de las asociaciones. Es posible indicar el número de instancias de una clase que participan en una relación 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 asociación 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 asociación que determina los valores que indican cuales son los valores que se asociarán. Una asociación 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 asociación. Existe una forma especial de asociación, la agregación, que especifica una relación entre las clases donde el llamado "agregado" indica él todo y el "componente" es una parte del mismo. Composición: Es un tipo de agregación donde la relación de posesión es tan fuerte como para marcar otro tipo de relación. Las clases en UML tienen un tiempo de vida determinado, en las relaciones de composición, el tiempo de vida de la clase que es parte d el todo (o agregado) viene determinado por el tiempo de vida d e 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. Generalización: Cuando se establece una relación de este tipo entre dos clases, una es una Sup erclase y la otra es una Subclase. La subclase comparte la estructura y el comportamiento de la superclase. Puede haber más de una clase que se comporte como subclase. Dependencia: Una relación 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. Relación de Refinamiento
Es una relación entre dos elementos donde uno d e ellos especifica de forma completa al otro que ya ha sido especificado con cierto detalle. Nuevas características del UML Además de los conceptos extraídos de métodos anteriores, se han añadido otros n uevos que vienen a suplir carencias antiguas d e la metodología de modelado. Estos nuevos conceptos son los siguientes:
Definición 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 extensión del modelo. Responsabilidades.
Mecanismos de extensibilidad: estereotipos, valores etiquetados y restricciones. Tareas y procesos. Distribución y concurrencia (para modelar po r ejemplo ActiveX / DCOM y CORBA). Patrones/Colaboraciones. Diagramas de actividad (para reingeniería de proceso de negocios) Clara separación de tipo, clase e instancia. Refinamiento (para manejar relaciones entre niveles de abstracción). 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 tendrán en común con otras organizaciones que utilicen UML serán los tipos de diagramas. UML es un método independiente del proceso. Los p rocesos de desarrollo deben ser definidos dentro d el 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 especificación del UML 1.1. Esta herramienta propone la utilización de cuatro tipos de modelo para realizar un diseño del sistema, utilizando una vista estática y otra dinámica de los modelos del sistema, uno lógico y otro físico. 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 iteración comienza con una pr imera aproximación del análisis, diseño e implementación para identificar los riesgos del diseño, los cuales se utilizan para conducir la iteración, primero se identifican los riesgos y después se prueba la aplicación para que éstos se hagan mínimos. Cuando la implementación pasa todas las pruebas que se determinan en el proceso, ésta se revisa y se añaden los elementos modificados al modelo de análisis y diseño. Una vez que la actualización del modelo se ha modificado, se realiza la siguiente iteración. Trabajo en Grupo Rose permite que haya varias personas trabajando a la vez en el p roceso 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 propagación de los c ambios en ese espacio de trabajo. También 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 u nidades. Generador de Código Se puede generar código en distintos lenguajes de programación a partir de un diseño en UML. Ingeniería Inversa Rational Rose proporciona mecanismos para realizar la denominada Ingeniería Inversa, es decir, a partir del código de un programa, se puede obtener información sobre su diseño.
Lenguaje Unificado de Modelado De Wikipedia, la enciclopedia libre Saltar a: navegación, búsqueda
Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de
modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar 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 programación, esquemas de b ases de datos y componentes reutilizables. Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir métodos 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 d e formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar. UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización en un requerimiento. Mientras que, programación estructurada, es una forma de programar como lo es la orientación a objetos, sin embargo, la programación orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados a objetos. UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas. ==
Contenido [ocultar]
1 Estandarización de UML
2 Críticas a UML
3 Historia
o o
3.1 Antes de UML 1.x 3.2 UML 1.x
4 Referencias
5 Enlaces externos
[editar] Estandarización de UML
Desde el año 1995, UML es un estándar aprobado por la ISO como ISO / IEC 19501:2005 Information technology — Open Distributed Processing — Unified Modeling Language (UML) Version 1.4.2. Uno d e los diagramas más conocidos es el diagrama del tipo arcano y el del sis tema fotovoltaico; el cual esta compuesto por interaciones arcaicas moderadamente complejas en talentos de ramas logisticas que abarcan el emparejamiento estatico irreversible. [editar] Críticas a UML
A pesar de su status de estándar ampliamente reconocido y utilizado, UML siempre ha sido muy criticado por su carencia de una semántica precisa, lo que ha dado lugar a que la interpretación de un modelo UML no pueda ser o bjetiva. Otro problema de UML es que no se presta con facilidad al diseño de sistemas distribuidos. En tales sistemas cobran importancia factores como transmisión, serialización, persistencia, etc. UML no cuenta con maneras de describir tales factores. No se puede, por ejemplo, usar UML para señalar que un objeto es persistente o remoto, o que existe en un servidor que corre continuamente y que es compartido entre varias instancias de ejecución del sistema analizado. Sin embargo, UML sí acepta la c reación de nuestros propios componentes para este tipo de modelado.
Entorno de desarrollo integrado
Herramienta CASE
Técnica de Modelado a Objetos
Programación orientada a objetos
XMI, un formato estándar basado en XML para el intercambio de modelos UML.
OCL, Lenguaje de especificación para los diferentes modelos en UML.
EEYORE¹
Webml, Metodología para el diseño de Sistemas de Infor mación Web.
Categoría:Herramientas UML
[editar] Historia [editar] Antes de UML 1.x
Después 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 más populares de la época: el OMT (Object-modeling technique) de Rumbaugh, que era mejor para
análisis orientado a objetos, y el Método Booch de Grady Booch, q ue era mejor para el diseño orientado a objetos. Poco despué s se les unió Ivar Jacobson, el creador del método de ingenieríá de software orientado a objetos. Jacobson se unió a Rational en 1995, después de que su compañía Objectory AB fuera comprada por Rational. Los tres metodologistas eran conocidos como los Tres Amigos, porque se sabia de sus constantes argumentos sobre las prácticas metodológicas. En 1996 Rational concluyó que la abundancia de lenguajes de modelado estaba alentando la adopción de la tecnología de objetos, y para orientarse hacia un método unificado, encargaron a los Tres Amigos que desarrollaran un Lenguaje Unificado de Modelado abierto. Se consultó con representantes de compañías competidoras en el área de la tecnología de objetos durante la OOPSLA '96; eligieron cajas para representar clases en lugar de la notación de Booch que utilizaba simbolos de nubes. Bajo la dirección técnica 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 especificación UML 1.0 de UML Partners fue propuesto a la OMG en enero de 1997. Durante el mismo mes la UML Partners formó un a Fuerza de Tarea Semántica, encabezada por Cris Kobryn y administrada por Ed Eykholt, para finalizar las semánticas de la especificación y para integrarla con otros esfuerzos de estandarización. 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 notación de modelado, la influencia de la OMT domina UML (por ejemplo el uso de rectángulos para clases y objetos). Aunq ue se quitó la notación de "nubes" de Booch, si se adoptó la capacidad de Booch para especificar detalles de diseño en los niveles inferiores. La notación de Casos de Uso del Objectory y la notación de componentes de Booch fueron integrados al resto de la notación, pero la integración semántica era relativamente débil en UML 1.1, y no se arregló realmente hasta la revisión mayor de UML 2.0. Conceptos de muchos otros métodos OO fueron integrados superficialmente en UML con el propósito de hacerlo compatible con todos los métodos OO. Además el grupo tomó en cuenta muchos otro s métodos de la época, con el objetivo de asegurar amplia cobertura en el do minio de los sistemas en tiempo real. Como resultado, UML es útil en una variedad de probl emas de ingeniería, desde procesos sencillos y aplicaciones de un sólo usuario a sistemas concurrentes y distribuidos.
RMM (Metodología de Administración de Relaciones) - RMDM (Modelo de Datos de Administración de Rel aciones) La RMM o Relationship Management Methodology se define como un proceso de análisis, diseño y desarrollo de aplicaciones hipermedia. Los elementos principales de este método son el modelo E-R (Entidad-Relación) y el modelo RMDM (Relationship Management Data Model) basado en el modelo HDM. La metodología fue creada por Isakowitz, Stohr y Balasubramanian. Esta metodología es apropiada para dominios con estructuras regulares (es decir, con clases de objetos bien definidas, y con claras relaciones entre esas clases). Por ejemplo, catálogos o "frentes" de bases de datos tradicionales. Según sus autores, está orientada a problemas con datos dinámicos que cambian con mucha frecuencia, más que a entornos estáticos. El modelo propone un lenguaje que permite describir los objetos del dominio, sus interrelaciones y los mecanismos de navegación hipermedia de la aplicación. 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 presentación de las entidades. Un slice corresponde a un subconjunto de atributos de una misma entidad destinados a s er presentados de forma agrupada. La navegación se modeliza con la ayuda de primitivas de acceso, enlaces estructurales (unidireccional y bidireccional) que permiten especificar la navegación entre slices , y visita guiada condicional, índice condicional y agrupación , que permiten especificar la navegación entre entidades. El esquema completo del dominio y de la navegación de la aplicación se denomina esquema RMDM y se obtiene como resultado de las tres pr imeras etapas del método. Las etapas son:
Primera etapa: representar los objetos del dominio con la ayuda del modelo Entidad-Relación ampliado con relaciones asociativas (aquéllas que permiten representar caminos navegacionales entre entidades puestos en evidencia en la fase de análisis). Segunda etapa : determinar la presentación del contenido de las entidades de la aplicación 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-Relación 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 navegación inducidos por las relaciones asociativas del esquema E -R+. A continuación, es posible definir estructuras de acceso de alto nivel (agrupaciones), lo que permite dotar a la aplicación de accesos jer árquicos a niveles diferentes de los trozos de información. El esquema R MDM resultante se obtiene añadiendo al esquema E -R+ las agrupaciones y caminos navegacionales definidos en esta etapa.
Las cuatro etapas restantes consisten en:
definición del protocolo de conversión de elementos del diagrama RMDM en objetos de la plataforma de desarrollo concepción del interfaz usuario concepción del comportamiento en ejecución construcción del sistema y test
Muestra de un diagrama entidad-relación (las entidades se representan con un recuadro y las relaciones mediante un símbolo en forma de tridente) Veamos con más detalle algunos ejemplos del modelo de datos RMDM (Relationship Management Data Model), que se genera a partir de un diagrama entidad-relación. Con él se describirá no sólo la información referente a las clas es de objetos, sino también a la navegación 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 má s típica es la entidad (se representa medi ante un recuadro y su nombre) . Como en la teoría relacional una entidad está compuesta por varios atributos. Además, en RMDM se incorpora una nu eva primitiva denominada "slice" , que define conjuntos de atributos de una entidad que se a grupan de forma lógica. La figura de la izquierda muestra las principales primitivas y la figura de la derecha es un diagrama RMDM. Estos diagramas especifican la navegación en el sistema:
De acuerdo con HDM, RMM define correspondencias tipo. Propone el modelo Entidad -Relación para especificar el dominio y lo enriquece introduciendo los conceptos de slice ( trozo) y de relación estructural para los cuales se preestablece una metáfora 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 p reestablecidos que tienen una correspondencia clara en términos hipermedia. En RMM, el modelo h ipermedia retoma los elementos enlace, índice y visitas guiadas de HDM e nriqueciéndolos con capacidades condicionales. Sin embargo, el método no permite al diseñador definir elementos hipermedia propios que tengan capacidades específicas ya que impone la utilización de m etáforas preestablecidas. Ante las limitaciones que ofrecía RMM, sus autores Balasubramanian, Bieber e Isakowitz , analizaron la estructura de navegación en RMM y propusieron añadir 2 nuevos tipos de slices : los slices híbridos (que permiten combinar atributos de diferentes entidades y estructuras
de acceso), los slices mínimos (la mínima 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 c on otros slices de otras entidades para crear un m-slice). Se propone crear la estructura de la navegación no en base a las entidades sino a los slices , es decir a conjuntos de a tributos. A partir de las carencias de RMM e incorporando la novedad de los slices mínimos e híbridos, Lopistéguy, Losada y Dagorret analizan el modelo RMM y encuentran algunas carencias, por lo que proponen la creación de unas nuevas estructuras de navegación 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:
navegación jerárquica : al tener varias relaciones 1:N encadenadas, se permite navegar des de cualquier entidad a otra que esté por debajo de ella en la jerarquía. Estos e nlaces inferidos, no extraídos directamente de una relación 1:N, se representarán con trazo discontinuo. navegación en relaciones N:M : se permite navegar de un extremo al otro de la relación, pero teniendo en cuenta la entidad intermedia, cuyos atributos deberán incluirse en un slice híbrido. Para representar un enlace de este tipo, uniremos la primitiva de acceso (índice, visita guiada, ...) con la entidad intermedia. navegación múltiple: se crean unas nuevas primitivas que permiten el acceso múltiple 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, cuál la destino y cuál la tercera. Recordar que esta navegación es especialmente apropiada en estructuras todo-parte. acceso aleatorio: permite acceder a un elemento de forma aleatoria, sin saber exactamente a cuál. acceso simultáneo: 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 simultáneamente, todos a la vez, y n o mediante un índice o uno tras otro en una visita guiada
Y así quedará la lista de primitivas con la inclusión de las nuevas primitivas de acceso:
La metodología RMM permite hacer explícita la navegación al hacer el análisis, lo que permite, teóricamente, obtener una nave gación más estructurada e intuitiva, y lo hace de una forma muy sencilla, como es añadir unas primitivas a un modelo entidad-relación tradicional. El concepto de slice es muy útil, ya que perm ite agrupar datos de una entidad en diferentes pantallas. Se utilizaría, por ejemplo, para mostrar dos vídeos en dos pantallas diferentes sobre un mismo fenómeno. También es interesante la primi tiva de grupo, que permite mostrar la jerarquía de menús. RMM representa el primer caso en el que se crea una metodología completa definiendo las distintas fases y no únicamente un modelo de datos. Además, se basa en un modelo de datos relacional, ajustándose así a la gran mayoría de las aplicaciones existentes. Sin embargo, los mecanismos de acceso a la información son excesivamente simples y valen para un problema con pocas entidades, pero el modelo se queda corto si hay gran número de ellas.
Diagrama Entidad-Relación
Jerarquía de menús con detalle
Para ver un ejemplo de diseño hipermedia usando la metodología RMM, es decir, siguiendo el modelo RMDM, se puede consultar: Antonio Navarrete Terrasa: "Una metodología relacional hipermedia. Estudio de casos p rácticos. CD-ROM del Parc Natural de S'albufera" . http://www.iua.upf.es/~jblat/material/albu/albu.pdf , de donde se han extraído muchos de los ejemplos aquí expuestos.
Diagrama RMDM
