Liderazgo y Trabajo en Equipo

INGENIERÍA DEL SOFTWARE II TEMA 1
Introducción
• Visualizar,
especificar, construir y documentar sistemas
Orientados a Objetos (O.O.) es el propósito del Lenguaje
Unificado de Modelado (UML. Unified Modeling
Language).
Jorge Salamanca Escorial 1

Introducción
• Una empresa de software de éxito es aquella que produce de
manera consistente software de calidad que satisface las necesidades
de sus usuarios.
• Una empresa que puede desarrollar este software de forma
predecible y puntual, con un uso eficiente y efectivo de recursos, tanto
humanos como materiales, tendrá un negocio sostenible.
• Para hacer todo esto de forma consistente y predecible, con una
estimación de los costes del sistema en cada etapa de su vida hay
que disponer de un proceso de desarrollo sólido que pueda adaptarse
a las necesidades cambiantes del problema en cuestión y de la
tecnología.

Introducción
• La importancia de modelar. El modelado es una técnica de
ingeniería probada y bien aceptada.
• El modelado es una simplificación de la realidad.
• El modelado es una parte central de las actividades que conducen
a la producción de buen software.
• Construimos modelos para comunicar la estructura deseada y el
comportamiento de nuestro sistema.
• Construimos modelos para visualizar y controlar la arquitectura del
sistema.
• Construimos modelos para comprender mejor el sistema que
estamos construyendo, muchas veces descubriendo oportunidades
para la simplificación y la reutilización.

Introducción
• Los modelos nos proporcionan plantillas que nos guían en la
construcción de un sistema.
• Construimos modelos para controlar y minimizar el riesgo.
• Finalmente, los modelos documentan las decisiones que hemos
adoptado.
• El modelado no es exclusivo de los grandes sistemas, simplemente

construimos modelos de sistemas complejos, principalmente porque
es más habitual no comprender el sistema en su totalidad.

Principios del modelado
• La elección de qué modelos crear tiene una profunda influencia
sobre cómo se acomete un problema y como se da forma a una
solución.
– Esto es, hay que elegir bien los modelos, así estos ofrecerán una
comprensión que no podríamos obtener de otra forma.
– Por el contrario modelos erróneos nos desorientaran, centrando el
problema en cuestiones irrelevantes.
• Todo modelo puede ser expresado a diferentes niveles de

precisión.
– Los mejores modelos son aquellos que permiten elegir el grado de
detalle, dependiendo que quién esté viendo el sistema.

• Los mejores modelos están ligados a la realidad.
– Como hemos dicho un modelo es una simplificación de la realidad,
para ello se deben usar modelos que tengan una clara conexión con la
realidad.
– Hay que asegurarse que en dicha simplificación no perdemos ningún
detalle importante.
– En las técnicas de análisis estructurado es posible encontrar
diferencias entre el modelo de análisis y el modelo de diseño. En
ocasiones esto hace que el sistema analizado y el construido diverjan
con el paso del tiempo.
– En los técnicas de análisis O.O., es posible conectar las vistas
independientes de un sistema en un todo semántico.
• Un único modelo no es suficiente.

– Cualquier sistema

•Un único modelo no es suficiente.
– Cualquier sistema no trivial se aborda mejor a través de un pequeño
conjunto de modelos casi independientes.
– Esta independencia parcial nos permitirá construir y estudiar
separadamente dichos modelos pero siendo capaces de
interrelacionarlos.
– Así, en el modelado O.O. nos encontraremos con vistas
complementarias: vista de casos de uso (que muestre los requisitos del
sistema), vista de diseño (que capture el vocabulario del espacio del
problema y del espacio de la solución), una vista de procesos (que
modele la distribución de los procesos e hilos del sistema, una vista de
implementación (que se ocupe de la realización física del sistema) y una
vista de despliegue (que se centre en las cuestiones de ingeniería del
sistema.

Modelado orientado a objetos
• En el software nos encontramos varias formas de enfocar un
modelo, siendo las más comunes la perspectiva algorítmica y al
perspectiva O.O.
– La visión tradicional del desarrollo de software toma una perspectiva
algorítmica. En este enfoque el bloque principal de construcción de todo
el Sw. es el procedimiento o función.
– Los desarrolladores se centran en cuestiones de control y
descomposición de algoritmos grandes en otros más pequeños. Cuando
los requisitos cambian y el sistema crece, los sistemas construidos bajo
este enfoque se vuelven muy difíciles de mantener.
– La visión actual del desarrollo de Sw. toma una perspectiva O.O. En

este enfoque el principal bloque de construcción de todos los sistemas
Sw. es el objeto o clase.

Modelado orientado a objetos
– Un objeto es una abstracción, extraída del vocabulario del problema o
del espacio de la solución: una clase es una descripción de un conjunto
de objetos similares.
– Todo objeto tiene identidad (puede nombrarse o distinguirse de otros
objetos), estado (generalmente hay unos datos asociados a él), y
comportamiento (se le pueden hacer cosas al objeto y él puede hacer
cosas a otros objetos.

Métodos estructurados…

… y Métodos Orientados a Objetos

UML
• UML es un lenguaje para Visualizar, especificar construir y
documentar.
– Visualizar. La visualización de un sistema software plantearía
problemas de comunicación de los modelos conceptuales entre
personas implicadas en el desarrollo si esa comunicación no estuviera
regida por el mismo lenguaje.
UML permite visualizar símbolos gráficos detrás de los cuales hay una
semántica bien definida, esto permite que distintas personas
involucradas en el proyecto puedan interpretar el modelo sin
ambigüedad.
– Especificar. En este contexto, especificar significa construir modelos
precisos, sin ambigüedades y completos. En este sentido, UML permite
especificar todas las decisiones de análisis, diseño e implementación
que se realizan en un gran proyecto Sw.

UML
– Construir. UML no es un lenguaje de programación visual, pero en sus
modelos se pueden establecer correspondencias hacia lenguajes de
programación (Java, C++,…); es lo que se ha denominado ingeniería
directa.
– Documentar. Una organización de desarrollo software genera una
serie de información, a parte del código ejecutable.
Así, si la forma de trabajar es correcta, tendremos unos requisitos, una
arquitectura, un diseño, una planificación del proyecto, pruebas, unos
prototipos, versiones.
Esta información generada puede tratarse de forma más o menos
formal, se considera crítica para controlar, medir y comunicar que
requiera un sistema durante su desarrollo.
UML se puede utilizar para generar la documentación de arquitectura,
proporciona un lenguaje para expresar requisitos y pruebas, además
permite modelar las actividades de planificación de proyectos y gestión
de versiones.

Entorno de la Ing. del Soft.
Rational Rose,
Together Rose,…
HERRAMIENTAS
UML
TÉCNICAS
UP
PROCESO
• Proceso: Define el marco de trabajo y permite un desarrollo racional

de la Ing. del Soft.
• Técnicas: Indican como visualizar, especificar, construir y
documentar el Sw.
• Herramientas: Proporcionan el soporte automático para el proceso y
las técnicas.

Entorno de la Ing. del Soft.
• A este conjunto, proceso, técnica (notación) y herramientas es a lo
que se ha llamado triángulo del éxito de un proyecto software.
• Así, es necesario disponer de un proceso, ser capaces de
comunicar dicho proceso (notación) y tener una serie de
herramientas para plasmar ambos. (visualizar Æ especificar
Ædocumentar)
Notación
Proceso Herramienta

Evolución UML

Evolución UML
• El UML es la consecuencia de aglutinar diversos enfoques,
principalmente los de Booch, Rumbaugh y Jacobson que desde
Rational impulsaron la consecución de UML como lenguaje estándar
de modelado, aceptado por el OMG (Object Management Group).

Modelo Conceptual
• Para comprender UML es necesario adquirir un modelo conceptual del
lenguaje, en particular conocer tres elementos principales:
– los bloques básicos de construcción de UML
– las reglas que dictan como se pueden combinar esos bloques.
– algunos mecanismos comunes que se aplican a través de
UML.

Modelo Conceptual
Bloques básicos de construcción
• El vocabulario de UML incluye tres clases de bloques de
construcción:
– Elementos. Son abstracciones en el modelo
– Relaciones. Ligan elementos entre sí.
– Diagramas. Agrupan colecciones interesantes de elementos y
relaciones.

Modelo Conceptual
• Elementos. Encontramos cuatro tipos de elementos en UML
– Elementos estructurales.
– Elementos de comportamiento.
– Elementos de agrupación.
– Elementos de anotación.

Modelo Conceptual
• Elementos.
– Elementos estructurales
• Son, en su mayoría, las partes estáticas de un modelo, y representan
cosas que son conceptuales o materiales, hay siete tipos.
Clase. Es una descripción de un conjunto de objetos que comparten los
mismos atributos, operaciones, relaciones y semántica. Una clase
implementa una o más interfaces.
Se representa como un rectángulo en el que se incluyen nombre,
atributos y operaciones.
Ventana
origen
tamaño
abrir()
cerrar()
mover()
dibujar()

Modelo Conceptual
• Elementos.
Interfaz. Es una colección de operaciones que especifican un servicio de
una clase o componente, por lo tanto una interfaz describe el
comportamiento visible externamente de ese elemento.
Puede representar el comportamiento completo de una clase o sólo una
parte de ese comportamiento.
Define un conjunto de especificaciones de operaciones, pero nunca un
conjunto de implementaciones de operaciones.
Suele aparecer conectada a la clase o componente que la realiza y se
representa como un círculo junto a su nombre.
Ortografía

Modelo Conceptual
• Elementos.
Colaboración. Define una interacción y es una sociedad de roles y otros
elementos que colaboran para proporcionar un comportamiento
cooperativo mayor que la suma de los comportamientos de sus
elementos.
Una clase puede participar en varias colaboraciones.
Estas colaboraciones representan la implementación de patrones que
forman un sistema.
Se representa como una elipse de borde discontinuo.
Cadena de
responsabilidad

Modelo Conceptual
• Elementos.
Caso de uso. Es una descripción de un conjunto de secuencias de
acciones que un sistema ejecuta y que produce un resultado observable
de interés para un actor particular.
Se utiliza para estructurar los aspectos de ciomportamiento en un
modelo.
Un caso de uso es realizado por una colaboración.
Se representa como una elipse borde continuo.
Realizar pedido

Modelo Conceptual
• Elementos.
Los tres elementos restantes (clases activas, componentes y nodos) son
todos similares a las clases, en cuanto que describen un conjunto de
objetos que comparten los mismos atributos, operaciones, relaciones y
semántica.
Son necesarios para modelar ciertos aspectos de un sistema O.O.

Modelo Conceptual
• Elementos.
Clase activa. Es una clase cuyos objetos tienen uno o mas procesos o
hilos de ejecución y por lo tanto pueden dar origen a actividades de
control, esto es, los objetos representan elementos cuyo comportamiento
es concurrente con otros elementos.
Se representa como una clase pero con líneas más gruesas.
Gestor eventos
suspender()
vaciarCola()

Modelo Conceptual
• Elementos.
Los dos elementos restantes (componentes y nodos) también son
diferentes. Representan elementos físicos, mientras los anteriores
representan cosas conceptuales o lógicas.
Componente. Es una parte física y reemplazable de un sistema que
conforma con un conjunto de interfaces y proporciona la
implementación de dicho conjunto.
Representa típicamente el encapsulamiento físico de diferentes
elementos lógicos, como clases, interfaces y colaboraciones.
orderform.java

Modelo Conceptual
• Elementos.
Nodo. Es un elemento físico que existe en tiempo de ejecución y
representa un recurso computacional, que por lo general dispone de
algo de memoria y, con frecuencia, capacidad de procesamiento.
Un conjunto de componentes puede residir en un nodo y puede migrar
de un nodo a otro.
Servidor

Modelo Conceptual
• Elementos.
Estos siete elementos, son los elementos estructurales básicos que se
pueden incluir en un modelo UML.
Existen variaciones de estos elementos, tales como actores, señales,
utilidades, procesos e hilos, aplicaciones, documentos, archivos,
bibliotecas, páginas y tablas.

Modelo Conceptual
• Elementos.
– Elementos de comportamiento
• Son las partes dinámicas de los modelos UML, representan
comportamiento en el tiempo y el espacio. Hay dos tipos principales
de elementos
Interacción. Es un comportamiento que comprende un conjunto de
mensajes intercambiados entre un conjunto de objetos, dentro de un
contexto particular, para alcanzar un propósito específico.
El comportamiento de una sociedad de objetos o una operación
individual puede especificarse con una interacción.
Involucra muchos otros elementos, mensajes, secuencias de acción
(el comportamiento invocado por un mensaje) y enlaces (conexiones
entre objetos.
Se representa como una línea dirigida, incluyendo el nombre de su
operación
dibujar

Modelo Conceptual
• Elementos.
Máquina de estados. Es un comportamiento que especifica las
secuencias de estados por las que pasa un objeto o una interacción
durante su vida en respuesta a eventos, junto con sus reacciones a
estos eventos.
El comportamiento de una clase o una colaboración de clases puede
especificarse con este elemento.
Involucra a otros elementos, incluyendo estados, transiciones (flujo
de un estado a otro, eventos (que disparan una transición) y
actividades (la respuesta a una transición)
Esperando

Modelo Conceptual
• Elementos.
En el modelo UML estos elementos están conectados normalmente a
diversos elementos estructurales, principalmente clases,
colaboraciones y objetos.

Modelo Conceptual
• Elementos.
– Elementos de agrupación
• Son las partes organizativas de los modelos UML, son las cajas en
las que puede descomponerse un modelo. Hay un elemento de
agrupación principal, los paquetes.
Paquete. Es un mecanismo de propósito general para organizar
elementos en grupos. Los elementos estructurales, de
comportamiento, e incluso otros elementos de agrupación pueden
incluirse en un paquete.
Al contrario que los componentes (que existen en tiempo de
ejecución) un paquete es algo puramente conceptual (sólo existe en
tiempo de desarrollo)
Reglas del negocio

Modelo Conceptual
• Elementos.
– Elementos de anotación
• Son las partes explicativas de los modelos UML. Son comentarios
que se pueden aplicar para describir, clarificar y hacer observaciones
sobre cualquier elemento de un modelo. Hay un elemento de
anotación principal, la nota.
Nota. Es un símbolo para mostrar restricciones y comentarios junto a
un elemento.
Se utilizan para adornar los diagramas con restricciones o
comentarios que se expresen mejor en texto formal o informal.
Se representa como un rectángulo con una esquina doblada.
Devuelve una
copia del objeto
receptor

Modelo Conceptual
• Relaciones. Encontramos cuatro tipos de relaciones en UML
– Dependencia.
– Asociación.
– Generalización.
– Realización.

Modelo Conceptual
• Relaciones.
– Dependencia. Es una relación semántica entre dos elementos, en la
cual un cambio en un elemento (el elemento independiente) puede
afectar a la semántica del otro elemento (el elemento dependiente)
– Asociación. Es una relación estructural que describe un conjunto de

enlaces, los cuales son conexiones entre objetos. La agregación es un
tipo especial de asociación que representa una relación estructural
entre un todo y sus partes.
0..1 *
patrón empleado

Modelo Conceptual
• Relaciones.
– Generalización. Es una relación de especialización/generalización
en la cual los objetos del elemento especializado (el hijo) pueden
sustituir a los objetos del elemento general (el padre). De esta forma el
hijo comparte el comportamiento y la estructura del padre.
– Realización. Es una relación semántica entre clasificadores, en

donde un clasificador especifica un contrato que otro clasificador
garantiza que cumplirá.
Se pueden encontrar relaciones de realización en dos sitios: entre
interfaces y las clases y componentes que las realizan, y entre los
casos de uso y las colaboraciones que los realizan.

Modelo Conceptual
• Relaciones.
– Estos cuatro elementos son los elementos básicos relacionales que
se pueden incluir en un modelo UML. También existen variaciones de
estos cuatro, tales como el refinamiento, la traza, la inclusión y la
extensión.

Modelo Conceptual
• Diagramas. Un diagrama es la representación gráfica de un
conjunto de elementos, visualizado la mayoría de las veces como
un grafo conexo de nodos (elementos) y arcos (relaciones).
Se utilizan para dibujar un sistema desde diferentes perspectivas,
de forma que un diagrama es una proyección de un sistema.
En teoría, un diagrama puede contener cualquier combinación de
elementos y relaciones. En la práctica, sólo surge un pequeño
número de combinaciones.
– Diagrama de clases –Diagrama de estados

– Diagrama de objetos – Diagrama de actividades
– Diagrama de casos de uso – Diagrama de componentes
– Diagrama de secuencia – Diagrama de despliegue
– Diagrama de colaboración

Modelo Conceptual
• Diagramas. UML incluye nueve de estos diagramas
– Diagrama de clases Modelado de estructura
– Diagrama de objetos estática.
Modelado de requisitos de
– Diagrama de casos de uso usuario.
– Diagrama de secuencia
Modelado de interacción
– Diagrama de colaboración
– Diagrama de estados
Modelado dinámico
– Diagrama de actividades
– Diagrama de componentes Modelado de

– Diagrama de despliegue implementación

Modelado Conceptual

Modelo Conceptual
• Diagramas.
– Diagrama de casos de uso.
• Muestra un conjunto de casos de uso y actores (tipo especial de
clases) y sus relaciones.
Cubren la vista de casos de uso estática de un sistema. Son
especialmente importantes en el modelado y organización de un
sistema.
De empleo en la etapa de elicitación de requisitos de usuario.

Modelo Conceptual
• Diagramas.
– Diagrama de casos de uso.

Modelo Conceptual
• Diagramas.
– Diagrama de objetos. Muestra un conjunto de objetos y sus
relaciones. Representan instantáneas de instancias de los
elementos encontrados en los diagramas de clases.
Cubren la vista de diseño estática pero desde la perspectiva de
casos reales o prototípicos.
– Diagrama de clases
•Muestra un conjunto de clases, interfaces y colaboraciones, así como
sus relaciones. Son los diagramas más comunes en el modelado de
sistemas O.O.
Cubren la vista de diseño estática de un sistema; cuando incluyen
clases activas cubren la vista de procesos estática de un sistema.

Modelo Conceptual
• Diagramas.
– Diagrama de clases.

Modelo Conceptual
• Diagramas.
– Tanto los diagramas de secuencia como los de colaboración, son
un tipo de diagramas de interacción. Esta clase de diagramas de
interacción, muestran una interacción, esto es, un conjunto de
objetos y sus relaciones, incluyendo los mensajes que pueden ser
enviados entre ellos.
– Diagrama de secuencia.
Es un diagrama de interacción que resalta la ordenación temporal de
los mensajes.

Modelo Conceptual
• Diagramas.
– Diagrama de secuencia

Modelo Conceptual
• Diagramas.
– 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.

Modelo Conceptual
• Diagramas.
– Diagrama de colaboración.

Modelo Conceptual
• Diagramas.
– Diagrama de estados.
Muestra una máquina de estados, que consta de estados,
transiciones, eventos y actividades.
Son importantes en el modelado del comportamiento de una
interfaz, de una clase o una colaboración y resaltan el
comportamiento dirigido por eventos de un objeto.
Se utilizan para representar el ciclo de vida de los objetos de una
única clase (estados posibles en la vida de los objetos).

Modelo Conceptual
• Diagramas.
– Diagrama de estados.

Modelo Conceptual
• Diagramas.
– Diagrama de actividades.
Muestra el flujo de actividades dentro de un sistema.
Son importantes al modelar el funcionamiento de un sistema y
resaltan el flujo de control entre objetos.
Permite destacar y sincronizar las operaciones concurrentes y
establecer caminos alternativos.
Sirve para describir comportamientos complejos

Modelo Conceptual
• Diagramas.
– Diagrama de actividades.

Modelo Conceptual
• Diagramas.
– Diagrama de componentes.
Muestra la organización y las dependencias entre un conjunto de
componentes. Los diagramas de componentes cubren la vista de
implementación estática de un sistema.
Se relacionan con los diagramas de clases en que un componente
se corresponde, por lo común, con una o más clases, interfaces o
colaboraciones.
– Diagrama de despliegue.
Muestra la configuración de nodos de procesamiento en tiempo de
ejecución y los componentes que residen en ellos.
Cubren la vista de despliegue estática de una arquitectura.
Se relacionan con los diagramas de componentes en que un nodo
incluye, por lo común, uno o más componentes.

Modelo Conceptual
Reglas de UML
• Los bloques de construcción de UML no pueden combinarse de
cualquier manera.
UML posee un número de reglas que especifican a qué debe parecerse
un modelo bien formado.
Un modelo bien formado es aquel que es semánticamente
autoconsistente y está en armonía con todos sus modelos relacionados.
UML tiene reglas semánticas para:
– Nombres. Cómo llamar a los elementos, relaciones y diagramas.
– Alcance. El contexto que da significado específico a un nombre.
– Visibilidad. Cómo se pueden ver y utilizar estos nombres por otros.
– Integridad. Cómo se relacionan apropiada y consistentemente
unos elementos por otros.
– Ejecución. Qué significa ejecutar o simular un modelo dinámico.

Modelo Conceptual
Reglas de UML
• Los modelos construidos durante el desarrollo de un sistema con gran
cantidad de software tienden a evolucionar y pueden ser vistos por
diferentes usuarios de formas diferentes y en diferentes momentos.
Es común no sólo construir modelos bien formados, sino construir
modelos que sean:
– Abreviados. Ciertos elementos se ocultan para simplificar la vista.
– Incompletos. Pueden estar ausentes ciertos elementos.
– Inconsistentes. No se garantiza la integridad del modelo.
Estos modelos son inevitables conforme los detalles de un sistema van

apareciendo y mezclándose durante el proceso de desarrollo Sw.

Modelo Conceptual
Mecanismos comunes en UML
• Un sistema se hace más simple y armonioso al ajustarse a un patrón
de características comunes.
Esta simplificación se consigue mediante la presencia de cuatro
mecanismos comunes que se aplican de forma consistente a través de
todo el lenguaje:
– Especificaciones.
– Adornos.
– Divisiones comunes.
– Mecanismos de extensibilidad.

Modelo Conceptual
• Especificaciones.
– UML no es solo un lenguaje gráfico, sino que detrás de cada
notación gráfica hay una especificación que proporciona una
explicación textual de la sintaxis y semántica de ese bloque de
construcción.
Por ejemplo, detrás de un icono de clase hay una especificación que
proporciona el conjunto completo de atributos, operaciones
(incluyendo sus signaturas completas) y comportamiento que incluye
la clase.
La notación gráfica de UML se utiliza para visualizar un sistema; la
especificación de UML se utiliza para enunciar los detalles del
sistema.
Así, es posible construir un modelo de forma incremental dibujando
primero diagramas y añadiendo después semántica a las
especificaciones del modelo.

Modelo Conceptual
• Adornos
– La mayoría de los elementos de UML tienen una única y clara
notación gráfica que proporciona una representación visual de los
aspectos más importantes del elemento.
Por ejemplo, la notación de una clase se a diseñado de forma que
sea fácil de dibujar al ser uno de los elementos que aparecen con
más frecuencia al modelar sistemas O.O.
La especificación de una clase puede incluir otros detalles, tales
como si es abstracta, o la visibilidad de sus atributos y operaciones.
Muchos de estos detalles se pueden incluir como adornos gráficos o
textuales en la notación rectangular básica de la clase.


• Adornos
– En el ejemplo se muestra una clase, con adornos que indican que
es una clase abstracta con dos operaciones públicas (+), una
protegida (#) y la otra privada (-).
Transacción
+ ejecutar ()
+ rollback ()
# prioridad
- marcaDeTiempo()

Modelo Conceptual
• Divisiones comunes
– Al modelar sistemas O.O. el mundo puede dividirse, al menos, en
un par de formas.
En primer lugar está la división entre clase y objeto. Una clase es
una abstracción, un objeto es una manifestación concreta de esa
abstracción.
– Casi todos los bloques de UML presentan este mismo tipo de

dicotomía clase/objeto.

Modelo Conceptual
• Divisiones comunes
– En segundo lugar, tenemos la separación entre interfaz e
implementación. Una interfaz declara un contrato y una
implementación representa una realización concreta de ese
contrato, responsable de hacer efectiva de forma fidedigna la
semántica completa de la interfaz.
asistenteortográfico.dll
|Unknown
|Ortografía
– Componente llamado asistenteortográfico.dll que implementa dos
interfaces, |Unknown y |Ortografía.

Modelo Conceptual
• Mecanismos de extensibilidad
– Aparecen al no ser posible que un lenguaje cerrado sea siempre
suficiente para expresar todos los matices posibles de todos los
modelos en todos los dominios y en todos los momentos.
Así es posible extender el lenguaje de manera controlada.
Los mecanismos de extensión de UML incluyen:
• Estereotipos.
• Valores etiquetados.
• Restricciones.

Modelo Conceptual
– Estereotipos
Extiende el vocabulario de UML, permitiendo crear nuevos tipos
de bloques de construcción que deriven de los existentes pero
sean específicos a un problema.
Por ejemplo se pueden utilizar para modelar excepciones
(comunes en C++ o Java); normalmente solo se permitirá que
sean lanzadas y capturadas.
Se representan encerrados entre los símbolos << >>
ColaEventos
{versión 3.2
autor=jse }
añadir ()
quitar()
vaciar ()

Modelo Conceptual
– Valores etiquetados
Extiende las propiedades de un bloque de construcción,
permitiendo añadir nueva información en la especificación de ese
elemento.
Por ejemplo, a menudo se querrá registrar algún dato de ciertas
abstracciones críticas (versión, autor,…)
Son parejas de etiqueta + valor

Modelo Conceptual
– Restricciones
Permiten añadir nuevas reglas o modificar las existentes.
Son relaciones semánticas que especifican condiciones y
proposiciones que deben ser respetadas y mantenidas como
ciertas.
Van encerradas entre llaves { } .
En ejemplo se puede desear restringir la clase ColaEventos para
que todas las adiciones se hiciesen en orden.
Se puede añadir una restricción que indique explícitamente eso
para la operación de añadir.

Modelo Conceptual
ColaEventos
{versión 3.2
<<exception>> autor=jse }
Overflow
añadir () {ordenado}
quitar()
vaciar ()

Arquitectura
• En modelado de un gran sistema Sw, se requiere que este
sistema sea visto desde varias perspectivas.
• Diferentes usuarios, (usuarios finales, analistas,
desarrolladores, integradores de sistemas, encargados de los
tests, documentalistas, jefes de proyecto,…) siguen diferentes
agendas en relación al proyecto, y cada uno mira ese sistema
de formas diferentes en distintos momentos.
• La arquitectura de un sistema es quizás el artefacto más
importante que puede emplearse para manejar estos diferentes
puntos de vista y controlar el desarrollo iterativo e incremental
de un sistema a lo largo de su ciclo de vida.

Arquitectura
• La arquitectura es el conjunto de decisiones significativas
sobre:
– la organización de un sistema Sw.
– la selección de elementos estructurales y sus interfaces a través
de los cuales se constituye el sistema.
– su comportamiento, como se especifica en las colaboraciones
entre esos elementos.
– la composición de esos elementos estructurales y de
comportamiento en subsistemas progresivamente más grandes.
– el estilo arquitectónico que guía esta organización: los elementos
estáticos y dinámicos y sus interfaces, sus colaboraciones y su
composición.

Arquitectura
• La arquitectura Sw no solo tiene que ver con la estructura y el
comportamiento, sino también con el uso, la funcionalidad, el
rendimiento y la capacidad de adaptación, la reutilización, la
capacidad de ser comprendido, las restricciones económicas y
de tecnología y los compromisos entre alternativas, así como los
aspectos estéticos.
• La arquitectura de un sistema Sw puede describirse mejor a
través de cinco vistas interrelacionadas. Cada vista es una
proyección de la organización y la estructura del sistema,
centrada en un aspecto particular de ese sistema

Arquitectura
vocabulario, ensamblado del
funcionalidad sistema, gestión de
configuraciones
comportamiento
funcionamiento, topología del sistema,

capacidad de distribución, entrega,
crecimiento, instalación
rendimiento

Arquitectura
• Vista casos de uso
– Comprende los casos de uso que describen el comportamiento
del sistema tal y como es percibido por los usuarios finales,
analistas y encargados de las pruebas.
– Esta vista no especifica la organización de un sistema Sw,
especifica las fuerzas que configuran la arquitectura del sistema;
los aspectos estáticos se capturan en los diagramas de casos de
uso, los dinámicos en los diagramas de interacción (secuencia y
colaboración), diagramas de estados, diagramas de actividades.
• Vista de diseño
– Comprende las clases, interfaces y colaboraciones que forman el
vocabulario del problema y su solución.
– Soporta principalmente los requisitos funcionales del sistema,
entendiendo por ello los servicios que se deberían proporcionar a
los usuarios finales. Los aspectos estáticos se capturan en los
diagramas de clases y objetos; los dinámicos en los de interacción,
estados y actividades.
Arquitectura
• Vista de procesos
– Comprende los hilos y procesos que forman los mecanismos de
sincronización y concurrencia del sistema.
– Cubre principalmente el funcionamiento, capacidad de
crecimiento y rendimiento del sistema. Los aspectos estáticos y
dinámicos de esta vista se capturan en el mismo tipo de
diagramas que la vista de diseño, pero con énfasis en las clases
activas que representan estos hilos y procesos.
• Vista de implementación
– Comprende los componentes y archivos que se utilizan para
ensamblar y hacer disponible el sistema físico.
– Se preocupa principalmente de la gestión de configuraciones de
las distintas versiones de un sistema, a partir de que componentes
y archivos un tanto independientes y que pueden ensamblarse de
varias formas para producir un sistema en ejecución. Los aspectos
estáticos se capturan en los diagramas de componentes; los
dinámicos en los de interacción, estados y actividades.
Arquitectura
• Vista de despliegue
– Contiene los nodos que forman la topología hardware sobre la
que se ejecuta el sistema.
– Se preocupa principalmente de la dsitribución, entrega e
instalación de las partes que constituyen el sistema físico.
– Los aspectos estáticos se capturan en los diagramas de
despliegue; los dinámicos se capturan en los diagramas de
interacción, de estados y de actividades.

Liderazgo y Trabajo en Equipo

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Liderazgo y Trabajo en Equipo

Uploaded by

Copyright:

Available Formats

INGENIERÍA DEL SOFTWARE II TEMA 1

Jorge Salamanca Escorial 1

Jorge Salamanca Escorial 2

Jorge Salamanca Escorial 3

• El modelado no es exclusivo de los grandes sistemas, simplemente

Jorge Salamanca Escorial 4

• Todo modelo puede ser expresado a diferentes niveles de

Jorge Salamanca Escorial 5

• Un único modelo no es suficiente.

Jorge Salamanca Escorial 6

Jorge Salamanca Escorial 7

– La visión actual del desarrollo de Sw. toma una perspectiva O.O. En

Jorge Salamanca Escorial 8

Jorge Salamanca Escorial 9

Jorge Salamanca Escorial 10

Jorge Salamanca Escorial 11

Jorge Salamanca Escorial 12

Jorge Salamanca Escorial 13

• Proceso: Define el marco de trabajo y permite un desarrollo racional

Jorge Salamanca Escorial 14

Jorge Salamanca Escorial 15

Jorge Salamanca Escorial 16

Jorge Salamanca Escorial 17

Jorge Salamanca Escorial 18

Jorge Salamanca Escorial 19

Jorge Salamanca Escorial 20

Jorge Salamanca Escorial 21

Jorge Salamanca Escorial 22

Jorge Salamanca Escorial 23

Jorge Salamanca Escorial 24

Jorge Salamanca Escorial 25

Jorge Salamanca Escorial 26

Jorge Salamanca Escorial 27

Jorge Salamanca Escorial 28

Jorge Salamanca Escorial 29

Jorge Salamanca Escorial 30

Jorge Salamanca Escorial 31

Jorge Salamanca Escorial 32

Reglas del negocio

Jorge Salamanca Escorial 33

Jorge Salamanca Escorial 34

Jorge Salamanca Escorial 35

– Asociación. Es una relación estructural que describe un conjunto de

Jorge Salamanca Escorial 36

– Realización. Es una relación semántica entre clasificadores, en

Jorge Salamanca Escorial 37

Jorge Salamanca Escorial 38

– Diagrama de clases –Diagrama de estados

Jorge Salamanca Escorial 39

– Diagrama de componentes Modelado de

Jorge Salamanca Escorial 40

Jorge Salamanca Escorial 41

Jorge Salamanca Escorial 42

Jorge Salamanca Escorial 43

Jorge Salamanca Escorial 44

Jorge Salamanca Escorial 45

Jorge Salamanca Escorial 46

Jorge Salamanca Escorial 47

Jorge Salamanca Escorial 48

Jorge Salamanca Escorial 49

Jorge Salamanca Escorial 50

Jorge Salamanca Escorial 51

Jorge Salamanca Escorial 52

Jorge Salamanca Escorial 53