Desarrollo de Software Orientado a Objetos
Enviado por batman87 • 13 de Abril de 2014 • Tesis • 2.241 Palabras (9 Páginas) • 275 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
...