PROGRAMA DE FORMACIN

ANALISIS Y DESERROLLO DE SISTEMAS DE INFORMACIN

UML

APRENDIZ: Anderson Gonzlez Cervantes FICHA: 296584 C

1.

Qu es un paradigma de programacin? RTA: Un paradigma de programacin es una propuesta tecnolgica que es adoptada
por una comunidad de programadores cuyo ncleo central es incuestionable en cuanto a que unvocamente trata de resolver uno o varios problemas claramente delimitados. La resolucin de estos problemas debe suponer consecuentemente un avance significativo en al menos un parmetro que afecte a la ingeniera de software. Tiene una estrecha relacin con la formalizacin de determinados lenguajes en su momento de definicin. Un paradigma de programacin est delimitado en el tiempo en cuanto a aceptacin y uso ya que nuevos paradigmas aportan nuevas o mejores soluciones que la sustituyen parcial o totalmente.

2.

Indague sobre la Clasificacin por paradigmas de programacin.

RTA: -Alto nivel. (Lenguaje similar al humano) -Bajo nivel (Lenguaje entre el humano y lenguaje mquina, tambin llamado lenguaje ensamblador) -Lenguaje maquina (Lenguaje que entiende directamente la computadora, ya que esta en binario) -Alto nivel. (Lenguaje similar al humano) -Bajo nivel (Lenguaje entre el humano y lenguaje mquina, tambin llamado lenguaje ensamblador) -Lenguaje maquina (Lenguaje que entiende directamente la computadora, ya que esta en binario)
Paradigma Imperativo: describe la programacin como una secuencia instrucciones o comandos que cambian el estado de un programa. El cdigo mquina en general est basado en el paradigma imperativo. Su contrario es el paradigma declarativo. En este paradigma se incluye el paradigma procedimental (procedural) entre otros. Paradigma Declarativo: No se basa en el cmo se hace algo (cmo se logra un objetivo paso a paso), sino que describe (declara) cmo es algo. En otras palabras, se enfoca en describir las propiedades de la solucin buscada, dejando indeterminado el algoritmo (conjunto de instrucciones) usado para encontrar esa solucin. Es ms complicado de implementar que el paradigma imperativo, tiene desventajas en la eficiencia, pero ventajas en la solucin de determinados problemas. Paradigma Estructurado: la programacin se divide en bloques (procedimientos y funciones) que pueden o no comunicarse entre s. Adems la programacin se controla con secuencia, seleccin e iteracin. Permite reutilizar cdigo programado y otorga una mejor compresin de la programacin. Es contrario al paradigma estructurado, de poco uso, que no tiene ninguna estructura, es simplemente un bloque, como por ejemplo, los archivos batch (.bat). Paradigma Orientado a Objetos: est basado en la idea de encapsular estado y operaciones en objetos. En general, la programacin se resuelve comunicando dichos objetos a travs de mensajes (programacin orientada a mensajes). Se puede incluir -aunque no formalmentedentro de este paradigma, el paradigma basado en objetos, que adems posee herencia y subtipos entre objetos. Ej.: Simula, Smalltalk, C++, Java, Visual Basic .NET, etc. Su principal ventaja es la reutilizacin de cdigos y su facilidad para pensar soluciones a determinados problemas. Paradigma Funcional: este paradigma concibe a la computacin como la evaluacin de funciones matemticas y evita declarar y cambiar datos. En otras palabras, hace hincapi en la aplicacin de las funciones y composicin entre ellas, ms que en los cambios de estados y la ejecucin secuencial de comandos (como lo hace el paradigma procedimental). Permite resolver ciertos problemas de forma elegante y los lenguajes puramente funcionales evitan los efectos secundarios comunes en otro tipo de programaciones. Paradigma lgico: se basa en la definicin de reglas lgicas para luego, a travs de un motor

de inferencias lgicas, responder preguntas planteadas al sistema y as resolver los problemas. Ej.: prolog. Otros paradigmas y subparadigmas son: paradigma orientado al sujeto, paradigma reflectante, programacin basada en reglas, paradigma basado en restricciones, programacin basada en prototipos, etc.

Busque que modelos de Ciclo de Vida del Software existen y presntelos en un cuadro con la explicacin correspondiente.
4.

RTA: Ciclo de Vida del Software

Un modelo de ciclo de vida define el estado de las fases a travs de las cuales se mueve un proyecto de desarrollo de software. El primer ciclo de vida del software, "Cascada", fue definido por Winston Royce a fines del 70. Desde entonces muchos equipos de desarrollo han seguido este modelo. Sin embargo, ya desde 10 a 15 aos atrs, el modelo cascada ha sido sujeto a numerosas crticas, debido a que es restrictivo y rgido, lo cual dificulta el desarrollo de proyectos de software moderno. En su lugar, muchos modelos nuevos de ciclo de vida han sido propuestos, incluyendo modelos que pretenden desarrollar software ms rpidamente, o ms incrementalmente o de una forma ms evolutiva, o precediendo el desarrollo a escala total con algn conjunto de prototipos rpidos.

Modelo Cascada Este es el ms bsico de todos los modelos, y sirve como bloque de construccin para los dems modelos de ciclo de vida. La visin del modelo cascada del desarrollo de software es muy simple; dice que el desarrollo de software puede ser a travs de una secuencia simple de fases. Cada fase tiene un conjunto de metas bien definidas, y las actividades dentro de una fase contribuyen a la satisfaccin de metas de esa fase o quizs a una subsecuencia de metas de la fase. Las flechas muestran el flujo de informacin entre las fases. La flecha de avance muestra el flujo normal. Las flechas hacia atrs representan la retroalimentacin. El modelo de ciclo de vida cascada, captura algunos principios bsicos:

Planear un proyecto antes de embarcarse en l. Definir el comportamiento externo deseado del sistema antes de disear su arquitectura interna. Documentar los resultados de cada actividad. Disear un sistema antes de codificarlo. Testear un sistema despus de construirlo.

Modelo De Desarrollo Incremental Los riesgos asociados con el desarrollo de sistemas largos y complejos son enormes. Una forma de reducir los riesgos es construir slo una parte del sistema, reservando otros aspectos para niveles posteriores. El desarrollo incremental es el proceso de construccin siempre incrementando subconjuntos de requerimientos del sistema. Tpicamente, un documento de requerimientos es escrito al capturar todos los requerimientos para el sistema completo. Note que el desarrollo incremental es 100% compatible con el modelo cascada. El desarrollo incremental no demanda una forma especfica de observar el desarrollo de algn otro incremento. As, el modelo cascada puede ser usado para administrar cada esfuerzo de desarrollo, como se muestra en la figura. El modelo de desarrollo incremental provee algunos beneficios significativos para los proyectos:

Construir un sistema pequeo es siempre menos riesgoso que construir un sistema grande. Al ir desarrollando parte de las funcionalidades, es ms fcil determinar si los requerimientos planeados para los niveles subsiguientes son correctos. Si un error importante es realizado, slo la ltima iteracin necesita ser descartada. Reduciendo el tiempo de desarrollo de un sistema (en este caso en incremento del sistema) decrecen las probabilidades que esos requerimientos de usuarios puedan cambiar durante el desarrollo. Si un error importante es realizado, el incremento previo puede ser usado. Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del comienzo del prximo incremento.

Modelo De Desarrollo Evolutivo Como el modelo de desarrollo incremental, el modelo de desarrollo evolutivo (algunas veces denominado como prototipado evolutivo) construye una serie de grandes versiones sucesivas de un producto. Sin embargo, mientras que la aproximacin incremental presupone que el conjunto completo de requerimientos es conocido al comenzar, el modelo evolutivo asume que los requerimientos no son completamente conocidos al inicio del proyecto. En el modelo evolutivo, los requerimientos son cuidadosamente examinados, y slo esos que son bien comprendidos son seleccionados para el primer incremento. Los desarrolladores construyen una implementacin parcial del sistema que recibe slo estos requerimientos.

Modelo Espiral El modelo espiral de los procesos software es un modelo del ciclo de meta-vida. En este modelo, el esfuerzo de desarrollo es iterativo. Tan pronto como uno completa un esfuerzo de desarrollo, otro comienza. Adems, en cada desarrollo ejecutado, puedes seguir estos cuatros pasos:

Determinar qu quieres lograr. Determinar las rutas alternativas que puedes tomar para lograr estas metas. Por cada una, analizar los riesgos y resultados finales, y seleccionar la mejor. Seguir la alternativa seleccionada en el paso 2. Establecer qu tienes terminado.

Modelo Concurrente Como el modelo espiral, el modelo concurrente provee una meta-descripcin del proceso software. Mientras que la contribucin primaria del modelo espiral es en realidad que esas actividades del software ocurran repetidamente, la contribucin del modelo concurrente es su capacidad de describir las mltiples actividades del software ocurriendo simultneamente. Esto no sorprende a nadie que ha estado involucrado con las diversas actividades que ocurren en algn tiempo del proceso de desarrollo de software

5.

Qu es UML?

R: (Unified Modeling Language - Lenguaje Unificado de Modelado). UML es un popular lenguaje de modelado de sistemas de software. Se trata de un lenguaje grfico para construir, documentar, visualizar y especificar un sistema de software. Entre otras palabras, UML se utiliza para definir un sistema de software UML preescribe una notacin estndar y semnticas esenciales para el modelado de un sistema orientado a objetos. Previamente, un diseo orientado a objetos podra haber sido modelado con cualquiera de la docena de metodologas populares, causando a los revisores tener que aprender las semnticas y notaciones de la metodologa empleada antes que intentar entender el diseo en s. Ahora con UML, diseadores diferentes modelando sistemas diferentes pueden sobradamente entender cada uno los diseos de los otros.

6.

Cundo se utiliza UML?

R: Cuando empezamos a desarrollar un sistema por lo general nos encontramos con la dificultad de no saber cuando utilizar diagramas UML y cuando no hacerlo ... Muchos de nosotros de preferencia no lo hacemos pues veamos algunas razones para hacer y no hacerlo segn lo dice en su libro UML para programadores Java Prentice Hall. No hacer una regla que todo debe ser diagramado. Enorme monto de tiempo en un proyecto puede ser gastado en diagramas que nadie leer.
3.

De dnde surge UML?

R: Tras la aparicin de los lenguajes orientados a objetos se buscaron nuevas metodologas que permitiesen el anlisis y diseo de aplicaciones bajo dichos lenguajes; estas metodologas fueron los primeros lenguajes de modelado orientados a objetos. Al no poder cubrir stos todas las necesidades de los desarrolladores, surgi una nueva generacin de lenguajes ms potentes liderados por el mtodo de Booch, el mtodo OOSE de Jacobson y el mtodo OMT de Rumbaugh; cada uno de estos mtodos destacaba en algunos puntos pero fallaba en otros. UML se comenz a gestar en la empresa Rational cuando Booch y Rumbaugh decidieron unir sus mtodos para conseguir un lenguaje estndar y slido. Ms tarde se incorpor Jacobson, lo que dio lugar a la versin 0.9 de UML en 1996; posteriormente se cre un consorcio con varias organizaciones interesadas en UML. La versin 1.0 de UML surgi en 1997 con la contribucin de IBM, HP, Oracle, Microsoft y otras organizaciones.

11.Utilice la grfica que esta al comienzo de esta gua y ubique, en la tabla de abajo, sealando con el nmero que corresponda, las partes que contiene el Lenguaje UML 2.0, agregue la definicin y una grfica de ejemplo:
No. DIAGRAMA ESTRUCTURA?;COMPORTAMIE NTO?;INTERACCIN? DEFINICIN GRAFICA DE EJEMPLO

DIAGRAMA GLOBAL DE INTERACCIN

Interaccin

DIAGRAMA DE CLASES

estructural

Muestran la cooperacin entre otros diagramas de interaccin para reflejar el flujo de control que responde a un propsito abarcativo. Como los Diagramas de Descripcin de las Interacciones son una variante de los diagramas de actividades, la mayor parte de la notacin es similar, al igual que el proceso de construccin del diagrama. Los puntos de decisin, bifurcacin, unin, puntos de inicio y final son los mismos. En lugar de actividades se usan elementos rectangulares. Hay dos tipos de estos elementos: El Diagrama de Clases es el diagrama principal para el anlisis y diseo. Un diagrama de clases presenta las clases del sistema con sus relaciones estructurales y de herencia. La definicin de clase incluye definiciones para atributos y operaciones.

DIAGRAMA DE CASOS DE USO

comportamiento

es mediante entrevista directa con los usuarios o posibles futuros usuarios del sistema, poniendo atencin a cada una de las actividades o pasos que se van a ir desarrollando desde un primer momento hasta un momento final. La elaboracin de diagramas de uso ayuda poderosamente a un analista a comprender la forma en que un sistema deber comportarse, obteniendo los requerimientos desde el punto de vista del usuario. En todo caso de uso siempre hay un actor, que es quien inicia, y luego otro actor (que puede ser el mismo que inicia el caso de uso o puede ser otro diferente), que recibir algo por parte del sistema. La representacin grfica es directa, de la siguiente forma:

DIAGRAMA DE SECUENCIA

interacion

Este tipo de diagramas muestra una interaccin ordenada segn la secuencia de eventos vista a la luz de una lnea de tiempo. En particular, se muestran los objetos participantes en la interaccin y los mensajes que intercambian ordenados segn su secuencia en el tiempo.
La especificacin del Lenguaje de Modelado Unificado UML define un diagrama de actividad como: una variacin de una mquina estados, lo cual los estados representan el rendimiento de las acciones o sub actividades y las transiciones se provocan por la realizacin de las 1 acciones o subactividades. El propsito del diagrama de actividad es modelar un proceso de flujo de trabajo (workflow) y/o modelar operaciones. Una Operacin es un servicio proporcionado por un objeto, que est disponible a travs de una interfaz. Una Interfaz es un grupo de operaciones relacionadas con la semntica

DIAGRAMA DE ACTIVIDAD

comportamiento

DIAGRAMA DE TIEMPOS

los diagramas de tiempo son una representacin especial de interaccin que se enfoca en el tiempo de los mensajes enviados entre objetos. Se pueden usar estos diagramas para mostrar restricciones detalladas sobre los embebidos.

DIAGRAMA DE COMPOSICION

estructura

Los diagramas de composicin de estructuras (Composite Structures Diagram) fueron especficamente diseados para la representacin de patrones de diseo, y son una de las modificaciones de mayor impacto dentro de UML 2.0. Esta modificacin al UML hace que ahora todos los Clasificadores puedan tener una estructura compuesta. Mediante una composicin de estructuras, el comportamiento de las instancias de otros Clasificadores contenidos (estructura interna) en un Clasificador determinado, puede especificarse como Colaboraciones. Los conceptos principales para describir la estructura interna son: Partes, Puertos y Conectores.

DIAGRAMA DE MAQUINA DE ESTADO

comportamiento

Conforme un sistema interacta con los usuarios y (posiblemente) con otros sistemas, los objetos que lo conforman pasan por cambios necesarios para ajustar las interacciones. Por esa razn se necesita contar con un mecanismo para cambios en el modelo. Un cambio en un sistema se da debido a que los objetos que componen dicho sistema modificaron su estado como respuesta a los sucesos y al tiempo. Un diagrama de estados tambin se conoce como un "motor de estado."

DIAGRAMA DE COMUNICACI N

interaccin

Un diagrama de comunicacin modela las interacciones entre objetos o partes en trminos de mensajes en secuencia. Los diagramas de comunicacin representan una combinacin de informacin tomada desde el diagrama de clases, secuencia, y diagrama de casos de uso describiendo tanto la estructura esttica como el comportamiento dinmico de un sistema.

DIAGRAMA DE OBJETOS

estructural

Partiendo del hecho que un objeto es una instancia de clase, tal como se define en la conceptualizacin bsica de la programacin orientada a objetos, en UML la representacin de un diagrama de objetos se hace de tal forma que teniendo ya una clase, el smbolo del objeto es un rectngulo, pero con el nombre subrayado.

estructural

DIAGRAMA DE PAQUETES

Los diagramas de paquetes se usan para reflejar la organizacin de paquetes y sus elementos. Cuando se usan para representaciones, los diagramas de paquete de los elementos de clase se usan para proveer una visualizacin de los espacios de nombres. Los usos ms comunes para los diagramas de paquete son para organizar diagramas de casos de uso y diagramas de clase, a pesar de que el uso de los diagramas de paquete no es limitado a estos elementos UML

DIAGRAMA DE COMPONENTES

estructural

Un componente de software es una parte fsica de un sistema, y se encuentra en la computadora, no en la mente del analista. Ejemplos de componentes son tablas, archivos de datos, ejecutables, bibliotecas de vnculos dinmicos, documentos y cosas por el estilo. Lo que contiene un diagrama de componentes es lgicamente componentes, interfaces y relaciones, aunque tambin pueden aparecer otros tipos de smbolos vistos anteriormente

DIAGRAMA DE DESPLIEGUE

estructural

es un tipo de diagrama del Lenguaje Unificado de Modelado que se utiliza para modelar el hardware utilizado en las implementaciones de sistemas y las relaciones entre sus componentes. Los elementos usados por este tipo de diagrama son nodos (representados como un prisma), componentes (representados como una caja rectangular con dos protuberancias del lado izquierdo) y asociaciones.

12. Indique en las siguientes grficas: en la parte superior la clasificacin del diagrama (Estructura, Comportamiento Interaccin), al igual , en la parte de abajo, el nombre del diagrama.

Clasificacin: comportamiento

Clasificacin: interaccin

Clasificacin: estructura

Diagrama de caso de uso

Diagrama de interaccin

Diagrama de despliegue