Desarrollo de Software Orientado a Objetos
batman87Tesis13 de Abril de 2014
2.241 Palabras (9 Páginas)338 Visitas
Weitzenfeld: Capítul
o 6
1
Parte III Desarrollo de Software Orientado a Objetos
En esta tercera parte del libro describiremos las actividades más importantes relacionadas con el desarrollo de
software:
Requisitos
(Capítulo 6),
Análisis
(Capítulo 7),
Diseño
(Capítulo 8),
Implementaci
ón
(Capítulo 9) y
Pruebas
(Capítulo 10).
6 Modelo de Requisitos
El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la funcionalidad que debe ofrecer desde
la perspectiva del usuario. Este modelo puede funcionar como un contrato ent
re el desarrollador y el cliente o
usuario del sistema, y por lo tanto proyecta lo que el cliente desea según la percepción del desarrollador. Por lo
tanto, es esencial que los clientes puedan comprender este modelo.
El modelo de requisitos es el primer m
odelo a desarrollarse, sirviendo de base para la formación de todos los demás
modelos en el desarrollo de software. En general, el cualquier cambio en la funcionalidad del sistema es más fácil de
hacer, y con menores consecuencias, a este nivel que posteri
ormente. El modelo de requisitos que desarrollaremos se
basa en la metodología
Objectory
(Jacobson et al. 1992), basada principalmente en el modelo de
casos de uso
.
Actualmente esta metodología es parte del
Proceso Unificado de Rational
(RUP). El modelo de
casos de uso y el
propio modelo de requisitos son la base para los demás modelos, como se describió anteriormente en el Capítulo 3 y
se resume aquí:
?
?
Requisitos
: El modelo de casos de uso sirve para expresar el modelo de requisitos, el cual se desarrolla e
n
cooperación con otros modelos como se verá más adelante.
?
?
Análisis
: La funcionalidad especificada por el modelo de casos de uso se estructura en el modelo de análisis,
que es estable con respecto a cambios, siendo un modelo lógico independiente del ambie
nte de implementación.
?
?
Diseño
: La funcionalidad de los casos de uso ya estructurada por el análisis es realizada por el modelo de
diseño, adaptándose al ambiente de implementación real y refinándose aún más.
?
?
Implementación
: Los casos de uso son implementad
os mediante el código fuente en el modelo de
implementación.
?
?
Pruebas
: Los casos de uso son probados a través de las pruebas de componentes y pruebas de integración.
?
?
Documentación
: El modelo de casos de uso debe ser documentado a lo largo de las diversas ac
tividades, dando
lugar a distintos documentos como los manuales de usuario, manuales de administración, etc.
El diagrama de la Figura 6.1 ilustra los distintos modelos. Describiremos los detalles y la notación más adelante.
Modelo de
Requisitos
Modelo de
Análisis
Modelo de
Diseño
Modelo de
Implementación
Modelo de
Pruebas
class
...
OK
OK
falla
Modelo de
Documentación
El caso..
Figura 6.1 Dependencia de lo
s distintos modelos del proceso de software del modelo de casos de uso.
El propósito del modelo de requisitos es comprender completamente el problema y sus implicaciones. Todos los
modelos no solamente se verifican contra el modelo de requisitos, sino que
también se desarrollan directamente de
él. El modelo de requisitos sirve también como base para el desarrollo de las instrucciones operacionales y los
manuales ya que todo lo que el sistema deba hacer se describe aquí desde la perspectiva del usuario. El
modelo de
requisitos no es un proceso mecánico, el analista debe interactuar constantemente con el cliente para completar la
información faltante, y así clarificar ambigüedades e inconsistencias. El analista debe separar entre los requisitos
verdaderos y l
as decisiones relacionadas con el diseño e implementación. Se debe indicar cuales aspectos son
obligatorios y cuales son opcionales para evitar restringir la flexibilidad de la implementación. Durante el diseño se
debe extender el modelo de requisitos con
especificaciones de rendimiento y protocolos de interacción con sistemas
externos, al igual que provisiones sobre modularidad y futuras extensiones. En ciertas ocasiones ya se puede incluir
aspectos de diseño, como el uso de lenguajes de programación parti
culares.
En la metodología de
Objectory
, el modelo de requisitos consiste de tres modelos principales, visualmente
representado por un diagrama de tres dimensiones como se muestra en la Figura 6.2.
Weitzenfeld: Capítul
o 6
2
Comportamiento
(casos de uso)
Presentación
(interfaces/borde)
Información
(dominio del problema)
Figura 6.2 Los tres ejes de modelado del modelo de re
quisitos.
?
?
El modelo de
comportamiento
, basado directamente en el modelo de
casos de uso
, especifica la funcionalidad
que ofrece el sistema desde el punto de vista del usuario. Este modelo utiliza dos conceptos claves:
actores
para
representar los distinto
s papeles que los usuarios pueden jugar con el sistema, y
casos de uso
para representar
qué pueden hacer los actores con respecto al sistema
?
?
El modelo de
presentación
o modelo de
interfaces
o
borde
especifica cómo interactúa el sistema con actores
externo
s al ejecutar los casos de uso, en particular, en los sistemas de información ricos en interacción con el
usuario, especifica cómo se verán visualmente las interfaces gráficas y que funcionalidad ofrecerá cada una de
ellas.
?
?
El modelo de
información
o model
o del
dominio del problema
especifica los aspectos estructurales del sistema.
Este modelo
conceptualiza el sistema según los objetos que representan las entidades básicas de la aplicación.
Aunque en muchas metodologías se permite especificar la funcionalid
ad completa del sistema utilizando el
modelo del dominio del problema, incluyendo operaciones formales sobre los objetos correspondientes a un
modelo de requisitos expresado sin casos de uso, el modelo del dominio del problema será de mucha más ayuda
como
apoyo al modelo de casos de uso y no como una entidad totalmente independiente.
Es importante resaltar que esta separación en tres ejes de modelado independientes es la base para una mayor
estabilidad en el desarrollo del sistema, permitiendo minimizar los
efectos de cada uno sobre los otros dos.
Para ilustrar el modelo de requisitos y el desarrollo de los modelos posteriores, utilizaremos el ejemplo del
“
Sistema
de Reservaciones de Vuelo
”
como se mencionó anteriormente. Para tal meta, mostraremos inicialm
ente una
descripción del problema
. A partir de esta descripción inicial se describirán los tres modelos básicos del modelo de
requisitos.
6.1 Descripción del Problema
La descripción del problema es una descripción muy preliminar de necesidades que sirve ún
icamente como punto de
inicio para comprender los requisitos del sistema. Se trata aquí de simular una descripción preparada por un cliente
la cual debe evolucionar por medio del modelo de requisitos para lograr la especificación final del sistema a
desarr
ollarse. La descripción del problema debe ser una descripción de necesidades y no una propuesta para una
solución. La descripción inicial puede ser incompleta e informal. No hay razón para esperar que la descripción
inicial del problema, preparada sin un a
nálisis completo, sea correcta.
Utilizaremos como ejemplo un
Sistema de Reservaciones de Vuelos
con acceso vía Internet. Este es un sistema que
permite al usuario hacer consultas y reservas de vuelos, además de poder comprar los boletos aéreos de forma
re
mota, sin la necesidad de recurrir a un agente de viajes humano. Se desea que el sistema de reservaciones sea
accesible a través del Internet (World Wide Web). Como base para estos sistemas, existen en la actualidad múltiples
bases de datos de reservacione
s de vuelos que utilizan las agencias de viajes para dar servicio a los clientes, por
ejemplo,
Sabre
,
Apollo
,
Worldspan
,
Amadeus
,
Sahara
,
Panorama
,
Gemini
,
Galileo
,
Axess
, etc. Muchos de estas
bases de datos y sistemas correspondientes son la base para los
sistemas
...