FUNDAMENTOS DE INGENIERIA DE SOFWARE.

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.

ContenidoINTRODUCCIÓ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.

Control (Comportamiento)

Vista (Presentación).

Modelo (Información).

Control (Comportamiento)

Vista (Presentación).

Modelo (Información).

Vista (Presentación).

Modelo (Información).

7.1 Arquitectura de clasesEl 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.

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-registro-

usuario. 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 interface-

base-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 sub-

flujos 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íaLibro- Ingeniería de software orientada a objetos con uml, java e internet.

Autor: Alfredo Weitzenfeld.