REPÚBLICA BOLIVARIANA DE VENEZUELA UNIVERSIDAD RAFAEL

BELLOSO CHACIN FACULTAD DE INGENIERIA ESCUELA DE INGENIERIA

INFORMATICA
CATEDRA: NGENIERÍA DEL SOFTWARE II SECCION: N-913

CORTE 1 - TALLER 2

PRESENTADO POR:
José Buenaño CI: 26.710.923

MARACAIBO, ENERO 2022

1. GENERALIDADES DE UML.

Un lenguaje proporciona vocabulario y las reglas para combinar palabras

de ese vocabulario con el objetivo de posibilitar la comunicación. En un lenguaje

de modelado su vocabulario y reglas se centran en la representación conceptual

y física de un sistema. UML es un lenguaje estándar para los planos software.

Proporciona una comprensión del sistema. Nunca es suficiente un único modelo,

para comprender cualquier cosa se necesitan múltiples modelos conectados

entre sí. Para sistemas con gran cantidad de software, se requiere un lenguaje

que abarque las diferentes vistas de la arquitectura de un sistema conforme

evoluciona a través del ciclo de vida del desarrollo de software. El vocabulario y

las reglas de un lenguaje como UML indican cómo crear y leer modelos bien

formados, pero no dicen qué modelos se deben crear ni cuándo se deberían

crear. Esta es la tarea del proceso de desarrollo de software. Un proceso bien

definido guiará a sus usuarios al decidir qué artefactos producir, qué actividades

y qué personal se emplea para crearlos y gestionarlos, y cómo usar esos

artefactos para medir y controlar el proyecto de forma global.

 UML ES UN LENGUAJE PARA VISUALIZAR.

Un programador a veces realiza el modelado mentalmente, es decir,

avanza en el desarrollo codificando simultáneamente. Se puede vales de

bosquejos de ideas, pero no son entendibles fácilmente por otros ó

simplemente este sujeta a errores, a menos que haya personas implicadas

que hablen el mismo lenguaje. El código fuente del sistema no es bagaje

suficiente para interpretar un sistema y surgen lenguajes de texto y

gráficos como UML.

 UML ES UN LENGUAJE PARA ESPECIFICAR.

Especificar es construir modelos precisos, no ambiguos y

completos. UML cubre la especificación de todas las decisiones de

análisis, diseño e implementación que deben realizarse al desarrollar y

desplegar un sistema con gran cantidad de software.

 UML ES UN LENGUAJE PARA CONSTRUIR.

No es un lenguaje de programación visual, pero sus modelos

pueden conectarse de forma directa a una gran variedad de lenguajes de

programación. Java, C++, Visual Basic, tablas en una base de datos

relacional. Las cosas que se expresan mejor se gráficamente se expresan

en UML mientras que las que se expresan mejor textualmente se plasman

en el lenguaje de programación. Esto permite la ingeniería directa, es decir

la generación de código a partir de un modelo UML como también la

ingeniería inversa que consiste en escribir código a partir de una

implementación, ésta requiere de herramientas que la soporten y de la

intervención humana. UML es lo suficientemente expresivo y no ambiguo

para permitir la ejecución directa de modelos, la simulación de sistemas y

la coordinación de sistemas de ejecución.

 UML ES UN LENGUAJE PARA DOCUMENTAR.

Una organización de software, además de código ejecutable, debe

producir toda clase de artefactos como:

 Requisitos.

 Arquitectura.

 Diseño.

 Código fuente.

 Planificación de proyectos.

 Pruebas.

 Prototipos.

 Versiones.

Estos son críticos para el control, la medición y comunicación que

requiere un sistema durante su desarrollo y después de su despliegue.

UML cubre la documentación de la arquitectura y todos sus detalles. UML

proporciona un lenguaje para expresar requisitos y pruebas y para

modelar las actividades de planificación de proyectos y gestión de

versiones.
2. USOS DE UML.

 SISTEMAS CON GRAN CANTIDAD DE SOFTWARE TALES

COMO:

 Sistemas de información empresarial.

 Bancos y servicios financieros.

 Telecomunicaciones.

 Transporte.

 Defensa / industria aeroespacial.

 Comercio.

 Electrónica médica.

 Ámbito científico.

 Servicios distribuidos basados en la Web.

 OTRAS ÁREAS:

 Flujos de trabajo (workflows) en el sistema jurídico.

 Estructura y comportamiento de un sistema de vigilancia

médica de un enfermo.

 Diseño de hardware.

3. PERSPECTIVA DE UML.
 A la hora de modelar diagramas de clases o realizar el también

denominado modelado estructura de un sistema con notación UML, nos

encontramos con diferentes perspectivas asociadas a las diferentes etapas del

ciclo de vida del software.

Cabe destacar que en el modelado estructural se describen los tipos de

objetos de un sistema y las relaciones estáticas que existen entre ellos y que un

diagrama de clases no deja de ser una representación gráfica de este modelo.

Veamos pues a grandes rasgos estas posibles perspectivas:

 MODELADO CONCEPTUAL.

En primera instancia, podemos hablar del Modelado Conceptual

donde vamos a contemplar los conceptos del dominio del problema:

atributos, restricciones y relaciones entre ellos. A continuación, en el

Modelo del Análisis podemos refinar un poco más el sistema, estipulando

clases que corresponden a conceptos del dominio junto con atributos y

métodos.

 MODELO DE DISEÑO.

Por otro lado, ya en la fase de diseño, nos encontramos con el

Modelo de Diseño donde podemos incluir clases que corresponden a

 decisiones del diseño y hacer uso de interfaces y patrones. Como se

puede apreciar aquí ya empiezan a presentarse elementos de la solución

software.

 MODELO DE IMPLEMENTACIÓN.

Por último, en el Modelo de Implementación incorporaremos clases

que corresponden al propio lenguaje o entorno de programación que

estemos utilizando en el desarrollo de nuestra aplicación. Este último

modelo suele asociarse al concepto de ingeniería inversa, es decir,

obtener un modelo a partir de código.

4. IMPORTANCIA DEL MODELADO.

De acuerdo al tipo de emprendimiento, tanto en su tamaño como en

características se necesitará de distintas herramientas, procesos, arquitectura,

recursos humanos y las tecnologías. El truco está en crear el software apropiado

y en imaginar cómo escribir menos software. Un proyecto puede ser concebido

con respecto a su tamaño en un programa pequeño, y crecer enormemente, pero

si no se han tenido en cuenta, previamente la arquitectura, el proceso o las

herramientas, este colapse.

El modelado es común en los proyectos software exitosos.

 El modelado es una técnica de ingeniería probada y bien aceptada. Nos

ayuda a:

 Visualizar a sus usuarios el producto final.

 Comprender mejor el sistema.

 Comunicar las ideas a otros.

5. OBJETIVOS LOGRADOS CON UML.

Durante el desarrollo del UML sus autores tuvieron en cuenta:

 Proporcionar una notación y semánticas suficientes para poder

alcanzar una gran cantidad de aspectos del modelado contemporáneo de

una forma directa y económica.

 Proporcionar las semánticas suficientes para alcanzar aspectos del

modelado que son de esperar en un futuro, como por ejemplo aspectos

relacionados con la tecnología de componentes, el cómputo distribuido,

etc.

 Proporcionar mecanismos de extensión de forma que proyectos

concretos puedan extender el meta-modelo a un coste bajo.

 Proporcionar mecanismos de extensión de forma que

aproximaciones de modelado futuras podrían desarrollarse encima del

UML.

 Permitir el intercambio de modelos entre una gran variedad de

herramientas.

 Proporcionar semánticas suficientes para especificar las interfaces

a bibliotecas para la comparación y el almacenamiento de componentes

del modelo.

 Ser tan simple como sea posible, pero manteniendo la capacidad de

modelar toda la gama de sistemas que se necesita construir.

 UML es un lenguaje de modelado de propósito general que pueden

usar todos los modeladores.

 UML no pretende ser un método de desarrollo completo.

 Debe ser un lenguaje universal, como cualquier lenguaje de

propósito general.
  Imponer un estándar mundial.

 Proporcionar a los usuarios un lenguaje de modelado visual

expresivo y utilizable para el desarrollo e intercambio de modelos

significativos.

 Proporcionar mecanismos de extensión y especialización.

 Ser independiente del proceso de desarrollo y de los lenguajes de

programación.

 Proporcionar una base formal para entender el lenguaje de

modelado.

 Fomentar el crecimiento del mercado de las herramientas OO.

 Soportar conceptos de desarrollo de alto nivel como pueden ser

colaboraciones, frameworks, patterns, y componentes.

El UML debe entenderse como un estándar para modelado y no como un

estándar de proceso software. Aunque UML debe ser aplicado en el contexto de

un proceso, la experiencia ha mostrado que organizaciones diferentes y dominios

del problema diferentes requieren diferentes procesos. Por ello se han centrado

los esfuerzos en un meta-modelo común (que unifica las semánticas) y una

notación común que proporcione una representación de esas semánticas. De

todas formas, los autores de UML fomentan un proceso guiado por casos de uso,

centrado en la arquitectura, iterativo e incremental. Bajo estas líneas genéricas

proponen el proceso software definido en una de las extensiones del UML

(Objectory Extension for Software Engineering), pero en general el proceso

software es fuertemente dependiente de la organización y del dominio de

aplicación.

6. PRINCIPIOS DEL MODELADO.

 La elección acerca de qué modelos crear tiene una profunda

influencia sobre cómo se acomete un problema y cómo se da forma a una

solución. De acuerdo con el paradigma con el que se enfoque el problema

a solucionar serán distintas las herramientas, los procesos, la arquitectura,

los recursos humanos y las tecnologías a utilizar.

 Todo modelado puede ser expresado con diferentes niveles de

precisión.
 Los mejores modelos están ligados a la realidad. Los modelos

simplifican la realidad, hay que asegurarse que las simplificaciones no

enmascaren ningún detalle importante. En las técnicas de análisis

estructurado el punto débil es que existe una brecha entre el modelo de

análisis y el modelo de diseño del sistema. En los sistemas orientados a

objetos es posible conectar todas las vistas casi independientes de un

sistema en un todo semántico.

 Un único modelo o vista no es suficiente. Cualquier sistema no

trivial se aborda mejor a través de un pequeño conjunto de modelos casi

independientes con múltiples puntos de vista. Significa tener modelos que

podemos construir y estudiar separadamente, pero, aun así, están

interrelacionados.