 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Unidad III Técnicas para el análisis de requerimientos 3.1 Técnicas estructuradas para el análisis de requerimientos Aquí se presentan las fases que integran la vida de un sistema de manejo de información para la administración y la función del analista de sistemas dentro de las mismas. ETAPAS DE LA VIDA DE UN SISTEMA La vida de un sistema de negocios recorre 3 etapas claramente definidas: 1. La primera es el análisis y diseño en el cual es revisado un sistema existente para ganar comprensión, especificando sus verdaderos requerimientos, diseñando un nuevo sistema que cumpla con dichos requerimientos. 2. La Segunda etapa consiste básicamente en poner a prueba el sistema diseñado en la primera etapa, llevando a la practica todos los trabajos planeados en los estudios y proyectos del nuevo sistema, adecuando y coordinando todos los elementos que en su funcionamiento habrán de invertir. 3. La tercera etapa es la operación, rutina diaria de pasadas y manejo del sistema, y su modificación a medida que van apareciendo nuevos requerimientos. Etapas en la vida de un sistema: 1- Estudio y diseño. Fase 1. Comprender el negocio actual Fase2. Determinar requerimientos del sistema Fase3. Diseño del nuevo sistem 2- Implementación. 3- Operación y supervisión. Existen 4 metodos principales de reunir información: · Entrevistas y cuestionarios · Investigaciones en registros y archivos · Muestreos y estimaciones · Observaciones directas Entrevista Es tal vez la forma mas productiva de obtener información, si el analista cuenta con la confianza del entrevistado. Debe entrevistarse a todo el personal que se considere conveniente, independientemente del nivel jerárquico del puesto que desempeñen. Unos cuantos puntos que deben tomarse en cuenta al planear una entrevista son los siguientes:
Cuestionarios Constituyen otro medio de reunir información, resultan de menos utilidad que las entrevistas, pero deben aplicarse en caso de considerarse necesario. Se recomienda tener cuidado al elaborar los cuestionarios, tratando de hacer las preguntas de la forma mas entendible y sencilla que sea posible, de tal manera que puedan ser entendidas plenamente por las personas que las resolverán. Investigación en registros y archivos Normalmente las fuentes de informacion dentro de los negocios existen en diversos lugares, por lo que antes de entrar de lleno a la reunion de informacion, debe obtenerse de parte de la administracion una lista de las fuentes donde podra encontrarse la información que sea necesaria. Estimaciones y muestreo Es común que en algunos negocios en crecimiento se preste poca atención al mantenimiento de Registros Históricos. Por consiguientes la búsqueda de archivos raramente da como resultado el reunir datos adecuados. En estos casos es aceptable el metodo estimativo de desarrollar datos, lo mismo que en aquellas situaciones de alto volumen o sumamente complejas, en los cuales no hay procedimientos establecidos que permitan el resumen inmediato de los datos. Observaciones directas Cuando los datos se obtienen directamente por el investigador, captados por sus propios sentidos. Tipo de información que conviene reunir No es posible especificar en forma definitiva la cantidad y calidad de la informacion que es necesaria reunir al efectuar un trabajo de análisis y diseño de un sistema, Mas bien esta situacion debe ser definida por el analista encargado del estudio del sistema de acuerdo a los objetivos previamente fijados, asi como al alcance que se desea dar a los resultados que el sistema deba obtener. En este aspecto lo único que puede recomendarse es que debe reunirse solamente la información que se crea pertinente, con tal que permita al analista conocer todos los elementos que intervienen dentro del sistema a estudiar; conocimiento que le será de gran ayuda al pensar en la solucion que vaya a dar el problema planteado, pues contará con todos los elementos del juicio requeridos para escoger la alternativa que mejor se adapte a la situacion especifica que se le plantee. Los Niveles de información a reunir, pueden agruparse en:
3.1.1 Caracteristicas del Analisis Estructurado El análisis estructurado hace uso de los siguientes componentes:
Características de un sistema Diagrama de Flujo Proceso Eentrada/Salida Conectores Símbolos relacionados con programación Decision Terminal Proceso predefinido Simbolos relacionados con sistemas Ejemplo 1 El siguiente diagrama muestra los pasos a seguir por un joven para enamorar a una dama Ejemplo 2 3.1.2 Especificacion Formal de Datos Cuando los analistas de sistemas intentan entender los requerimientos de información de los usuarios, deben tener la capacidad de visualizar como se mueven los datos en la organización, los procesos o transformaciones que sufren dichos datos y cuales son los resultados . Aunque las entrevistas y la investigación de datos reales y concretos proporcionan una descripción verbal del sistema, una descripción visual puede consolidar esta información de manera bastante útil. El analista de sistemas puede elaborar una representación grafica de los procesos que se realizan con los datos en toda la organización, mediante una técnica de análisis estructurada llamada diagramas de flujo de datos (DFD's) . Con el uso de tan solo cuatro símbolos, el analista de sistemas puede crear una descripción grafica de los procesos que, con el tiempo, contribuirá a desarrollar una solida documentación del sistema. Ventajas del enfoque de flujo de datos El enfoque de flujo de datos posee cuatro ventajas principales sobre las explicaciones descriptivas en relación con la forma en que los datos se mueven a través del sistema. 1.- Libertad para emprender la implementación técnica del sistema en las etapas tempranas 2.- Una comprensión mas profunda de la interrelación entre sistemas y sub sistemas 3.- Comunicar a los usuarios el conocimiento sobre el sistema actual mediante diagramas de flujo de datos 4.- Análisis de un sistema propuesto para determinar si se han definido los datos y procesos necesarios Quizás la ventaja mas grande es la libertad conceptual para utilizarlos cuatro símbolos . Ninguno de los símbolos que especifica los aspectos físicos de la implementación. Los DFDs hacen énfasis en el procesamiento o la transformación de datos conforme estos pasan por una variedad de procesos. En los DFD's lógicos no hay distinción entre procesos manuales o automatizados. Los procesos tampoco se representan gráficamente en orden cronológico. En vez de ello, se agrupan solo si el análisis detallado dicta que tiene sentido hacerlo. Los procesos automatizados también se pueden agrupar. Este concepto, llamado particionamiento. 3.1.2.1 Diagrama de Flujo y Control de Datos El analista de sistemas puede elaborar una representacion grafica de los procesos que se realizan con los datos e toda la organización, mediante una tecnica de analisis estructurada llamada diagrama de flujo de datos (DFDs) Ventajas del enfoque de flujo de datos • Libertad para emprender la implementacion tecnica del sistema en las etapas tempranas. • Una comprencion mas profunda de la interrelacion entre sistemas y subsistemas. • Comunicar a los usuarios el conocimiento sobre el tema actual mediante diagramas de flujo de datos. • Analisis de un sistema propuesto para determinar si se han definido los datos y procesos necesarios. Convenciones usadas en los diagramas de flujo de datos Con la combinacion de estos 4 simbolos se puede describir graficamente un sistema completo y varios subsistemas. Desarrollo de diagramas de flujo de datos usando un enfoque jerárquico de arriba abajo
• Entidades externas • Flujo de datos • Procesos • Almacenes de datos 2. Cree un diagrama de contexto que muestre las entidades externas y los flujos de datos desde y hacia el sistema. No muestre procesos ni almacenes de datos detallados. Contiene un solo proceso que representa a todo el sistema (número 0) 3. Dibuje el Diagrama 0 (el siguiente nivel). Muestre procesos, pero que sean generales. En este nivel muestre almacenes de datos. 4. Cree un diagrama hijo para cada uno de los procesos del Diagrama 0 5. Revise que no haya errores y asegúrese de que sean significativos los nombres que haya asignado a cada proceso y flujo de datos 6. Desarrolle un diagrama de flujo de datos físico a partir del diagrama de flujo de datos lógico. Distinga entre los procesos manuales y automatizados, describa los archivos reales y los informes por nombre y agregue controles para indicar cuándo se completan los procesos o cuándo ocurren errores. 7. Particione el diagrama de flujo de datos físico separando o agrupando sus partes con el propósito de facilitar la programación y la implementación Ejemplo.- resumen de las actividades de negocios del sistema de renta a clientes
3.1.2.2Diccionario de Datos Un diccionario de datos es un conjunto de metadatos que contiene las características lógicas de los datos que se van a utilizar en el sistema que se programa, incluyendo nombre, descripción, alias, contenido y organización. Estos diccionarios se desarrollan durante el análisis de flujo de datos y ayuda a los analistas que participan en la determinación de los requerimientos del sistema, su contenido también se emplea durante el diseño del proyecto. • REGISTRO DE EMPLEADOS = {Registro del empleado} • REGISTRO DE TIEMPOS DEL EMPLEADO = {Registro de tiempos del empleado} • Registro del empleado = • * Datos de cada empleado* • Número de empleado + Información personal + Información de pago + Información de pago actual + Información anual • Registro de tiempos del empleado = Número de empleado + Nombre del empleado + Horas trabajadas • Cheque de pago del empleado = Número de empleado + Nombre de empleado + Dirección + Cantidades del pago actual + 5 • Produce el cheque de pago del empleado • REGISTRO DE TIEMPOS DEL EMPLEADO • Empleado • Cheque de pago del empleado • Registro del empleado • Registro de tiempos del empleado • REGISTRO DE EMPLEADOS • El DD provee información del DER. En general, las instancias del DER corresponden a los almacenes de datos de los DFD. EJEMPLO: CLIENTES = {cliente} • cliente = nombre-cliente + dirección + número-teléfono • compra = * asociación entre un cliente y uno o más artículos * • nombre-cliente + 1{id-artículo + cantidad-artículos} • ARTÍCULOS = {artículo} • artículo = id-artículo + descripción 3.1.3 Especificacion de Procesos La especificación de procesos, es una herramienta de modelado de sistemas, que permite definir qué sucede en los procesos o funciones de un sistema. No hay una única forma de realizar la especificación de procesos; existen múltiples herramientas que facilitan esta tarea, aunque deberían emplearse aquellas que permitan fácil comprensión. Desarrollo de una especificación de procesos Algunas herramientas utilizadas para generar especificaciones de procesos son: * Otras • Tablas de decisiones, • Lenguaje narrativo, • Diagramas de flujos, • Diagrama Nassi-Shneiderman, • Gráficas, etc. 3.1.3.1 Lenguaje natural Tiene la debilidad inherente del lenguaje natural como herramienta para especificar: • Imprecisa. • Redundante. • Llena de implicaciones y connotaciones. Como mencionamos anteriormente el Lenguaje Natural (LN) es el medio que utilizamos de manera cotidiana para establecer nuestra comunicación con las demás personas Este tipo de lenguaje es el que nos permite el designar las cosas actuales y razonar a cerca de ellas, fue desarrollado y organizado a partir de la experiencia humana y puede ser utilizado para analizar situaciones altamente complejas y razonar muy sutilmente. • Desarrollados por enriquecimiento progresivo antes de cualquier intento de formación de una teoría. • La importancia de su carácter expresivo debido grandemente a la riqueza del componente semántico (poli semántica). • Dificultad o imposibilidad de una formalización completa. 3.1.3.2Lenguaje estructurado Lenguaje natural limitado en palabras y construcciones, lo que le da más precisión y claridad, evitando ambigüedades (el lenguaje natural humano carece de precisión y es muy ambiguo). • El lenguaje estructurado puede utilizarse para especificar un algoritmo. Luego, para que la computadora pueda procesarlo, deberá transformarse o “traducirse” a un lenguaje de programación específico. • El lenguaje estructurado es una herramienta que puede utilizarse en la especificación de procesos, en el desarrollo de sistemas. • Se desarrollan de una teoría preestablecida. • Componente semántico mínimo. • Posibilidad de incrementar el componente semántico de acuerdo con la teoría a formalizar. • La sintaxis produce oraciones no ambiguas. • La importancia del rol de los números. • Completa formalización y por esto, el potencial de la construcción computacional. 3.1.3.3Tablas de decision La tabla de decisión es una matriz de renglones y columnas que indican condiciones y acciones. Las reglas de decisiones, incluidas en una tabla de decisión establecen el procedimiento a seguir cuando existen ciertas condiciones. Este método se emplea desde mediados de la década de los 50, cuando fue desarrollado por General Electric para el análisis de funciones de la empresa como control de inventarios, análisis de ventas, análisis de créditos y control de transporte y rutas. Se utiliza la tabla de decisión cuando existen muchas combinaciones. Características de las Tablas de Decisión • Identificación de Condiciones • Entradas de Condiciones • Identificación de Acciones • Entradas de Acciones Para desarrollar tablas de decisión, se deben emprender los siguientes pasos: 1. Determinar los factores considerados como más relevantes en la toma de decisiones. Esto permite identificar las condiciones en la decisión. Cada condición seleccionada de detener la característica de ocurrir quo no ocurrir; en este caso no es posible la ocurrencia parcial. 2. Determinar los pasos o actividades más factibles bajo condiciones que cambian (no sólo las condiciones actuales). Esto permite identificar las acciones. 3. Estudiar las diferentes posibilidades de combinaciones de condiciones. Para cualquier número N condiciones, existen 2^n combinaciones a considerar, por ejemplo para tres condiciones es necesario examinar ocho posibles combinaciones 2^3= 8. 4. Llenar la tabla con reglas de decisiones. 5. Marcar las entradas correspondientes a las acciones con una X para indicar que éstas se emprenden; dejar las celdas vacías o marcadas con un guión para señalar que en ese renglón no emprende ninguna acción. 6. Examinar la tabla para detectar reglas redundantes o contradicciones entre estas. Una vez confeccionada la tabla, quedarán determinadas las reglas de decisión. Estas son proposiciones que se leerán verticalmente, partiendo desde la sección Valores de Condiciones y descendiendo por la sección Valores de Acciones. Se las enuncia así: “SI.......(condición1, condición2, etc.)... ENTONCES ... (acción1, acción2, etc.)....”.
Las tablas de decisión permiten agrupar todas las combinaciones de condiciones y todas las posibilidades lógicas en un conjunto de fácil entendimiento y análisis, creando además la posibilidad de controlar que no se haya omitido ninguna alternativa y que se hayan cubierto todas las posibilidades. Tipos de tablas de decision. v Tablas de entrada limitada v Tablas de entrada extendida v Tablas de entrada mixta Ejemplo de Tabla de entrada limitada Ejemplo de tabla de entrada extendida Ejemplo de tabla de entrada mixta (condiciones en entrada extendida y acciones en entrada limitada)
Usos de las tablas de Decisión a) En la etapa de análisis de sistemas: para efectuar una representación gráfica simplificada de los procesos lógicos que hayan sido relevados durante la investigación detallada, a efectos de analizar si se adecuan o no a los requerimientos del sistema. b) En la etapa de diseño de sistemas: para representar gráficamente procesos lógicos creados para satisfacer las necesidades del sistema bajo estudio. c) Aisladamente, es decir, en tareas que no tengan que ver con el estudio de sistemas, para la representación simplificada de procedimientos específicos que sirvan de apoyo para una interpretación correcta del mismo y su posterior ejecución (procedimientos legales, impositivos, laborales, previsionales, aplicación de normas técnicas, etc.) 3.1.3.4 Arboles de decisión El árbol de decisión es un diagrama que representan en forma secuencial condiciones y acciones; muestra qué condiciones se consideran en primer lugar, en segundo lugar y así sucesivamente. Este método permite mostrar la relación que existe entre cada condición y el grupo de acciones permisibles asociado con ella. Un árbol de decisión sirve para modelar funciones discretas, en las que el objetivo es determinar el valor combinado de un conjunto de variables, y basándose en el valor de cada una de ellas, determinar la acción a ser tomada. Los árboles de decisión son normalmente construidos a partir de la descripción de la narrativa de un problema. Ellos proveen una visión gráfica de la toma de decisión necesaria, especifican las variables que son evaluadas, qué acciones deben ser tomadas y el orden en la cual la toma de decisión será efectuada. Cada vez que se ejecuta un árbol de decisión, solo un camino será seguido dependiendo del valor actual de la variable evaluada. Se recomienda el uso del árbol de decisión cuando el número de acciones es pequeño y no son posibles todas las combinaciones. Uso de árboles decisiones. El desarrollo de árboles de decisión beneficiado analista en dos formas. Primero que todo, la necesidad de describir condiciones y acciones llevan a los analistas a identificar de manera formal las decisiones que actualmente deben tomarse. De esta forma, es difícil para ellos pasar por alto cualquier etapa del proceso de decisión, sin importar que este dependa de variables cuantitativas o cualitativas. Los árboles también obligan a los analistas a considerar la consecuencia de las decisiones. Se ha demostrado que los árboles de decisión son eficaces cuando es necesario describir problemas con más de una dimensión o condición. También son útiles para identificar los requerimientos de datos críticos que rodean al proceso de decisión, es decir, los árboles indican los conjuntos de datos que la gerencia requiere para formular decisiones o tomar acciones. El analista debe identificar y elaborar una lista de todos los datos utilizados en el proceso de decisión, aunque el árbol de decisión no muestra todo los datos. Si los árboles de decisión se construyen después de completar el análisis de flujo de datos, entonces es posible que los datos críticos se encuentren definidos en el diccionario de datos (el cual describe los datos utilizados por el sistema y donde se emplean). Si únicamente se usan árboles de decisiones, entonces el analista debe tener la certeza de identificar con precisión cada dato necesario para tomar la decisión. Los árboles de decisión no siempre son la mejor herramienta para el análisis de decisiones. El árbol de decisiones de un sistema complejo con muchas secuencias de pasos y combinaciones de condiciones puede tener un tamaño considerable. El gran número de ramas que pertenecen a varias trayectorias constituye más un problema que una ayuda para el análisis. En estos casos los analistas corren el riesgo de no determinar qué políticas o estrategias de la empresa son la guía para la toma de decisiones específicas. Cuando aparecen estos problemas, entonces es momento de considerar las tablas de decisión. 3.2 Técnicas orientadas a objetos para el análisis de requerimiento. Objeto ¨ Un objeto es una representación en computadora de una cosa o evento del mundo real. ¨ Un objeto es una entidad que tiene un estado y un conjunto definido de operaciones que operan sobre este estado. ¨ El estado se representa mediante un conjunto de atributos del objeto. ¨ Los objetos se crean de acuerdo a una definición de la clase objeto. Clase ¨ Categoría de objetos similares. ¨ Define el conjunto de atributos y comportamientos compartidos que se encuentran en cada objeto de la clase. Ejemplo Un paquete de harina para pastel empacado es igual a una clase, ya que contiene los ingredientes y las instrucciones para mezclar y hornear el pastel. Herencia ¨ Reduce el trabajo de la programación usando fácilmente objetos comunes. Conceptos y diagramas del Lenguaje Unificado de Modulación (UML) ¨ UML proporciona un conjunto estandarizado de herramientas para documentar el análisis y diseño de un sistema de software . ¨ El conjunto de herramientas UML incluye diagramas que permiten a las personas visualizar la construcción de un sistema orientado a objetos. Vista general de UML y sus componentes: cosas, relaciones y diagramas
Vista general de UML y sus componentes: cosas, relaciones y diagramas
Los diagramas UML más utilizados 1. Diagramas de caso de uso, que describe como se usa el sistema 2. Escenarios de casos de uso(aunque técnicamente no es un diagrama), es una descripción verbal de las excepciones para el comportamiento principal descrito por el caso de uso principal. 3. Diagrama de actividades, ilustra el flujo general de las actividades 4. Diagramas de secuencias, muestran la secuencia de actividades y las relaciones de las clases 5. Diagramas de clases, muestran las clases y relaciones 6. Diagramas de grafico de estado, muestran las transacciones de los estados 3.2.1Características del análisis orientado a objetos. La abstracción ¨ Es uno de los medios más importantes, el cual no enfrentamos con la complejidad inherente al software. ¨ Abstracción es la técnica de quitarle a una idea o a un objeto todos los acompañamientos innecesarios hasta que los deja en una forma esencial y mínima. ¨ Una buena abstracción elimina todos los detalles poco importantes y le permite enfocarse y concentrarse en los detalles importantes. ¨ Una abstracción se centra en la vista externa de un objeto, de modo que sirva para separar el comportamiento esencial de un objeto de su implementación. Tipos de abstracción que podemos encontrar en un programa. ¨ Abstracción funcional: Crear procedimientos y funciones e invocarlos mediante un nombre donde se destaca que hace la función y se ignora como lo hace. El usuario solo necesita conocer la especificación de la abstracción (el que) y puede ignorar el resto de los detalles (el como). Abstracción de datos: ¨ Tipo de datos: Proporcionado por los lenguajes de alto nivel. La representación usada es invisible al programador, al cual solo se le permite ver las operaciones predefinidas para cada tipo. 3.2.2 Especificación formal de objetos ¨ Una parte importante de cualquier proceso de diseño es la especificación de las interfaces entre los diferentes componentes del diseño. Es necesario identificar las interfaces para que los objetos y otros componentes se puedan diseñar un paralelo. ¨ Los diseñadores deben evitar la información de representación de la interfaz en el diseño de la interfaz. En su lugar, se debe ocultar la representación y se deben proveer las operaciones de los objetos para acceder y actualizar los datos. Si la representación esta oculta, se puede cambiar sin afectar a los objetos que utilizan estos atributos ¨ Estos se permite en Java de forma directa donde las interfaces se declaran independientemente de los objetos, y los objetos “implementan” las interfaces. De igual forma, se puede acceder a un grupo de objetos a través de una sola interfaz. ¨ Las interfaces se especifican un UML utilizando la misma notación que en los diagramas de clases. Sin embargo, no existe una sección de atributos, y el estereotipo en UML <interfaz> se debe incluir en la parte del nombre. ¨ La descripción en Java muestra que algunos métodos pueden tomar un numero de parámetros diferente. Por lo tanto, el método apagar se puede aplicar a la estación como un todo si esta no tiene parámetros o puede apagar un solo instrumento. 3.2.2.1Casos de Uso. Un caso de uso es una técnica para la captura de requisitos potenciales de un nuevo sistema o una actualización software. Cada caso de uso proporciona uno o más escenarios que indican cómo debería interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo específico. Pasos para la Definición de un Caso de Uso: ¨ ID ¨ NOMBRE ¨ REFERENCIAS CRUZADAS ¨ CREADO POR ¨ ULTIMA ACTUALIZACION POR ¨ FECHA DE CREACION ¨ FECHA DE ULTIMA ACTUALIZACION ¨ ACTORES ¨ REQUERIMIENTOS ESPECIALES ¨ DESCRIPCION ¨ TRIGGER ¨ PRE-CONDICION ¨ POST-CONDICION ¨ FLUJO NORMAL ¨ FLUJOS ALTERNATIVOS ¨ INCLUDES ¨ FRECUENCIA DE USO ¨ REGLAS DE NEGOCIO ¨ NOTAS Y ASUNTO Un caso de uso debe: ¨ Describir una tarea del negocio que sirva a una meta de negocio ¨ Tener un nivel apropiado del detalle ¨ Ser bastante sencillo como que un desarrollador lo elabore en un único lanzamiento Situaciones que pueden darse: ¨ Un actor se comunica con un caso de uso (si se trata de un actor primario la comunicación la iniciará el actor, en cambio si es secundario, el sistema será el que inicie la comunicación). ¨ Un caso de uso extiende otro caso de uso. ¨ Un caso de uso utiliza otro caso de uso. Ventajas: ¨ La técnica de caso de uso tiene éxito en sistemas interactivos, ya que expresa la intención que tiene el actor (su usuario) al hacer uso del sistema. ¨ Como técnica de extracción de requerimiento permite que el analista se centre en las necesidades del usuario, qué espera éste lograr al utilizar el sistema ¨ A su vez, durante la extracción (eliciation en inglés), el analista se concentra en las tareas centrales del usuario describiendo por lo tanto los casos de uso que mayor valor aportan al negocio. Esto facilita luego la priorización del requerimiento. Limitaciones: ¨ Los casos de uso pueden ser útiles para establecer requisitos de comportamiento, pero no establecen completamente los requisitos funcionales ni permiten determinar los requisitos no funcionales. Los casos de uso deben complementarse con información adicional como reglas de negocio, requisitos no funcionales, diccionario de datos que complementen los requerimientos del sistema. ¨ Sin embargo la ingeniería del funcionamiento especifica que cada caso crítico del uso debe tener un requisito no funcional centrado en el funcionamiento asociado. 3.2.2.2 Modelado de clases, responsabilidades y colaboraciones. ¨ CLASES Es la estructura de un objeto, es decir, la definición de todos los elementos de que esta hecho un objeto. Un objeto es, por lo tanto, el “resultado ” de una clase. En realidad, un objeto es una instancia de una clase, por lo que se pueden intercambiar los términos objeto o instancia (o incluso un evento). Una clase se compone de dos partes: ¨ VARIABLES ¨ ATRIBUTOS ¨ FUNCIONES RESPONSABILIDADES Las responsabilidades de un objeto son los servicios que provee. Cuando un objeto cumple una petición realizada por otro objeto juega un rol de servidor. Un contrato entre dos clases representa una lista de servicios que una instancia solicita a otra de otra. COMO IDENTIFICAR RESPONSABILIDADES: A través de la especificación se listan los verbos y se determina si representan acciones que algún objeto debe ejecutar. COLABORACIONES Con esto se identifica para cada contrato cuales son las clases que juegan el rol de cliente y cuales las de servidor. Analizando colaboraciones se pueden detectar responsabilidades mal asignadas en la etapa previa. Para determinar las colaboraciones se examina cada responsabilidad de cada clase preguntando. Un objeto cumple una responsabilidad o solo requiere asistencia y otros objetos : 3.2.2.3 Definición de atributos Un atributo es un valor almacenado en los objetos de la clase. Los atributos son algunas de las características asignadas a los ficheros y directorios. Éstos pueden ser: ¨ Sólo lectura: indica que no se pueden realizar modificaciones e impide que éstas se realicen en el fichero o directorio que tiene asignado este atributo. ¨ Oculto: indica que, en la lista de ficheros y directorios, no se debe mostrar ninguno de los ficheros ni directorios que tienen asignado este atributo (siempre y cuando la configuración esté así establecida). ¨ Sistema: indica que el fichero o directorio que tienen asignado este atributo, pertenece al sistema operativo. ¨ Modificado: indica que el fichero o directorio que tienen asignado este atributo, están modificados. Los atributos se clasifican en tres tipos: Tipo 1: Estos atributos son “datos precisos” (clásico, sin imprecisión) que pueden tener etiquetas lingüísticas definidas sobre ellos. Los atributos de Tipo 1 reciben una representación igual que los datos precisos, pero puedan ser manejados en condiciones difusas. Por ejemplo, una persona es alta. Tipo 2: Son atributos que pueden almacenar o tomar “datos imprecisos sobre referencial ordenado”. Estos atributos admiten tanto datos clásicos como difusos, en forma de distribuciones de posibilidad. Por ejemplo, la edad puede tener las etiquetas niño, joven, adulto, referenciadas sobre un conjunto entre 0 y 100. Tipo 3: Son atributos sobre “datos imprecisos sobre referencial no ordenado normalizado”. Estos atributos son definidos sobre un dominio subyacente no ordenado, por ejemplo, el atributo “color del pelo” puede tener las etiquetas rubio, pelirrojo y castaño. 3.2.2.4 Definición de servicios Definición de servicios: Servicio Repositorio de datos: Proporciona facilidades para el almacenamiento y gestión de los elementos de datos y sus relaciones. Servicio de integración de datos: Proporciona facilidades para gestionar grupos o establecimiento de relaciones entre ellos, estos servicios y los anteriores son la base de la integración de datos en el entorno. Servicios de gestión de tareas: Proporcionar facilidades para la definición y establecimiento de normas de los modelos de procesos. Soportan integración de procesos. Servicios de Mensajes: Estos proporcionan facilidades para comunicación herramienta – herramienta y entorno – entorno, soporta la integración de control. Servicios de interfaz de usuario: Proporciona facilidades para el desarrollo de interfaces de usuario, soportan la integración de la presentación. 3.2.3 Prototipos rápidos en la determinación de requerimientos PROTOTIPOS Los prototipos son una visión preliminar del sistema futuro que se implantara. La elaboración de prototipos es una técnica valiosa para la recopilación rápida de información especifica a cerca de los requerimientos de información de los usuarios. Los prototipos efectivos deben hacerse tempranamente en el desarrollo de sistemas, durante la fase de determinación de requerimientos. El analista busca reacciones iníciales de los usuarios y de la administración hacia el prototipo. Tipos de Información que busca el Analista durante la Elaboración de Prototipos. ¨ Reacciones del usuario. ¨ Innovaciones. ¨ Sugerencias del usuario. ¨ Plan de revisión. Reacciones: recopilación por medio de observaciones, entrevistas y formas de retroalimentación, parea recoger la opinión de cada persona acerca del prototipo cuando interactúa con el. Sugerencias: cuando el analista esta interesado en las sugerencias de los usuarios y la administración acerca de cómo refinar o cambiar el prototipo presentado. Innovaciones: parte de la información buscada por el equipo de análisis de sistema Plan de revisión: identifica prioridades para lo que se debe construir un prototipo. TIPOS DE PROTOTIPO ¨ Prototipo Parchado: sistema que tiene todas las características propuesta pero es realmente un modelo básico que eventualmente será mejorado. Pero el prototipo no es suficiente ni elegante. ¨ Prototipo no Operacional: modelo o escala no funcional para objeto de probar determinados aspectos del diseño. ¨ Prototipo Primero de una Serie: seleccionada permite que el sistema sea puesto en su lugar mientras otras características pueden ser añadidas en fecha posterior. Cuando se construye este tipo de prototipo, el sistema se va construyendo por módulos, de modo que si las características reciben una evaluación satisfactoria, éstas puedan incorporarse en el sistema final, mucho más grande sin tener que hacer un trabajo inmenso en interfaces. Lineamientos para el Desarrollo de un Prototipo. ¨ Trabajar en módulos manejables. ¨ Construir el prototipo rápidamente. ¨ Modificar el prototipo en interacción sucesiva. ¨ Enfatizar la interfaz del usuario. Trabajar en Módulos Manejables: aquel que permite la interacción con sus características principales, pero todavía puede ser construido por separado de otros módulos del sistema. Construcción Rápido del Prototipo: La velocidad es esencial para la elaboración satisfactoria de un prototipo en un sistema. La elaboración de un prototipo debe llevarse a cabo en una semana, para construir un prototipo tan rápidamente se deben de usar herramientas especiales tales como: Los sistemas de administración de las base de datos y software, existente que permitan la entrada y salida generalizada. El poner un prototipo operacional rápidamente junto a las primeras etapas del ciclo de vida de desarrollo de sistemas, permite obtener observaciones valiosas sobre la manera en que se debe realizar el resto del proyecto. De este modo se le va mostrando al usuario como actúan las partes del sistema. ¨ Modificaciones del Prototipo: debe ser flexible para futura modificaciones. . Los cambios al prototipo deben mover al sistema más cerca a lo que los usuarios dicen que es importante. ¨ Enfatizar la Interfaz de Usuarios: para que los usuarios muestren cada vez más sus requerimientos de información, debe ser capas de interactuar fácilmente con el prototipo del sistema. PAPEL DEL USUARIO EN LOS PROTOTIPOS Hay tres formas principales en que un usuario puede ser de ayuda en la elaboración del Prototipo. ¨ Experimentando con el Prototipo. ¨ Reaccionar abiertamente ante el Prototipo. ¨ Sugiriendo adiciones y/o eliminaciones del prototipo. Experimentando con el Prototipo: Los usuarios deben tener libertad para experimentar con el prototipo. Reaccionar Abiertamente ante el Prototipo: Si los usuarios se siente temerosos de hacer comentarios, o criticar lo que puede ser un proyecto consentido de superiores o iguales dentro de la organización, es poco probable que se de reacciones abiertas ante el prototipo. ¨ Experimentando con el Prototipo: Los usuarios deben tener libertad para experimentar con el prototipo. ¨ Reaccionar Abiertamente ante el Prototipo: Si los usuarios se siente temerosos de hacer comentarios, o criticar lo que puede ser un proyecto consentido de superiores o iguales dentro de la organización, es poco probable que se de reacciones abiertas ante el prototipo. ¨ Sugerencias de Cambios al Prototipo: Un tercer aspecto del papel de los usuarios en la elaboración de los prototipos es sugerir adiciones y/o eliminaciones a las características que se están probando. 3.2 Tecnicas Basadas En Componentes HISTORIA la ingeneria Del soFTWARE basada en componentes (CBSE) surgio a finales de los 90 como una aproximacion basada en reutilizacion al desarollo de sistemas de software. Su creacion fue motivada por la frustacion de los diseñadores de que el desarollo orientado a objetos . Que es un cbse? Es el proceso de definir,implementar e integrar en sistemas componentes independientes debilmente acoplados. Conclusion La unica forma en la que podemos tratar de la complejidad y entregar mejor sofware mas rapidamente es reutilizar componentes software en ves de reimplementarlos . Los fundamentos de la ingeneria del software basada en componentes son: ü Componentes independientes ü Estandares de componentes ü El middleware ü Proceso de desarollo ü Componentes independientes Son completamente especificados por sus interfaces .deberia haber una clara separacion entre la interfaz dde los componentes y su implementacion para que una implementacion de un componente pueda remplazarse por otro sin cambiar el sistema. Estandares de componentes Facilita la integracion de los componentes.estos estandares se incluyen en un modelo de componentes y se definen , en el nivel mas bajo, como las interfaces de componentes deberian especificarse y como se comunican componentes. El middleware Proporciona soportes software para la integracion de componentes. Para conseguir que componentes independientes y distribuidos trabajen juntos , se necesita un soporte middleware que maneje las comunicaciones de los componentes. Proceso de desarollo Si se intenta añadir una aproximacion basada en componentes a un proceso de desarollo que esta adaptado a la produccion de software original, se puede obvervar que las supociones inherentes al proceso limitan el potencial del CBSE. 3.3.1 ingeneria del dominio La ingeniería de dominio se puede definir como el proceso clave que se necesita para el diseño sistemático de una arquitectura y de un conjunto de elementos software reutilizables que pueden ser usados en la construcción de una familia de aplicaciones relacionadas o subsistemas. El objetivo fundamental de la ingeniería de dominio es la optimización del proceso de desarrollo del software en un espectro de múltiples aplicaciones que representan un negocio común o problema de dominio Dentro del contexto de la id, cada una de las características que define un sistema es una feature tanto los usuarios, como los analistas y los desarrolladores están involucrados en el desarrollo pero con diferentes perspectivas. los usuarios están más preocupados por los servicios o funciones que debe ofrecer el sistema; los analistas y diseñadores se centran en las tecnologías del dominio; y los desarrolladores se interesan especialmente por las técnicas de implementación. Las features pueden clasificarse en 4 categorías 3.3.2 Identificacion Y Clasificacion De Los Componentes Reutilizables. Clasificación según su modificabilidad Componentes caja-negra. El componente es reutilizado "tal como es“. No se modifica y No se requiera conocer los detalles internos de su implementación. El usuario del componente sólo requiere conocer la funcionalidad del componente (qué hace) y como se usa (su interfaz). Componentes caja-blanca Clasificación según su granularidad Clasificación según la tecnología Componentes orientados a objetos Servicios Web (Web Services) 3.3.3 Caracteristicas de los componentes . 1) ESTANDARIZADO 2) INDEPENDIENTE 3) COMPONIBLE 4) DESPLEGABLE 5) DOCUMENTADO ESTANDARIZADO La estandizacion de compontes significa que un componente usado en un proceso cbse tiene que ajustarse a algun modelo estandarizado de componentes . Este modelo puede definir interfaces de componentes , metadatos de componentes, documentacion , composicion y despliegue. INDEPENDIENTE Un componente deberia ser independiente, deberia ser posible componerlo y desplegarlo sin tener que utilizar otros componetes especificos. En las situaciones en las que el componente necesita servicios proporcionados externamente, estos deberian hacerse explicitos en una especificacion de interfaz del tipo <requiere>. COMPONIBLE Para que un componente sea componible, todas las interacciones externas deben tener lugar a traves de interfaces definidas publicamente. Ademas debe proporcionar acceso externo ala informacion sobbre si mismo , como por ejemplo a sus metodos y atributos. DESPLEGABLE Para ser desplegable, un componente deber ser independiente y debe ser capaz de funcionar como una entidad autonoma o sobre una plataforma de componentes que implemente el modelo de componentes. Esto normalmente significa que el componente es binario y que no tiene que compilarse antes de ser desplegados. DOCUMENTADO Los componentes tienen que estar completamente documentados para que los usuarios potenciales puedan decidir si los componentes satisfacen o no sus necesidades. 3.4 Otras tecnicas MÉTODOS PARA LA OBTENCIÓN DE INFORMACIÓN Todo análisis y diseño de un sistema implica la búsqueda y obtención de información relevante para la estructuración y definición de problemas, generación de soluciones, validación de soluciones, etc. La información en una organización no siempre es fácil de obtener, más bien es un proceso lento y costoso, que exige tiempo y dedicación por parte del analista de sistemas. Las fases de búsqueda de información en cualquier proyecto, suelen ser grandes consumidoras de tiempo, y el éxito de los resultados depende en gran medida de la calidad de la información. Es muy común que la información requerida no se encuentre escrita, o inclusive que ésta no se conozca. Esto hace necesaria la interacción del analista con las personas del sistema para identificar y/o generar la información faltante. Si se cuenta con información escrita formal y adecuada utilícelas, le ahorraría tiempo y le facilitaría la comprensión del sistema. Existen métodos básicos para recopilar información dentro de una organización o sistema social. Estos incluyen: a) Cuestionarios |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||