Contenido. 1. El proceso 2. Los modelos 3. Los diagramas 4. Ejemplo

Tutorial Contenido 1. El proceso 2. Los modelos 3. Los diagramas 4. Ejemplo 1. El proceso Fases soportadas por UML Análisis de requisitos de usua

0 downloads 75 Views 122KB Size

Recommend Stories


Ejemplo Traza la gráfica de los puntos: ( 5, 4), (3, 2), ( 2, 0), ( 1, 3), (0, 4) y (5, 1) en el plano cartesiano
Apuntes para el módulo: Pensamiento Algebraico Plano cartesiano El plano cartesiano se forma con dos rectas perpendiculares, cuyo punto de intersecci

*#*0+$1$'!$)"!"-2$!(#$)"%,!'3*&(&'#$(#")*(&(#$ ($#4$(,-'+&*5(3'
INVESTIGACIÓN DIDÁCTICA !"#$%"&'!"#$&'$!($)*'+)*($,(-($'.,!*)(-$ !($/*#*0+$1$'!$)"!"-2$!(#$)"%,!'3*&(&'#$(#")*(&(#$ ($#4$(,-'+&*5(3' Bravo, Bettina6;

GRAMÁTICA ESPAÑOLA LOS PRONOMBRES. 1 Los pronombres personales 2 Los pronombres relativos 3 Los pronombres reflexivos 4 Los pronombres recíprocos
GRAMÁTICA ESPAÑOLA VLLDC VI LOS PRONOMBRES Los pronombres personales 2 Los pronombres relativos 3 Los pronombres reflexivos 4 Los pronombres r

ACTIVIDADES INICIALES. a) 2 3 ( 4) 5 (2 3 5) (6 5) b) 3 5 (2 3 3) (5 8) (4 2) 10 (3 4 2 ) 1
Solucionario 1 Números reales ACTIVIDADES INICIALES 1.I. Realiza las siguientes operaciones. a) 2  3  ( 4)  5  (2  3  5)  1 b) 3  5(23

LOS DIAGRAMAS BIOCLIMATICOS
LOS DIAGRAMAS BIOCLIMATICOS por JAVIER GONZALEZ DE ALAIZA GARCIA DEPARTAMENT0 DE CIENCIAS I TERCERA HIPOTESIS. EVAPOTRANSPIRACION RESIDUAL En la hi

Story Transcript

Tutorial

Contenido 1. El proceso 2. Los modelos 3. Los diagramas 4. Ejemplo

1. El proceso Fases soportadas por UML

Análisis de requisitos de usuario

Análisis de requisitos de usuario Análisis de requisitos de software Diseño de la plataforma Diseño de aplicaciones Diseño interfaz

Análisis de requisitos de software

de usuario Diseño plataforma

Diseño del modelo de datos

Diseño aplicaciones

Análisis de requisitos de usuario Objetivos Identificar los conceptos que existen en el ámbito que se desea automatizar Identificar las relaciones entre los conceptos: herencia, pertenencia y asociación Identificar las actividades y procesos (secuencias de actividades) que realizan los actores Resultado Modelo del dominio

Análisis de requisitos de software Objetivos Identificar los objetos que van a estar presentes en el software que se va a desarrollar Identificar las operaciones que van a estar disponibles para aplicarlas a esos objetos

Resultado Modelo del software

Diseño de la plataforma Objetivos Identificar los aplicaciones que van a desarrollarse para dar soporte a las necesidades analizadas Especificar las posibles configuraciones de las aplicaciones

Resultado Arquitectura de la plataforma

Diseño de aplicaciones Objetivos Identificar los módulos con los que se va a construir cada aplicación Definir las relaciones entre estos módulos

Resultado Arquitectura de las aplicaciones

2. Los modelos Modelo del dominio Modelo del software Modelo arquitectónico de la plataforma Modelo arquitectónico de las aplicaciones

Modelo del dominio Diagrama de clases del dominio Para representar los conceptos que deben tener los usuarios en el dominio en el que se desea realizar el software, y las relaciones que existen entre estos conceptos

Diagramas de actividades Para representar los procesos en los que un usuario o conjunto de usuarios deben resolver conjuntamente una situación

Diagrama de estado Para representar los distintos estados por los que atraviesa un sistema en la medida en la que el estado afecte a su comportamiento.

Modelo del software Diagrama de clases del software Para representar los conceptos que van a estar virtualizados en el software. Se deben incluir en las descripciones de clases los atributos que van a estar visibles. En este diagrama se especifican solamente las clases que van a existir en el software.

Diagrama de casos de uso Para representar las situaciones en las que los usuarios pueden necesitar el software y las operaciones que van a tener disponibles.

Arquitectura de la plataforma Diagrama de emplazamiento Para representar los componentes de una plataforma hardware (servidores, estaciones de trabajo, terminales...) y software (bases de datos, servicios, aplicaciones). Es posible desarrollar varios diagramas de emplazamiento, de manera que se establezcan posibles configuraciones diferentes.

Diagramas de actividades Para describir el comportamiento del software en una situación que afecte a muchas aplicaciones.

Diagramas de estados Para describir los posibles estados del conjunto de la plataforma en función de las operaciones que ejecuten los usuarios.

Arquitectura de las aplicaciones (1) Diagrama de clases de diseño Para representar las clases que van a componer la arquitectura de una aplicación. También se representan las relaciones que van a existir entre esas clases (composición, herencia, dependencia, navegabilidad)

Diagramas de paquetes Para agrupar clases en un software grande. Los paquetes son útiles para la prueba, ya que cada paquete debe tener una o mas unidades de prueba que compruebe el comportamiento del paquete

Diagrama de estados Para representar los estados en los que se puede encontrar un objeto de una clase.

Arquitectura de las aplicaciones (2) Diagramas de interacción de objetos Para describir como grupos de objetos colaboran para proporcionar algún comportamiento en una situación simple como ejecutar una operación, atender algún evento... Hay dos tipos de diagramas de interacción Diagrama de colaboración Son útiles en los casos de interacciones síncronas entre objetos. Diagrama de secuencia Son muy útiles para representar procesos concurrentes y respuestas asíncronas.

3. Los diagramas Diagrama de clases Diagrama de casos de uso Diagrama de interacción Diagrama de paquetes Diagrama de estados Diagrama de actividades Diagrama de emplazamiento

Diagrama de clases (1) Descripción de una clase Se utiliza en el análisis para describir el contenido de una clase y las operaciones que puede ejecutar el usuario. Se utiliza en el diseño de la arquitectura de las aplicaciones para describir la estructura de una clase y los servicios que ofrecen a otras clases. Clase [visibilidad] atributo: tipo [=valordefecto] [visibilidad] atributo: tipo [=valordefecto] ...

[visibilidad] operacion(argumentos): retorno [visibilidad] operacion(argumentos): retorno ...

Visibilidad de los atributos y operaciones + #

publico privado protegido

Diagrama de clases (2) Relación de asociación Representa cualquier tipo de relación entre clases. No obstante en caso de relaciones estándares se aconseja utilizar la notación disponible. Fundamentalmente se utilizan en el análisis Clase A

Papel de B. Cardinalidad

Papel de A. Cardinalidad

{ Restricción }

Clase A

Clase A

Clase B

Papel de clase representa el tipo de asociación entre las clases Cardinalidad [ n | n,m | n..m | * | +]

Clase B

Restricción. Son reglas escritas en lenguaje natural que establecen en que casos es válida la relación

Clase B

Clases asociadas. Son clases cuyo contenido es derivado de una relación

Clase asociación

Clase A

Cualificador

Clase B

Cualificador. Son relaciones en las que existe un cualificador sirve como elemento de búsqueda o selección en una relación con muchos elementos

Diagrama de clases (3) Relación de generalización

Relación de agregación

La generalización se asocia a las relaciones es-un en el análisis y herencia en el diseño, es decir, el subtipo tiene todas las características que tiene el supertipo.

Representa la composición de un objeto. Se utiliza para representar las relaciones es-parte-de en el análisis Clase

Clase I

Clase A Criterio discriminante

Clase Ax

Clase Ay

Criterio discriminante define la jerarquía representada

Relación de composición También representa la composición de un objeto, pero la existencia de los componentes es dependiente de la existencia de la clase que lo contiene. Se utiliza par representar la composición de una clase en el diseño C

Clase

Clase C

Clase I

Clase I

Diagrama de clases (4) Relación de navegabilidad

Relación de dependencia

Se utilizan en diseño para indicar que una clase accede al contenido de otra clase.

Se utilizan en el diseño para indicar que una clase accede a los servicios de otra clase.

Fuente

Destino

Clase

Clase

Clase parametrizada

Interfaces

Se utilizan en el diseño para representar plantillas (templates). Son muy útiles para definir colecciones

Se utilizan en el diseño para representar

Plantilla

Clase

Diagramas de casos de uso Hay que distinguir entre las intenciones del usuario y las interacciones con el sistema. Un caso de uso representa una intención de un usuario y las interacciones que va a realizar dicho usuario. En un diagrama de casos de uso se representan varios casos de uso para cumplir con las intenciones de un usuario. También se utilizan para representar las operaciones que ejecuta un actor virtual. «usa»

Caso de uso

Actor

«extiende»

Diagrama de actividades Este diagrama se puede utilizar en el análisis de requisitos de usuario para representar las actividades de un proceso y las condiciones de ejecución del mismo. También se puede utilizar en el diseño de la arquitectura de la plataforma para describir el comportamiento del software en una situación que afecte a muchas aplicaciones.

Actividad condición transición * para n elementos

Actividad

Actividad Actividad

condición sincronización

condición transición

Actividad

Diagrama de secuencia Este diagrama se utiliza en el diseño de la arquitectura de las aplicaciones para representar una traza de un proceso, aunque también es muy útil para representar las interacciones entre aplicaciones cliente-servidor o aplicaciones multihilo con varios procesos. El diagrama permite representar durante el tiempo de vida de un objeto su comportamiento.

objeto: clase

create

objeto: clase

mensaje autodelegación

retorno

destroy

Diagrama de colaboración El significado de un diagrama de colaboración es bastante similar al diagrama de secuencia. Fudamentalmente se utiliza en el diseño de la arquitectura de las aplicaciones para describir la traza de un proceso. objeto: clase 1: mensaje(..)

: clase

objeto 1.1*: mensaje(..) 1.2:[condicion] mensaje(..)

Diagrama de paquetes Este diagrama se utiliza para representar los detalles del diseño de la arquitectura de las aplicaciones. Se representan las unidades de código que se hayan desarrollado así como la visibilidad entre ellas. Para cada unidad se identifican los módulos que contienen. paquete B paquete A Clase A

Clase B

Clase C

Diagrama de estados Este diagrama se puede utilizar tanto el análisis de requisitos de usuario como en el diseño de la arquitectura de las aplicaciones. Un diagrama de estados se emplea cuando el estado de un sistema u objeto pueda afectar a su comportamiento. En el análisis representa los estados de un sistema, mientras que el diseño representa los estados de un objeto.

comienzo

Estado Estado var: tipo=valor entry / acción exit / acción evento / acción do / actividad

Estado

evento[condición] / acción

Estado

Estado

Estado

fin

Diagrama de emplazamiento Para representar los componentes de una plataforma hardware (servidores, estaciones de trabajo, terminales...) y software (bases de datos, servicios, aplicaciones). Es posible desarrollar varios diagramas de emplazamiento, de manera que se establezcan posibles configuraciones diferentes.

nodo componente

componente

Get in touch

Social

© Copyright 2013 - 2024 MYDOKUMENT.COM - All rights reserved.