miércoles, 9 de mayo de 2012

Examen Parcial Unidad 1

UNIVERSIDAD DE NOVA DE LISBOA

La Universidade Nova de Lisboa (UNL) nos ha encargado el desarrollo de una aplicación Web para la gestión de su centro de deportes llamado Desporto Novo.
Según nos explica el gerente del centro existen 4 tipos de usuarios.
El administrativo del centro de deportes, los socios alumnos, los socios que no son alumnos y personas externas.
El administrativo es quien gestiona las nuevas actividades deportivas que se celebran en el centro. Para dar de alta una actividad se le debe asignar una instalación, una fecha y una hora, una descripción, un precio, nº de personas y un o un conjunto de monitores.
Debe poder llevar también la gestión de estos monitores. Para dar de alta un monitor se precisan sus datos personales, su preparación o especialidad y las actividades que puede llevar a cabo según su capacitación.
Hay dos tipos de socios (los que son alumnos de la UNL y los que no son alumnos), la diferencia radica en los descuentos aplicados. Un socio que a la vez es alumno tiene el 50% de descuento en la inscripción de actividades y un 30% en el alquiler de instalaciones.
A la hora de inscribirse en una actividad, se debe comprobar si quedan plazas libres. Para el alquiler de una instalación se deberá consultar su disponibilidad. Una vez se haya pagado la inscripción de una actividad o el alquiler de una instalación se enviará una copia del resguardo al correo, y de forma opcional podrá imprimirlo en papel. Importante saber que cuando se alquila una instalación se deben actualizar los datos de disponibilidad.
Las personas externas se pueden hacer socios rellenando un formulario de inscripción. Una vez rellenado y enviado se le manda una copia a su correo electrónico. De forma opcional puede imprimirlo en papel. Hasta que no son socios sólo pueden consultar las instalaciones y las actividades, pero no pueden inscribirse en ninguna actividad ni alquilar instalaciones.


miércoles, 2 de mayo de 2012

PROCESOS DE NEGOCIOS

Un proceso de negocio es un conjunto de tareas relacionadas lógicamente llevadas a cabo para lograr un resultado de negocio definido. Cada proceso de negocio tiene sus entradas, funciones y salidas. Las entradas son requisitos que deben tenerse antes de que una función pueda ser aplicada. Cuando una función es aplicada a las entradas de un método, tendremos ciertas salidas resultantes.
Es una colección de actividades estructurales relacionadas que producen un valor para la organización, sus inversores o sus clientes. Es, por ejemplo, el proceso a través del que una organización ofrece sus servicios a sus clientes.
Un proceso de negocio puede ser parte de un proceso mayor que lo abarque o bien puede incluir otros procesos de negocio que deban ser incluidos en su función. En este contexto un proceso de negocio puede ser visto a varios niveles de granularidad. El enlace entre procesos de negocio y generación de valor lleva a algunos practicantes a ver los procesos de negocio como los flujos de trabajo que efectúan las tareas de una organización. Los procesos poseen las siguientes características:
  1. Pueden ser medidos y están orientados al rendimiento
  2. Tienen resultados específicos
  3. Entregan resultados a clientes o “stakeholders”
  4. Responden a alguna acción o evento específico
  5. Las actividades deben agregar valor a las entradas del proceso.

Los procesos de negocio pueden ser vistos como un recetario para hacer funcionar un negocio y alcanzar las metas definidas en la estrategia de negocio de la empresa. Las dos formas principales de visualizar una organización, son la vista funcional y la vista de procesos.

reglas de negocio

Las Reglas del Negocio o Conjunto de Reglas de Negocio describe las políticas, normas, operaciones, definiciones y restricciones presentes en una organización y que son de vital importancia para alcanzar los objetivos misionales.
Ejemplos de reglas de negocio: "Un cliente al que facturamos más de 10.000 al año es un cliente de tipo A", "A los clientes de tipo A les aplicamos un descuento del 10% en pedidos superiores a 3.000".
Las organizaciones funcionan siguiendo múltiples reglas de negocio, explícitas o tácitas, que están embebidas en procesos, aplicaciones informáticas, documentos, etc. Pueden residir en la cabeza de algunas personas o en el código fuente de programas informáticos.
En los últimos años se viene observando una tendencia a gestionar de forma sistemática y centralizada las reglas de negocio, de modo que sea fácil y sencillo consultarlas, entenderlas, utilizarlas, cambiarlas, etc. Para ello se puede utilizar un motor de reglas de negocio. El motor de reglas de negocio es un sistema que se configura para dar servicio a las necesidades de negocio a través de la definición de objetos y reglas de negocio, el software se rige por flujos que derivan responsabilidades a los distintos cargos de la empresa repartiendo así el trabajo equitativamente y cuantitativamente, cuando, quien y donde tiene que desempeñar la tarea asignada.

Las reglas de negocio son un medio por el cual la estrategia es implementada. Las reglas especifican - en un nivel adecuado de detalle - lo que una organización debe hacer.

Requerimientos



La determinación de requerimientos
 
 es el conjunto de actividades encaminadas a obtener las características necesarias que deberá poseer el nuevo sistema, es el estudio de un sistema, actividad o proceso, para comprender cómo trabaja y dónde es necesario efectuar mejoras o cambios considerables.



Este es el primer paso en el análisis de sistemas y se puede decir que es el más importante.


Uso de los diagramas de casos de usos

Diagramas de Casos de uso



Los diagramas son una técnica para capturar información de como un sistema o negocio trabaja actualmente,o de como se desea que trabaje. Aquí aún no hay orientación a objetos, más bien es una técnica para el modelado de escenarios.



Los casos de uso se representan por las figuras de “actor”, “caso de uso” y “asociación”, el actor es una entidad externa que interactúa con el sistema, los casos de uso son las funciones que realizará nuestro sistema y las asociaciones son los mensajes entre actores y casos de uso, y los casos de uso entre si:








Como ejemplo de caso de uso, describimos la forma en que se reserva una hora libre en el centro de cómputo.








Iniciando StarUML.
Selecciona el icono de lanzamiento de la aplicación. Dado que un proyecto se puede
realizar siguiendo distintos enfoques, StarUML nos pregunta cuál queremos utilizar. En
esta práctica utilizaremos el “Default Approach”.
Procedimiento
Programación II. Guía 2
5
Una vez que iniciamos StarUML, nos aparece una ventana principal, que tiene los
elementos que se muestran a continuación:
Creación de Casos de Uso.
En la parte de elementos de Proyecto, seleccionamos el modelo de casos de uso y
cambiamos el nombre, así:
Programación II, Guía 2
6
Al seleccionar este tipo de modelo, nos despliega la barra de herramientas de Casos de
Uso, donde nos permite utilizar los componentes para este tipo de diagrama.
Para seleccionar un componente damos clic al componente deseado y luego damos clic
en el área de trabajo. Cuando el componente es agregado, aparece el nombre
sombreado, lo que indica que podemos cambiar esa propiedad a nuestro antojo.
Para realizar la comunicación entre el actor con los casos de uso, utilizamos el
componente DirectedAssociation
Programación II. Guía 2
7
Creación de Diagramas de Clases.
Para crear el diagrama de clases, en el mismo proyecto que tenemos abierto, nos vamos
a elementos de proyecto y seleccionamos Design Model y cambiamos el nombre del Main
Ahora lo único que tenemos que hacer es seleccionar el componente clases y dar clic en
el área de trabajo
Nos centramos en los botones de la derecha, el celeste y el rojo. El celeste nos permite
agregar atributos o propiedades a la clase El rojo nos permite agregar métodos u
operaciones a la clase.
Programación II, Guía 2
8
Seleccionamos cualquiera de las opciones, agregamos un atributo y un método y la clase
toma la siguiente forma, note que los métodos terminan con un paréntesis.

DIAGRAMAS DE CASOS DE USO



En el Lenguaje de Modelado Unificado, un diagrama de casos de uso es una especie de diagrama de comportamiento. UML mejorado El Lenguaje de Modelado Unificado define una notación gráfica para representar casos de uso llamada modelo de casos de uso. UML no define estándares para que el formato escrito describa los casos de uso, y así mucha gente no entiende que esta notación gráfica define la naturaleza de un caso de uso; sin embargo una notación gráfica puede solo dar una vista general simple de un caso de uso o un conjunto de casos de uso. Los diagramas de casos de uso son a menudo confundidos con los casos de uso. Mientras los dos conceptos están relacionados, los casos de uso son mucho más detallados que los diagramas de casos de uso.





La descripción escrita del comportamiento del sistema al afrontar una tarea de negocio o un requisito de negocio. Esta descripción se enfoca en el valor suministrado por el sistema a entidades externas tales como usuarios humanos u otros sistemas.
La posición o contexto del caso de uso entre otros casos de uso. Dado que es un mecanismo de organización, un conjunto de casos de uso coherentes y consistentes promueven una imagen fácil de comprender del comportamiento del sistema, un entendimiento común entre el cliente/propietario/usuario y el equipo de desarrollo.

Es práctica común crear especificaciones suplementarias para capturar detalles de requisitos que caen fuera del ámbito de las descripciones de los casos de uso. Ejemplos de esos temas incluyen restricciones de diseño como: rendimiento, temas de escalabilidad/gestión, o cumplimiento de estándares.


El diagrama de la derecha describe la funcionalidad de un Sistema Restaurante muy simple. Los casos de uso están representados por elipses y los actores están, por ejemplo, los casos de uso se muestran como parte del sistema que está siendo modelado, los actores no.

La interacción entre actores no se ve en el diagrama de casos de uso. Si esta interacción es esencial para una descripción coherente del comportamiento deseado, quizás los límites del sistema o del caso de uso deban de ser re-examinados. Alternativamente, la interacción entre actores puede ser parte de suposiciones usadas en el caso de uso. Sin embargo, los actores son una especie de rol, un usuario humano u otra entidad externa puede jugar varios papeles o roles. Así el Chef y el Cajero podrían ser realmente la misma persona.
Relaciones de Casos de Uso

Las tres relaciones principales entre los casos de uso son soportadas por el estándar UML, el cual describe notación gráfica para esas relaciones. Veamos una revisión de ellas a continuación:
Inclusión (include o use)

Es una forma de interacción o creación, un caso de uso dado puede "incluir" otro caso de uso. El primer caso de uso a menudo depende del resultado del caso de uso incluido. Esto es útil para extraer comportamientos verdaderamente comunes desde múltiples casos de uso a una descripción individual, desde el caso de uso. El estándar de Lenguaje de Modelado Unificado de OMG define una notación gráfica para realizar diagramas de casos de uso, pero no el formato para describir casos de uso. Mucha gente sufre la equivocación pensando que un caso de uso es una notación gráfica (o es su descripción). Mientras la notación gráfica y las descripciones esto no sirve..
Extensión (Extend)

Es otra forma de interacción, un caso de uso dado (la extensión) puede extender a otro. Esta relación indica que el comportamiento del caso de la extensión se utiliza en casos de uso, un caso de uso a otro caso siempre debe tener extensión o inclusión. El caso de uso extensión puede ser insertado en el caso de uso extendido bajo ciertas condiciones. La notación, es una flecha de punta abierta con línea discontinua, desde el caso de uso extensión al caso de uso extendido, con la etiqueta «extend». Esto puede ser útil para lidiar con casos especiales, o para acomodar nuevos requisitos durante el mantenimiento del sistema y su extensión .


"La extensión, es el conjunto de objetos a los que se aplica un concepto. Los objetos de la extensión son los ejemplos o instancias de los conceptos."
Generalización

"Entonces la Generalización es la actividad de identificar elementos en común entre conceptos y definir las relaciones de una superclase (concepto general) y subclase (concepto especializado). Es una manera de construir clasificaciones taxonómicas entre conceptos que entonces se representan en jerarquías de clases. Las subclases conceptuales son conformes con las superclases conceptuales en cuanto a la intención y extensión."

En la tercera forma de relaciones entre casos de uso, existe una relación generalización/especialización. Un caso de uso dado puede estar en una forma especializada de un caso de uso existente. La notación es una línea sólida terminada en un triángulo dibujado desde el caso de uso especializado al caso de uso general. Esto se asemeja al concepto orientado a objetos de sub-clases, en la práctica puede ser útil factorizar comportamientos comunes, restricciones al caso de uso general, describirlos una vez, y enfrentarse a los detalles excepcionales en los casos de uso especializados..

martes, 1 de mayo de 2012

DEPENDENCIAS/RELACIONES DE CASOS DE USOS


  • <<include>>: En la nueva versión de UML): Relación de dependencia entre dos casos de uso que denota la inclusión del comportamiento de un escenario en otro.

  • << extends>>
    : Relación de dependencia entre dos casos de uso que denota que un caso de uso es una especialización de otro. Por ejemplo, podría tenerse un caso de uso que extienda la forma de pedir azúcar, para que permita escoger el tipo de azúcar (normal, dietético o moreno) y además la cantidad en las unidades adecuadas (cucharadas o bolsas). Un posible diagrama se muestra en la figura.


Se utiliza una relación de tipo <<extends>> entre casos de uso cuando nos encontramos con un caso de uso similar a otro pero que hace algo más que éste (variante). 



En una relación << extends>>, un actor que lleve a cabo el caso de uso base puede realizar o no sus extensiones. Mientras, en una relación <<include>> el actor que realiza el caso de uso base también realiza el caso de uso incluido.



En general utilizaremos <<extends>> cuando se presenta una variación del comportamiento normal, y <<include>> cuando se repite un comportamiento en dos casos de uso y queremos evitar dicha repetición.



Por último en un diagrama de casos de uso, además de las relaciones entre casos de uso y actor (asociaciones) y las dependencias entre casos de uso (<<include>> y <<extends>>), pueden existir relaciones de herencia ya sea entre casos de uso o entre actores.


Por último se debe tener en cuenta, que aunque cada caso de uso puede llevar a diferentes realizaciones, es importante reflejar en cada representación el motivo que nos ha llevado a descartarla, si es el caso.

Taller de Sistemas(Especificaciones de casos de uso)