P. 1
Fundamentos de ingeniería de software

Fundamentos de ingeniería de software

|Views: 877|Likes:
Ensayo sobre modelo de análisis.
Ensayo sobre modelo de análisis.

More info:

Categories:Types, School Work
Published by: Luis Alfredo Moctezuma Pascual on Oct 30, 2012
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOCX, PDF, TXT or read online from Scribd
See more
See less

04/12/2014

pdf

text

original

Luis Alfredo Moctezuma Pascual

FUNDAMENTOS DE INGENIERIA DE SOFWARE.

Nombre del profesor: Romero Fuentes María Estela. No De Control: 10640115
Objetivo de la actividad: Conocer el modelo de análisis realizando un ensayo para la mejor comprensión y a la vez dar un paso mas a el conocimiento sobre la materia que la profesora antes mencionada nos esta impartiendo. .

INTRODUCCIÓN: En este trabajo se realizara un ensayo sobre el modelo de requisitos del capítulo 7 del libro ingeniería de software orientado a objetos con uml. A lo largo de este ensayo mostrare lo que he comprendido de este capítulo y lo mostrare con palabras fáciles de entender para que pueda servir un poco a los que estén estudiando sobre este modelo de requisitos. Cada subtema está distribuido de tal manera que pueda ser entendido fácilmente por cualquier lector, los ejemplos usados solo son pocos ya que si se quisiera consultar a detalle el autor lo hace muy bien aquí solo trato de extraer lo más esencial y los ejemplos que no se repiten tanto en los siguientes casos de uso o clases etc. Con este trabajo pretendo aprender todo lo referente al modelo de requisitos y a la vez enseñarles a los lectores lo que se necesita para comprender de manera sencilla este tema tan amplio. Cuando dejo este material en tus manos es porque estoy seguro que te servirá para el análisis e implementación de la teoría presentada y haciendo saber que es información 100% verídica y confiable para que de esta manera si es necesario la toma de decisiones se realice sin problemas y sin llevar a tomar decisiones que no estén controladas y soportadas por teoría.

Contenido
INTRODUCCIÓN:....................................................................................................................... 1 7.0 Modelo De Análisis. ............................................................................................................. 4 7.1 Arquitectura de clases......................................................................................................... 5 7.1.1 Clases con estereotipos. ............................................................................................. 6 7.1.2 Clases para casos de uso. .......................................................................................... 7 7.2 Identificación de clases según estereotipos. .................................................................. 7 7.2.1 Borde. ............................................................................................................................. 8 7.2.2 Entidad. .......................................................................................................................... 9 7.2.3 Control. ........................................................................................................................... 9 7.3 Clases según casos de uso. ............................................................................................ 10 7.3.1 Validar Usuario. .......................................................................................................... 10 7.3.2 Ofrecer Servicios. ....................................................................................................... 10 7.3.3 Registrar usuario. ....................................................................................................... 10 7.3.4 Registrar Tarjeta. ........................................................................................................ 10 7.3.5 Consultar información. ............................................................................................... 10 7.3.6 Hacer Reservación. .................................................................................................... 11 7.3.7 Pagar Reservación. .................................................................................................... 11 7.4 Diagrama de secuencias. ................................................................................................. 11 7.4.1 Registrar usuario. ....................................................................................................... 12 7.4.2 Registrar tarjeta. ......................................................................................................... 12 7.4.3 Consultar Información. ............................................................................................... 12 7.4.4 Hacer reservación. ..................................................................................................... 13 7.4.5 Pagar Reservación. .................................................................................................... 13 7.5 Casos de uso para el sistema de reservacion de vuelos. ........................................... 14 7.5.1 Validar Usuario. .......................................................................................................... 14 7.5.2 Ofrecer Servicios. ....................................................................................................... 14 7.5.3 Registrar servicios. ..................................................................................................... 14 7.5.4 Registrar tarjeta. ......................................................................................................... 14 7.5.5 Consultar información. ............................................................................................... 14 7.5.6 Hacer Reservación. .................................................................................................... 14 7.5.7 Pagar Reservación. .................................................................................................... 14 7.6 Diccionario de clases según modulos. ........................................................................... 15 7.6.1 Interface Usuario. ....................................................................................................... 15

7.6.2 Principal. ...................................................................................................................... 15 7.6.3 Registro. ....................................................................................................................... 15 7.6.4 Servicios. ..................................................................................................................... 16 Conclusión. ................................................................................................................................ 17 Bibliografía ................................................................................................................................. 17

7.0 Modelo De Análisis.

Una vez que ya se ha desarrollado y aceptado el modelo de requisitos se inicia el modelo de análisis siguiendo el modelo de los casos de uso. El objetivo es generar y comprender una arquitectura de objetos para el sistema con base en lo especificado en el modelo de requisitos. Este modelo es una representación conceptual correspondiente al modelo de requisitos en términos de clases de objetos y cada clase contribuye a la gran arquitectura deseada. La rastreabilidad es una cualidad importante de su metodología

Este diagrama muestra de manera conceptual el modelo de análisis con la arquitectura general de objetos y en relación con el modelo de requisitos.

7.1 Arquitectura de clases El objetivo del modelo de análisis (también conocido como dimensión de la arquitectura) es generar una arquitectura de objetos que sirva como base para el diseño del sistema. Las arquitecturas se distinguen según la organización de los objetos de acuerdo a su funcionalidad. Si existe un grupo de objetos para el manejo de la funcionalidad de la aplicación y otro para interactuar con las entidades externas de la aplicación como el usuario y las bases de datos, entonces se considera de dos dimensiones. Puede tener la cantidad de dimensiones que quiera tener pero esto determinara además que tan estable y fácil de extender. Si es que se tuvieran muchas dimensiones lo que también tendría que tener son ejes de funcionalidad completamente ortogonales (que además es difícil de lograr), el cambio en una dimensión no debería de afectar a las demás dimensiones. Una de las arquitecturas mas utilizadas es la de modelo, vista, control que fue popularizada por los lenguajes de smalltalk.

C o n tro l ( C o m p o r t a m ie n t o )

Modelo (Información).

Vista (Presentación).

La vista o presentación de la información corresponde a las interfaces que se le presentan al usuario para el manejo de la información, la información representa el dominio del problema y se almacena en bases de datos. El control corresponde a la manipulación de la información. En el modelo se usa MVC descrito en los temas anteriores por su popularidad en los lenguajes de programación.

7.1.1 Clases con estereotipos. - Entidad. Estos estereotipos guardan información sobre el estado interno del sistema a corto y largo plazo. Estos objetos corresponden al dominio del problema. Un ejemplo de objeto entidad es un registro de usuario con sus datos y comportamiento asociados. - Borde. Implementan las interfaces del sistema con el mundo externo, correspondiente a todos los actores. Un ejemplo de objeto borde es una interface donde usuario o pantalla para insertar o modificar información en el registro de usuario. - Control. Estos objetos modelan la funcionalidad que no se asocia naturalmente con un objeto. Ejemplo: Validar Usuario existente o insertar uno nuevo. En el caso de el ejemplo que hemos usado anteriormente.

7.1.2 Clases para casos de uso. En cada caso de uso se identifican los objetos necesarios para su implementación. Se define explícitamente que objeto es responsable de que comportamiento dentro del caso de uso. Se comienza identificando los objetos bordes necesarios después la entidad y finalmente los de control. Este proceso se continúa a los demás casos de uso. La meta es formar una arquitectura que reutilice la mayor cantidad de objetos posibles. La asignación de objetos se hace siguiendo los principios. Funcionalidad de los casos de uso que dependen directamente de la interacción del sistema con el mundo externo se asigna a los objetos borde. La funcionalidad relacionada con el almacenamiento y manejo de información del dominio del problema se asigna a los objetos entidad. La funcionalidad especifica a uno o varios casos de uso. Se asigna un objeto control por cada caso de uso.

7.2 Identificación de clases según estereotipos. Para llevar a cabo la transición de modelo de requisitos a modelo de análisis se deben identificar los objetos necesarios para implementar todos los casos de uso. ESTEREOTIPOS DE OBJETOS DE LA ARQUITECTURA DE OBJETOS Se deben identificar las clases borde. Luego las clases entidad. Finalmente las de control

El analista debe distribuir de la mejor manera el comportamiento entre los diferentes tipos de objetos de la arquitectura de análisis.

La asignación de funcionalidad es bastante difícil en la practica y afecta la calidad y mantenimiento del sistema por eso mismo los buenos analistas consideran desde el principio los posibles cambios futuros. Los cambios más comunes a un sistema son los de funcionalidad y bordes. 7.2.1 Borde. Su tarea es traducir los eventos necesarios generados por un actor en eventos comprendidos por el sistema y traducir eventos del sistema en una presentación comprensible por el actor. Estrategias para identificar las clases borde. 1. Con base a los actores. 2. Con base a las descripciones de las interfaces del sistema que acompañan al modelo de requisitos. 3. Con base a las descripciones de los casos de uso y extraer la funcionalidad especifica a los objetos bordes.

Existen dos tipos de clases borde a modelar, dependiendo del tipo del autor: Que se comunican con otros sistema: Estos objetos borde pueden traducir las salidas del sistema a un protocolo de comunicación estandarizado o simplemente enviar eventos producidos internamente sin conversiones complejas. La ventaja de esto es que si se cambia el protocolo estos cambios serán locales al objeto borde. Que se comunican con usuarios humanos. Para esto es necesario que las interfaces con el usuario sean lógicas y coherentes. Aunque los dos tienen diferentes propósitos la primera puede realizar otras actividades a parte de las presentaciones tales como administrar información y tener comportamiento

Para identificar qué parte del flujo de un caso de uso debe asignarse a los objetos borde se deben analizar las interacciones entre los actores y los casos de uso: Buscar aspectos como la funcionalidad del comportamiento del actor. Un ejemplo es hacerlo con el sistema de reservación de vuelos donde intervienen todos los actores principales y secundarios para intercambiar información con el sistema. 7.2.2 Entidad. Se utilizan estos objetos entidad para modelar la información que el sistema debe manejar a corto y lago plazo. La información a corto plazo existe durante la ejecución mientras que la de largo plazo trasciende de los casos de uso, por lo que es necesario tenerla guardada en algún archivo o base de datos. Es difícil identificar qué operaciones y cuales atributos serán incluidos dentro de los objetos. La única manera de manipular estos objetos es mediante sus operaciones se deben identificar suficientes operaciones para manipularlo completamente. Pueden ser sencillas las operaciones sirviendo de acceso a los valores de los atributos o complejas como una operación matemática. Sea cual se la complejidad solo deben depender y afectar información local. Esto se aplicaría siguiendo el ejemplo del sistema de reservación a lo que seria la base de datos de registro 7.2.3 Control. Un cambio en el comportamiento podría afectar varios objetos, dificultando su modificación; para evitar esto tal comportamiento se asigna a objetos control. Inicialmente se asigna el comportamiento a los objetos borde y entidad. El comportamiento restante se asigna a los objetos control. Una manera de asignar el comportamiento es modelar inicialmente el caso de uso sin ningún objeto control; En pocas palabras solo asignar un objeto control a objetos borde y entidad.

7.3 Clases según casos de uso. En esta sección mostrare diagrama de clases según los casos de uso de acuerdo a las clases identificadas en las secciones anteriores. 7.3.1 Validar Usuario. Involucra una clase control manejador-registro-usuario que controla la información de registro usuario y las clases borde. 7.3.2 Ofrecer Servicios. Aquí se involucra la una clase control manejador-servicio que controla la pantalla pantalla-servicio 7.3.3 Registrar usuario. Involucra la clase control manejador registro-usuario que controla la información de registro usuario y las clases borde pantalla-crear-registrousuario. Borde interface-usuario. 7.3.4 Registrar Tarjeta. Involucra Clase control manejador-registro-tarjeta que controla la

información de registro tarjeta. Clases borde. Pantalla-crear-reg-tarjeta y pantalla-obtener-registro además de interface usuario interface-base-datos-registro .

7.3.5 Consultar información. Involucra una clase control para los diferentes tipos de consultas junto con la clase borde correspondiente a la pantalla pantalla-consultas. Los subflujos son: Consultar horarios Consultar Tarifas. Consultar Estado.

7.3.6 Hacer Reservación. La clase que involucra se encarga de controlar las reservaciones junto con las clases borde las clases control se encargan de esto. Pantallas-clave-reserva Pantalla-crear-reserva-vuelos

Clases borde. Interface-usuario. Interface-base-datos-reserva.

Entidad. Vuelo. Asiento. Avión Tarifa Viajero frecuente. Pasajero. Etc.

7.3.7 Pagar Reservación. Involucra la clase control manejador –pagos que controla la información de pagos y clases borde correspondiente a las pantallas pantalla-pagar-reg-tarjeta y pantalla-rembolsar-reg-tarjeta y la clase borde interface-usuario e interfacebase-datos-reserva.

7.4 Diagrama de secuencias. Este paso es importante ya que con base en esta funcionalidad, se definirá la arquitectura del sistema tanto estructural como funcional. Para esto se introducen diagramas de secuencias los cuales describen los diferentes casos de uso según la interacción o eventos enviados entre los objetos de la arquitectura del modelo de análisis. Estos diagramas describen aspectos dinámicos de un sistema y usan objetos como elementos básicos.

Cada objeto en el diagrama es representado con una línea vertical, correspondiente al eje del tiempo, donde el tiempo avanza hacia abajo. Un diagrama de secuencias permite apreciar la fluidez de los eventos en la arquitectura y la correspondencia de la funcionalidad con la del caso de uso. Dado que existen múltiples posibles flujos de secuencia se describirán únicamente secuencias de funcionalidad completas que pudieran incluir múltiples flujos en múltiplos casos de uso. 7.4.1 Registrar usuario. Existen diversas secuencias que pueden ser instancias por un usuario. Se muestran las secuencias que pudieran desarrollarse entre los objetos para asegurar que la lógica que se utiliza sea correcta y que corresponda a los casos de uso especificados en el modelo. En resumen la secuencia podría iniciar con el caso de uso validar usuario seguido de los subflujos crear registro y administrar registro usuario del caso de uso registrar usuario. 7.4.2 Registrar tarjeta. En este caso de uso registrar tarjeta existen diversas secuencias que pueden ser instanciados por un usuario. Se muestran diagramas de secuencia para crear-registro-tarjeta actualizar-registro-tarjeta y eliminar registro-tarjeta para especificar todas las actividades que realizan cada uno de los antes mencionados se debe planear que y con quien se va a involucrar cada uno. La secuencia podrá iniciar con el caso de uso validar usuario después por el de ofrecer servicios y por ultimo registrar usuario donde a su vez entran los subflujos obtener registro usuario. 7.4.3 Consultar Información. Existen diversos sub-flujos que pueden ser instanciados por un usuario. Aquí se muestran diagramas para diferentes consultas que siguiendo el ejemplo anterior serian Consultar horarios. Consultar tarifas.

-

Consultar estado.

Consultar horarios. Esta secuencia inicia en el flujo principal consultar informacion y entra la validacion de usuario seguidos por ofrecer servicios y otros sub-flujos(consultar horarios, devolver horarios). Consultar Tarifas. En este caso muetra las secuencias pero son exactamente las mismas que las anteriores solo que en el caso anterior es con los horarios y en este caso es con el usuario(Consultar tarifas, devolver tarifas.) Consultar estado. Al igual que los anteriores esta secuencia muestra y devuelve consultar estado y devolver estado. 7.4.4 Hacer reservación. Aquí se muestran diversos sub-flujos (reservación,actualizar y eliminar reservación) que pueden ser instanciados por un usuario. Para crear la reservación se inicia la secuencia incluyendo cosas previas que tiene que haber pasado antes como validar usuario, ofrecer servicios asi como solicitar clave para acceder a esta parte. En la actualización tambien se muestra la secuencia de pasos que debe de haber pasado previamente validar usuario, ofrecer servicios, solicitar clave, obtener reservacion, administrar reservación y actualizar información. Eliminar Reservación tendra que seguir una secuencia hasta llegar a administrar reservacion para entrar en eliminar tal reservación. 7.4.5 Pagar Reservación. Existen diversos subflujos que tambien puede instanciar el usuario. Que son pagar reservacion y rembolsar pago.

Al igual que en los casos anteriores se muestran las secuencias en ambos casos para llegar hasta el punto de donde se requiere hacer la modificacion o pago.

7.5 Casos de uso para el sistema de reservacion de vuelos.
Con la información anterior es posible generar una descripcion completa a detalle, mas que nada se especifican los actores, proposito, precondiciones y de donde inicia el flujo. 7.5.1 Validar Usuario.

7.5.2 Ofrecer Servicios. 7.5.3 Registrar servicios. 7.5.4 Registrar tarjeta. 7.5.5 Consultar información. 7.5.6 Hacer Reservación. 7.5.7 Pagar Reservación. En el paso del 5.1 al 5.7 se realiza la identificacion de actores que intervienen en cada caso de uso las precondiciones que necesita,excepciones y los flujos principales respectivamente y sub-flujos.

7.6 Diccionario de clases según modulos.
Se actualiza el diccionario de clases organizada según modulos que fueron descritos en el dominio del problema para incluir todas las clases identificadas durante el modelo de analisis.

Se separan en diferentes módulos con el fin de lograr una mejor organización y correcpondencia clases-casos de uso.

7.6.1 Interface Usuario. Toda la interacción con el usuario se hace por medio del borde de usuario. Esta compuesta por una clase que maneja toda las interfaces del usuario. 7.6.2 Principal. Esta compuesta por clases comunes a la funcionalidad general del sistema. Pantalla principal (Clase Borde). Manejador principal (Clase control).

7.6.3 Registro. Se divide en: Usuario. Tarjeta. Interface de base de datos.

Que estos a su vez están formados por varias clases para manejo e interacción con la base de datos. 7.6.4 Servicios. Se divide en módulos. Dominio. Interface de base de datos. Consultas. Reservas Pagos.

Que son para manejo de pantallas y de información principalmente. Por ejemplo en el caso de pagos estaría compuesto por las clases. Pantalla pagar-reg-tarjeta. Pantalla rembolsar-reg-tarjeta. Manejador de pagos.

Conclusión.

Con este trabajo ya finalizado vemos que se logro lo que se planteo al inicio que es transmitir lo más esencial pero necesario para aprender sobre el modelo de análisis y todo lo que involucra para llevarlo a cabo. Confiamos en que con este trabajo se quede el interés de desarrollarlo y de investigar más a profundidad sobre cada punto ya que si se explicara a fondo en este ensayo se tornaría muy extenso y difícil de digerir por el lector. Gracias a este trabajo logre reafirmar conocimientos que pudieran servir para realizar el análisis de software sin importar el área ya que al entender esto lo podremos aplicar a cualquier problema de la vida real.

Bibliografía
Libro- Ingeniería de software orientada a objetos con uml, java e internet. Autor: Alfredo Weitzenfeld.

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->