El ingeniero de sistemas dispone de tres métodos para integrar y lograr una propuesta eficaz de sistemas: la organización funcional del contenido de la propuesta, la redacción de la propuesta en un estilo propio para la organización, y la presentación oral de una propuesta de sistemas informativo. Ya que la propuesta es la esencia del trabajo que ha realizado, así como del esfuerzo futuro, es un documento decisivo para vender el sistema. Sea eficaz, la propuesta debe escribirse de una manera clara y comprensible en diez secciones funcionales. Debe contar con un título adecuado que capture el interés de sus lectores y presente de manera clara lo que contiene. La propuesta debe contar con un resumen ejecutivo que ofrezca una visión concisa del proyecto de sistemas y las recomendaciones.
Las consideraciones visuales son importantes cuando se busca una plena comunicación. Utilice suficientes espacios en blanco para resaltar el texto; sea generoso cuando incluya títulos principales y subtítulos; numere todas las páginas y mantenga un mínimo de referencias y apéndices.
Lo más relevante de la propuesta de sistemas puede enfatizarse por medio del uso adecuado de figuras, incluyendo tablas y gráficas. Las gráficas comparan dos o más variables en el tiempo o en un momento particular del tiempo. Las figuras siempre se acompañarán de una interpretación escrita en la propuesta. Las gráficas y las tablas que se utilicen durante la planificación previa a la propuesta, pueden incorporarse si se consideran relevantes.
La presentación oral de la propuesta del sistema se basa en el documento de la propuesta y es otra forma eficaz de vender el sistema. Con el fin de lograr una presentación con trascendencia, el ingeniero debe conocer anticipadamente cuatro elementos: quien integra la audiencia; el tópico (la propuesta de sistemas o parte de ella); el tiempo disponible para la presentación y el equipo disponible (incluyendo las instalaciones). Estos cuatro elementos se encuentran relacionados y cada uno debe pensarse y planearse para asegurar el éxito.
En el Lenguaje de Modelado Unificado, un diagrama de casos de uso es una especie de diagrama de comportamiento. UML mejorado El Lenguaje de Modelado Unificado define una notación gráfica para representar casos de uso llamada modelo de casos de uso. UML no define estándares para que el formato escrito describa loscasos de uso, y así mucha gente no entiende que esta notación gráfica define la naturaleza de un caso de uso; sin embargo una notación gráfica puede solo dar una vista general simple de un caso de uso o un conjunto de casos de uso. Losdiagramas de casos de uso son a menudo confundidos con los casos de uso. Mientras los dos conceptos están relacionados, los casos de uso son mucho más detallados que los diagramas de casos de uso.
La posición o contexto del caso de uso entre otros casos de uso. Dado que es un mecanismo de organización, un conjunto de casos de uso coherentes, consistentes promueve una imagen fácil del comportamiento del sistema, un entendimiento común entre el cliente/propietario/usuario y el equipo de desarrollo.
Es práctica común crear especificaciones suplementarias para capturar detalles de requisitos que caen fuera del ámbito de las descripciones de los casos de uso. Ejemplos de esos temas incluyen rendimiento, temas de escalabilidad/gestión, o cumplimiento de estándares.
Relaciones de Casos de Uso
Las tres relaciones principales entre los casos de uso son soportadas por el estándar UML, el cual describe notación gráfica para esas relaciones. Veamos una revisión de ellas a continuación:
Inclusión (include o use)
Es una forma de interacción o creación, un caso de uso dado puede "incluir" otro. El primer caso de uso a menudo depende del resultado del caso de uso incluido. Esto es útil para extraer comportamientos verdaderamente comunes desde múltiples casos de uso a una descripción individual, desde el caso de uso. El estándar de Lenguaje de Modelado Unificado de OMG define una notación gráfica para realizar diagramas de casos de uso, pero no el formato para describir casos de uso. Mucha gente sufre la equivocación pensando que un caso de uso es una notación gráfica (o es su descripción). Mientras la notación gráfica y las descripciones son importantes, ellos forman parte de la documentación de un caso de uso --un propósito para el que el actor puede usar el sistema. La notación es de una flecha de punta abierta con línea discontinua desde el caso de uso que lo incluye hasta el caso de uso incluido, con la etiqueta "«include»". Este uso se asemeja a una expansión de una macro, donde el comportamiento del caso incluido es colocado dentro del comportamiento del caso de uso base. No hay parámetros o valores de retorno. Aqui tambien podemos decir que éste va de padre a hijo.
Extensión (Extend)
Es otra forma de interacción, un caso de uso dado (la extensión) puede extender a otro. Esta relación indica que el comportamiento del caso de la extensión se utiliza en casos de uso, un caso de uso a otro caso siempre debe tener extensión o inclusión. El caso de uso extensión puede ser insertado en el caso de uso extendido bajo ciertas condiciones. La notación, es una flecha de punta abierta con línea discontinua, desde el caso de uso extensión al caso de uso extendido, con la etiqueta «extend». Esto puede ser útil para lidiar con casos especiales, o para acomodar nuevos requisitos durante el mantenimiento del sistema y su extensión.
"La extensión, es el conjunto de objetos a los que se aplica un concepto. Los objetos de la extensión son los ejemplos o instancias de los conceptos."
Generalización
"Entonces la Generalización es la actividad de identificar elementos en común entre conceptos y definir las relaciones de una superclase (concepto general) y subclase (concepto especializado). Es una manera de construir clasificaciones taxonómicas entre conceptos que entonces se representan en jerarquías de clases. Las subclases conceptuales son conformes con las superclases conceptuales en cuanto a la intención y extensión."
En la tercera forma de relaciones entre casos de uso, existe una relación generalización/especialización. Un caso de uso dado puede estar en una forma especializada de un caso de uso existente. La notación es una línea sólida terminada en un triángulo dibujado desde el caso de uso especializado al caso de uso general. Esto se asemeja al concepto orientado a objetos de sub-clases, en la práctica puede ser útil factorizar comportamientos comunes, restricciones al caso de uso general, describirlos una vez, y enfrentarse a los detalles excepcionales en los casos de uso especializados.
Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.
Se puede aplicar en el desarrollo de software entregando gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar.
UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización en un requerimiento. Mientras que, programación estructurada, es una forma de programar como lo es la orientación a objetos, sin embargo, la programación orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados a objetos.
UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas.
A pesar de su status de estándar ampliamente reconocido y utilizado, UML siempre ha sido muy criticado por su carencia de una semántica precisa, lo que ha dado lugar a que la interpretación de un modelo UML no pueda ser objetiva. Otro problema de UML es que no se presta con facilidad al diseño de sistemas distribuidos. En tales sistemas cobran importancia factores como transmisión, serialización, persistencia, etc. UML no cuenta con maneras de describir tales factores. No se puede, por ejemplo, usar UML para señalar que un objeto es persistente o remoto, o que existe en un servidor que corre continuamente y que es compartido entre varias instancias de ejecución del sistema analizado. Sin embargo, UML sí acepta la creación de nuestros propios componentes para este tipo de modelado.
UML es el Lenguaje Unificado de Modelado (Unified Modeling Language, por sus siglas en inglés). Se trata del lenguaje de diseño y modelado de sistemas más usado y conocido en la actualidad. A continuación se presentan los diagramas utilizados en UML para el modelado de sistemas:
Este de diagramas describe cómo se usa el sistema, partiendo desde el de vista del usuario . Esto da una buena pauta para conocer más a fondo los requisitos que deberá tener el sistema a desarrollar. Debe tenerse el cuidado de no confundir la palabra "cómo", cuando se dice los diagramas de caso de uso describen "cómo se usa el sistema". Esto se refiere al "cómo" desde el punto de vista de los pasos que se van a realizar por parte del usuario final, y no al "cómo" del procedimiento técnico que se va a utilizar para dar solución a un problema o caso específico.
El objetivo de este tipo de diagramas es mostrar la manera en la que un usuario final va a interactuar con el sistema a desarrollar, sin preocuparse por la forma en la que se va a lograr implementar eso, técnicamente hablando, es decir, sin tomar en cuenta los mecanismos que se van a utilizar para crear o hacer funcionar el sistema.
a mejor forma de desarrollar un buen diagrama de caso de uso es mediante entrevista directa con los usuarios o posibles futuros usuarios del sistema, poniendo atención a cada una de las o pasos que se van a ir desarrollando desde un primer momento hasta un momento .
La elaboración de diagramas de uso ayuda poderosamente a un analista a comprender la forma en que un sistema deberá comportarse, obteniendo los requerimientos desde el de vista del usuario.
En todo caso de uso siempre hay un , que es quien inicia, y luego otro actor (que puede ser el mismo que inicia el caso de uso o puede ser otro diferente), que recibirá algo por parte del sistema. La representación gráfica es directa, de la siguiente forma:
En la figura anterior, la elipse representa el caso de uso. Las dos figuras en los extremos izquierdo y derecho son los actores que intervienen. El actor que inicia se encuentra a la izquierda del caso de uso, y el que recibe a la derecha. El nombre del actor aparece justo debajo de él, y el nombre del caso de uso aparece ya sea dentro de la elipse o justo debajo de ella. Una línea asociativa conecta a un actor con el caso de uso, y representa la comunicaciónentre el actor y el caso de uso. La línea asociativa es sólida. El rectángulo envuelve a los casos de uso dentro del sistema.
A continuación se muestra un caso de uso que aunque en instancia podría parecer complejo, realmente no lo es una vez se comprende el significado de cada uno de los símbolos utilizados, los cuales se explicarán posteriormente uno a uno:
Ya se explicó anteriormente lo que significan la elipse, las figuras de los actores en los extremos izquierdo y derecho, el nombre de los actores debajo de dichas figuras de los extremos, el nombre del caso de uso dentro de las elipses, así como las líneas asociativas y el rectángulo dentro del cual aparecen todos los casos de uso, con el nombre del sistema en la parte superior y siempre dentro del rectángulo.
En el diagrama de ejemplo, un aspecto importante que se ha utilizado es la "inclusión", que permite volver a utilizar los pasos de un caso de uso dentro de otro. Esto significa según el ejemplo mostrado, que tanto "Reabastecer" como "Recolectar dinero" son casos de uso que incluyen siempre otro conjunto de pasos que son los correspondientes a "Exhibir el interior" y "Cubrir el interior". Esto es así porque siempre que se quiera "Reabastecer" una máquina de gaseosas o "Recolectar dinero" contenido en la máquina, inevitablemente se iniciará mediante la de la máquina y se finalizará con el cierre y sellado de la misma.
Se han utilizado líneas discontinuas con una de flecha que se dirige hacia las clases dependientes ("Exhibir el interior" y "Cubrir el interior" son las dos clases dependientes). Este de flechas son el símbolo que representa inclusión en la nomenclaturaUML. Justo sobre la línea se ha agregado una palabra que se utiliza para revelar la relación de inclusión existente entre los casos de uso vinculados. Esta palabra debe ponerse precisamente sobre la flecha (o a un lado de la línea, si esta fuera vertical, o incluso debajo de la línea si el espacio de trabajo obliga a ello) y debe ser bordeada por dos pares de paréntesis angulares. La palabra que se ha utilizado es «incluir».
En el ejemplo también se ha utilizado la "extensión", que consiste en añadir un nuevo caso de uso al caso original, que sería el caso de uso "base". Para el ejemplo concreto que se ha mostrado, en lugar de sólo reabastecer la máquina de gaseosas con marcas y sabores aleatorios, el reabastecimiento se hace de tal manera que la máquina tenga la misma cantidad de latas para cada una de las marcas y sabores. Pero se debe tener en cuenta que la extensión sólo se puede realizar en puntos indicados de manera específica dentro de la secuencia del caso de uso base. A estos puntos se les conoce como "puntos de extensión." En el caso de uso "Reabastecer," los nuevos pasos (anotar las ventas y abastecer de manera acorde) se darían luego que el haya abierto la máquina y esté listo para llenar los compartimientos de las marcas de gaseosas. En este ejemplo, el punto de extensión es "Llenar los compartimientos." Nótese también que para realizar la inclusión, se ha usado una línea de dependencia (línea discontinua con una punta de flecha), junto con la palabra "extender" entre paréntesis angulares. Pero es importante destacar la dirección que tiene la línea de dependencia, pues siempre deben ir dirigidas hacia las clases dependientes. Para el ejemplo, el caso de uso dependiente es "Reabastecer", y el caso de uso independiente es "Reabastecer de acuerdo a las ventas", pues lo primero que se tiene que hacer es verificar cuántas latas de gaseosa hay en existencia para cada marca y sabor según las ventas que se hayan hecho, y luego partiendo de eso se procede a reabastecer con una proporción adecuada. En síntesis, la línea discontinua con una flecha denota una "relación de dependencia", donde el sentido de la flecha apunta hacia la clase o caso de uso dependiente, y porlógica donde no se encuentra la flecha es el caso de uso independiente. Dentro de la elipse del caso de uso básico, para el caso de estar utilizando extensión, debe aparecer el nombre del caso de uso y el punto de extensión, en este caso "Reabastecer" y debajo de eso "Punto de extensión llenar los compartimientos", respectivamente.
En el ejemplo también se ha hecho uso de la "generalización". Esto significa que las clases pueden heredarse entre sí. La generalización se modela con líneas continuas y una punta de flecha en forma de triángulo sin rellenar que apunta hacia el caso de uso primario. La relación de generalización puede establecerse entre actores, así como entre casos de uso. Para el ejemplo presentado se ha hecho entre casos de uso, y el significado es que el caso de uso primario es "Comprar gaseosa" (pues hacia ahí apunta la flecha), y el caso de uso secundario es "Comprar un vaso de gaseosa". Entonces el caso de uso secundario hereda o tiene acciones del caso de uso primario, tales como "agregar hielo", etc. El caso secundario hereda las acciones del primario, pero además agrega sus propias acciones. Por tanto, se puede aplicar el caso de uso secundario en cualquier lugar donde aplique el primario.
Ejemplo de diagrama de estados
Conforme un sistema interactúa con los usuarios y (posiblemente) con otros sistemas, los objetos que lo conforman pasan por cambios necesarios para ajustar las interacciones. Por esa razón se necesita contar con un mecanismo para cambios en el modelo. Un cambio en un sistema se da debido a que los objetos que componen dicho sistema modificaron su estado como respuesta a los sucesos y al tiempo. Un diagrama de estados también se conoce como un "motor de estado."
El ícono para el estado, como se aprecia en la Figura 3, es un rectángulo de vértices redondeados, y el símbolo de una transición es una línea continua y una punta de flecha. El círculo relleno se interpreta como el punto inicial de una secuencia de estados, y la diana representa al punto final.
Se puede subdividir el símbolo de la Figura 3 en áreas que muestren el nombre, variables y actividades del estado, de esta forma:
Las variables de estado como cronómetros o contadores son, en ocasiones, de ayuda. Las actividades constan de sucesos y acciones: tres de las más utilizadas son entrada (qué sucede cuando el sistema entra al estado), salida (qué sucede cuando el sistema sale del estado), y hacer (qué sucede cuando el sistema está en el estado). Se pueden agregar otros conforme sea necesario.
A continuación se muestra un ejemplo concreto de un diagrama de estados:
Como se puede ver en la Figura 5, lo primero que se hace es encender la máquina de fax, con lo cual esta arranca y se encuentra lista en condiciones normales, para realizar el envío de fax, que es el siguiente estado registrado. Cuando se envía un fax –esto es, cuando se encuentra en estado de envío de fax- la máquina de fax anota la fecha y hora en que inició el envío (los valores de las variables de estado "fecha" y "hora"), y también anota el número telefónico así como el nombre del propietario (los valores de las variables de estado "teléfono" y "propietario"). Al encontrarse en este estado, la máquina se encarga de agregar un registro de fecha y hora al fax, número telefónico y nombre del propietario. En otras actividades de este estado, la máquina jalará las hojas, paginará el fax y finalizará la transmisión. Mientras se encuentre en el estado de inactividad, la máquina de fax mostrará la fecha y la hora en una pantalla. Finalmente, cuando ya no se vaya a utilizar la máquina de fax por un periodo determinado, se podrá apagar, siendo este también un estado concreto.
Ejemplo de diagrama de secuencias
Este tipo de diagramas muestra una interacción ordenada según la secuencia de eventos vista a la luz de una línea de tiempo. En particular, se muestran los objetos participantes en la interacción y los mensajes que intercambian ordenados según su secuencia en el tiempo.
El eje vertical representa , y en el eje horizontal se colocan los objetos y actores participantes en la interacción, sin un orden prefijado, aunque por orden lo usual es colocar los objetos de izquierda a derecha y en la parte superior. 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 hacia abajo. Se pueden colocar etiquetas (como restricciones de tiempo, descripciones de acciones, etc.) bien en el margen izquierdo o bien junto a las transiciones o activaciones a las que se refieren. Cada línea de vida de un objeto es una línea discontinua que se desplaza hacia abajo del objeto. Una línea continua con una punta de flecha conecta a una línea de vida con otra, y representa un mensaje de un objeto a otro. El tiempo se inicia en la parte superior y continúa hacia abajo. Aunque un actor es el que normalmente inicia la secuencia, su símbolo no es parte del conjunto de símbolos del diagrama de secuencias. No necesariamente se debe especificar el tiempo de manera explícita (como en segundos, minutos, horas, días, etc.), aunque se puede hacer si resulta necesario o conveniente. En todo caso lo que siempre se tiene que hacer es ubicar correctamente en el eje vertical la secuencia correcta de eventos que se deben ir dando de forma cronológica o en una línea de tiempo.
El siguiente ejemplo muestra cómo se puede realizar un diagrama de secuencias:
En la Figura 6 se representa la forma en que la GUI interacciona con otros objetos. Obsérvese que la secuencia se origina y finaliza en el estado operativo de la GUI, como es de esperar, pero para llegar a eso se da una secuencia de procesos plasmados en el diagrama.
Ejemplo de diagrama de colaboraciones
En este tipo de diagramas se muestra una interacción organizada, basándose en los objetos que toman parte en la interacción y los enlaces entre los mismos (en cuanto a la interacción se refiere). 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. Aunque se muestran los mensajes que se envían los objetos entre sí, por lo general se evita la multiplicidad de mensajes dado que podría ser fuente de confusión. En la representación de los mensajes, la flecha que se dibuja cerca de la línea de asociación entre dos objetos, apunta al objeto receptor. El mensaje finaliza con un par de paréntesis, dentro de los cuales se colocan los parámetros (en caso de haber alguno) con los que funcionará la operación.
Se puede convertir cualquier diagrama de secuencias en diagrama de colaboraciones y viceversa. Por medio de esto se puede representar lainformación de secuencia en un diagrama de colaboraciones. Para ello se agrega una cifra a la etiqueta de un mensaje, la cual corresponde a la secuencia propia del mensaje. La cifra y el mensaje se separan mediante dos puntos (:).
El ejemplo de diagrama de secuencias mostrado en la Figura 6, se convertirá ahora a un diagrama de colaboraciones, quedando de la siguiente manera:
Las colaboraciones representadas en la Figura 8 se dan de esta manera:
5. La tarjeta de vídeo envía un mensaje al monitor.
6. El monitor presenta el carácter alfanumérico en la pantalla, con lo que se hará evidente al usuario.
Ejemplo de diagrama de actividades
Este tipo de diagrama le resulta familiar a la mayoría de programadores, pues en cualquier curso básico de programación se comienza por trabajar con los diagramas de flujo para conocer la lógica que llevará un programa. Los tradicionales diagramas de flujo muestran una secuencia de pasos, procesos, puntos de decisión y bifurcaciones. Con sus diversas características y tipos de diagramas, el UML se podría decir que es en cierta medida, un diagrama de flujo robustecido o reforzado. Para el caso particular del diagrama de actividades, es muy parecido a los viejos diagramas de flujo, pues muestra los pasos (conocidos como actividades) así como puntos de decisión y bifurcaciones. Lo que hacen es mostrar una visión simplificada de lo que ocurre durante una operación o proceso. Se puede decir también que es una extensión del diagrama de estados. El diagrama de estados muestra los estados de un objeto y representa las actividades como flechas que conectan a los estados. Por su parte, el diagrama de actividades resalta, precisamente, las actividades.
Cada actividad se representa por un rectángulo con las esquinas redondeadas (más angosto y ovalado que la representación del estado). El procesamiento dentro de una actividad se lleva a cabo y, al realizarse, se continúa con la siguiente actividad. Una flecha representa la transición de una a otra actividad. Al igual que el diagrama de estados, el de actividad cuenta con un punto inicial (representado por un círculo relleno) y uno final (representado por una diana).
Los diagramas de actividades tienen la poderosa herramienta de permitir tomar decisiones, como se muestra en la siguiente figura:
Es posible también modelar actividades que serán ejecutadas al mismo tiempo (es decir, de forma concurrente) y que luego se reúnan. Para representar esto, se utiliza una línea gruesa perpendicular a la transición y las rutas parten de ella. Para representar la reincorporación, ambas rutas apuntan a otra línea gruesa, de esta forma:
Se muestra ahora un ejemplo en el que se utilizará un diagrama de actividades para utilizar una aplicación de oficina (software) para crear un documento. La secuencia sería la siguiente:
1. Abrir la aplicación para procesamiento de textos.
2. Crear un archivo con un nombre único en una carpeta.
3. Guardar el archivo con un nombre único en una carpeta.
4. Teclear el documento.
5. Si se necesitan ilustraciones, se abre la aplicación relacionada, se generan los gráficos y se colocan en el documento.
6. Si se necesita una hoja de cálculo, se abre la aplicación relacionada, se crea la hoja correspondiente y se coloca en el documento.
7. Se guarda el archivo.
8. Se imprime el documento.
9. Se sale de la aplicación de oficina.
El diagrama de actividades queda representado así:
Ejemplo de diagrama de componentes
Un componente de software es una parte física de un sistema, y se encuentra en la computadora, no en la mente del analista. Ejemplos de componentes son tablas, archivos de datos, ejecutables, bibliotecas de vínculos dinámicos, documentos y cosas por el estilo.
Lo que contiene un diagrama de componentes es lógicamente componentes, interfaces y relaciones, aunque también pueden aparecer otros tipos de símbolos vistos anteriormente.
El símbolo principal de un diagrama de componentes es un rectángulo que tiene otros dos sobrepuestos en su lado izquierdo, con el nombre del componente dentro del rectángulo más grande, como se muestra en la siguiente figura:
Como ejemplo se presenta el siguiente diagrama de componentes para una página web con componentes ActiveX:
Como se observa en el ejemplo, existe un conjunto de componentes que se encuentran interrelacionados utilizando flechas discontinuas que como se explicó anteriormente en los diagramas de casos de uso, representan relaciones de dependencia, donde la dirección de la flecha apunta a la clase dependiente, que en este caso sería el componente dependiente, y por consecuencia en el extremo donde no hay flecha se encuentra el componente independiente. Se ha hecho uso también de un símbolo que no se había utilizado antes, que es el símbolo de anotación y que sirve para hacer precisamente anotaciones o comentarios:
Ejemplo de diagrama de distribución
Este tipo de diagramas se enfoca específicamente al hardware de un sistema determinado.
El elemento primordial del hardware es un nodo, que es un nombre genérico para todo tipo de recurso de cómputo.
Para comenzar, se debe saber que un nodo se representa mediante un cubo:
Dentro del cubo se puede introducir información sobre el nodo, que puede ser simplemente texto o inclusive componentes, usando los diagramas de componentes anteriormente ejemplificados. En el ejemplo que se muestra a continuación, puede verse un nodo que tiene componentes de software (Windows, Office e Internet Explorer). Aunque como ya se dijo, los diagramas de distribución se enfocan en la parte de hardware, cada uno de los nodos puede contener otros componentes, incluyendo software, lo cual puede ser especificado en el diagrama:
Ejemplo de diagrama de clases
En UML, un rectángulo es el símbolo que representa a la clase, y se divide en tres áreas. El área superior contiene el nombre de la clase, el área central contiene los atributos o propiedades, y el área inferior, las acciones, procedimientos, métodos o funciones. Un diagrama de clases está formado por varios rectángulos de este tipo conectados por líneas que muestran la manera en que las clases se relacionan entre sí.
En el ejemplo que se presentará a continuación, se muestran tres clases, donde las líneas continuas con extremos en forma de triángulo sin rellenar, tal como se había explicado anteriormente en este documento, son los símbolos de asociación de generalización, que sirven para mostrar herencia de una clase a otra, donde el extremo del triángulo sin rellenar (que simula una flecha) apunta hacia la clase base, y en el extremo de la línea continua que no tiene dicho triángulo se encuentra la clase que hereda. Para decirlo de forma más concreta y de acuerdo al ejemplo, la clase base es "Vehículo" y las clases que heredan las propiedades y acciones de la clase "Vehículo" son "Auto" y "Camioneta", lo cual al imaginarlo en un escenario de la vida real, es completamente atinado y razonable.
Ejemplo de diagrama de objetos
Partiendo del hecho que un objeto es una instancia de clase, tal como se define en la conceptualización básica de la programación orientada a objetos, en UML la representación de un diagrama de objetos se hace de tal forma que teniendo ya una clase, el símbolo del objeto es un rectángulo, pero con el nombre subrayado. El nombre de la instancia específica se encuentra a la izquierda de los dos puntos (:), y el nombre de la clase a la derecha. Por ejemplo, si ya se tuviera una clase llamada "Lavadora", una instancia de esa clase o un objeto instanciado a partir de esa clase se representaría de la siguiente forma:
DFD). Los diagramas de flujo de datos son un tipo de herramienta de modelado, permiten modelar todo tipo de sistemas, concentrándose en las funciones que realiza, y los datos de entrada y salida de esas funciones.
Componentes de los DFD
* PROCESOS (burbujas): representan la parte del sistema que transforma ciertas entradas en ciertassalidas.
* FLUJOS: representan los datos en movimiento. Pueden ser flujos de entrada o flujos de salida. Los flujos conectan procesos entre sí y también almacenes con procesos.
* ALMACENES: representan datos almacenados. Pueden ser una base de datos, un archivo físico, etc.
* TERMINADORES: representan entidades externas que se comunican con el sistema. Esas entidades pueden ser personas, organizaciones u otros sistemas, pero no pertenecen al sistema que se está modelando.
Existen procesos y flujos especiales llamados procesos de control y flujos de control. Se emplean para modelar sistemas en tiempo real.
Los flujos de control son señales o interrupciones, en tanto los procesos de control son burbujas que coordinan y sincronizan otros procesos. Los procesos de control sólo se conectan con flujos de control.
Los flujos de control de salida "despiertan" otras burbujas, en tanto los flujos de control de entrada, especifican que una tarea terminó o se presentó un evento extraordinario.
Representación de un sistema en DFD
Un sistema puede representarse empleando varios diagramas de flujos de datos, cada flujo de datospuede representar una parte "más pequeña" del sistema.
Los DFD permiten una partición por niveles del sistema. El nivel más general se representa con un DFDglobal llamado diagrama de contexto.
El diagrama de contexto DFD representa a todo el sistema con una simple burbuja o proceso, lasentradas y salidas de todo el sistema, y las interacciones con los terminadores.
Complementos del DFD
Los DFD suelen servir para comprender fácilmente el funcionamiento de un sistema. De todas maneras, no es la única herramienta para diagramar sistemas, es más, se debe complementar con otrasherramientas para agregar comprensión y exactitud al DFD.
El proceso de seleccionar sistemáticamente elementos representativos de una población es llamado muestreo. El objeto del muestreo es seleccionar y estudiar documentos, tales como facturas, reportes de ventas y memorándums, o tal vez seleccionar y entrevistar, dar cuestionarios u observar a miembros de la organización. El muestreo puede reducir costos, velocidad de recolección de datos, hacer potencialmente que el estudio sea más efectivo y posiblemente reducir la ascendencia en el estudio. Cuatro tipos principales de muestras que tiene el analista. Un analista de sistemas debe seguir cuatro pasos en el diseño de una buena muestra. Primero, se tiene la necesidad de determinar la población misma. Segundo, se debe decidir el tipo de muestra. Tercero, se debe calcular el tamaño de muestra. Por último, se deben planear los datos que necesitan ser recolectados o descritos. Tipos de información buscada en la investigación Los tipos de muestras útiles para un analista de sistemas son: de conveniencia, intencionada, aleatoria simple y aleatoria compleja. El último tipo incluye las subcategorías de muestreo sistemático y muestreo estratificado. Hay varios lineamientos a seguir para la determinación del tamaño de muestra. El analista de sistemas puede hacer una decisión subjetiva en relación con el estimado de intervalo aceptable. Luego se selecciona un nivel de confianza y puede ser calculado el tamaño de muestra necesario.
El analista de sistemas necesita investigar datos relevantes, incluyendo reportes, documentos, estados financieros, manuales de procedimientos y memorándums. Los datos relevantes muestran dónde ha estado la organización y hacia dónde creen sus miembros que están yendo. Es necesario que sean analizados documentos cuantitativos y cualitativos.
Debido a que los documentos son mensajes persuasivos, debe ser reconocido que el cambiarlos también puede cambiar a la organización. Las consignas que se colocan revelan la cultura oficial de la organización Hay muchas formas de analizar documentos cuantitativos y cualitativos. Sin embargo, es importante recordar que la investigación de los datos archivados tiene ventajas y desventajas. Debido a que muchas de las desventajas pueden ser superadas, vale la pena la investigación de archivos. Una de las desventajas del uso de datos archivados es que los datos pueden ser importantes solamente para aquel que originalmente los guardó.
ENTREVISTAS.
El proceso de las entrevistas es un método que usa el analista de sistemas para la recolección de datos sobre los requerimientos de información. El analista de sistemas escucha buscando objetivos, sentimientos, opiniones y procedimientos informales en entrevistas con los tomadores de decisiones de la organización. También vende el sistema durante las entrevistas. Las entrevistas son diálogos de
preguntas respuestas planeados por anticipado entre dos personas.
Hay cinco pasos que deben tomarse para la planeación previa de la entrevista:
5. Decisión sobre el tipo y estructura de las preguntas
Las preguntas tienen dos tipos básicos: abiertas y cerradas. Las preguntas abiertas dejan abiertas todas las opciones de respuesta para el entrevistado, Las preguntas cerradas limitan las opciones posibles de la respuesta. Las averiguaciones pueden ser abiertas o cerradas, pero le solicitan al interlocutor una respuesta más detallada. Las entrevistas pueden estar estructuradas en tres formas básicas, estructura de pirámide, de embudo o de rombo. Lasestructuras piramidales comienzan con preguntas cerradas y detalladas y se amplían a preguntas más generales. Las estructuras de embudo comienzan con preguntas abiertas generales y luego se estrechan a preguntas cerradas más específicas. Las estructuras de rombo combinan las fuerzas de las otras dos estructuras pero se llevan más tiempo para realizarse. Hay compromisos involucrados sobre la decisión de cómo estructurar para re
alizar las preguntas y sec
uencias de preguntas de la entrevista. Las entrevistas deben ser grabadas por medio de grabadoras de cinta o la toma de notas. Después de la entrevista, el entrevistador debe escribir un reporte que liste los puntos principales que se proporcionaron, así como opiniones acerca de lo que fue dicho. Es extremadamente importante documentar la entrevista lo más pronto posible después de que haya sido realizada. Para reducir tanto el tiempo como el costo de las entrevistas personales, los analistas pueden considerar el diseño conjunto de aplicaciones (JAD) como una alternativa. Mediante el uso del JAD los analistas logran tanto el análisis de requerimientos como el diseño de la interfaz de usuario con los usuarios en un lugar de reunión de grupo. La valoración cuidadosa del lugar de reunión para la organización ayudará a juzgar al analista si el JAD es una alternativa adecuada.
6. USO DE CUESTIONARIOS.
Mediante el uso de cuestionarios los analistas de sistemas pueden recolectar datos sobre actitudes, creencias, comportamientos y características de gentes importantes en la organización. Los cuestionarios son útiles sí: las personas de la organización están ampliamente dispersas, muchas gentes están involucradas con el proyecto de sistema, se necesita un trabajo exploratorio antes de recomendar alternativas o hay una necesidad para la sensibilización del problema antes de que se realicen entrevistas. Una vez que han sido articulados los objetivos del cuestionario, el analista puede comenzar a escribir preguntas abiertas o cerradas. La selección de la redacción es extremadamente importante y debe reflejar el lenguaje de los miembros de la organización. Idealmente, las preguntas deben ser simples, específicas, sin ascendencia, sin menosprecio, técnicamente precisas y dirigidas a aquellos que tienen el conocimiento. La asignación de escalas es el proceso de asignar números u otros símbolos a un atributo o característica. Tal vez quiera el analista de sistemas usar escalas para medir las actitudes o las características de los interlocutores o para hacer que los interlocutores actúen como jueces sobre el tema del cuestionario.
Las cuatro formas de medición son escalas nominales, ordinales, de intervalo y de relación. La forma de medición es frecuentemente indicada por los datos, y el análisis de los datos es a su vez indicado en alguna medida por la forma de medición.
Los analistas de sistemas necesitan tomar en consideración la validez y la confiabilidad. La validez significa que el cuestionario mide lo que el analista de sistemas pretendió medir. La confiabilidad significa que los resultados son consistentes.
Los analistas deben ser cuidadosos para evitar problemas como lenidad, tendencia central y el efecto de halo cuando construyen escalas. El control consistente del formato y estilo del cuestionario puede dar como resultado una mejor tasa de respuesta. Adicionalmente, el ordenamiento y agrupamiento significativo de las preguntas es importante para ayudar a que los interlocutores comprendan el cuestionario.
