unidad 4. anÁlisisdelosrequerimientos objetivo de la unidad: aplicar los requerimientos...

UNIDAD 4.UNIDAD 4.

ANÁLISIS ANÁLISIS

DE DE

LOS LOS

REQUERIMIENTOSREQUERIMIENTOS

OBJETIVO DE LA UNIDAD: Aplicar los requerimientos correspondientes a su proyecto, diseñará las interfaces de usuario y los casos de uso del proyecto.

Temario de la UnidadTemario de la Unidad

4.1 Requerimientos Funcionales y no 4.1 Requerimientos Funcionales y no funcionalesfuncionales

4.2 Casos de Uso4.2 Casos de Uso

4.3 Diseño de Interfaz4.3 Diseño de Interfaz4.3.1 Reglas en el diseño de IGU4.3.1 Reglas en el diseño de IGU

4.3.2 Integración de la IGU al caso de uso4.3.2 Integración de la IGU al caso de uso

Examen programado.Examen programado.

Planeación de las sesionesPlaneación de las sesiones

TemaTema Fecha (s)Fecha (s) ModalidadModalidad

4.1 Requerimientos 4.1 Requerimientos Funcionales y no Funcionales y no funcionalesfuncionales

Exposición del docente y Exposición del docente y trabajo en equipotrabajo en equipo

Examen Unidad 3Examen Unidad 3 26 octubre26 octubre Examen escritoExamen escrito

Practica 7 .1(Traer Practica 7 .1(Traer documento de req.) documento de req.)

Trabajo por equipos en el Trabajo por equipos en el centro de computocentro de computo

4.2 Casos de uso4.2 Casos de uso ExposiciónExposición

Practica 7.2 C.U.Practica 7.2 C.U. Trabajo por equipos en el Trabajo por equipos en el centro de computocentro de computo

4.3.1 Diseño de interfaz4.3.1 Diseño de interfaz Exposición del docente y Exposición del docente y trabajo en equipotrabajo en equipo

TemaTema Fecha (s)Fecha (s) ModalidadModalidad

Practica 8. Practica 8. Entrega del reporte de Entrega del reporte de la practica 9 y la practica 9 y trabajo por equipos trabajo por equipos en el centro de en el centro de cómputo.cómputo.

4.3.2 Integración de la 4.3.2 Integración de la interfaz al caso de uso interfaz al caso de uso

Exposición de todos Exposición de todos los equipos (de la los equipos (de la practica 8).practica 8).Entrega del reporte. Entrega del reporte. practica 9.practica 9.

Entrega de practicas Entrega de practicas revisadas, repaso, revisadas, repaso, dudas.dudas.

Examen Unidad 4Examen Unidad 4 Aplicación del examen Aplicación del examen escrito. escrito.

Entrega de resultados Entrega de resultados Resultados finalesResultados finales

4.1 Requerimientos funcionales y no 4.1 Requerimientos funcionales y no funcionalesfuncionales

Análisis y diseño Análisis y diseño

La mayoría de proyectos de software son complejos, La mayoría de proyectos de software son complejos, y la estrategia primaria para superar la complejidad, y la estrategia primaria para superar la complejidad, es la descomposición (divide y vencerás). es la descomposición (divide y vencerás).

La estrategia es dividir el problema en unidades más La estrategia es dividir el problema en unidades más pequeñas que sean manejables. Un enfoque pequeñas que sean manejables. Un enfoque tradicional para realizar esto fue el análisis y diseño tradicional para realizar esto fue el análisis y diseño estructurados, donde se trata de descomponer el estructurados, donde se trata de descomponer el problema en funciones o procesos. Este método problema en funciones o procesos. Este método origina una división jerárquica de procesos origina una división jerárquica de procesos constituidos por sub-procesos. constituidos por sub-procesos.

Otra forma de realizar la descomposición, es Otra forma de realizar la descomposición, es usando un esquema de análisis y diseño usando un esquema de análisis y diseño orientado a objetos. En este esquema, se busca orientado a objetos. En este esquema, se busca descomponer el problema en objetos, y no en descomponer el problema en objetos, y no en funciones.funciones.



Algunas de las tareas a realizarse en la etapa de Algunas de las tareas a realizarse en la etapa de análisis son las siguientes: análisis son las siguientes:

1. Definir los requerimientos. 2. Definir los casos 1. Definir los requerimientos. 2. Definir los casos esenciales de uso. 3. Crear y perfeccionar los esenciales de uso. 3. Crear y perfeccionar los diagramas de casos de uso. 4. Crear y diagramas de casos de uso. 4. Crear y perfeccionar el modelo conceptual. 5. Crear y perfeccionar el modelo conceptual. 5. Crear y perfeccionar el glosario. 6. Definir los diagramas perfeccionar el glosario. 6. Definir los diagramas de secuencia de los sistemas. 7. Definir los de secuencia de los sistemas. 7. Definir los contratos de operaciones.contratos de operaciones.


Algunas de las tareas a realizarse en la etapa de Algunas de las tareas a realizarse en la etapa de diseño son las siguientes: diseño son las siguientes:

1. Definir los casos reales de uso. 2. Definir los 1. Definir los casos reales de uso. 2. Definir los reportes, la interfaz de usuario y la secuencia de reportes, la interfaz de usuario y la secuencia de las pantallas. 3. Perfeccionar la arquitectura del las pantallas. 3. Perfeccionar la arquitectura del sistema. 4. Definir los diagramas de interacción. 5. sistema. 4. Definir los diagramas de interacción. 5. Definir los diagramas de diseño de clases. 6. Definir los diagramas de diseño de clases. 6. Definir el esquema de la base de datos. Definir el esquema de la base de datos.


Los requerimientos son una descripción de las Los requerimientos son una descripción de las necesidades o deseos de un producto. La meta necesidades o deseos de un producto. La meta principal en esta etapa es identificar y documentar principal en esta etapa es identificar y documentar lo que en realidad se necesita, en una forma en lo que en realidad se necesita, en una forma en que pueda fácilmente ser transmitido al cliente y al que pueda fácilmente ser transmitido al cliente y al equipo de desarrollo. Se recomienda aquí definir equipo de desarrollo. Se recomienda aquí definir al menos los siguientes puntos: al menos los siguientes puntos:

• • Panorama general • Metas • Funciones del Panorama general • Metas • Funciones del sistema • Atributos del sistema.sistema • Atributos del sistema.

a) Panorama general: Este proyecto tiene por objeto crear a) Panorama general: Este proyecto tiene por objeto crear un sistema de terminal para el punto de venta que se un sistema de terminal para el punto de venta que se utilizará en las ventas al menudeo. utilizará en las ventas al menudeo.

b) Metas: En términos generales, la meta es una mayor b) Metas: En términos generales, la meta es una mayor automatización del pago en las cajas registradoras, y dar automatización del pago en las cajas registradoras, y dar soporte a servicios más rápidos, más baratos y mejores.soporte a servicios más rápidos, más baratos y mejores.

4.1 Requerimientos funcionales y no 4.1 Requerimientos funcionales y no funcionales. Ejemplos.funcionales. Ejemplos.

c) Funciones del sistema Las funciones del sistema son lo que éste c) Funciones del sistema Las funciones del sistema son lo que éste deberá de hacer. Hay que identificar estas funciones y listarlas en deberá de hacer. Hay que identificar estas funciones y listarlas en grupos lógicos. Para verificar que X es en verdad una función del grupos lógicos. Para verificar que X es en verdad una función del sistema, la siguiente frase deberá tener sentido: “El sistema deberá sistema, la siguiente frase deberá tener sentido: “El sistema deberá hacer X”. Por ejemplo: “el sistema deberá autorizar pagos a crédito”. hacer X”. Por ejemplo: “el sistema deberá autorizar pagos a crédito”.

Las funciones pueden clasificarse en tres categorías: evidentes, Las funciones pueden clasificarse en tres categorías: evidentes, ocultas y superfluas. Las evidentes deben realizarse, y el usuario ocultas y superfluas. Las evidentes deben realizarse, y el usuario debe saber que se han realizado. Las ocultas también deben debe saber que se han realizado. Las ocultas también deben realizarse, y puede que no sean visibles para el usuario. Muchas de realizarse, y puede que no sean visibles para el usuario. Muchas de estas funciones se omiten (erróneamente) durante el proceso de estas funciones se omiten (erróneamente) durante el proceso de obtención de requerimientos. Las superfluas son opcionales, y su obtención de requerimientos. Las superfluas son opcionales, y su inclusión no repercute significativamente en el costo ni en otras inclusión no repercute significativamente en el costo ni en otras funciones. funciones.


d) Atributos del sistema Los atributos del sistema son d) Atributos del sistema Los atributos del sistema son cualidades no funcionales que a menudo se confunden cualidades no funcionales que a menudo se confunden con las funciones: facilidad de uso, tolerancia a fallas, con las funciones: facilidad de uso, tolerancia a fallas, tiempo de respuesta, metáfora de interfaz, plataformas. tiempo de respuesta, metáfora de interfaz, plataformas.

Por ejemplo: Por ejemplo:

tiempo de respuesta = (psicológicamente correcto) tiempo de respuesta = (psicológicamente correcto) metáfora de interfaz = (gráfico, colorido, basado en metáfora de interfaz = (gráfico, colorido, basado en formularios) formularios)


Algunos atributos del sistema también pueden tener restricciones de Algunos atributos del sistema también pueden tener restricciones de frontera del atributo, que son condiciones obligatorias de frontera, frontera del atributo, que son condiciones obligatorias de frontera, generalmente en un rango numérico de valores de un atributo. Por generalmente en un rango numérico de valores de un atributo. Por ejemplo: ejemplo:

tiempo de respuesta tiempo de respuesta = (dos segundos como máximo)= (dos segundos como máximo)

Practica para los equiposPractica para los equipos: Identifiquen los requerimientos : Identifiquen los requerimientos funcionales y no funcionales de su proyecto de software. Definir funcionales y no funcionales de su proyecto de software. Definir también el panorama general y las metas. también el panorama general y las metas.

Inclúyalo en su reporte de la practica 7 Fecha limite de entrega:.Inclúyalo en su reporte de la practica 7 Fecha limite de entrega:.

4.1 Requerimientos funcionales y no 4.1 Requerimientos funcionales y no funcionales. funcionales.

4.1 Requerimientos funcionales y no 4.1 Requerimientos funcionales y no funcionales.funcionales.

Los requerimientos caen en dos categorías, Los requerimientos caen en dos categorías, funcionales y no funcionales.funcionales y no funcionales.

Requerimiento funcional:Requerimiento funcional: Un requerimiento funcional especifica una acción Un requerimiento funcional especifica una acción

que deberá ser capaz de desempeñar el producto que deberá ser capaz de desempeñar el producto deseado. Los requerimientos regularmente se deseado. Los requerimientos regularmente se expresan en términos de entradas y salidas: dada expresan en términos de entradas y salidas: dada una entrada específica, el requerimiento funcional una entrada específica, el requerimiento funcional estipula cuál debe ser la salida.estipula cuál debe ser la salida.

4.1 Requerimientos funcionales y no 4.1 Requerimientos funcionales y no funcionales.funcionales.

Requerimiento No Funcional:Requerimiento No Funcional:

Un requerimiento no funcional especifica propiedades del Un requerimiento no funcional especifica propiedades del producto deseado en sí, como producto deseado en sí, como

restricciones de la plataformarestricciones de la plataforma (“el producto de software (“el producto de software

debe ejecutarse en Linux”), debe ejecutarse en Linux”), tiempo de respuestatiempo de respuesta (“en promedio, las consultas del Tipo (“en promedio, las consultas del Tipo

3B deberán responderse dentro de 2.5 segundos”), o 3B deberán responderse dentro de 2.5 segundos”), o confiabilidadconfiabilidad (“el producto de software debe ejecutarse en (“el producto de software debe ejecutarse en

99.95% del tiempo”).99.95% del tiempo”).

4.2 Casos de uso4.2 Casos de uso Programación Orientada a ObjetosProgramación Orientada a Objetos

Según Según BoochBooch: : La programación Orientada a Objetos es un método de La programación Orientada a Objetos es un método de

implementación en el cual los programas están organizados implementación en el cual los programas están organizados como colecciones cooperativas de objetos, cada uno de los como colecciones cooperativas de objetos, cada uno de los cuales representa una instancia de alguna clase, y cuyas cuales representa una instancia de alguna clase, y cuyas clases son todas miembros de una jerarquía de clases clases son todas miembros de una jerarquía de clases unidas vía relaciones de herencia.unidas vía relaciones de herencia.

Aquí hay tres partes importantes: La programación Aquí hay tres partes importantes: La programación

orientada a objetos:orientada a objetos: Usa objetos, no algoritmos, como bloques lógicos de Usa objetos, no algoritmos, como bloques lógicos de

construcción (jerarquía "parte de…"). construcción (jerarquía "parte de…"). Cada objeto es instancia de alguna clase. Cada objeto es instancia de alguna clase. Las clases están relacionadas entre si vía relaciones de Las clases están relacionadas entre si vía relaciones de

herencia (jerarquía "tipo de…"). herencia (jerarquía "tipo de…").

4.2 Casos de uso4.2 Casos de uso

Diseño Orientado a ObjetosDiseño Orientado a Objetos El énfasis en métodos de programación está El énfasis en métodos de programación está

primariamente en el uso adecuado y efectivo de primariamente en el uso adecuado y efectivo de mecanismos de lenguajes particulares. En contraste con mecanismos de lenguajes particulares. En contraste con esto, los métodos de diseño enfatizan la estructuración esto, los métodos de diseño enfatizan la estructuración adecuada y efectiva de sistemas complejos.adecuada y efectiva de sistemas complejos.

Según Booch:Según Booch: Diseño orientado a objetos es un método de diseño que Diseño orientado a objetos es un método de diseño que

guía el proceso de descomposición orientado a objetos y guía el proceso de descomposición orientado a objetos y define una notación para expresar tanto los modelos lógico define una notación para expresar tanto los modelos lógico (estructura de clase y objeto) y físico (arquitectura de (estructura de clase y objeto) y físico (arquitectura de módulo y proceso) (tanto estáticos como dinámicos).módulo y proceso) (tanto estáticos como dinámicos).


Análisis Orientado a Objetos:Análisis Orientado a Objetos: El modelo orientado a objetos ha influido El modelo orientado a objetos ha influido

incluso en las fases iniciales del ciclo de incluso en las fases iniciales del ciclo de vida del desarrollo del software. El AOO vida del desarrollo del software. El AOO enfatiza la construcción de modelos del enfatiza la construcción de modelos del mundo real, utilizando una visión del mundo mundo real, utilizando una visión del mundo orientada a objetos.orientada a objetos.

4.2 Casos de uso4.2 Casos de usoEl modelo de objetos abarca El modelo de objetos abarca

Objeto:Objeto: Un objeto es una entidad que tiene un estado y un Un objeto es una entidad que tiene un estado y un

conjunto definido de operaciones que operan sobre este conjunto definido de operaciones que operan sobre este estado.estado.

El estado se representa mediante un conjunto de atributos El estado se representa mediante un conjunto de atributos del objeto.del objeto.

Las operaciones asociadas con el objeto proveen servicios Las operaciones asociadas con el objeto proveen servicios a otros objetos (clientes) que requieren estos servicios a otros objetos (clientes) que requieren estos servicios cuando necesitan realizar alguna actividad de cómputo.cuando necesitan realizar alguna actividad de cómputo.

Los objetos se crean de acuerdo a una definición de la Los objetos se crean de acuerdo a una definición de la clase objeto.clase objeto.

La definición de la clase objeto sirve como template para La definición de la clase objeto sirve como template para los objetos. Esta incluye las declaraciones de todos los los objetos. Esta incluye las declaraciones de todos los atributos y servicios los cuales deben estar asociados con atributos y servicios los cuales deben estar asociados con un objeto de esta clase. un objeto de esta clase.


Clase AlumnosClase Alumnos

Ejemplo:

si se realza el análisis de un si se realza el análisis de un sistema de control de sistema de control de alumnos, se tendría que alumnos, se tendría que analizar a los alumnos como analizar a los alumnos como una clase con atributos y una clase con atributos y métodos, con atributos como métodos, con atributos como el num_ctrl, nombre, direcc, el num_ctrl, nombre, direcc, tel, etc. y métodos como alta tel, etc. y métodos como alta de alumno, baja y de alumno, baja y modificaciones de alumnos.modificaciones de alumnos.

num_ctrlnum_ctrl

NombreNombre

DireccDirecc

teltel

Alta_alumno()

Baja_alumno()

Modi_alumno()


Objeto AlumnoObjeto Alumno








GradyGrady BoochBooch

Grady BoochGrady Booch (nació el 27 de febrero de 1955) es un (nació el 27 de febrero de 1955) es un diseñador de software, un metodologista de software y diseñador de software, un metodologista de software y entusiasta de diseño de patrones. Es director científico de entusiasta de diseño de patrones. Es director científico de Rational Software (ahora parte de IBM) y editor de una Rational Software (ahora parte de IBM) y editor de una serie de Benjamin/Cummings. En 1995 se recibió como serie de Benjamin/Cummings. En 1995 se recibió como miembro de la Asociación de Maquinaria Computacional miembro de la Asociación de Maquinaria Computacional (ACM). Fue nombrado socio de IBM en 2003.(ACM). Fue nombrado socio de IBM en 2003.

Booch es mejor conocido por el desarrollo del Lenguaje Booch es mejor conocido por el desarrollo del Lenguaje Unificado de Modelado con Ivar Jacobson y James Unificado de Modelado con Ivar Jacobson y James Rumbaugh. También desarrolló el método Booch de Rumbaugh. También desarrolló el método Booch de desarrollo de software, el que presenta en su libro, Análisis desarrollo de software, el que presenta en su libro, Análisis y Diseño Orientado a Objetos. Él aconseja la adición de y Diseño Orientado a Objetos. Él aconseja la adición de más clases para simplificar códigos complejos.más clases para simplificar códigos complejos.

http://images.google.com.mx/imgres?imgurl=http://www.reengineer.org/stevens/images/grady_booch.jpg&imgrefurl=http://www.reengineer.org/stevens/previous.htm&usg=__Z5r3wjXl0okfncvRUPJwKujpX04=&h=379&w=331&sz=12&hl=es&start=1&um=1&tbnid=vFddwOPFc5twyM:&tbnh=123&tbnw=107&prev=/images%3Fq%3Dgrady%2Bbooch%26ndsp%3D20%26hl%3Des%26sa%3DN%26um%3D1


Cómo determinar lo que el cliente necesitaCómo determinar lo que el cliente necesita

Un concepto que erróneamente se tiene es que, Un concepto que erróneamente se tiene es que, durante el flujo de trabajo de los requerimientos, durante el flujo de trabajo de los requerimientos, los desarrolladores deben determinar qué los desarrolladores deben determinar qué software es el que el cliente quiere. Por el software es el que el cliente quiere. Por el contrario el objetivo real del flujo de los contrario el objetivo real del flujo de los requerimientos es determinar requerimientos es determinar qué software es el qué software es el que el cliente necesitaque el cliente necesita. .


Ejemplo:Ejemplo: S. I. Hayakawa (1906- 1992), senador estadounidense de S. I. Hayakawa (1906- 1992), senador estadounidense de

California, una vez declaró a un grupo de periodistas: “Yo California, una vez declaró a un grupo de periodistas: “Yo sé que ustedes creen que entendieron lo que piensan que sé que ustedes creen que entendieron lo que piensan que les dije, pero no estoy seguro de que ustedes se hayan les dije, pero no estoy seguro de que ustedes se hayan dado cuenta de que lo que escucharon no es a lo que yo dado cuenta de que lo que escucharon no es a lo que yo me refería”.me refería”.

Esta excusa aplica de igual manera al punto del análisis de Esta excusa aplica de igual manera al punto del análisis de requerimientos. Los analistas de sistemas escucharon las requerimientos. Los analistas de sistemas escucharon las peticiones de su cliente, pero lo que ellos escucharon no peticiones de su cliente, pero lo que ellos escucharon no es lo que el cliente debería estar diciendo.es lo que el cliente debería estar diciendo.

http://images.google.com.mx/imgres?imgurl=http://www.digitaljournal.com/img/9/0/1/2/2/1/i/5/0/1/o/Hayakawa_p15.jpg&imgrefurl=http://www.digitaljournal.com/image/50112&usg=__5DUKI4VcxpbXrXzfGBeC442jLp0=&h=461&w=316&sz=86&hl=es&start=8&um=1&tbnid=yCdXSB0WrjItSM:&tbnh=128&tbnw=88&prev=/images%3Fq%3DS.I.%2BHAYAKAWA%26hl%3Des%26sa%3DN%26um%3D1


Flujo de trabajo de los requerimientosFlujo de trabajo de los requerimientos::

1.1. Comprender el dominioComprender el dominio

Comprender el dominio, esto es, el Comprender el dominio, esto es, el ambiente específico en el cual operaría el ambiente específico en el cual operaría el producto deseado. Ejemplo: bancos, producto deseado. Ejemplo: bancos, exploración espacial, industria automotriz, exploración espacial, industria automotriz, industria petroquímica.industria petroquímica.


2.2. Construir el modelo del negocioConstruir el modelo del negocio

Utilizar diagramas UML para describir los Utilizar diagramas UML para describir los procesos de negocio del cliente. procesos de negocio del cliente.

Se utiliza para determinar los Se utiliza para determinar los requerimientos iniciales del cliente.requerimientos iniciales del cliente.


1.1. Comprender el dominioComprender el dominio Para extraer las necesidades del cliente, los miembros Para extraer las necesidades del cliente, los miembros

del equipo de requerimientos deben familiarizarse con el del equipo de requerimientos deben familiarizarse con el dominio de la aplicación, esto es, el área general en la dominio de la aplicación, esto es, el área general en la cual se usará el producto deseado. Por ejemplo, no es cual se usará el producto deseado. Por ejemplo, no es fácil realizar preguntas significativas a un banquero sin fácil realizar preguntas significativas a un banquero sin antes familiarizarse con la banca.antes familiarizarse con la banca.

Usar la terminología correcta.Usar la terminología correcta. Construir un glosario, una lista de palabras técnicas Construir un glosario, una lista de palabras técnicas

utilizadas en el dominio, junto con sus significados.utilizadas en el dominio, junto con sus significados.

Comprender el dominioComprender el dominio

Para una persona común palabras como abrazadera, Para una persona común palabras como abrazadera, barra, trabe y poste pudieran ser sinónimos, pero para un barra, trabe y poste pudieran ser sinónimos, pero para un ingeniero civil son términos distintos.ingeniero civil son términos distintos.

Si un desarrollador no aprecia que un ingeniero civil utiliza Si un desarrollador no aprecia que un ingeniero civil utiliza estos cuatro términos en una forma precisa y si el estos cuatro términos en una forma precisa y si el ingeniero civil asume que el desarrollador está ingeniero civil asume que el desarrollador está familiarizado con las diferencias de estos términos, el familiarizado con las diferencias de estos términos, el desarrollador pudiera tratar los cuatro términos como desarrollador pudiera tratar los cuatro términos como equivalentes; el software de diseño de puentes asistido por equivalentes; el software de diseño de puentes asistido por computadora resultante pudiera contener fallas que computadora resultante pudiera contener fallas que ocasionarían un colapso del puente.ocasionarían un colapso del puente.

¿ En quién caería la responsabilidad? ¿ En quién caería la responsabilidad?


2.2. Construir el modelo del negocioConstruir el modelo del negocio

Un modelo de negocio es una descripción de los Un modelo de negocio es una descripción de los procesos de negocio de una organización. Por ejemplo: procesos de negocio de una organización. Por ejemplo: algunos de los procesos de negocio de un banco algunos de los procesos de negocio de un banco incluyen incluyen

aceptar depósitos de los clientes, aceptar depósitos de los clientes, prestar dinero a los clientes prestar dinero a los clientes y hacer inversiones.y hacer inversiones. La razón para construir un modelo de negocio se debe La razón para construir un modelo de negocio se debe

primero a que éste proporciona una comprensión del primero a que éste proporciona una comprensión del negocio del cliente como un todo.negocio del cliente como un todo.

Construir el modelo del negocioConstruir el modelo del negocio

Se pueden utilizar diferentes técnicas para Se pueden utilizar diferentes técnicas para obtener la información necesaria para obtener la información necesaria para construir el modelo de negocio:construir el modelo de negocio:

Entrevista Entrevista CuestionarioCuestionario Observación directaObservación directa Cámaras de videoCámaras de video

Construir el modelo del negocioConstruir el modelo del negocio

Un modelo de negocio:Un modelo de negocio:

Es un conjunto de diagramas UML que Es un conjunto de diagramas UML que representan uno o más aspectos del representan uno o más aspectos del producto de software a ser desarrollado.producto de software a ser desarrollado.

Uno de los principales diagramas UML Uno de los principales diagramas UML utilizados en el modelado de negocio es el utilizados en el modelado de negocio es el de caso de uso.de caso de uso.

4.2 Casos de uso4.2 Casos de uso Concepto creado por Jacobson (1986)Concepto creado por Jacobson (1986) Un caso del uso describe una característica del sistema.Un caso del uso describe una característica del sistema. Cada caso de uso se centra en describir cómo alcanzar una Cada caso de uso se centra en describir cómo alcanzar una

única meta o tarea de negocio.única meta o tarea de negocio. Describen el comportamiento del software o de los sistemas.Describen el comportamiento del software o de los sistemas. Muestran los pasos que el actor sigue para realizar una Muestran los pasos que el actor sigue para realizar una

tarea.tarea. Los casos del uso no describen ninguna funcionalidad Los casos del uso no describen ninguna funcionalidad

interna (oculta al exterior) del sistema, ni explican cómo se interna (oculta al exterior) del sistema, ni explican cómo se implementará.implementará.

Y no permiten determinar los requisitos no funcionales.Y no permiten determinar los requisitos no funcionales.


Caso de uso Retiro de DineroCaso de uso Retiro de Dinero

Retiro de dinero

Producto de software del banco

Cliente Cajero


Ejercicio:Ejercicio:

Realizar el diagrama de casos de uso de un Realizar el diagrama de casos de uso de un cajero automático. cajero automático.

Realizar la descripción de los casos de uso.Realizar la descripción de los casos de uso.

unidad 4. anÁlisisdelosrequerimientos objetivo de la unidad: aplicar los requerimientos...

Documents