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.

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..

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)

TÉCNICAS DE RECOLECCIÓN DE DATOS

CUESTIONARIO

1 ¿tiene computador en casa?

2 ¿sabe usar la computadora?

3 ¿usa la computadora?

4 ¿usa el internet?

5 ¿cuanto tiempo?

a) menos de una hora b) una hora c) mas de una hora (por dia)

6 ¿que programas utiliza?

7 ¿cuales son sus preferencias al navegar (si lo hace)?

8 ¿en que utiliza la computadora?

opciones: a) diversion b) tareas escolares c)trabajo

9 ¿a utilizado el internet para comunicarse con amigos y familiares (facebook)?

10 ¿que opina de las TIC?

ENCUESTA

*Como ejemplo tenemos la encuesta de una tienda que vende sofware y hardware de la computadora:

La encuesta tiene como objetivo reunir opiniones de los clientes para asi poder mejorar nuestra atencion y nuestros productos

1.-¿Que opinion tiene sobre nuestros productos?

2.-¿Que opina de la atencion afrecida por el vendedor?

3.-¿Que opinion da sobre los precios de nuestros productos?

4.-¿El ambiente de nuestra tienda le parecio agradable?

5.-¿Al momento de comprar algun producto. el vendedor le entrega ls instrucciones del producto?

6.-Considera a nuestros productos...

              *Buenos           *Regulares            *Malos

7.-Le gusto la actitud de los vendedores...

               *Si                   *No

8.-El servicio de entrega del producto fue ...

               *Rapido            *Lento                  *Regular

9.-Los precios se le icieron...

                *Caros           *Muy caros          *Normales          *Baratos

10.-Recomendaria a demas personas esta tienda...

                *Si                 *No

ENTREVISTA

 *Como ejemplo tenemos la entrevista a una persona para que pueda entrar a una empresa como diseñador grafico:

1.-Ha laborado en alguna otra empresa

              *Si              *No

2.-¿Cuales fueron sus trabajos anteriores?

3.-¿Como fue su desempeño en su anterior trabajo?

 4.-¿De que manera obtuvo el puesto en su anterior trabajo?

5.-¿Como fue su desempeño?

6.-Que actividades desarrollaba?

7.-¿Que estudios tiene cursados?

             *Primaria            *Secundaria          *Estudios superiores

8.-¿Defina sus defectos?

9.-¿Defina sus virtudes?

10.-¿Cual es su interes en este trabajo?

TIPOS DE DIAGRAMAS UML

DIAGRAMAS DE CASOS DE USO


Los Casos de Uso no forma parte de la llamada Fase de Diseño, sino parte de la fase de Análisis, respondiendo el interrogante ¿Qué?. De forma que al ser parte del análisis ayuda a describir que es lo que el sistema debe hacer.

Estos diagramas muestran operaciones que se esperan de una aplicación o sistema y como se relaciona con su entorno, es por ello que se ve desde el punto de vista del usuario. Describen un uso del sistema y como éste interactúa con el usuario.

Los casos de usos se representan en el diagrama por una elipses la cual denota un requerimiento solucionado por el sistema.
El conjunto de casos de usos representa la totalidad de operaciones que va a desarrollar el sistema. Por último a estos elipses lo acompaña un nombre significativo de manera de rótulo.











Otro elemento fundamental de estos diagramas son los actores la cual representa a un usuario del sistema, que necesita o interactúa con algún caso de uso, la que también es acompañado por un nombre.Por último tenemos los flujos de eventos quecorresponde a la ejecución normal y exitosa del caso de uso.




DIAGRAMA DE CLASES



En UML el diagrama de clases es uno de los tipos de diagramas o símbolo estático y tiene como fin describir la estructura de un sistema mostrando sus clases, atributos y relaciones entre ellos.




Estos diagramas son utilizados durante el proceso de análisis y diseño de los sistemas informáticos, en donde se intentan conformar el diagrama conceptual de la información que se manejará en el sistema.






Como ya sabemos UML es un modelado de sistema Orientados a Objetos, por ende los conceptos de este paradigma se incorporan a este lenguaje de modelado.




























Los diagramas de clases tiene las siguientes características:
Las clases define el ámbito de definición de un conjunto de objetos.
Cada objeto pertenece a una clase.
Los objetos se crean por instanciación de las clases.






DIAGRAMA DE OBJETOS



Forma parte de la vista estática del sistema. En este diagrama se modelan las instancias de la clases del Diagrama de Clases. Este diagrama cabe aclarar que cuenta con objetos y enlaces. En estos diagramas también es posible encontrar las clases para tomar como referencia su instanciación.











En otras palabras el Diagrama de Objetos muestra un conjunto de objetos y sus relaciones en un momento concreto.Los Diagramas de Objetos son realmente útiles para modelar estructuras de datos complejas








DIAGRAMAS DE COMPORTAMIENTOS





Diagrama de Estados


Un estado es una condición durante la vida de un objeto, de forma que cuando dicha condición se satisface se lleva a cabo alguna acción o se espera por un evento.


El estado de un objeto se puede caracterizar por el valor de uno o varios de los atributos de su clase, además, el estado de un objeto también se puede caracterizar por la existencia de un enlace con otro objeto.






El diagrama de estados engloba todos los mensajes que un objeto puede enviar o recibir, en otras palabras es un escenario que representa un camino dentro de un diagrama.

Como característica de estos diagramas siempre cuentan con dos estados especiales, el inicial y el final, con la particularidad que este diagrama puede tener solo un estado inicial pero varios estados finales.

Una transición entre estados representa un cambio de un estado origen a un estado sucesor destino que podría ser el mismo que el estado origen, dicho cambio de estado puede estar aparejado con alguna acción. Además las acciones se asocian a las transiciones y se consideran que ocurre de forma rápida e ininterrumpible.











Los elementos que componen estos diagramas son:



Círculo lleno, apuntando el estado inicial.
Círculo hueco que contiene un círculo lleno más pequeño en el interior, indicando el estado final.
Rectángulo redondeado dividido por una línea horizontal, indicado los estados, en la parte de arriba se encuentra el nombre del estado y abajo se indica la actividad que realiza.
Flecha, la cual denota la transición, el nombre del evento que causa esta transición etiqueta el cuerpo de la flecha.






Diagrama de actividad


Un Diagrama de Actividades representa un flujo de trabajo paso a paso de negocio y operacionales de los componentes en un sistema.

En UML 1, un diagrama de actividades es una variación del Diagrama de Estados UML donde los estados representan operaciones y las transiciones representan las actividades que ocurren cuando la operación es completa.

En la actualidad, el diagrama de actividades en UML 2.0 es similar al aspecto del diagrama en UML 1, solo que ahora la semántica esta basada en lo que se conoce como Redes de Petri. En UML 2.0, el diagrama general de interacción está basado en el diagrama de Actividad.

Componentes:
Inicio: el inicio de un diagrama de actividades es representado por un círculo de color negro sólido.
Actividad: Una actividad representa la acción que será realizada por el sistema la cual representa dentro de un óvalo.
Transición: Una transición ocurre cuando se lleva acabo el cambio de una actividad a otra, la transición es representada simplemente por una línea con una flecha en su terminación para indicar su dirección.

















DIAGRAMA DE INTERACCION




Diagrama de Secuencia




Un Diagrama de Secuencias muestra una interacción ordenada según la secuencia temporal de eventos y el intercambio de mensajes. Los diagramas diagramas de secuencia ponen especial énfasis en el orden y el momento en el que se envían los mensajes a los objetos.

















En los diagramas de Secuencias los elementos están representados por líneas intermitentes verticales, con el nombre del objeto en la parte más alta.

Los mensajes pueden ser o bien síncronos, el tipo normal de llamada del mensaje donde se pasa el control a objeto llamadohasta que el método finalize, o asíncronos donde se devuelve el control directamente al objeto que realiza la llamada.

Los mensajes síncronos tienen una caja vertical en un lateral del objeto invocante que muestra el flujo del control del programa.






Diagrama de Colaboración

Un diagrama de colaboración, se puede decir que es una forma alternativa al diagrama de secuencias a la hora de mostrar un escenario.
Este tipo de diagrama muestra las interacciones que ocurren entre los objetos que participan en una situación determinada.
A diferencia del diagrama de secuencia, el diagrama de colaboración se enfoca en la relación entre los objetos y su topología de comunicación.

En estos diagramas los mensajes enviados de un objeto a otro se representa mediante flechas, acompañado del nombre del mensaje, los parámetros y la secuencia del mensaje.

Estos diagramas están indicados para mostrar una situación o flujo de programa específico y son considerados uno de los mejores diagramas para mostrar o explicar rápidamente un proceso dentro de la lógica del programa












DIAGRAMA DE IMPLEMENTACION




Diagrama de componentes




Lo que distingue el Diagrama de Componentes de otro tipo de diagramas es sin duda su contenido. Normalmente contiene componentes, interfaces y relaciones entre ellos.Los componentes perteneces a un mundo físico, es decir, representan a un bloque de construcción al modelar aspectos físicos de un sistema.


Cada componente debe tener un nombre que lo distinga de los demás. Al igual que las clases los componentes pueden enriquecerse con compartimientos adicionales que muestran sus detalles.








Diagrama de Despliegue




Básicamente este tipo de diagrama se utiliza para modelar el Hardware utilizado en la implementación del sistema y la relaciones entre sus componentes.


Los elementos usados por este tipo de diagrama son nodos, componentes y asociaciones. En el UML 2.0 los componentes ya no están dentro de nodos, en cambio puede haber artefactos (archivo, un programa, una biblioteca o Base de datos) u otros nodos dentro de nodos.

















Además los Diagramas de Despliegue muestran la configuración en funcionamiento del sistema incluyendo su software y su hardware. Para cada componente de un diagrama es necesario que se deba documentar las características técnicas requeridas, el trafico de red, el tiempo de respuesta, etc.