Aula 2 sobre diagramas de caso de uso, revisando brevemente os conceitos de UML, ao final da aula o aluno deverá estar capacitado para escrever diagramas de caso de uso iniciais. Nas aula 3 aprofundaremos nos relacionamentos entre casos de uso e construção de diagramas mais complexos
Aborda aspectos da elicitação, gestão e documentação dos requisitos de um software. Estudo dos desafios que o analista de sistemas precisa enfrentar. Expõe exemplos dos tipos de artefatos de requisitos que podem ser documentados. Recomenda melhores práticas para a escrita dos requisitos e casos de uso.
U.T.N. - F.R.T. Cátedra de Diseño de Sistemas. 3K1. 2011. Unidad V. Diseño de Interfaces. El Proceso de Diseño de Interfaces del Usuario. Roger Pressman
Aula 2 sobre diagramas de caso de uso, revisando brevemente os conceitos de UML, ao final da aula o aluno deverá estar capacitado para escrever diagramas de caso de uso iniciais. Nas aula 3 aprofundaremos nos relacionamentos entre casos de uso e construção de diagramas mais complexos
Aborda aspectos da elicitação, gestão e documentação dos requisitos de um software. Estudo dos desafios que o analista de sistemas precisa enfrentar. Expõe exemplos dos tipos de artefatos de requisitos que podem ser documentados. Recomenda melhores práticas para a escrita dos requisitos e casos de uso.
U.T.N. - F.R.T. Cátedra de Diseño de Sistemas. 3K1. 2011. Unidad V. Diseño de Interfaces. El Proceso de Diseño de Interfaces del Usuario. Roger Pressman
El Lenguaje Unificado de Modelado (UML) fue creado para forjar un lenguaje de modelado visual común y semántica y sintácticamente rico para la arquitectura, el diseño y la implementación de sistemas de software complejos, tanto en estructura como en comportamiento.
Existen dos tipos principales de diagramas UML: diagramas de estructura y diagramas de comportamiento (y dentro de esas categorías se encuentran varios otros). Estas variaciones existen para representar los numerosos tipos de escenarios y diagramas que usan los diferentes tipos de personas.
UML se utiliza principalmente en el desarrollo de software orientado a objetos. Al ampliar el estándar en la versión 2.0, también es adecuado para visualizar procesos empresariales.
ascensor o elevador es un sistema de transporte vertical u oblicuo, diseñado...LuisLobatoingaruca
Un ascensor o elevador es un sistema de transporte vertical u oblicuo, diseñado para mover principalmente personas entre diferentes niveles de un edificio o estructura. Cuando está destinado a trasladar objetos grandes o pesados, se le llama también montacargas.
Aletas de Transferencia de Calor o Superficies Extendidas.pdfJuanAlbertoLugoMadri
Se hablara de las aletas de transferencia de calor y superficies extendidas ya que son muy importantes debido a que son estructuras diseñadas para aumentar el calor entre un fluido, un sólido y en qué sitio son utilizados estos materiales en la vida cotidiana
Metodología - Proyecto de ingeniería "Dispensador automático"cristiaansabi19
Esta presentación contiene la metodología del proyecto de la materia "Introducción a la ingeniería". Dicho proyecto es sobre un dispensador de medicamentos automáticos.
2. UML
• Es un lenguaje gráfico para visualizar,
especificar, construir y documentar un sistema
de software. UML ofrece un estándar para
describir un "plano" del sistema (modelo),
incluyendo aspectos conceptuales tales como
procesos de negocios y funciones del sistema, y
aspectos concretos como expresiones de
lenguajes de programación, esquemas de bases
de datos y componentes de software
reutilizables.
3. UML
• UML (Unified Modeling Language) es un lenguaje que
permite modelar, construir y documentar los elementos
que forman un sistema software orientado a objetos. Se
ha convertido en el estándar de facto de la industria,
debido a que ha sido impulsado por los autores de los
tres métodos más usados de orientación a objetos:
Grady Booch, Ivar Jacobson y Jim Rumbaugh. Estos
autores fueron contratados por la empresa Rational
Software Co. para crear una notación unificada en la
que basar la construcción de sus herramientas CASE.
En el proceso de creación de UML han participado, no
obstante, otras empresas de gran peso en la industria
como Microsoft, Hewlett-Packard, Oracle o IBM, así
como grupos de analistas y desarrolladores.
4. UML
• Qué no es UML
• UML no es un método de desarrollo. No te va
a decir cómo pasar del análisis al diseño y de
este al código. No son una serie de pasos que
te llevan a producir código a partir de unas
especificaciones.
• UML al no ser un método de desarrollo es
independiente del ciclo de desarrollo que vayas
a seguir, puede encajar en un tradicional ciclo
en cascada, o en un evolutivo ciclo en espiral o
incluso en los métodos ágiles de desarrollo.
6. DIAGRAMAS DE COMPORTAMIENTO
Los Diagramas de Comportamiento se enfatizan en las partes dinámicas del
sistema. Estos son los verbos de un modelo y representan comportamiento en
el tiempo y en el espacio:
• Diagramas de Casos de Uso
• Diagramas de secuencia
• Diagramas de Colaboración
• Diagrama de estado
• Diagrama de Actividad
7. DIAGRAMAS DE COMPORTAMIENTO
Diagramas de Casos de Uso
• El diagrama de casos de uso representa la
forma en como un Cliente (Actor) opera con el
sistema en desarrollo, además de la forma, tipo
y orden en como los elementos interactúan
(operaciones o casos de uso). Un diagrama de
casos de uso consta de los siguientes
elementos:
• Actor.
• Casos de Uso.
• Relaciones de Uso, Herencia y Comunicación
8. DIAGRAMAS DE COMPORTAMIENTO
Diagramas de Casos de Uso
• Actor
Un Actor es un rol que un
usuario juega con
respecto al sistema.
Un Actor no
necesariamente
representa a una persona
en particular, sino más
bien la labor que realiza
frente al sistema
9. DIAGRAMAS DE COMPORTAMIENTO
Diagramas de Casos de Uso
• Caso de Uso:
Es una operación o tarea
específica que se realiza
tras una orden de algún
agente externo, sea
desde una petición de un
actor o bien desde la
invocación desde otro
caso de uso
10. DIAGRAMAS DE COMPORTAMIENTO
Diagramas de Casos de Uso
Relaciones:
• Asociación
Es el tipo de relación más
básica que indica la
invocación desde un
actor o caso de uso a
otra operación (caso de
uso). Dicha relación se
denota con una flecha
simple.
11. DIAGRAMAS DE COMPORTAMIENTO
Diagramas de Casos de Uso
Relaciones:
• Generalización:
Es una relación que amplía la
funcionalidad de un Caso de Uso
o refina su funcionalidad original
mediante el agregado de nuevas
operaciones y/o atributos y/o
secuencias de acciones.
12. DIAGRAMAS DE COMPORTAMIENTO
Diagramas de Casos de Uso
Relaciones:
• Extensión (extends):
Es una relación que amplía la
funcionalidad de un Caso de Uso
mediante la extensión de sus
secuencias de acciones.
Se utiliza cuando un caso de uso
es similar a otro (características).
13. DIAGRAMAS DE COMPORTAMIENTO
Diagramas de Casos de Uso
Relaciones:
• Inclusión (include)
Es una relación mediante la cual
se re-usa un Caso de Uso
encapsulado en distintos
contextos a través de su
invocación desde otros Casos de
Uso.
15. DIAGRAMAS DE COMPORTAMIENTO
Diagramas de interacción
• Los diagramas de interacción se utilizan para modelar
los aspectos dinámicos de un sistema, lo que conlleva
modelar instancias concretas o prototípicas de clases
interfaces, componentes y nodos, junto con los
mensajes enviados entre ellos, todo en el contexto de un
escenario que ilustra un comportamiento.
• Hay dos tipos de diagrama de interacción:
Diagramas de Secuencia
Diagramas de Colaboración.
16. DIAGRAMAS DE COMPORTAMIENTO
Diagramas de Secuencia
• Un diagrama de Secuencia muestra una
interacción ordenada según la secuencia
temporal de eventos.
• Muestra los objetos participantes en la
interacción y los mensajes que se intercambian
ordenados según su secuencia en el tiempo.
• Resaltan el orden temporal de los mensajes que
se intercambian.
17. DIAGRAMAS DE COMPORTAMIENTO
Diagramas de Secuencia
• El eje vertical representa el
tiempo.
• En el eje horizontal se colocan
los objetos y actores
participantes en la interacción,
sin un orden prefijado.
• Cada objeto o actor tiene una
línea vertical, y los mensajes
se representan mediante
flechas entre los distintos
objetos.
• El tiempo fluye de arriba abajo.
19. DIAGRAMAS DE COMPORTAMIENTO
Diagramas de Colaboración
• Un Diagrama de Colaboración muestra una
interacción organizada basándose en los
objetos que toman parte en la interacción y los
enlaces entre los mismos
• A diferencia de los Diagramas de Secuencia, los
Diagramas de Colaboración muestran las
relaciones entre los roles de los objetos.
• La secuencia de los mensajes y los flujos de
ejecución concurrentes deben determinarse
explícitamente mediante números de secuencia.
20. DIAGRAMAS DE COMPORTAMIENTO
Diagramas de Colaboración
• Un Diagrama de Colaboración muestra una
interacción organizada basándose en los
objetos que toman parte en la interacción y los
enlaces entre los mismos
• A diferencia de los Diagramas de Secuencia, los
Diagramas de Colaboración muestran las
relaciones entre los roles de los objetos.
• La secuencia de los mensajes y los flujos de
ejecución concurrentes deben determinarse
explícitamente mediante números de secuencia.
21. DIAGRAMAS DE COMPORTAMIENTO
Diagramas de Colaboración
• Un diagrama de colaboración
se construye :
• Primero se colocan los objetos
que participan en la
colaboración como nodos de
un grafo.
• Después se representa los
enlaces que conectan esos
objetos como arcos de grafo
• Por último a los enlaces se le
escriben los mensajes que
envían y reciben los objetos.
23. DIAGRAMAS DE COMPORTAMIENTO
Diagramas de Estados
• Un Diagrama de Estados muestra la
secuencia de estados por los que pasa un
caso de uso o un objeto a lo largo de su
vida, indicando qué eventos hacen que se
pase de un estado a otro y cuáles son las
respuestas y acciones que genera.
• Son importantes para describir el
comportamiento de un sistema reactivo.
24. DIAGRAMAS DE COMPORTAMIENTO
Diagramas de Estados
Estados
• Un estado es una condición o
situación en la vida de un objeto
durante la cual satisface alguna
condición, realiza una actividad o
espera un evento.
• Un objeto puede estar en
cualquier estado durante una
cantidad de tiempo determinado.
Un diagrama de estados es un
grafo cuyos nodos son estados y
cuyos arcos dirigidos son
transiciones etiquetadas con los
nombres de los eventos.
26. DIAGRAMAS DE COMPORTAMIENTO
Diagramas de Actividades
• Los diagramas de actividad muestran el
orden en el que se van realizando tareas
en un sistema.
• Un diagrama de actividades contiene:
• Estados de actividad
• Estados de acción
• Transiciones
• Objetos
27. DIAGRAMAS DE COMPORTAMIENTO
Diagramas de Actividades
Estados de actividad y estados de acción
• La representación de ambos es un
rectángulo con las puntas redondeadas,
en cuyo interior se representa bien una
actividad o bien una acción.
29. DIAGRAMAS DE COMPORTAMIENTO
Diagramas de Actividades
Transiciones
• Las transiciones reflejan el paso
de un estado a otro, bien sea de
actividad o de acción.
• Esta transición se produce como
resultado de la finalización del
estado del que parte el arco
dirigido que marca la transición.
• Como todo flujo de control debe
empezar y terminar en algún
momento, podemos indicar esto
utilizando dos disparadores de
inicio y fin
30. DIAGRAMAS DE COMPORTAMIENTO
Diagramas de Actividades
Bifurcaciones
• Para representar caminos
alternativos o bifurcación se
utiliza como símbolo el rombo.
• La bifurcación tendrá una
transición de entrada y dos o
más de salida.
• En cada transición de salida
se colocará una expresión
booleana que será evaluada
una vez al llegar a la
bifurcación.
31. DIAGRAMAS DE COMPORTAMIENTO
Diagramas de Actividades
División y unión
• No sólo existe el flujo
secuencial y la bifurcación,
también hay algunos casos en
los que se requieren tareas
concurrentes.
• UML representa gráficamente
el proceso de división, que
representa la concurrencia, y
el momento de la unión de
nuevo al flujo de control
secuencial, por una línea
horizontal ancha.
32. DIAGRAMAS DE COMPORTAMIENTO
Diagramas de Actividades
Calles
• Cuando se modelan flujos de
trabajo de organizaciones, es
especialmente útil dividir los
estados de actividades en grupos,
cada grupo tiene un nombre
concreto y se denominan calles.
• Cada calle representa a la parte
de la organización responsable de
las actividades que aparecen en
esa calle.
34. II. DIAGRAMAS ESTRUCTURALES
Los Diagramas de Estructura enfatizan en los elementos que
deben existir en el sistema modelado:
• Diagrama de clases
• Diagrama de componentes
• Diagrama de objetos
• Diagrama de estructura compuesta
Diagrama de despliegue
• Diagrama de paquetes
35. 1. Diagramas de Clases
• Un diagrama de clases es un tipo de diagrama
estático que describe la estructura de un
sistema mostrando sus clases, atributos y las
relaciones entre ellos. Los diagramas de clases
son utilizados durante el proceso de análisis y
diseño de los sistemas, donde se crea el diseño
conceptual de la información que se manejará
en el sistema, y los componentes que se
encargaran del funcionamiento y la relación
entre uno y otro.
36. Diagrama de Clases
Definiciones
• Propiedades también llamados atributos o
características, son valores que corresponden a un
objeto, como color, material, cantidad, ubicación.
Generalmente se conoce como la información detallada
del objeto. Suponiendo que el objeto es una puerta, sus
propiedades serían: la marca, tamaño, color y peso.
• Operaciones son aquellas actividades o verbos que se
pueden realizar con/para este objeto, como por ejemplo
abrir, cerrar, buscar, cancelar, acreditar, cargar. De la
misma manera que el nombre de un atributo, el nombre
de una operación se escribe con minúsculas si consta
de una sola palabra. Si el nombre contiene más de una
palabra, cada palabra será unida a la anterior y
comenzará con una letra mayúscula, a excepción de la
primera palabra que comenzará en minúscula. Por
ejemplo: abrirPuerta, cerrarPuerta, buscarPuerta, etc.
37. Diagrama de Clases
Definiciones
• Interfaz es un conjunto de operaciones y/o propiedades
que permiten a un objeto comportarse de cierta manera,
por lo que define los requerimientos mínimos del objeto.
• Herencia se define como la reutilización de un objeto
padre ya definido para poder extender la funcionalidad
en un objeto hijo. Los objetos hijos heredan todas las
operaciones y/o propiedades de un objeto padre. Por
ejemplo: Una persona puede subdividirse en
Proveedores, Acreedores, Clientes, Accionistas,
Empleados; todos comparten datos básicos como una
persona, pero además tendrá información adicional que
depende del tipo de persona, como saldo del cliente,
total de inversión del accionista, salario del empleado,
etc.
38. Diagrama de Clases
• Una clase se representa
mediante una caja subdividida
en tres partes: En la superior
se muestra el nombre de la
clase, en la media los atributos
y en la inferior las
operaciones. Una clase puede
representarse de forma
esquemática, con los atributos
y operaciones suprimidos,
siendo entonces tan solo un
rectángulo con el nombre de la
clase. En la Figura 5 se ve
cómo una misma clase puede
representarse a distinto nivel
de detalle según interese, y
según la fase en la que se
esté.
39. Diagrama de Clases
Atributos
En UML, los atributos se muestran al menos con su nombre, y también
pueden mostrar su tipo, valor inicial y otras propiedades. Los
atributos también pueden ser mostrados visualmente:
• + Indica atributos públicos
• # Indica atributos protegidos
• - Indica atributos privados
Operaciones
• La operaciones (métodos) también se muestan al menos con su
nombre, y pueden mostrar sus parámetros y valores de retorno. Las
operaciones, al igual que los atributos, se pueden mostrar
visualmente:
• + Indica operaciones públicas
• # Indica operaciones protegidas
• - Indica operaciones privadas
41. Diagrama de Clases
Asociaciones
• Las asociaciones entre dos clases se
representan mediante una línea que
las une. La línea puede tener una
serie de elementos gráficos que
expresan características particulares
de la asociación.
Generalización
• La herencia es uno de los
conceptos fundamentales de la
programación orientada a
objetos, en la que una clase
“recoge” todos los atributos y
operaciones de la clase de la que
es heredera, y puede
alterar/modificar algunos de ellos,
así como añadir más atributos y
operaciones propias
• En UML, una asociación de
generalización entre dos clases,
coloca a estas en una jerarquía
que representa el concepto de
herencia de una clase derivada de
la clase base. En UML, las
generalizaciones se representan
por medio de una línea que
conecta las dos clases, con una
flecha en el lado de la clase base.
42. Diagrama de Clases
Asociaciones - Multiplicidad
• La multiplicidad es una
restricción que se pone a una
asociación, que limita el
número de instancias de una
clase que pueden tener esa
asociación con una instancia
de la otra clase. Puede
expresarse de las siguientes
formas:
• Con un número fijo: 1.
• Con un intervalo de valores:
2..5.
• Con un rango en el cual uno
de los extremos es un
asterisco. Significa que es un
intervalo abierto. Por ejemplo,
2..* significa 2 o más.
• Con una combinación de
elementos como los anteriores
separados por comas: 1, 3..5,
7, 15..*.
• Con un asterisco: * . En este
caso indica que puede tomar
cualquier valor (cero o más).
43. Diagrama de Clases
Asociaciones - Roles
Para indicar el papel que juega una clase en una asociación se puede
especificar un nombre de rol.
45. Diagrama de Clases
Asociaciones
Acumulación
• Las acumulaciones son tipos especiales de asociaciones en las que
las dos clases participantes no tienen un estado igual, pero
constituyen una relación “completa”. Una acumulación describe
cómo se compone la clase que asume el rol completo de otras
clases que se encargan de las partes. En las acumulaciones, la
clase que actúa como completa, tiene una multiplicidad de uno.
• En UML, las acumulaciones están representadas por una
asociación que muestra un rombo en uno de los lados de la clase
completa.
46. Diagrama de Clases
Asociaciones
Composición
• Las composiciones son asociaciones que representan
acumulaciones muy fuertes. Esto significa que las
composiciones también forman relaciones completas,
pero dichas relaciones son tan fuertes que las partes no
pueden existir por sí mismas. Únicamente existen como
parte del conjunto, y si este es destruido las partes
también lo son.
• En UML, las composiciones están representadas por un
rombo sólido al lado del conjunto
47. Diagrama de Clases
Asociaciones
Herencia
• Indica que una subclase
hereda los métodos y
atributos especificados
por una Super Clase, por
ende la Subclase además
de poseer sus propios
métodos y atributos,
poseerá las
características y atributos
visibles de la Super Clase
(public y protected),
ejemplo:
50. DIAGRAMA DE OBJETOS
• Los diagramas de objetos modelan las instancias de
elementos contenidos en los diagramas de clases.
Un diagrama de objetos muestra un conjunto de
objetos y sus relaciones en un momento concreto.
• Los diagramas de objetos se emplean para modelar
la vista de diseño estática o la vista de procesos
estática de un sistema al igual que se hace con los
diagramas de clases, pero desde la perspectiva de
instancias reales o prototípicas. Esta vista sustenta
principalmente los requisitos funcionales de un
sistema. Los diagramas de objetos permiten
modelar estructuras de datos estáticas,
52. DIAGRAMA DE PAQUETES
• Los diagramas de paquetes se usan para reflejar la organización de
paquetes y sus elementos. Cuando se usan para representaciones,
los diagramas de paquete de los elementos de clase se usan para
proveer una visualización de los espacios de nombres. Los usos
más 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.
• En el Lenguaje Unificado de Modelado, un diagrama de paquetes
muestra como un sistema está dividido en agrupaciones lógicas
mostrando las dependencias entre esas agrupaciones. Dado que
normalmente un paquete está pensado como un directorio, los
diagramas de paquetes suministran una descomposición de la
jerarquía lógica de un sistema
55. DIAGRAMA DE COMPONENTES
• Un diagrama de componentes muestra las
organizaciones y dependencias lógicas entre
componentes software, sean éstos componentes de
código fuente, binarios o ejecutables. Desde el
punto de vista del diagrama de componentes se
tienen en consideración los requisitos relacionados
con la facilidad de desarrollo, la gestión del
software, la reutilización, y las restricciones
impuestas por los lenguajes de programación y las
herramientas utilizadas en el desarrollo. Los
elementos de modelado dentro de un diagrama de
componentes serán componentes y paquetes.
56. DIAGRAMA DE COMPONENTES
• Dado que los diagramas de componentes muestran
los componentes software que constituyen una
parte reusable, sus interfaces, y su interrelaciones,
en muchos aspectos se puede considerar que un
diagrama de componentes es un diagrama de clases
a gran escala. Cada componente en el diagrama
debe ser documentado con un diagrama de
componentes más detallado, un diagrama de clases,
o un diagrama de casos de uso.
• Normalmente los diagramas de componentes se
utilizan para modelar código fuente, versiones
ejecutables, bases de datos físicas.
57. Diagramas de Componentes
Definición
Un componente es una parte física y reemplazable de un sistema.
nombre agente.java
agentefraudes.dll
Realiza
AgenteFraudes
PoliticaFraudes
BuscarPatrones
system::dialog.dll
{version = 2.0.1}
Ej:
58. DIAGRAMA DE ESTRUCTURA
COMPUESTA
• Un diagrama de estructura compuesta es
un diagrama que muestra la estructura
interna de un clasificador, incluyendo sus
puntos de interacción a otras partes del
sistema. Esto muestra la configuración y
relación de las partes que juntas realizan
el comportamiento de clasificador
contenido
59. DIAGRAMA DE ESTRUCTURA
COMPUESTA
• Se describe la forma en que las clases
se pueden mostrar como elementos
compuestos exponiendo interfaces y
conteniendo puertos y partes.
• Una parte es un elemento que
representa un conjunto de una o más
instancias que pertenecen a una
instancia del clasificador contenida.
Por ejemplo, si una instancia de
diagrama se apropia de un conjunto
de elementos gráficos, luego los
elementos gráficos se pueden
representar como partes, si fuera útil
hacer eso para modelar algún tipo de
relación entre ellos. Tener en cuenta
que una parte se puede quitar de sus
padres antes de que el padre se
elimine, para que la parte no se
elimine al mismo tiempo.