DIAGRAMA DE CLASES

El diagrama de clases es una técnica central y ampliamente difundida en los distintos
métodos orientados a objeto.
Los diagramas de clase describen los tipos de objetos de un sistema, así como los
distintos tipos de relaciones que pueden existir entre ellos. Los diagramas de clase se
convierten así en la técnica más potente para el modelado conceptual de un sistema
software, la cual suele recoger los conceptos clave del modelo de objetos subyacente al
método orientado a objetos que la incorpora.

El propósito de un diagrama de clase es describir las clases que conforman el modelo de
un determinado sistema. Dado el carácter de refinamiento iterativo que caracteriza un
desarrollo orientado a objetos, el diagrama de clase va a ser creado y refinado durante
las fases de análisis y diseño, estando presente como guía en la implementación del
sistema.Se puede decir que existen tres perspectivas diferentes desde las cuales se pueden
utilizar los diagramas de clase:
• Conceptual: El diagrama de clase representa los conceptos en el dominio del
problema que se está estudiando. Este modelo debe crearse con la mayor
independencia posible de la implementación final del sistema.
• Especificación: El diagrama de clase refleja las interfaces de las clases, pero no su
implementación. Aquí las clases aparecen más cercanas a los tipos de datos, ya que
un tipo representa una interfaz que puede tener muchas implementaciones
diferentes.
• Implementación: Esta vista representa las clases tal cual aparecen en el entorno de
implementación.

EJEMPLO DE NARRATIVA DE CASOS DE USO

NARRATIVA

La narrativa:

El caso de uso se puede ver como un documento narrativo que describe la secuencia de
eventos de un actor que utiliza un sistema para completar un proceso. Los casos de uso son historias
o casos de utilización de un sistema; no son exactamente los requerimientos ni las especificaciones
funcionales, sino que ejemplifican e incluyen los requerimientos en las historias que narran. El
siguiente ejemplo corresponde a un caso de uso de alto nivel, que describe claramente el
proceso de comprar artículos en una tienda cuando se emplea una caja una caja registradora en el
punto de venta.


Caso de Uso          Comprar Productos
Actores                  Cliente (iniciador), Cajero
Tipo                       Principal
Descripción           Un Cliente llega a una caja con productos que desea comprar.
                               El Cajero registra los productos y obtiene el pago. Al
                              terminar la transacción, el Cliente se marcha con los
                               productos.

La explicación del formato es:

· Caso de uso: nombre del caso de uso.

· Actores: lista de actores en la que se indica quién inicia el caso de uso.

· Tipo: que puede ser Primario, Secundario, Opcional, entre otros.

· Descripción: repetición del caso de uso de alto nivel o alguna síntesis similar.

UML no especifica un formato rígido; puede modificarse para atender las necesidades y

ajustarse al espíritu de la documentación: ante todo, una combinación clara.

Conviene comenzar con los casos de uso de alto nivel para lograr rápidamente entender los

principales procesos globales. Posteriormente, se pasa al llamado caso de uso expandido para

mostrar más detalles, para lograr así un conocimiento más profundo de los procesos y de los

requerimientos. El caso de uso expandido del caso de uso de alto nivel Comprar Productos se

entrega en la página que sigue.

La estructura del formato expandido agrega a la del alto nivel lo siguiente:

· Propósito: intención del caso de uso.

· Referencias Cruzadas: casos de uso y funciones relacionadas con el sistema.

· Curso Normal de los Eventos: es la parte medular del formato expandido; describe los

detalles de la conversión interactiva entre los actores y el sistema. Un aspecto esencial de la

sección es explicar la secuencia más común de eventos: la historia normal de las actividades y el

término exitoso de un proceso. No incluye situaciones alternativas.

· Cursos Alternativos: describe importantes opciones o excepciones que pueden presentarse

en relación al curso normal. Si son éstas son complejas, se pueden expandir y convertir en

nuevos casos de uso.

Actores en los casos de uso

Se le llama actor a toda entidad externa al sistema que guarda una relación con éste y que le demanda una funcionalidad. Esto incluye a los operadores humanos pero también incluye a todos los sistemas externos, además de entidades abstractas, como el tiempo.

En el caso de los seres humanos se pueden ver a los actores como definiciones de rol por lo que un mismo individuo puede corresponder a uno o más Actores. Suele suceder sin embargo, que es el sistema quien va a tener interés en el tiempo. Es frecuente encontrar que nuestros sistemas deben efectuar operaciones automáticas en determinados momentos; y siendo esto un requisito funcional obvio, resulta de interés desarrollar alguna forma de capturar dicho requisito en el modelo de caso de uso final.

CASOS DE USO

Un caso de uso es una descripción de los pasos o las actividades que deberán realizarse para llevar a cabo algún proceso. Los personajes o entidades que participarán en un caso de uso se denominan actores. En el contexto de ingeniería del software, un caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la comunicación y el comportamiento de un sistema mediante su interacción con los usuarios y/u 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 especialización y la generalización son relaciones. Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar cómo reacciona a eventos que se producen en su ámbito o en él mismo.

Los más comunes para la captura de requisitos funcionales, especialmente con el desarrollo del paradigma de la programación orientada a objetos, donde se originaron, si bien puede utilizarse con resultados igualmente satisfactorios con otros paradigmas de programación.

INTRODUCCION A UML

Introducción a UML

El UML es una herramienta que nos permitirá expresarnos en un lenguaje común, permite facilitar la comunicación entre las áreas de una organización.
El "Lenguaje de Modelo Unificado" --- del inglés Unified Modeling Languague UML --- se basa en diagramas para la especificación, visualización, construcción y documentación de cualquier sistema complejo, aunque en este caso nos centraremos en el caso específico de sistemas sofware.
UML sirve para describir modelos. Un modelo básicamente es una simplificación de un caso de la realidad que se construye para llegar a comprender mejor el sistema a desarrollar. Si bien UML es independiente de las metodologías de análisis y diseño y de los lenguajes de programación que se utilicen en la construcción de los sistemas software, es importante destacar que se basa en el paradigma de la orientación a objetos. Por tanto, es especialmente adecuado cuando se ataca la construcción de sistemas software desde la perspectiva de la orientación a objetos.
La especificación, visualización, construcción y documentación de cualquier sistema software requiere que el sistema pueda ser estudiado desde diferentes puntos de vista, ya que un usuario final necesita una visión diferente del sistema de la que necesita un analista o un programador. UML incorpora toda una serie de diagramas y notaciones gráficas y textuales destinadas a mostrar el sistema desde las diferentes perspectivas, que pueden utilizarse en las diferentes fases del ciclo de desarrollo del software.

CARATULA

NOMBRE DE LA ESCUELA: UNILA SUR
NOMBRE DEL PROYECTO: FINAL DE UML
NOMBRE DE MATERIA: INFORMATICA IV
NOMBRE DEL PROFESOR(a): ADRIANA VEGA PALOS
NOMBRE DEL ALUMNO: BRIAN MEJIA AVELAR
FECHA DE ENTREGA: 13 DE MAYO