Modelando las necesidades del sistema
Un requerimiento es una característica
de diseño, atributo, o comportamiento de un sistema. Con las necesidades de un
sistema, se acuerda un pacto establecido entre las cosas fuera del sistema y el
sistema por sí mismo, cuando se declara qué se espera que el sistema realice.
En la mayor parte no se cuida cómo el sistema lo hace, solo se
cuida qué es lo que hace. Cuando se construye un sistema es
importante iniciar con acuerdos acerca de qué es lo que hará el sistema, aunque
se podrá desarrollar el entendimiento de esos requerimientos conforme iterativa
e incrementalmente se desarrolle el sistema.
Además, el diseño de sistemas incorpora la
especificación de tres componentes: la interfaz de usuario, la gestión de datos
y los mecanismos de administración de tareas. El diseño de objetos se centra en los detalles internos de
cada clase, definición de atributos, operaciones y detalles de los mensajes.
¿Cuál es el producto obtenido? El modelo de
diseño OO abarca arquitectura de software, descripción de la interfaz de
usuario, componentes de gestión de
datos, mecanismos de administración de tareas y descripciones detalladas de
cada una de las clases usadas en el sistema.
¿Cómo puedo estar seguro de que lo he hecho
correctamente? En cada diseño orientado a objetos son revisados por claridad,
corrección, integridad y consistencia con los requisitos del cliente y entre
ellos.
Modelar los requerimientos de un
sistema implica especificar qué es lo que hará el sistema (desde un punto de
vista fuera del sistema), independientemente de cómo el sistema lo hará.
Pudimos aplicar diagramas de casos de uso para especificar el comportamiento
deseado del sistema; de esta manera, un diagrama de casos de uso nos da una
vista del sistema completo como una caja negra; puedes ver qué hay fuera del sistema y puedes ver
cómo el sistema reacciona a cosas de fuera, pero no puedes ver como el sistema
trabaja en su interior.
¿Qué son los casos de uso?
Los casos de uso son una técnica para
especificar el comportamiento de un sistema. Un caso de uso es una secuencia de
interacciones entre un sistema y alguien o algo que usa alguno de sus
servicios. Todo sistema de software ofrece a su entorno –aquellos que lo usan–
una serie de servicios; un caso de uso es una forma de expresar cómo alguien o
algo externo a un sistema lo usa. Cuando decimos “alguien o algo” hacemos
referencia a que los sistemas son usados no sólo por personas, sino también por
otros sistemas de hardware y software. Trata
sobre qué hará nuestro sistema a un
alto nivel, y con un enfoque desde el usuario, con el propósito de realizar un
seguimiento del proyecto y brindarle alguna estructura a la aplicación.
Tipos de Casos de Uso
·
De Trazo Grueso o Esenciales
Ø Se realiza una
descripción “gruesa” de todos los Casos de Uso.
Ø Primero se identifican
todos los casos de uso del sistema, sólo al nivel de su nombre.
Ø No se deben contemplar
los detalles de la interacción entre el actor y el sistema.
Ø Se deben incluir las
alternativas más relevantes, ignorando la mayoría de los errores que pueden
aparecer en el uso del sistema.
Ø No se debe entrar en
detalle sobre las acciones que realiza el sistema internamente cuando el
usuario interactúa con él.
·
De Trazo Fino o de
Implementación
Se especifican una vez que se ha tomado
la decisión de implementarlos. Se detalla todo aquello que no se detalló en los casos de uso
de trazo grueso, por lo tanto se pueden incluir:
Ø Datos
a ser gestionados.
Ø Detalles sobre la forma de la interfaz en la
descripción del caso
Ø Especificaciones
con más detalle del comportamiento interno del sistema.
·
Temporales
Cuando el inicio de una determinada
funcionalidad del sistema es provocado exclusivamente por el paso del tiempo,
entonces es el paso del tiempo el que inicia el caso de uso. Es importante que
cuando se especifican los casos de uso de trazo fino, se exprese claramente
cuál es el momento del tiempo en el que se inicia el caso. De lo contrario,
estamos dejando en los diseñadores la decisión sobre cuándo generar esta
salida, y esto no es correcto, ya que la oportunidad de las salidas del sistema
debe ser definida por los usuarios.
·
Primarios
Los casos de uso primarios del sistema
son aquellos que son necesarios para el funcionamiento normal del sistema. Son
los CUs esenciales.
·
Secundarios
Los casos de uso secundarios no son
centrales al sistema, no documentan las funcionalidades principales. Son los
CUs útiles, deseables o que “quedarían bien”.
Qué no hacen los casos de
uso:
·
No capturan cómo el sistema hará lo que tiene que
hacer.
·
Especificar la interfaz (intención y no detalles de
la acción).
·
Especificar detalles de
implementación, sólo si es de crucial importancia para el logro del objetivo de
un actor.
Interfaz en UML. Definición
Una
interfaz es una colección de operaciones que especifican un servicio de una
clase o componente; por lo tanto, una interfaz describe el comportamiento visible
externamente de ese elemento. Puede representar el comportamiento
completo de una clase o componente o sólo una parte de este comportamiento, define
un conjunto de especificaciones de operaciones (o sea, sus signaturas), pero
nunca sus implementaciones. Una interfaz raramente se encuentra asilada, más
bien, suele estar conectada a la clase o componente que la realiza.
Componente de interfaz de usuario
Aunque la componente de interfaz de usuario se
implementa dentro del contexto del dominio del problema, la
interfaz por sí misma representa un subsistema de importancia crítica para la
mayoría de las aplicaciones modernas. El modelo de análisis OO, contiene los
escenarios de uso (llamados casos de uso), y una descripción de los roles que
juegan los usuarios (llamados actores) cuando interactúan con el sistema. Este
modelo sirve como entrada al proceso de diseño de interfaz de usuario.
Requerimientos
de interfaz
Los
requerimientos de interfaz son todos aquellos elementos que debe proveer el sistema
para permitir la interacción entre el usuario y las funcionalidades que este
tiene, con el fin de que en el proceso de diseño se tenga claridad de las interfaces
que se deben crear y la relación que debe existir entre ellas.
Para
la definición de los requerimientos de interfaz se deben identificar los
siguientes elementos:
·
Id: Identifica de manera
única una interfaz gráfica
·
Descripción: Indica los
elementos que debe tener la interfaz.
·
Requerimientos asociados:
Indican las funcionalidades asociadas a la interfaz gráfica.
En este nivel, no se va definir de manera detallada la
interfaz, solo se pretende tener una primera aproximación a los elementos que
deben ser tenidos en cuenta en el desarrollo de estas.
No hay comentarios.:
Publicar un comentario