Ingeniería de Software

Modelo de sistema
 MODELOS DE SISTEMAS
La modelación de sistemas es el proceso de elaboración de modelos
abstractos de un sistema, con cada modelo que presenta una vista o
perspectiva diferente de ese sistema. ²La modelación de sistemas ahora ha
llegado a significar lo que representa un sistema que utiliza algún tipo de
notación gráfica, que ahora es casi siempre basada en anotaciones en el
Lenguaje Unificado de Modelado (UML). ²La modelación de sistemas ayuda
al analista a entender la funcionalidad del sistema y se utilizan modelos para
comunicarse con los clientes.
 MODELOS DE CONTEXTO
En una primera etapa es la especificación de un sistema, debe decidir
sobre las fronteras del sistema. Esto implica trabajar con los
participantes del sistema para determinar cuál funcionalidad se incluirá
en el sistema y cuál la ofrece el entorno del sistema. Los modelos de
contexto, por lo general, muestran que el entorno incluye varios
sistemas automatizados. Por consiguiente, los modelos de contexto
simples se usan junto con otros modelos, como los modelos de proceso
empresarial. Éstos describen procesos humanos y automatizados que se
usan en sistemas particulares de software
 CARACTERISTICAS
▪ Nos sirven como una manera de representar los limites del sistema, se
distingue lo que conforma el sistema y su entorno

▪ El diagrama de este modelo es también conocido como el nivel 0 del

diagrama de un flujo de datos

▪ Se muestras las relaciones que se dan en el sistema y se debe tomar en

cuenta los requerimientos y el diseño del sistema

▪ Determina donde tiene que implementarse una nueva funcionalidad

▪ Debe hacerse profundamente durante el proceso. para limitar los costos

del sistema, así como el tiempo necesario para comprender los
requerimientos y el diseño del sistema
 VENTAJAS

❑ Busca posibles igualdades en la funcionalidad con los

sistemas existentes y determinar dónde tiene que
implementarse nueva funcionalidad

❑ .Ayuda al análisis del sistema por medio de los aspectos

tanto sociales como organizacionales

❑ Nos ayuda a saber las partes del sistema

 DESVENTAJAS
❑ Los requerimientos del sistema pueden cambiar en el transcurso de
describir funciones automatizadas del mismo.

❑ Al asociar o relacionar módulos se descartan en una gran mayoría

aspectos básicos como datos a utilizar o posibles fallos, a pesar de
especificar interacciones de usuario-sistema.

❑ No muestran las relaciones entre otros sistemas del entorno y el sistema

que se está especificando

❑ En el reemplazo de un sistema manual a uno automatizado, no se podría

dar tanta flexibilidad en ciertos casos.

❑ Descartar algún entorno de un requerimiento podría conducir a una

nueva revisión completa del mismo modelo ya que alteraría ciertos
procesos.
 Modelos de interacción

•Todos los sistemas contiene interacción , tanto como del usuario , de los
componentes del propio sistema e incluso con otros sistemas.
•Este ayuda a entender si es probable que la estructura de un sistema
propuesto vaya a tener el rendimiento y confiabilidad requeridos por el
sistema.

✔ Modelado de Caso de ✔ Diagramas de

Uso Secuencia
 Modelo de Caso de Uso

•Fue desarrollado originalmente por Jacobson y sus colaboradores en

1993 , fue incorporado en el primer lanzamiento del UML, este
modelado se usa ampliamente para apoyar la adquisición de
requerimientos. Este puede tomarse como un simple escenario que
describe lo que espera el usuario de un sistema.

•Cada caso de uso representa una tarea discreta es por eso que
implica una interacción externa con un sistema.
 Diagramas de Secuencia

•Son usados principalmente para modelar las interacciones entre los

actores y los objetos de un sistema, y también los objetos entre sí. En
el UML cuenta con una gran sintaxis para estos diagramas. Como aquí
no hay espacio para cubrir todas las posibilidades, sólo nos
enfocaremos en lo básico de este tipo de diagrama.

• Como sugiere el nombre, un diagrama de secuencia muestra la

sucesión de interacciones que ocurre durante un caso de uso
particular o una instancia de caso de uso.
 MODELOS ESTRUCTURALES
Los modelos estructurales de software muestran la organización de un
sistema, en términos de los componentes que constituyen dicho sistema y
sus relaciones. Los modelos estructurales son modelos estáticos, que
muestran la estructura del diseño del sistema, o modelos dinámicos, que
revelan la organización del sistema cuando se ejecuta.

Los modelos estructurales de un sistema se crean cuando se discute y

diseña la arquitectura del sistema. El diseño arquitectónico es un tema
particularmente importante en la ingeniería de software, y los diagramas
UML de componente, de paquete y de implementación se utilizan cuando
se presentan modelos arquitectónicos

La principal forma de emplear el modelado estructural es mediante el uso

de diagramas de clase.
 DIAGRAMAS DE CLASE
Los diagramas de clase pueden usarse cuando se desarrolla un modelo de
sistema orientado a objetos para mostrar las clases en un sistema y las
asociaciones entre dichas clases. De manera holgada, una clase de objeto
se considera como una definición general de un tipo de objeto del sistema.
Una asociación es un vínculo entre clases, que indica que hay una relación
entre dicha clases
Cuando se desarrollan modelos durante las primeras etapas del proceso de
ingeniería de software, los objetos representan algo en el mundo real,
como un paciente, registro del paciente, una receta, un médico, etcétera.

1 1
También es posible otras multiplicidades. Se define un número exacto de
objetos que están implicados, o bien, con el uso de un asterisco (*),
como se muestra en la figura, que hay un número indefinido de objetos
en la asociación
 GENERALIZACIÓN:
La generalización es una técnica cotidiana que se usa para gestionar la
complejidad. En vez de aprender las características detalladas de cada entidad
que se experimenta, dichas entidades se colocan en clases más generales
(animales, automóviles, casas, etcétera) y se aprenden las características de
dichas clases. Esto permite deducir que diferentes miembros de estas clases
tienen algunas características comunes (por ejemplo, las ardillas y ratas son
roedores).
 Modelos del comportamiento

Son modelos dinámicos del sistema conforme se

ejecutan. En ellos se muestra lo que sucede o lo que se

supone que pasa cuando un sistema responde ante un

estímulo de su entorno. Tales estímulos son de dos tipos:

- MODELADO DIRIGIDO POR DATOS

- MODELADO DIRIGIDO POR EVENTOS

 Modelado dirigido por datos

Los modelos dirigidos por datos muestran la secuencia de acciones

involucradas en el procesamiento de datos de entrada, así como la generación de
una salida asociada. Son particularmente útiles durante el análisis de
requerimientos, pues sirven para mostrar procesamiento “extremo a extremo” en
un sistema. Esto es, exhiben toda la secuencia de acciones que ocurren desde
una entrada a procesar hasta la salida correspondiente, que es la respuesta del
sistema.
 Modelado dirigido por un evento

El modelado dirigido por un evento

muestra cómo responde un sistema a
eventos externos e internos. Se basa en la
suposición de que un sistema tiene un
número finito de estados y que los eventos
(estímulos) pueden causar una transición
de un estado a otro
 INGENIERIA DIRIGIDA POR MODELO

La Ingeniería dirigida por modelos o MDE (Model Driven

Engineering) es una metodología de desarrollo de software
que se centra en la creación de modelos o abstracciones.
Todas las formas de ingeniería se basan en modelos de
Concepto sistemas reales. Los modelos se utilizan de muchas formas,
una para predecir las cualidades del sistema; otra para
comprender aspectos específicos del sistema, además
determinar el motivo del impacto de los cambios y es muy
útil para comunicar las características principales del sistema
a las partes interesadas.
 MDE surge como la respuesta de la ingeniería de
software a la industrialización del desarrollo de
software, este tiene enfoque abierto e inclusivo que
abarca muchos otros espacios tecnológicos de
manera uniforme. El espacio de trabajo tecnológico
Origen: es un contexto con una serie de conceptos
relacionados, la habilidad, herramientas,
conocimientos necesarios y posibilidades. Ejemplos
de espacios tecnológicos son los lenguajes de
programación con sintaxis concreta y abstracta,
ontologías de ingeniería basadas en XML, lenguajes
del Sistema de gestión de bases de datos (DBMS) y
Arquitectura basada en modelos (MDA).
 Objetivos de la Ingeniería Dirigida por Modelos

❖ La necesidad de separar claramente la lógica comercial y la tecnología utilizada.

❖ La separación de preocupaciones, considerado uno de los principios
fundamentales en la ingeniería de software. Este principio afirma que un
problema dado implica diferentes tipos de preocupaciones que deben
identificarse y segregarse para abordar la complejidad y lograr factores de
calidad de ingeniería como durabilidad, adaptabilidad, sostenibilidad y
reutilización.
❖ La necesidad de modelar y especificar la parte de la lógica empresarial a un
nivel abstracto, la plataforma de implementación y proyectar el nivel abstracto
en la plataforma.
❖ Generar nuevo software a partir del modelado.
❖ Dar apoyo y herramientas a los desarrolladores para mejorar su productividad.
❖ Completar el proceso de construcción del programa mediante el uso de los
modelos a lo largo del ciclo de vida del programa.
❖ Generar cambios en las partes del modelo.
 Metamodelado de Sistemas:

Un metamodelo es un modelo que

especifica los conceptos de un lenguaje,
las relaciones entre ellos y las reglas
estructurales que limitan los posibles
elementos de los modelos válidos, así
como el cumplimiento de las reglas
semánticas del dominio. Un metamodelo
define la sintaxis abstracta y la semántica
estática de un lenguaje de modelado.
Esto significa que cada modelo está
escrito en el lenguaje indicado por su
metamodelo.
 Modelo de arquitectura MOF

Meta-Object Facility (MOF) es

un estándar del Object
Management Group (OMG)
sobre ingeniería dirigida por
modelos. Su propósito es
proporcionar un sistema de tipos
para entidades en la arquitectura
CORBA y un conjunto de
interfaces a través de las cuales
esos objetos se pueden crear y
manipular.
Este modelo de arquitectura denominado MOF (Meta Object Facility)
representa el nivel meta más general (M3) y tiene el objetivo de permitir la
incorporación de nuevos lenguajes de modelado (metamodelos) para
propósitos específicos (OMG-MOF, 2003).

❑ Capa M3 (Metametamodelo): corresponde a MOF, es una especificación

que define un lenguaje abstracto para especificar, construir y
administrar elementos comunes a cualquier metamodelo.
❑ Capa M2 (Metamodelos): especifica las entidades de un lenguaje de
modelado. Los lenguajes que se han definido como instancias MOF son:
UML, CWM y el propio MOF. Además, los metamodelos se definen para
otros fines, como objetos de negocio, flujos de trabajo y modelos de
componentes (OMG-MOF, 2003).
❑ Capa M1 (Modelos): se refiere a los modelos de usuario que
generalmente se desarrollan al construir un sistema de información.
❑ Capa M0 (instancias): describe las instancias de entidad propuestas en
un modelo de un sistema de información. Es en este nivel que los
diagramas de objetos se pueden utilizar como instancias de clase para
verificar que se satisfacen las restricciones definidas en el nivel de
modelo (M1).
Un segundo aspecto del MDE, y estratégicamente más importante, es la reducción de
la sensibilidad de los primeros objetos de arte al cambio. Indican cuatro formas
fundamentales de los cambios que son de particular importancia:
Personal: El desarrollo del conocimiento vital no debe ser sólo almacenado en la
mente de los desarrolladores, esta información se perderá en el caso demasiado
frecuente de las fluctuaciones de personal. Por lo tanto, esta información debe ser de
fácil acceso para cualquier persona que no sean los creadores del artefacto software.
Requerimientos: Los cambios de los requerimientos es un problema conocido en
la ingeniería de software. En el actual entorno empresarial aparecen nuevas
funcionalidades más rápido que nunca. Todos estos cambios deben tener un bajo
impacto sobre los sistemas existentes en términos de mantenimiento y no perturbar
los sistemas en línea.
Plataformas de desarrollo: Están en un estado de constante evolución. Para
disociar la vida de un artefacto de software de la herramienta de desarrollo utilizado
para su creación inicial, es necesario disociar el objeto o el modelo que representa el
objeto de la herramienta de desarrollo.
El despliegue de plataformas: Para aumentar la vida útil de los objetos de
software es necesario protegerlos contra los cambios en el despliegue de la
plataforma.
Gracias por la
atención
prestada…