Métodos y técnicas del modelado de sistemas.
Métodos.
Para poder obtener buenos resultados en los sistemas de apoyo a
decisiones estructuradas, debemos dividir el trabajo como lo dice anteriormente
el análisis de sistema del que estamos hablando, debe tener en cuenta:
·
Si es
analítico o heurístico.
·
Cómo son
tomadas la decisiones en las tres fases de resolución de problemas de inteligencia.
·
El uso de
los métodos de criterios múltiples útiles para la resolución de
problemas semiestructurados.
Estos sistemas pueden funcionar de varias formas es
decir, la organización de la información para las situaciones de decisión, la interacción con los tomadores de decisiones que llevan consigo la
expansión en la toma de decisiones, la forma de presentar la información para
su mejor comprensión añadiendo modelos y criterios múltiples.
En donde los modelos de criterios múltiples incluyen procesos de compromiso, métodos ponderados y métodos de
eliminación secuencial y son los más adecuados para el manejo de la complejidad
y naturaleza semiestructurada.
Sistemas
de apoyo a Decisiones.
Este
método posee características que lo diferencia de los demás sistemas que
manejan información y que son tradicionales. Los usuarios finales de los DSS
(sistemas de apoyo a decisiones) poseen características especiales que merecen
ser tomadas en cuenta.
Debemos
tener en cuenta que un sistema de apoyo a decisiones lo definiremos como la
manera de organización de información que se pretende usar en la toma de
decisiones. Para lo cual al presentar la información debe estar diseñada
basándose en la solución de problemas y esto debe darse ya que el usuario no
debe tomar la decisión, sino el DSS.
Técnicas de modelado:
·
Modelado del contexto del sistema (utilidad
similar a los DFD).
·
Modelado de los requisitos de un sistema.
·
Modelado del proceso de test y estrés del
sistema.
·
Modelado
del vocabulario de un sistema a partir de las descripciones funcionales.
·
Modelado
de la distribución de responsabilidades en un sistema.
·
Modelado
de cosas que no son software (hardware, personas, etc.).
·
Modelado
de tipos primitivos.
·
Modelado
de dependencias simples.
·
Modelado
de herencia simple.
·
Modelado
de relaciones estructurales (composiciones y agregaciones).
·
Modelado
de comentarios.
Modelado
orientado a caso de usos.
Un caso de uso es una
técnica de modelado usada para describir lo que debería hacer un sistema nuevo
o lo que hace un sistema que ya existe. Los casos de uso describen bajo la
forma de acciones y reacciones el comportamiento de un sistema desde el punto
de vista de un usuario, permiten definir los límites del sistema y las
relaciones entre el sistema y el entorno.
Los componentes
primarios de un modelo de casos de uso (case-use model) son los casos de uso
(use cases), los actores y el sistema modelado. Los casos de uso son descripciones funcionales
del sistema; describen cómo los actores pueden usar un sistema. Los límites del
sistema se definen por la funcionalidad que se maneja en el sistema. La
funcionalidad se representa mediante diversos casos de uso, especificando cada uno
una funcionalidad completa (desde su inicio por parte de un actor externo hasta
que haya realizado la funcionalidad requerida). Un caso de uso siempre debe devolver
algún valor a un actor, siendo el valor cualquier cosa que el actor desee del
sistema. El actor es una entidad externa que tiene interés en interactuar con
el sistema. A menudo, es una persona que usa el sistema, pero también puede ser
otro sistema o alguna clase de dispositivo hardware que necesita interactuar
con el sistema.
En el modelado de casos de uso, el sistema se
observa como una caja negra que proporciona casos de uso. Cómo lo haga el
sistema, cómo se implementen los casos de uso y cómo trabajen internamente no
importa. Las clases e interacciones implementan los casos de uso del sistema.
Las interacciones se expresan en diagramas de secuencia, colaboración y actividad,
así, hay un enlace entre las vistas funcional y dinámica del sistema.
Las clases en la
implementación de los casos de uso se modelan y se describen en diagramas de
clases y de estados.
Los propósitos primarios de los casos de uso son:
Decidir y describir
los requerimientos funcionales del sistema, dando lugar a un acuerdo entre el
cliente (y/o usuario final) y los programadores que desarrollan el sistema.
Dar una descripción clara y consistente de lo
que debería hacer el sistema, de modo que el modelo se use a lo largo del
proceso de desarrollo.
Proporcionar una base
para realizar verificaciones (test) del sistema que comprueben su
funcionamiento.
Proporcionar la
capacidad para rastrear requerimientos funcionales en clases y operaciones
reales del sistema, verificando los casos de uso afectados por cambios y
extensiones al sistema.
El modelado de casos de uso también se utiliza
cuando se desarrolla una nueva versión del sistema.
Se añade la nueva
funcionalidad al modelo de casos de uso existente insertando nuevos actores y
casos de uso, o modificando la especificación de los casos de uso actuales.
Un caso de uso
representa una funcionalidad completa tal como la percibe un actor. Un caso de
uso en UML se define como una secuencia de acciones que realiza un sistema y
que conduce a un resultado observable.
Las acciones pueden
envolver comunicación con diversos actores (usuarios y otros sistemas) así como
realización de cálculos y trabajos dentro del sistema.
Las características de un caso de uso son:
Un caso de uso
siempre es iniciado por un actor: se realiza en interés de un actor que,
directa o indirectamente, debe ordenar al sistema que inicie el caso de uso.
Un caso de uso
proporciona un valor a un actor: debe entregar alguna clase de valor tangible
para el usuario.
Un caso de uso es
completo: debe ser una descripción completa. Un caso de uso no está completo
hasta que se produce el valor final, incluso si a lo largo del camino ocurren
varias comunicaciones (tales como diálogos con el usuario).
Un caso de uso se
representa en UML mediante una elipse que contiene el nombre del caso de uso, o
con el nombre del caso de uso debajo.
Los casos de uso se conectan a los actores
mediante asociaciones, denominadas líneas de comunicación (communication
lines).
Prototipo.
Consiste en la elaboración
de un modelo o maqueta del sistema que se construye para evaluar mejor los
requisitos que se desea que cumpla es particularmente útil cuando:
·
El área de la aplicación no está bien
definida, bien por su dificultad o bien por falta de tradición es su
automatización.
·
El coste del rechazo de la aplicación por los
usuarios, por no cumplir sus expectativas, es muy alto.
·
Es necesario evaluar previamente el impacto
del sistema en los usuarios y en la organización.
·
Estos modelos o prototipos suelen consistir
en versiones reducidas, demos o conjunto de pantallas (que no son totalmente
operativos) de la aplicación pedida.
Existen tres razones principales para emplear
prototipado ordenadas por frecuencia de usos:
·
Prototipado
de la interfaz de usuario: Para asegurarse de que está bien
diseñada que satisface las necesidades de quienes deben usarlo.
·
Modelado
de rendimiento: para evaluar el posible rendimiento de un
diseño técnico, especialmente en aplicaciones críticas en este aspecto.
·
Prototipado
funcional: cada vez más utilizado, está relacionado con un ciclo de
vida interactivo. En este caso en vez de seguir el procedimiento habitual, el prototipo supone una primera versión del
sistema con funcionalidad limitada.
Técnicas.
El uso más común de un caso de uso es modelar el
comportamiento de un elemento, ya sea el sistema completo, un subsistema o una
clase. Cuando modelas el comportamiento de estas cosas, es importante enfocarse
en qué hace el elemento, no cómo lo hace.
Aplicar los casos de uso a los elementos de esta
manera es importante por tres razones. Primero, al modelar el comportamiento de
un elemento con casos de usos, proporcionas una manera para que los expertos
del dominio especifiquen la vista externa en grado suficiente para que los
desarrolladores construyan su vista interna. Los casos de uso proveen un foro
para que los expertos del dominio, usuarios finales y desarrolladores, se
comuniquen entre sí. Segundo, los casos de uso proporcionan a los
desarrolladores un mecanismo para aproximarse a un elemento y entenderlo. Un
sistema, subsistema o clase puede ser complejo y lleno de operaciones y otras
partes. Al especificar los caso de uso de un elemento, puedes ayudar a los
usuarios de estos elementos a enfocarse de una manera directa, de acuerdo a
como ellos los utilizan. En la ausencia de tales casos de uso, los usuarios
tienen que descubrir por sí mismos como usar aquellos elementos. Los casos de
uso le permiten a un autor de un elemento comunicar su propósito de cómo debe ser
usado. Tercero, los casos de uso sirven como una base para probar cualquier
elemento contra sus casos de uso, continuamente validas su implementación. No
sólo haces que los casos de uso provean una fuente de pruebas de regresión,
pero cada vez que generas un nuevo caso de unos para un elemento, te fuerzas a
reconsiderar tu implantación para asegurar que este elemento es congruente al
cambio. Si no, deber corregir tu arquitectura apropiadamente.
Modelado del negocio.
Con esta disciplina se pretende llegar a un mejor
entendimiento de la organización donde se va a implantar el sistema de
software. Los principales motivos para ejecutar esta disciplina son los
siguientes: asegurarse de que el producto será algo útil y no un obstáculo;
conseguir que se ajuste de la mejor forma posible en la organización donde se
va a implantar; y tener un marco común para el equipo de proyecto, los clientes
y los usuarios finales. Esta disciplina no será siempre necesaria. Si sólo se
añaden funcionalidades que no verán los usuarios directamente, no hará falta.
Los objetivos específicos del modelado de negocio son:
- Asegurar que clientes, usuarios finales y desarrolladores tengan un entendimiento común de la organización objetivo.
- Derivar los requerimientos del sistema necesarios para apoyar a la organización objetivo en su mejora.
- Entender el problema actual en la organización objetivo e identificar potenciales mejoras.
- Entender la estructura y la dinámica de la organización para la cual el sistema va a ser desarrollado (organización objetivo).
Para lograr estos objetivos, el
modelado de negocio describe como desarrollar una visión de la nueva
organización, basado en esta visión se definen procesos, roles y
responsabilidades de la organización por medio de un Modelo de Casos de Uso del
Negocio. Los artefactos del modelo de negocio sirven como entrada y referencia
para la definición de los requerimientos del sistema.
Casos de uso del negocio.
Es un modelo que describe
los procesos de negocio y sus relaciones con los participantes externos, como
clientes y socios. Caso de Negocios: modelar la empresa (como funciona la
empresa a la que se le va a desarrollar el software) Captura de Datos Editor
Autor/Editor Administrador de Sub agencias Bibliotecario Librero Administración
de ISBN Mantenimiento Tablas Maestras Consultar Catálogo Conversión Libros
Importados Administrador.
Especificación
de CUN.
El diagrama de CUN da una visión
general a los diferentes procesos del negocio, aparece en cada proceso del
negocio como un CUN, este diagrama muestra los límites y entornos de la organización
en estudio.
Solo se muestran los actores
del negocio que corresponde a los roles externos al sistema, así los CUN en los
que tomen parte los roles internos a la organización no estarán conectados a ningún
actor.
Actividades
del negocio.
Por regla general cuando nos encargan
diseñar un sistema de información estamos adaptando unos flujos de trabajo y comportamientos a un sistema informático. Poder representar correctamente estos flujos y entenderlos nos será de gran ayuda a la hora de diseñar nuestro sistema. Dentro de UML disponemos del diagrama de actividades, este diagrama nos servirá para definir los procesos de negocio, que ha de contemplar nuestro sistema de información .Los diagramas de actividades forman parte del modelado del negocio. Al realizar el diagrama de actividades podemos ver de una forma clara todas actividades y su flujo lógico, incluyendo los procesos que se ejecutan en paralelo, (Y no solamente el flujo secuencial), flujo de actividades
y no de datos, esta es una de las diferencias principales entre el diagrama de actividades y otro tipo de diagramas de flujo, y es así como debemos de pensar cuando diseñamos un diagrama de actividades. Este tipo
de diagrama no es solamente utilizado en la ingeniería del software, sino en otras áreas donde se ha de definir procesos de trabajo, ya que con ellos podemos representar la secuencia lógica de un proceso de negocio, desglosando este en diferentes actividades, esta es una de las grandes virtudes de este tipo de diagrama.
Objetos
del negocio.
Un
objeto de negocio es un tipo de entidad inteligible que es un actor dentro de
la capa de negocio de un programa de ordenador basado en n capas.
Mientras
que un programa podría implementar clases, las cuales pueden ser objetos
controlando o ejecutando comportamientos, principalmente se distinguen en que
no realizan nada por si mismos, sino que albergan un conjunto de atributos y
asociaciones con otros, tejiendo un mapa de jugadores que representan las
relaciones de negocio.
Por
ejemplo, un "Jefe" podría ser un objeto de negocio, en el que sus
atributos pueden ser "Nombre", "Apellido",
"Edad", "Sección", "País", mientras que puede
soportar una asociación "1-n" con sus empleados (formalmente una
colección de instancias de "Empleado").
Integrantes:
Ascanio , Maryeling.
Chouza, Jose.
Diaz Carlos.
Prado, Williana .
Torrealba, Anadilis.
Zambrano Jhoskary.
