1
UNIDAD I
INTRODUCCIÓN AL ANÁLISIS Y DISEÑO CON UML
Contenido Por qué modelamos
La importancia Cuatro principios del modelado Los planos básicos de un sistema software Modelado orientado a objetos
Qué es UML?. Presentación del UML Diagramas Utilizados en UML (ejemplos)
2
Por qué Modelamos
El modelado es una técnica de hacer
modelos, que ofrece
Una visión global del sistema.
3
Importancia de Modelar
Objetivos del Modelar:
Visualizar, especificar la estructura, proporcionan plantillas, documentan decisiones
4
Principios del Modelado
La elección de qué modelos crear, y dar forma a una solución.
Todo modelo puede ser expresado a diferentes niveles de precisión.
Los mejores modelos están ligados a la Realidad
Un único modelo no es suficiente.
5
Modelado orientado a objetos
UML es un Lenguaje de Modelado Unificado basado en una notación gráfica la cual permite:
Especificar Construir Visualizar Documentar
los objetos de un sistema
6
U M L Qué es UML?.
UML puede ser utilizado por cualquier metodología de análisis y diseño orientada a objetos para expresar los modelos de diseño.
7
Qué es UML Este lenguaje es el resultado de la unificación
de los métodos de modelado orientados a objetos de:
Booch, Rumbaugh (OMT:Object Modeling
Technique) Jacobson (OOSE:Object-Oriented Sotfware
Engineering) .
8
Historia de UMLLa notación UML se deriva de y unifica, las tres metodologías de análisis y diseño O.O. más extendidas: •Metodología de Grady Booch para la descripción de conjuntos de objetos y sus relaciones.
•Técnica de modelado orientada a objetos de James Rumbaugh (OMT: Object-Modeling Technique).
•Aproximación de Ivar Jacobson (OOSE: Object- Oriented Software Engineering) mediante la metodología de casos de uso (use case).
9
Historia de UMLEl desarrollo de UML comenzó a finales de 1994 cuando Grady Booch y Jim Rumbaugh de Rational Software Corporation empezaron a unificar sus métodos.
A finales de 1995, Ivar Jacobson y su compañía Objectory se incorporaron a Rational en su unificación, aportando el método OOSE.
10
Historia de UMLDe las tres metodologías iniciales, las de Booch y Rumbaugh pueden ser descritas como centradas en objetos, ya que sus aproximaciones se enfocan hacia el modelado de los objetos que componen el sistema, su relación y colaboración.
Por otro lado, la metodología de Jacobson es más centrada a usuario, ya que todo en su método se deriva de los escenarios de uso. UML se ha ido fomentando y aceptando como estándar desde el OMG (), que es también el origen de CORBA, el estándar líder en la industria para la programación de objetos distribuidos.
11
Historia de UMLEn 1997 UML 1.1 fue aprobada por la OMG convirtiéndose en la notación estándar de facto para el análisis y el diseño O.O.
UML es el primer método en publicar un meta-modelo en su propia notación, incluyendo la notación para la mayoría de la información de requisitos, análisis y diseño (cualquier lenguaje de modelado de propósito general debería ser capaz de modelarse a sí mismo).
12
Historia de UML
Nov ‘97 UML aprobado por el OMG
1998
1999
2000
UML 1.2
UML 1.3
UML 1.4
2005? UML 2.0
Revisiones menores
UML 1.52003
*Desarrollo de Software Orientado a Objeto usando UML,
Patricio Letelier Torres, http://www.dsic.upv.es/~uml/cur
so.ppt 13
¡UML!
Es un lenguaje estándar para escribir planos de software.
Puede visualizar, especificar, construir y documentar los componentes de un sistemas OO que involucra una gran cantidad de software.
UML es apropiado para modelar sistemas de información en empresas hasta aplicaciones web. Es un lenguaje muy expresivo , cubre todas las vistas necesarias para desarrollar y desplegar sistemas.
14
¿Dónde puede utilizarse UML?
Sistema de Información Institucionales Bancos y Servicios Financieros Telecomunicaciones Transporte Comercio Electrónica médica Ámbito científico Servicios distribuidos basados en la
Web
15
1.1 ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS
16
APLICACIÓN DEL LENGUAJE UML Y DEL ANÁLISIS Y EL
DISEÑO O.O ¿Qué significa contar con un sistema o.o que esté
bien diseñado?
Significa adquirir y utilizar habilidades prácticas en el diseño OO.
Estas destrezas son indispensables para crear sistemas de software bien diseñados, robusto y de fácil mantenimiento, utilizando la tecnología de objetos y los lenguajes de programación O.O como C++, Java, etc. 17
QUÉ SON EL ANÁLISIS Y EL DISEÑO O.O
La esencia del análisis y el diseño orientado a objetos consiste en situar el dominio de un problema y su solución lógica dentro de la perspectiva de los objetos.
Análisis Diseño Construcción
Investigación del problema
Solución Lógica Código
18
QUÉ SON EL ANÁLISIS Y EL DISEÑO O.O
Durante el análisis orientado a objetos se procura ante todo identificar y describir los objetos o conceptos dentro del dominio del problema.
Por ejemplo:
Sistema de información de la biblioteca
Algunos Conceptos son:
Libro, Biblioteca y Cliente
19
QUÉ SON EL ANÁLISIS Y EL DISEÑO O.O
Durante el diseño orientado a objetos se procura definir los objetos lógicos del software que finalmente serán implementados en un lenguaje de programación O.O.
Los objetos tienen atributos y métodos.
Ejemplo: Sistema de información de la biblioteca Objeto: Libro, Atributo titulo Método imprimir
20
QUÉ SON EL ANÁLISIS Y EL DISEÑO O.O
Finalmente, durante la construcción o programación O.O se implementan los componentes del diseño, como una clase Libro en C++ o Java, etc.
Ejemplo:
Organización de la Empresa MicroChaos
21
Un proceso de desarrollo de software es un método de organizar las actividades relacionadas con la creación, presentación y mantenimiento de los sistemas de software.
EL LENGUAJE UML Y LOS PROCESO DE DESARROLLO
22
El lenguaje UML estandariza los artefactos y la notación, pero no define un proceso oficial de desarrollo.
Algunas de las razones que explican esto:
1.- Aumentar las probabilidades de una aceptación generalizada de la notación estándar del modelado, sin la obligación de adoptar un proceso oficial.
2.- La esencia de un proceso apropiado admite mucha variación y depende de las habilidades del personal, de la razón investigación-desarrollo, de la naturaleza del tiempo, etc.
EL LENGUAJE UML Y LOS PROCESO DE DESARROLLO
23
Una vez aclaradas estas razones, procedemos a aplicar los principios generales y los pasos normales que guían un proceso eficaz.
Pasos de macronivel:
En un nivel alto, los pasos principales en la presentación de una aplicación son los siguientes:
EL LENGUAJE UML Y LOS PROCESO DE DESARROLLO
24
1.- Planeación y elaboración:
Planear, definir los requerimientos, construir
prototipos, etc. 2.- Construcción:
La creación del sistema. 3.- Aplicación:
La transición de la implementación del sistema a su uso.
EL LENGUAJE UML Y LOS PROCESO DE DESARROLLO
25
Desarrollo iterativo
Un ciclo de vida iterativo se basa en el agrandamiento y perfeccionamiento secuencial de un sistema a través de múltiples ciclos de desarrollo de análisis, diseño, implementación y pruebas.
El sistema crece al incorporar nuevas funciones en cada ciclo de desarrollo. Tras una frase preliminar de planeación y especificación, el desarrollo pasa a la fase de construcción a través de una serie de ciclos de desarrollo.
EL LENGUAJE UML Y LOS PROCESO DE DESARROLLO
26
Desarrollo iterativo
En cada ciclo se aborda un conjunto relativamente pequeño de requerimientos, pasando por el análisis, el diseño, la construcción y las pruebas. El sistema va creciendo en cada ciclo que concluye.
Esto contrasta con el ciclo clásico de la vida en cascada, en el cual las actividades (análisis y diseño, entre otras) se llevan a cabo una vez con todos los requerimientos del sistema.
EL LENGUAJE UML Y LOS PROCESO DE DESARROLLO
27
Fijación de la duración de un ciclo de desarrollo
Una estrategia muy útil en los ciclos de desarrollo consiste en limitarlo a un marco temporal, esto es, un lapso rígidamente fijo, digamos cuatro o n semanas.
En un período menor sería muy difícil terminar las actividades; en un periodo mayor la complejidad se torna abrumadora y la retroalimentación se retras.
EL LENGUAJE UML Y LOS PROCESO DE DESARROLLO
28
Bloques de Construcción UML
Bloques
Elementos
Relaciones
Diagramas
29
Bloques de Construcción UML
Elementos Relaciones Diagramas
Estructurales
Clase
Ventana O rigen T amaño A brir( ) Cerrar() M over( ) D ibujar( )
interfaz
Cadena de responsabilidad
Casos de uso Realizar Pedido
Clase activa GestorEventos
Suspender () VaciarCola()
nodo
servidor
Esperando
EstadosComportamiento Dibujar
Mensajes
Agrupación
Reglas del negocio
Anotación
componente
Interacción
30
Elementos Estructurales Elementos estructurales, son la parte estática de un
modelo Clase: representa un conjunto de objetos que
comparten los mismos atributos, operaciones, relaciones y semántica.
Publicación
Código P Cadena(2)Copias EnteroImporte Decimal(10,2)
Agregar()Consultar()Listar()
Nombre de la clase
Atributos
Operaciones
31
Elementos Estructurales Atributo: Representa una propiedad de una
entidad. Cada atributo de un objeto tiene un valor que pertenece a un dominio de valores determinado.
Objeto: Se caracteriza por tener una identidad única, un estado definido por un conjunto de valores de atributos y un comportamiento representado por sus operaciones y métodos
32
Elementos Estructurales Interfaz: define un conjunto de
especificaciones de operaciones
Colaboración: define una iteración y es una sociedad de roles y otros elementos que colaboran cooperativamente
Cadena de Responsabilidad
33
Elementos Estructurales Caso de Uso: Conjunto de secuencia de
acciones que se ejecutan y el resultado es de interés para un actor en particular.
Realizar pedido
34
Elementos Estructurales Clase Activa: Son similares a las clases
excepto que sus objetos representan elementos cuyo comportamiento es concurrente con otros elementos
Gestor Ventas
Suspender()VaciarCola()
Nombre
Operaciones
35
Elementos Estructurales Componentes: Es empaquetamiento físico
de diferentes elementos lógicos como clases, interfaces, y colaboraciones.
Orderform.java
36
Elementos Estructurales
Nodo: Es elemento físico es decir un recurso computacional
Servidor
37
Elementos Comportamiento
Son la parte dinámica, y representan comportamiento en el tiempo y el espacio.
Interacción: Conjunto de mensajes intercambiados entre objetos.
38
Estado: Identifica un período de tiempo del objeto (no instantáneo) en el cual el objeto esta esperando alguna operación, recibe cierto tipo de estímulos y especifica la secuencia de estado por las que pasa un objeto
Elementos Comportamiento
Esperado
39
Elementos Agrupación
Elementos Agrupación son las partes organizativas
Un paquete: Mecanismo de propósito general para organizar elementos.
Reglas del Negocio
40
Elementos de Anotación
Elementos de Anotación son las partes explicativas, son comentarios, para describir, clasificar, y hacer observaciones
Nota: Sirve para hacer comentarios a un conjunto de elementos
Devuelve unaCopia del objetoreceptor
41
Bloques de Construcción UML
Elementos Relaciones Diagramas Dependencia
Relación entre dos elementos uno independiente a otro dependiente y puede afectar la semántica
Asociación Son conexiones entre objetos (rol, multiplicidad, calificador)
Generalización Especificación en donde el hijo comparte la estructura y el
comportamiento del padre
Realización Es una relación semántica entre clasificadores
0...1 *Patrón empleado
42
Elementos Relaciones Diagramas
Use CaseDiagramsDiagramas
Caso de Uso
ScenarioDiagramsDiagramas
Colaboración
StateDiagramsDiagramas
Componentes
ComponentDiagramsDiagramasDespliegue
StateDiagramsDiagramas
Objecto
ScenarioDiagramsDiagramas
Estado
Use CaseDiagramsDiagramasSecuencia
StateDiagramsDiagramas
Clase
DiagramasActividades
Modelos
Bloques de Construcción UML
43
Diagramas de clases
Un Diagrama de Clases muestra un conjunto de clases, interfaces, colaboraciones y relaciones.
Cubren la vista de diseño estático de un sistema
Cuando incluyen clases activas cubren la vista de procesos estáticos
44
Rol: Se identifica con un nombre al final de la línea y describe la semántica de la relación en el sentido indicado.
Cada asociación tiene dos roles; cada rol es una dirección y puede estar representado en el nombre de la clase.
Diagramas de clasesRelación de Asociación(Rol y Multiplicidad)
45
Multiplicidad:Describe la cardinalidad de la relación, es decir, cuantos objetos de esa clase pueden participar en la relación dada.
1
Exactamente unoClase
*
Cero a másClase0. ...1 Cero a unoClase
m. n Especificada numéricamenteClase
Diagramas de clasesRelación de Asociación(Rol y Multiplicidad)
46
Diagramas de clasesEjemploVendedor
NúmeroNombreDirección :
AsignarCuotaCalcularComisiones
VentaNúmeroFechaHora
CrearCalcularImporte
DetalleVenta
NúmeroRenglónCveArtículoCantidadImporte
CalcularIVACalcularImporte
Participa en
1..*
1..*
CLASES
RELACION
ATRIBUTOS
OPERACIONES
47
Diagramas de objetos
Diagrama de objetos muestra un conjunto de objetos y sus relaciones representan instantáneas de instancias de los elementos encontrados en los diagramas de clase.
Cubren la vista de diseño y proceso estático de un sistema
48
Diagramas de objetosEjemplo
Abstracciones más generales
Conceptos básicos de la Orientación a Objetos
Vehículo
Vehículo Terrestre Vehículo aéreo
Avión HelicópteroCoche Camión
49
Diagramas de casos de uso
Diagrama de casos de uso muestra un conjunto de casos de uso y actores y sus relaciones cubren la vista de casos de uso estática de un sistema.
Estos diagramas son especialmente importantes en el modelado y organización del comportamiento de un sistema.
50
Diagramas de Casos de Uso
Cada caso de uso es una operación completa desarrollada por los actores y por el sistema en un diálogo.
El conjunto de casos de uso representa la totalidad de operaciones desarrolladas por el sistema.
51
Actor: Es un usuario del sistema, que necesita o usa alguno o algunos de los casos de uso.
Un usuario puede jugar más de un rol.
Un caso de uso puede tener varios actores. Los actores no necesitan ser humanos pueden ser sistemas externos que necesitan alguna información del sistema actual.
Diagramas de Casos de Uso
52
Tienen tres tipos de relaciones:Comunica: (comunicates): entre un actor y un caso de uso, denota la participación del actor en el caso de uso determinado. Usa (uses): Relación entre dos casos de uso, denota la inclusión del comportamiento de un escenario en otro. Extiende (extends): Relación entre dos casos, denota cuando un caso de uso es una especialización de otro. Se usa cuando se describe una variación sobre el normal comportamiento.
Diagramas de Casos de Uso
53
Un diagrama de Casos de Uso muestra la distintas operaciones que se esperan de una aplicación o sistema y cómo se relaciona con su entorno (usuario u otras aplicaciones).
Es una herramienta esencial para la captura de requerimientos y para la planificación y control de un proyecto interactivo.
Diagramas de Casos de Uso
54
Diagramas Casos de Usos
Comunica
<<use>>
Profesor
Actualizar carga academica
Actor
<<extend>>
Actualizar carga
Administrativa
Pedir Permiso
Elaborar Informe de Actividades
Elaborar Planificación de Actividad
55
Diagramas de secuencia
Diagrama de secuencia Es un diagrama de interacciones que resalta la ordenación temporal de los mensajes.
Es importante mencionar que los diagramas de interacción es un conjunto de objetos y sus relaciones, incluyendo los mensajes que pueden ser enviados entre ellos.
56
Diagrama de secuencia
:USUARIOAUTORIZADO
:TOTAL_D
ACTUALIZAR DEPOSITO F.T.
OK
Diagrama de secuencias asociadas al proceso “Actualizar Depósito”
ACTUALIZAR TOTAL_D
OK
ACTUALIZAR TOTAL_D
OK
ACTUALIZAR DEPOSITO F.T.
OK
:USUARIOAUTORIZADO
57
Diagramas de colaboración
Diagrama de colaboración es un diagrama de interacción que resalta la organización estructural de los objetos, que envían y reciben mensajes de las iteraciones que están indicadas por un número
A diferencia de los diagramas de secuencia, pueden mostrar el contexto de la operación (cuáles objetos son atributos, cuáles temporales) y ciclos en la ejecución.
58
Diagramas de colaboración
Ejemplo
Cajero<<Cajero>> Aplicación : Cuenta cheques
: Cheque : Cliente
Interfaz Registra RetiroInfoCuentaFormateada C
heq
ueO
k
NumCliente, Nombre, SaldoCuenta
5.1 ValidaCheque(numCheque) Nom
reC
lien
te
3.1.1 ObtenerNombreCliente(NumCliente)
5.1.1 Valida Cheque No Robado (NumCheque)5.1.2 Valida Cheque No Canceladop (NumCheque)
Registra Retiro1 Arranca Aplicación2 Teclea Tipo mov3 Teclea num Cuenta4 Teclea Tipo Docto5 Teclea Num Cheque
59
Diagramas de Estado
Diagrama de estados (statechart) muestra una máquina de estados, que consta de estados transiciones, eventos y actividades.
Cubren la vista dinámica de un sistema y el comportamiento de una interfaz, clase, colaboración y resaltan el comportamiento dirigido por eventos de un objeto.
60
Diagramas de Estados
Muestra el conjunto de estado por los cuales pasa un objeto durante su vida en una aplicación junto con los cambios que permiten pasar de un estado a otro
Esta representado principalmente por los siguientes elementos:
estado, elemento y transición.
61
Diagramas de EstadosEventos: Es una ocurrencia que puede causar la transición de un estado a otro de un objeto. -Condición que toma el de verdadero o falso.-Recepción de una señal o mensaje de otro objeto en el modelo.-Paso de cierto período de tiempo, después de entrar al estado o de cierta hora y fecha particular.
62
Diagramas de Estados
Transición: Es una relación de tres o más estados en una transición de múltiples fuentes o múltiples destinos.
63
Diagramas de EstadosEjemplo
Inicio
No se revisan todos los artículos/ obtiene siguiente artículo
Todos los artículos comprobados && todos los artículos disponibles
Todos los artículos comprobados && algunos artículos no en inventario
Artículo recibido Algunos artículos no en existencia Artí
culo re
cibi
do
Todo
s lo
s ar
tícul
os d
ispon
ible
s
Transición
EstadoAutotransición
Hace / revisaartículo
Hace /iniciaentrega
Espera Entregado
Comprobación Despachando
64
Diagramas de Actividades
Diagrama de actividades muestra el flujo de actividades dentro de un sistema.
Cubren la vista dinámica, son importantes al modelar el funcionamiento del un sistema y resaltan el flujo de control de objetos.
65
Diagrama de ActividadesUn diagrama de actividades es un
diagrama de estados, casi todos los estados son estados de acción, y casi todas las transiciones son enviadas al terminar la acción ejecutada en el estado anterior.
Generalmente modelan los pasos de un algoritmo y puede dar detalle a un caso de uso, un objeto o un mensaje en un objeto.
66
Diagrama de Actividades
Sirven para representar transiciones internas, sin hacer mucho énfasis en transiciones o eventos externos
Los elementos que conforman el diagrama son: acción y transición.
67
Diagrama de Actividades
Transición: Es la relación entre dos estados y se encuentran unidos por flechas
Indican que un objeto que está en el primer estado, realizará una acción especificada y entrará en el segundo estado cuando un evento implícito ocurra y unas condiciones especificas sean satisfechas
68
Diagrama de Actividades
Ejemplo
Comprueba
artículo de línea
Reordena
artículo
Asigna orden
Despacha orden
Recibe orden
Cancela orden
Autoriza pago[Fallo]
[éxito]
[en existencia]
[se necesitaordenar]
[por cada artículo]
Condición de sincronización
[existencia asignada a todos los artículos de línea y pago autorizado]
69
Diagramas de Componentes
Diagrama de componentes muestra la organización y las dependencias entre un conjunto de componentes, cubren la vista de implementación estática.
Se relacionan con diagramas de clase en que un componente se corresponde con una o más clases, interfaces o colaboraciones.
70
Diagramas de Componentes
Representa las componentes físicas de la aplicación.
LISTADO
Reservación
AGENCIA DE VIAJES Actualizar
INTERFAZ
71
Diagramas de Despliegue
Diagrama de despliegue muestra la configuración de nodos de procesamiento en tiempo de ejecución y los componentes que residen en ellos.
Su relación con los diagramas de componentes en que un nodo incluye, uno o mas componentes.
72
Diagrama de despliegue
Representa la visualización
de los componentes
sobre los dispositivos
físicos.
SERVIDOR
reservaciones
listado
<<Base de Datos >>
CLIENTE: PC
Agencia de Viajes
73
ConclusionesEn este trabajo se ha aprendido los conceptos de UML (El Lenguaje Unificado de Modelado), como es el vocabulario, reglas de construcción de modelos.
Se vio, los elementos sus relaciones y los 9 Diagramas que utiliza UML para su modelado de Sistemas
74
BibliografíaEl lenguaje unificado de
modelado
Grady BoochJames Rumbaugh
Ivar Jacobson
El libro introductorio a UML
Addison Wesley
75
Top Related