Modelado
del sistema.
·
Técnicas
y Métodos de Modelado del Sistema.
LA VISIÓN DE SISTEMAS MODELOS
Abstracción y modelos:
Abstracción: es
el proceso de centrarse en los detalles esenciales (importantes) de un objeto o
situación (llamados entidades) ignora los detalles que no son esenciales (no
importantes) de esa entidad.
Modelos: es una
abstracción de una entidad, cualquier representación de los detalles esenciales
(importantes) de esa entidad son representaciones de lo que se considera
esencial (importante) acerca de una entidad.
El contenido de los modelos: Los
modelos se pueden utilizar para capturar y representar información referente a una
entidad individual, un conjunto de entidades interrelacionadas o interactuando
entre ellas.
La
localización en los modelos.
Localización: es
el proceso de ubicar objetos en la proximidad o alrededor de otros objetos.
Los
modelos funcionales localizan su información alrededor de las funciones basados
en datos, localizan su información alrededor de los datos y sus relaciones
entre ellos orientados a objetos localizan su información alrededor de los
objetos y situaciones orientadas a objetos (objetos interactuando con otros
objetos).
Modelos físicos: es
una representación en 3D de entidades y conjuntos de entidades •
Modelos textuales y de narración: son
descripciones textuales o narrativas de entidades y conjuntos de entidades•
Modelos gráficos:
representan gráficamente las características de entidades y conjuntos de
entidades.
Modelos matemáticos:
representan las características de las entidades por medio de ecuaciones
matemáticas•
Modelos ejecutables: Son
modelos que son ejecutables en una computadora•
Otros
modelos: Esta categoría genérica incluye todos los modelos que no están
dentro de las categorías anteriores.
Utilización
de los modelos:
Facilitar el entendimiento: un
modelo es más simple que su entidad•
Facilitar la comunicación: a
través de un modelo se puede comunicar información de una forma rápida y
precisa•
Predecir el comportamiento futuro:
esta es una característica principal de los modelos matemáticos.
Confección de los modelos:
mezcla de dos o más modelos medios mixtos, por ejemplo: la utilización de
papel, resortes, tachuelas, etc. medios visuales y auditivos tales como vídeo
grabadoras, audio cassettes, películas, fotografía, etc. Modelos de realidad virtual.
Modelos múltiples: A
menudo es útil construir modelos múltiples para una misma entidad. Estos
modelos para una entidad en el mismo nivel de abstracción (nivel de detalle)
permite un mejor entendimiento • Específicamente, un modelo puede mostrar algún
detalle que otro modelo no muestra o que es incapaz de mostrar Estos modelos
para una entidad en diferentes niveles de abstracción (diferentes niveles de
detalle) permiten controlar cuánta información se desea mostrar • Tales modelos
permiten revelar progresivamente más detalle acerca de una entidad como el
entendimiento de ellos se incrementa.
La creación de más de un modelo: Si
más de un modelo de la misma entidad se desarrolla para el mismo nivel de
abstracción, se debe mantener en mente, todos los modelos deben tener el mismo
nivel de detalle, cada modelo debe revelar alguna información que no revelan
los demás modelos, la terminología debe ser consistente a través de todos los
modelos; la misma entidad debe tener el mismo nombre en todos los modelos, los
modelos deben ser consistentes entre ellos.
·
Modelado
Orientado a casos de uso, Prototipo y Técnicas de análisis.
Modelado del Negocio: Casos de Uso del
Negocio, Especificación de CUN, Actividades del Negocio, Objeto del Negocio.
Prototipos:
Los
prototipos permiten al desarrollador crear un modelo del software que debe ser
construido.
Al
igual que todos los enfoques al proceso de desarrollo del software, el
prototipado comienza con la captura de requerimientos. Desarrolladores y
clientes se reúnen y definen los objetivos globales del software, identifican
todos los requerimientos que son conocidos, y señalan áreas en las que será
necesaria la profundización en las definiciones. Luego de esto, tiene lugar un
"diseño rápido". El diseño rápido se centra en una representación de
aquellos aspectos del software que serán visibles al usuario (por ejemplo,
entradas y formatos de las salidas). El diseño rápido lleva a la construcción
de un prototipo. El prototipo es evaluado por el cliente y el usuario y
utilizado para refinar los requerimientos del software a ser desarrollado. Un
proceso de iteración tiene lugar a medida que el prototipo es "puesto a
punto" para satisfacer las necesidades del cliente y permitiendo al mismo
tiempo una mejor comprensión del problema por parte del desarrollador.
Existen principalmente dos
tipos de prototipos:
Prototipo rápido (o
concept prototipe): El
prototipado rápido es un mecanismo para lograr la validación pre-compromiso. Se
utiliza para validar requerimientos en una etapa previa al diseño específico.
En este sentido, el prototipo puede ser visto como una aceptación tácita de que
los requerimientos no son totalmente conocidos o entendidos antes del diseño y
la implementación. El prototipo rápido puede ser usado como un medio para
explorar nuevos requerimientos y así ayudar a "controlar" su
constante evolución.
Prototipo evolutivo:
Desde una perspectiva diferente, todo el ciclo de vida de un producto puede ser
visto como una serie incremental de detallados prototipos acumulativos.
Tradicionalmente, el ciclo de vida está dividido en dos fases distintas:
desarrollo y mantenimiento. La experiencia ha demostrado que esta distinción es
arbitraria y va en contra de la realidad ya que la mayor parte del costo del
software ocurre después de que el producto se ha entregado. El punto de vista
evolutivo del ciclo de vida del software considera a la primera entrega como un
prototipo inicial en el campo. Modificaciones y mejoras subsecuentes resultan
en nuevas entregas de prototipos más maduros. Este proceso continúa hasta que
se haya desarrollado el producto final. La adopción de esta óptica elimina la
distinción arbitraria entre desarrollo y mantenimiento, resultando en un
importante cambio de mentalidad que afecta las estrategias para la estimación
de costos, enfoques de desarrollo y adquisición de productos.
Modelado del Negocio:
Para
conseguir sus objetivos, una empresa organiza su actividad por medio de un
conjunto de procesos de negocio. Cada uno de ellos se caracteriza por una
colección de datos que son producidos y manipulados mediante un conjunto de
tareas, en las que ciertos agentes (por ejemplo, trabajadores o departamentos)
participan de acuerdo a un flujo de trabajo determinado. Además, estos procesos
se hallan sujetos a un conjunto de reglas de negocio, que determinan las
políticas y la estructura de la información de la empresa. Por tanto, la
finalidad del modelado del negocio es describir cada proceso del negocio,
especificando sus datos, actividades (o tareas), roles (o agentes) y reglas de
negocio.
El primer paso del modelado
del negocio consiste en capturar los procesos de negocio de la organización
bajo estudio. La definición del conjunto de procesos del negocio es una tarea
crucial, ya que define los límites del proceso de modelado posterior. De
acuerdo con el concepto de objetivo estratégico de Cockburn, capturamos los
procesos del negocio a partir de los objetivos principales de la empresa. En
primer lugar, consideramos los objetivos estratégicos de la organización.
Teniendo en cuenta que estos objetivos van a ser muy complejos y de un nivel de
abstracción muy alto, serán descompuestos en un conjunto de subobjetivos más
concretos, que deberán cumplirse para conseguir el objetivo estratégico. Estos
subobjetivos pueden a su vez ser descompuestos en otros, de manera que se
defina una jerarquía de objetivos. En nuestro estudio, hemos experimentado que
dos o tres niveles de descomposición son suficientes. Para cada uno de estos
subobjetivos de segundo nivel definimos un proceso de negocio que deberá dar
soporte a dicho subobjetivo. Representamos cada proceso del negocio como un
caso de uso del negocio, que inicialmente será descrito de forma textual.
En el resto del trabajo,
ilustramos el proceso mediante el ejemplo de una compañía que fabrica productos
bajo demanda (siguiendo un esquema just in time). Los objetivos estratégicos de
dicha compañía podrían incluir Satisfacer un pedido de un cliente, Incrementar
en un 25% las ventas, o Disminuir el tiempo de fabricación en un 15%.El
objetivo Satisfacer un pedido de un cliente puede ser dividido en subobjetivos
tales como: Registrar Pedido de Cliente, Fabricar Producto Pedido, Gestionar
Almacén y Realizar Pedidos a Proveedores. Éstos serán los objetivos que
utilizaremos para definir nuestros procesos del negocio.
Los
casos de uso:
Son una técnica para especificar el comportamiento de un sistema: "Un caso de uso es
una secuencia de interacciones entre un sistema y alguien o algo que usa alguno
de sus servicios."
Todo sistema de software ofrece a su entorno una serie de servicios. Un
caso de uso es una forma de expresar cómo alguien o algo externo a un sistema
lo usa. Cuando decimos "alguien o algo" hacemos referencia a que los
sistemas son usados no sólo por personas, sino también por otros sistemas de hardware y software.
Por ejemplo, un sistema de ventas, si pretende tener éxito, debe ofrecer
un servicio para ingresar un nuevo pedido de un
cliente. Cuando un usuario accede a este servicio, podemos decir que está
"ejecutando" el caso de uso ingresando pedido.
Los Casos de Uso fueron introducidos por Jacobson en 1992 [Jacobson92].
Sin embargo, la idea de especificar un sistema a partir de su interacción con el entorno es original de McMenamin
y Palmer, dos precursores del análisis estructurado, que en 1984 definieron
un concepto muy parecido al del caso de uso: el
evento. Para McMenamin y Palmer, un evento es algo que ocurre fuera de
los límites del sistema, ante lo cual el sistema
debe responder. Siguiendo con nuestro ejemplo anterior, nuestro sistema de
ventas tendrá un evento "Cliente hace Pedido". En este caso el
sistema deberá responder al estimulo que recibe.
- Los eventos se
centran en describir qué hace el sistema cuando el evento ocurre, mientras
que los casos de uso se centran en describir cómo es el diálogo entre
el usuario y el sistema.
- Los eventos son
"atómicos": se recibe una entrada, se la procesa, y se genera
una salida, mientras que los casos de uso se prolongan a lo largo del
tiempo mientras dure la interacción del usuario con el sistema. De esta
forma, un caso de uso puede agrupar a varios eventos.
- Para los
eventos, lo importante es qué datos ingresan al sistema o salen de él
cuando ocurre el evento (estos datos se llaman datos esenciales), mientras
que para los casos de uso la importancia del detalle sobre la información
que se intercambia es secundaria. Según esta técnica, ya habrá tiempo más
adelante en el desarrollo del sistema para ocuparse de este tema.
Los casos de uso combinan el concepto de evento del análisis
estructurado con otra técnica de especificación de requerimientos bastante poco
difundida: aquella que dice que una buena forma de expresar los requerimientos
de un sistema es escribir su manual de usuario antes de construirlo. Esta
técnica, si bien ganó pocos adeptos, se basa en un concepto muy interesante: al
definir requerimientos, es importante describir al sistema desde el punto de
vista de aquél que lo va a usar, y no desde el punto de vista del que lo va a
construir. De esta forma, es más fácil validar que los requerimientos
documentados son los verdaderos requerimientos de los usuarios, ya que éstos
comprenderán fácilmente la forma en la que están expresados.
Los Casos de Uso y UML
A partir de la publicación del libro de Jacobson, gran parte de los más
reconocidos especialistas en métodos Orientados a Objetos coincidieron en
considerar a los casos de uso como una excelente forma de especificar el
comportamiento externo de un sistema. De esta forma, la notación de los casos
de uso fue incorporada al lenguaje estándar de modelado UML (Unified Modeling Language) propuesto
por Ivar Jacobson, James Rumbaugh y Grady Booch, tres de los precursores de las
metodologías de Análisis y Diseño Orientado a Objetos, y avalado por las principales
empresas que desarrollan software en el mundo. UML va en camino de convertirse
en un estándar para modelado de sistemas de software de amplia difusión.
Técnica de Análisis:
Orientado a Objetos, es importante destacar
que los casos de uso poco tienen que ver con entender a un sistema como un
conjunto de objetos que interactúan, que es la premisa básica del análisis
orientado a objetos "clásico". En este sentido, el éxito de los casos
de uso no hace más que dar la razón al análisis estructurado, que propone que
la mejor forma de empezar a entender un sistema es a partir de los servicios
o funciones que ofrece a su entorno,
independientemente de los objetos que interactúan dentro del sistema para
proveerlos.
Como era de esperar, es probable que en el futuro los métodos de
análisis y diseño que prevalezcan hayan adoptado las principales ventajas de
todos los métodos disponibles en la actualidad (estructurados, métodos
formales, métodos orientados a objetos, etc.
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").
Otro ejemplo podría ser un
concepto como "Proceso" que tenga los atributos
"Identificador", "Nombre", "Fecha de inicio",
"Fecha de finalización" y "Tipo", y asociado al
"Empleado" que lo inició.
Finalmente, aunque un objeto
de negocio representa una entidad, no se deben confundir con las entidades
relacionales. Muchas veces una entidad relacional puede ser representada por un
objeto de negocio, pero esto no es la regla. Se puede tomar como ejemplo una
entidad relacional como "Empleado" que tiene un atributo
"Tipo" que permite diferenciar los "Empleados nativos" y
los "Empleados extranjeros". Debido a las necesidades de un diseño,
puede que la entidad relacional acabe siendo dos objetos de negocio:
"Empleado Nativo" y "Empleado Extranjero", ya que éstos no
van a contener las mismas asociaciones. El primero tendrá asociaciones con su
información fiscal, mientras que la segunda tendrá lo propio con los impuestos
y la aduana.
