Buscar este blog

sábado, 19 de febrero de 2011

EJEMPLO Y TABLA DE FUNCIONES


Teniendo en cuenta   que los requisitos son  capacidades y condiciones con las cuales debe ser conforme  el sistema y más ampliamente  el proyecto, hemos elaborado una tabla   en la cual se identifica los requisitos primordiales  en un sistema cualquiera:

TIPO
REQUISITO
OBLIGATORIO
SI
NO
Funcional
seguridad
X

Facilidad  de uso
Factores humanos, ayuda, documentación
X

Fiabilidad
Capacidad de recuperar  algún fallo
X

Rendimiento
Menor tiempo de respuesta
X

Legalidad
licencia

X
Interfaz
Restricción para interactuar con sistemas externos

X


  EJEMPLO DE APLICACIÓN


      DESCRIPCIÓN DEL PROBLEMA

En una empresa de comunicaciones   se da  muy regularmente  el envió de mensajes  entre objetos en relación con el tiempo (comunicación  vía  móvil)
-           
      TABLA DE REQUERIMIENTOS

REQUISITO
OBLIGATORIO
SI
NO
Conexión a red existente
X

Aviso llamada entrante
X

Buen funcionamiento  de los parlantes del móvil
X

Buen funcionamiento  de loa auriculares
X

Moderno modelo del móvil

X
Pertenecer  a algún plan

X



-                                                                                                                        DIAGRAMA DE SECUENCIA














                                                                                                                                                                               

miércoles, 16 de febrero de 2011

LEVANTAMIENTO DE REQUERIMIENTOS

El siguiente escenario es tí­pico: Un consultor trabaja con los usuarios para describir los procesos de negocio que serán soportados por el software. El equipo de desarrollo recibe la descripción del consultor pero no están familiarizados con los términos de negocio y consideran la descripción demasiado informal. Los desarrolladores escriben su propia descripción desde un punto de vista técnico. El usuario no entiende esta descripción pero la acepta para que el proyecto avance. El resultado puede ser un sistema que desde el punto de vista del usuario es difícil de usar y que no cumple con sus expectativas.
Parte de este problema es metodológico, y en parte es intrínseco a las caracterí­sticas de los usuarios. Algunas de las problemáticas que se presentan:
  • Los usuarios no saben que es lo que quieren
  • Los usuarios no aceptan como un compromiso los requerimientos escritos
  • Los usuarios insistirán en nuevos requerimientos después de fijar costos y agendas.
  • Los usuarios no están disponibles y la comunicación con ellos es lenta
  • Los usuarios no participan en revisiones de avance.
  • Los usuarios no entienden el proceso de desarrollo y no les interesa.

Existen herramientas y metodologías para el levantamiento de requerimientos. Casos de uso y UML son medios para formalizar este proceso. Que diagramas UML es apropiado usar dependerá del sistema a desarrollar. 

Una guía simple en términos de la complejidad del sistema: 
  • Aplicación mono usuario
    • Diagrama de casos de uso.
    • Diagrama de clases.
    • Diagrama de interacción.
  • Aplicación mono usuario, con manejo de eventos:
    • Añadir: Diagrama de estados.
  • Aplicación cliente servidor:
    • Añadir: Diagrama de despliegue y diagrama de componentes, dependiendo de la complejidad.
  • Aplicación compleja distribuida:
    • Todos.
Para una aplicación sencilla debemos realizar entre tres y seis tipos de diagramas, y para una aplicación compleja unos nueve tipos. El diagrama de casos de uso puede modelar el contexto de un sistema o los requisitos del mismo. Se puede extender la colección de elementos base de UML utilizando estereotipos.

DIAGRAMA DE PAQUETES

Paquete que proporciona los medios para
organizar los artefactos en piezas manejables.
Es un mecanismo de agrupamiento que tiene
que se altamente cohesivo internamente y con
las interacciones mínimas con otros paquetes.
Puede clases, casos de uso, otros diagramas,
paquetes, …., ARTEFACTOS.
Desde afuera solo se puede acceder a los
elementos públicos de los artefactos que
contiene.
EJEMPLO:




sábado, 5 de febrero de 2011

...UML (Lenguaje Unificado de Modelado)...


Es la sucesión de una serie de métodos de un análisis y diseño orientadas a objetos, en otras palabras es un lenguaje de modelado que permite la representación conceptual y física de un sistema, indica los pasos que se deben seguir para llegar a un diseño.

Se necesitaba un lenguaje que fuese gráfico, a fin de especificar y documentar un sistemas de software, de un modo estándar incluyendo aspectos conceptuales tales como procesos de negocios y funciones del sistema; se necesitaba un lenguaje que cumpliera que con los desarrollos de software se hagan bajo una arquitectura en capas y se formalice como un lenguaje estándar y unificado, es decir que cada una de las partes que comprende el desarrollo de todo software orientado a objetos se visualice, especifique y documente con lenguaje común, fue así como surgió UML el cual cumple con los anteriores requerimientos de: Especificar, visualizar, construir y documentar fases de un sistema de software. Se usa para entender, diseñar, configurar, mantener y controlar la información sobre los sistemas a construir. 

UML capta la información sobre la estructura estática y el comportamiento dinámico de un sistema. Un sistema se modela como una colección de objetos discretos que interactúan para realizar un trabajo que finalmente beneficia a un usuario externo.


Información basada en:


http://blog.smaldone.com.ar/2006/11/17/por-que-uml-no-sirve/
http://www.docirs.cl/uml.htm




BLOQUES DE CONSTRUCCIÓN DE LENGUAJE


*Elementos del Lenguaje: estructurales, comportamiento, agrupación, anotación. 
*Relaciones entre los elementos: dependencia, asociación, generalización, realización. 
*Diagramas: clases, objetos, casos de uso, secuencia, colaboración, estados, actividades, componentes, despliegue.


Después de conocer el concepto de UML y los bloques en los los que  se encuentra dividido, nos permitimos ampliar la información acerca del bloque diagrama,  y, asi especificamente el de secuencia. 





DIAGRAMA DE SECUENCIA


Es un tipo de diagrama usado para modelar interacción entre objetos en un sistema mostrando de manera explicita la secuencia de estímulos ordenada temporalmente, representa el envió de mensajes entre objetos en relación con el tiempo.
El diagrama de secuencia se utiliza para describir los distintos escenarios derivados de los casos de uso. Para mas claridad hay que notar que un escenario es una secuencia especifica de acciones que ilustra un comportamiento (instancia de caso de uso) , un caso de uso puede tener muchos escenarios.

Un diagrama de secuencia tiene:
* Objetos con sus lineas de vida
* Mensajes intercambiados entre objetos en una secuencia ordenada.
-Linea de vida activa. la cual puede ser opcional.


EJEMPLO DE DIAGRAMA DE SECUENCIA













ELEMENTOS DEL DIAGRAMA DE SECUENCIA

  • OBJETOS: Se representan mediante una linea vertical llamada linea de vida, en la parte superior se coloca un rectángulo con el nombre del objeto o la clase, en caso de que el objeto sea destruido antes de terminar el diagrama se representa la terminación mediante un aspa.  

  • FOCO DE CONTROL O ACTIVACIÓN: Se representa mediante un rectángulo superpuesto a la linea de vida del objeto, su tamaño depende de la duración de la acción realizada por el objeto, la parte superior indica el inicio de la acción, la parte inferior indica la terminación.
  •  
  • MENSAJES: Se representa mediante una linea horizontal entre las lineas de vida entre los objetos que intercambian los mensajes, es posible añadir a los mensajes condiciones o interacciones.




Información tomada de:


http://www.di.uniovi.es/-dediego/is/recursos/d_int.pdf