analisis

Analysis orientado a Objetos.
El AOO ofrece un enfoque nuevo para el análisis de requisitos de sistemas
software. En lugar de considerar el software desde una perspectiva clásica
de entrada/proceso/salida, como los métodos estructurados clásicos, se
basa en modelar el sistema mediante los objetos que forman parte de él y
las relaciones estáticas (herencia y composición) o dinámicas (uso) entreestos objetos.
Ventaja de AOO:
se basa en la utilizacion de objetos como abstracciones del mundo real.
Análisisisis estructurado:
El análisis estructurado se basa fundamentalmente en la descomposición
funcional del sistema que queremos construir. Esta descomposición
funcional requiere traducir el dominio del problema en una serie de
funciones y subfunciones.
Comunicación. El concepto OO es mássimple y está menos relacionado
con la informática que el concepto de flujo de datos. Esto permite una
mejor comunicación entre el analista y el experto en el dominio del
problema (es decir, el cliente).
Consistencia. Los objetos encapsulan tanto atributos como operaciones.
Debido a esto, el AOO reduce la distancia entre el punto de vista de los
quedatos y el punto de vista del proceso, dejando menoslugar a
inconsistencias o disparidades entre ambos modelos.
Reutilización. Aparte de la reutilización interna, basada en la expresión
explícita de características comunes, el paradigma OO desarrolla modelos
mucho más próximos al mundo real, con lo que aumentan las posibilidades
de reutilización. Es probable que en futuras aplicaciones nos encontremos
con objetos iguales o similares a los de laactual.
Casos de Uso:
Los requerimientos son importantes y es donde las técnicas del UML son
especialmente provechosas. El punto de partida son los casos de uso.
Estos, por lo tanto, son los motores de todo el proceso de desarrollo.
Un diagrama Caso de Uso describe lo que hace un sistema desde el punto
de vista de un usuario, debido a esto, un diagrama de este tipo
generalmente es de los más sencillosde interpretar en UML, ya que su

razón de ser se concentra en un Que hace el sistema, a diferencia de otros
diagramas UML que intentan dar respuesta a un Como logra su
comportamiento el sistema.
Un Caso de uso es empleado con más frecuencia en alguna de las
siguientes etapas :
Determinación de Requerimientos: Por lo general nuevos requerimientos
de sistema generan nuevos casos de uso, conformees analizado y
diseñado el sistema.
Comunicación con el Cliente: Debido a la sencillez de este tipo de
diagramas, son fáciles de emplear para comunicarse con el cliente final del
proyecto.
Generación de pruebas de Sistemas: A través de los diagramas caso de
uso se pueden generar una serie de pruebas de sistema.
Actores.
Los actores pueden ser personas, software o hardware; el término actorrepresenta el rol genérico de usuario del sistema. El nombre que se le dé a
un actor deberá reflejar el papel que tendrá para el sistema
Diagramas de casos de uso.
Los casos de uso pueden estar relacionados con actores o con otros casos
de uso; gráficamente una relación vendrá dada por una línea entre los
casos de uso y/o actores relacionados, siendo que el extremo de dicha
línea dependerá del tipo derelación; en principio tenemos cuatro tipos
posibles:
Comunicación (relación entre un actor y un caso de uso con el que
interactúa; se representa símplemente con una línea).
Uso (include, includes, uses; se representa por una flecha apuntando en el
sentido de la relación).
Extensión (extend, extends; gráficamente la representación es la misma
que para "uso").
Generalización (se trata del concepto deherencia, habitual en los
diagramas de clases, pero aplicado entre casos de uso, e incluso entre

actores; se representa por una flecha con un triángulo vacío por punta
señalando en el sentido de la relación).
Relaciones:
Relación <>.
Es una simple relación de inclusión, es decir, los escenarios o situaciones
posibles detalladas en un caso de uso están incluidas en otro caso de uso...

Leer documento completo

Regístrate para leer el documento completo.