Diseño orientado a objetos, casos de usos e interfaz de usuarios desarrollo de proyecto de software
Páginas: 6 (1284 palabras)
Publicado: 17 de enero de 2012
Información de donde se sacaron los mapas:
21.4.1. Casos de uso
Los casos de uso modelan el sistema desde el punto de vista del usuario. Creados durante la obtención de requisitos, los casos de uso deben cumplir los siguientes objetivos:
Definir los requisitos funcionales y operativos del sistema (producto), diseñando un escenario de uso acordado por el usuario final, y el equipo dedesarrollo; proporcionar una descripción clara y sin ambigüedades de cómo el usuario final interactúa con el sistema y viceversa, y proporcionar una base para la validación de las pruebas.
Durante el A00 los casos de uso sirven como base para los primeros elementos del modelo de análisis. Utilizando UML se puede crear una representación visual de los casos de uso llamada diagrama de casos de uso.Como otros elementos del análisis, los casos de uso pueden representarse a diferentes niveles de abstracción. Los diagramas de casos de uso contienen casos de uso y actores, siendo estos últimos las entidades que interactúan con el sistema. Pueden ser humanos u otras máquinas o sistemas que tengan definidas interfaces con nuestro sistema.
Referencia cruzada
Los casos de usa son una excelenteherramienta de licitación de requisitos, independientemente del método de análisis utilizado.
El sistema de seguridad HogarSeguro, discutido en capítulos anteriores, puede usarse para ilustrar cómo pueden desarrollarse casos de uso. Recordando los requisitos básicos de HogarSeguro, podemos definir tres actores: el propietario (el usuario), los sensores (dispositivos adjuntos al sistema) y elsubsistema de monitorización y respuesta (la estación central que monitoriza HogarSeguro). Para los propósitos de este ejemplo, consideraremos solamente el actor propietario.
La Figura 2 1.2.a muestra un diagrama de casos de uso de alto nivel para el propietario. En dicha figurase identifican dos casos de uso y se representan con elipses. Cada caso de uso de alto nivel puede detallarse mediantediagramas de casos de uso de nivel inferior. Por ejemplo, la Figura 21.2.b representa un diagrama de casos de uso para la función interactúa. Se crea un conjunto completo de diagramas de casos de uso para todos los actores. Pero para una detallada discusión sobre los casos de uso usando UML es mejor consultar la bibliografía sobre el tema (P.e. [ERI97] o [ALH98J).
(a)
(b)
El diseño orientadoa objetos transforma el modelo de análisis creado usando análisis orientado a objetos, en un modelo de diseño que sirve como anteproyecto para la construcción de software. El trabajo de diseñador de software puede ser intimidante. Gamma y sus colegas [GAM95] proveen un panorama razonablemente exacto del DO0 cuando declaran que:
El diseño de software orientado a objetos es difícil, y el diseñode software reusable orientado a objetos es aun más difícil. Se deben identificar los objetos pertinentes, clasificarlos dentro de las clases en la granularidad correcta, definir interfaces de clases y jerarquías de herencia y establecer relaciones clave entre ellos. El diseño debe ser específico al problema que se tiene entre manos, pero suficientemente general para adaptarse a problemas yrequerimientos futuros. Además se deberá evitar el rediseño, o por lo menos minimizarlo. Los diseñadores experimentados en O0 dicen que un diseño reusable y flexible es difícil, si no imposible de obtener «bien», la primera vez. Antes de que un diseño sea terminado, usualmente tratan de reutilizar lo varias veces, modificándolo cada vez. A diferencia de los métodos de diseño de software convencionales,el DO0 proporciona un diseño que alcanza diferentes niveles de modularidad. La mayoría de los componentes de un sistema, están organizados en subsistemas, un «módulo» a nivel del sistema. Los datos y las operaciones que manipulan los datos se encapsulan en objetos -una forma modular que es el bloque de construcción de un sistema 00-. Además, el DO0 debe describir la organización específica
de...
21.4.1. Casos de uso
Los casos de uso modelan el sistema desde el punto de vista del usuario. Creados durante la obtención de requisitos, los casos de uso deben cumplir los siguientes objetivos:
Definir los requisitos funcionales y operativos del sistema (producto), diseñando un escenario de uso acordado por el usuario final, y el equipo dedesarrollo; proporcionar una descripción clara y sin ambigüedades de cómo el usuario final interactúa con el sistema y viceversa, y proporcionar una base para la validación de las pruebas.
Durante el A00 los casos de uso sirven como base para los primeros elementos del modelo de análisis. Utilizando UML se puede crear una representación visual de los casos de uso llamada diagrama de casos de uso.Como otros elementos del análisis, los casos de uso pueden representarse a diferentes niveles de abstracción. Los diagramas de casos de uso contienen casos de uso y actores, siendo estos últimos las entidades que interactúan con el sistema. Pueden ser humanos u otras máquinas o sistemas que tengan definidas interfaces con nuestro sistema.
Referencia cruzada
Los casos de usa son una excelenteherramienta de licitación de requisitos, independientemente del método de análisis utilizado.
El sistema de seguridad HogarSeguro, discutido en capítulos anteriores, puede usarse para ilustrar cómo pueden desarrollarse casos de uso. Recordando los requisitos básicos de HogarSeguro, podemos definir tres actores: el propietario (el usuario), los sensores (dispositivos adjuntos al sistema) y elsubsistema de monitorización y respuesta (la estación central que monitoriza HogarSeguro). Para los propósitos de este ejemplo, consideraremos solamente el actor propietario.
La Figura 2 1.2.a muestra un diagrama de casos de uso de alto nivel para el propietario. En dicha figurase identifican dos casos de uso y se representan con elipses. Cada caso de uso de alto nivel puede detallarse mediantediagramas de casos de uso de nivel inferior. Por ejemplo, la Figura 21.2.b representa un diagrama de casos de uso para la función interactúa. Se crea un conjunto completo de diagramas de casos de uso para todos los actores. Pero para una detallada discusión sobre los casos de uso usando UML es mejor consultar la bibliografía sobre el tema (P.e. [ERI97] o [ALH98J).
(a)
(b)
El diseño orientadoa objetos transforma el modelo de análisis creado usando análisis orientado a objetos, en un modelo de diseño que sirve como anteproyecto para la construcción de software. El trabajo de diseñador de software puede ser intimidante. Gamma y sus colegas [GAM95] proveen un panorama razonablemente exacto del DO0 cuando declaran que:
El diseño de software orientado a objetos es difícil, y el diseñode software reusable orientado a objetos es aun más difícil. Se deben identificar los objetos pertinentes, clasificarlos dentro de las clases en la granularidad correcta, definir interfaces de clases y jerarquías de herencia y establecer relaciones clave entre ellos. El diseño debe ser específico al problema que se tiene entre manos, pero suficientemente general para adaptarse a problemas yrequerimientos futuros. Además se deberá evitar el rediseño, o por lo menos minimizarlo. Los diseñadores experimentados en O0 dicen que un diseño reusable y flexible es difícil, si no imposible de obtener «bien», la primera vez. Antes de que un diseño sea terminado, usualmente tratan de reutilizar lo varias veces, modificándolo cada vez. A diferencia de los métodos de diseño de software convencionales,el DO0 proporciona un diseño que alcanza diferentes niveles de modularidad. La mayoría de los componentes de un sistema, están organizados en subsistemas, un «módulo» a nivel del sistema. Los datos y las operaciones que manipulan los datos se encapsulan en objetos -una forma modular que es el bloque de construcción de un sistema 00-. Además, el DO0 debe describir la organización específica
de...
Leer documento completo
Regístrate para leer el documento completo.