miércoles, 28 de noviembre de 2012


DIAGRAMA DE SECUENCIA



El diagrama de secuencia de uml muestran la forma en que los objetos se comunican entre si al transcurrir el tiempo. 

Los diagramas de secuencia, formalmente diagramas de traza de eventos o de interacción de objetos, se utilizan con frecuencia para validar los casos de uso. 




El diagrama muestra:
  • Los objetos participando de la interacción
  • La secuencia de mensajes intercambiados
  • Un diagrama de secuencia contiene:
  • Objetos con su línea de vida
  • Mensajes intercambiados entre objetos de una secuencia ordenada
  • Línea de vida activa


OBJETOS



Los diagramas de secuencia constan de objetos que se representan de modo usual: rectángulo con nombre, mensajes entre los objetos representados por líneas continuas con una punta de flecha y el tiempo representado como una progresión vertical. Los objetos se colocan cerca de la parte superior del diagrama de izquierda a derecha y se acomodan de manera que simplifiquen el diagrama.
La extensión que esta debajo (en forma descendente) de cada objeto será una línea discontinua conocida como la línea de vida de un objeto, junto con la línea de vida de un (objeto rectángulo) se le conoce como activación, el cual una operación que realiza el objeto la interpreta como la duración de la activación.






LINEA DE VIDA


Una línea de vida representa un participante individual en un diagrama de secuencia. Una línea de vida usualmente tiene un rectángulo que contiene el nombre del objeto. Si el nombre es self entonces eso indica que la línea de vida representa el clasificador que posee el diagrama de secuencia.






MENSAJE


Un mensaje que va de un objeto a otro pasa de la línea de vida de un objeto al de otro. Un objeto puede enviarse un objeto a si mismo es decir de su línea de vida así propia línea de vida.



Un mensaje puede ser simple, síncrono y asíncrono

  • Mensaje simple: es la transferencia del control de un objeto a otro.
  • Mensaje síncrono: es cuando el objeto espera la respuesta a ese mensaje antes de continuar con su trabajo.
  • Mensaje asíncrono: es cuando el objeto no espera la respuesta a ese mensaje antes de continuar.



TIEMPO
El diagrama representa el tiempo en dirección vertical. El tiempo se inicia en la parte superior y avanza hacia la parte inferior. Un mensaje que este mas cerca de la parte superior ocurrirá antes que uno que esté cerca de la parte inferior.
Con ellos el diagrama de secuencia tiene 2 dimensiones: la dimensión horizontal (es la disposición de los objetos) y la dimensión vertical (muestra el paso del tiempo).
La siguiente figura muestra el conjunto basico de simbolos del diagrama desecuencia, junto con los simbolos de su funcionamiento.



RECURCIVIDAD
En ocasiones un objeto posee una operación que se invoca a si misma. A esto se le conoce como recursividad y es una característica fundamental de varios lenguajes de programación.
La siguiiente figura muestra este tipo de reprecentacion.



PALABRAS CLAVES
  • Diagrama
  • Secuencia
  • Objeto
  • Mensaje
  • Tiempo
  • Recurcividad
  • Linea
  • Vida
  • self

OBJETIVO

Descubrir las interfases requeridas para cada objeto y validar que cada interfase se usa realmente.
El diagrama de Secuencias modela interacciones entre objetos. Ya que estas interacciones pueden ser muy complejas, se modelan un pequeño juego de interacciones como un solo escenario.


EJEMPLO
Juego del ajedrez



martes, 27 de noviembre de 2012

Diccionario de Datos


Despues de leer un pregunta en el parcial que algo inquieto con este tema y este fue el concepto que consegui sobre el tema espero le sirva de ayuada.
Un diccionario de datos es un conjunto de metadatos que contiene las características lógicas de los datos que se van a utilizar en el sistema que se programa, incluyendo nombre, descripción, alias, contenido y organización. Estos diccionarios se desarrollan durante el análisis de flujo de datos y ayuda a los analistas que participan en la determinación de los requerimientos del sistema, su contenido también se emplea durante el diseño del proyecto e identifica los procesos donde se emplean los datos y los sitios donde se necesita el acceso inmediato a la información, se desarrolla durante el análisis de flujo de datos y en la determinación de los requerimientos del sistema ademas de que su contenido también se emplea durante el diseño. 

Ejemplo:
Nombre = Título + Primer-nombre + Apellido-paterno + Apellido-materno
Título = [ Sr | Sra | Dr | Ing]
Primer-nombre = {caracter}
Apellido-paterno = {caracter}
Apellido-materno = {caracter}
Caracter = [A-Z|a-z| |’] a 

domingo, 18 de noviembre de 2012


Arquitectura Cliente – Servidor




La arquitectura cliente-servidor es un modelo de aplicación distribuida en el que las tareas se reparten entre los proveedores de recursos o servicios, llamados servidores, y los demandantes, llamados clientes.
Un cliente realiza peticiones a otro programa, el servidor, que le da respuesta. Esta idea también se puede aplicar a programas que se ejecutan sobre una sola computadora, aunque es más ventajosa en un sistema operativo multiusuario distribuido a través de una red de computadoras.
En esta arquitectura la capacidad de proceso está repartida entre los clientes y los servidores, aunque son más importantes las ventajas de tipo organizativo debidas a la centralización de la gestión de la información y la separación de responsabilidades, lo que facilita y clarifica el diseño del sistema.
La separación entre cliente y servidor es una separación de tipo lógico, donde el servidor no se ejecuta necesariamente sobre una sola máquina ni es necesariamente un sólo programa. Los tipos específicos de servidores incluyen los servidores web, los servidores de archivo, los servidores del correo, etc. Mientras que sus propósitos varían de unos servicios a otros, la arquitectura básica seguirá siendo la misma.
Una disposición muy común son los sistemas multicapa en los que el servidor se descompone en diferentes programas que pueden ser ejecutados por diferentes computadoras aumentando así el grado de distribución del sistema.

jueves, 25 de octubre de 2012

caso de uso


Casos de Uso (Use Case)
Introducción
El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el sistema en desarrollo, además de la forma, tipo y orden en como los elementos interactuan (operaciones o casos de uso).
Un diagrama de casos de uso consta de los siguientes elementos:
  • Actor.
  • Casos de Uso.
  • Relaciones de Uso, Herencia y Comunicación.
Elementos:
Ejemplo:
Como ejemplo esta el caso de una Máquina Recicladora:
Sistema que controla una máquina de reciclamiento de botellas, tarros y jabas. El sistema debe controlar y/o aceptar:
  • Registrar el número de ítemes ingresados.
  • Imprimir un recibo cuando el usuario lo solicita:
    1. Describe lo depositado
    2. El valor de cada item
    3. Total
  • El usuario/cliente presiona el botón de comienzo
  • Existe un operador que desea saber lo siguiente:
    1. Cuantos ítemes han sido retornados en el día.
    2. Al final de cada día el operador solicita un resumen de todo lo depositado en el día.
  • El operador debe además poder cambiar:
    1. Información asociada a ítemes.
    2. Dar una alarma en el caso de que:
      1. Item se atora.
      2. No hay más papel.
Como una primera aproximación identificamos a los actores que interactuan con el sistema:
Luego, tenemos que un Cliente puede Depositar Itemes y un Operador puede cambiar la información de un Item o bien puede Imprimir un informe:
Además podemos notar que un item puede ser una Botella, un Tarro o una Jaba.
Otro aspecto es la impresión de comprobantes, que puede ser realizada después de depositar algún item por un cliente o bien puede ser realizada a petición de un operador.
Entonces, el diseño completo del diagrama Use Case es:

domingo, 21 de octubre de 2012

Ciclo de vida Rup


CICLO DE VIDA DE RUP
DIAGRAMA GENERAL DE RUP 



FASES DEL CICLO DE VIDA DE RUP

En cuanto a tiempo el ciclo de vida de RUP se descompone en 4 FASES secuenciales, cada cual concluye con un producto intermedio.
Al terminar cada fase se realiza una evaluación para determinar si se ha cumplido o no con los objetivos de la misma
.

      


INICIO

•    El objetivo general de esta fase es establecer un acuerdo entre todos los interesados acerca de los objetivos del proyecto.
•    Es significativamente importante para el desarrollo de nuevo software, ya que se asegura de identificar los riesgos relacionados con el negocio y requerimientos.
•    Para proyectos de mejora de software existente, esta fase es más breve y se centra en asegurar la viabilidad de desarrollar el proyecto.

ELABORACIÓN

•    El objetivo en esta fase es establecer la arquitectura base del sistema para proveer bases estables para el esfuerzo de diseño e implementación en la siguiente fase.
•    La arquitectura debe abarcar todas las consideraciones de mayor importancia de los requerimientos y una evaluación del riesgo.

CONSTRUCCIÓN
•    El objetivo de la fase de construcción es clarificar los requerimientos faltantes y completar el desarrollo del sistema basados en la arquitectura base.
•    Vista de cierta forma esta fase es un proceso de manufactura, en el cual el énfasis se torna hacia la administración de recursos y control de las operaciones para optimizar costos, tiempo y calidad.

TRANSICIÓN
•    Esta fase se enfoca en asegurar que el software esté disponible para sus usuarios.
•    Se puede subdividir en varias iteraciones, además incluye pruebas del producto para poder hacer el entregable del mismo, así como realizar ajuste menores de acuerdo a ajuste menores propuestos por el usuario.
•    En este punto, la retroalimentación de los usuarios se centra en depurar el producto, configuraciones, instalación y aspectos sobre utilización.

lunes, 15 de octubre de 2012

Cerdos y gallinas


Espero y esta este ejemplo del ciclo de vida scrum le agrade es el que indentifica esta metologia ya que en ella se explica dos roles muy importante dentro de este método llamado scrum 

Cerdos y gallinas: metodología Scrum

La metodología Scrum es un modelo de gran utilidad para todos aquellos quienes su actividad esté relacionada a la realización de proyectos para terceras partes. Buenos ejemplos de este tipo de profesionales son los arquitectos, programadores, consultores, desarrolladores web, publicistas, etc.
De una manera muy sintética consiste en la definición de un conjunto de prácticas y roles, para el establecimiento del proceso de desarrollo que se llevará a cabo durante la ejecución del proyecto. Los tres roles de los que se compone la metodología Scrum son el ScrumMaster, que se asimila al director de proyecto, el Product Owner, es decir, el cliente que puede ser interno o externo y el Team, que engloba el equipo que ejecuta el proyecto.
El proceso se inicia con una reunión de los roles para establecer el Sprint Planning. El Product Owner identifica los elementos del Product Backlog, es decir, el conjunto de requisitos priorizados que definen el trabajo a realizar y que quiere que el equipo complete por lo que se lo comunica a los miembros del equipo
El equipo determina la cantidad del trabajo al que puede comprometerse durante el siguiente sprint. En el desarrollo de cada sprint nadie puede cambiar el Sprint Backlog lo que significa que los requisitos permanecen invariables hasta la culminación del sprint que puede durar de 15 a 30 días.
Uno de los principios esenciales de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan, lo que implica que el equipo ha de estar abierto a afrontar nuevos desafíos. Por tanto requiere una planteamiento de maximización de la capacidad del equipo para responder a nuevos requisitos no planificados ni programados.
Para el establecimiento de roles se establece una comparación con los cerdos y las gallinas. Los primeros, los cerdos, son los que están comprometidos con el proyecto y el proceso Scrum y lo componen:
§  El Product Owner representa la voz del cliente. Se asegura de que el equipo Scrum trabaja de forma adecuada desde la perspectiva del negocio.
§  ScrumMaster (o Facilitador), cuyo trabajo primario es eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es el líder del equipo (porque ellos se auto-organizan), sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga. Es quien hace que las reglas se cumplan.
§  Team tiene la responsabilidad de entregar el producto. Un pequeño equipo de 5 a 9 personas con las habilidades transversales necesarias para realizar el trabajo.
Los roles gallina en realidad no son parte del proceso pero deben tenerse en cuenta. Incluyen a los usuarios, expertos del negocio y otros interesados (stakeholders). Es importante que esa gente participe y entregue retroalimentación con respecto a la salida del proceso a fin de revisar y planear cada sprint.

este es un

martes, 9 de octubre de 2012

COCOMO

la verdad este fue un tema q nos falto en la exposicion y quiero compartilo con ustedes

MODELO COCOMO
Barry Boehm en su libro "economía de la ingeniería de software" detalla un modelo amplio de estimación de costos llamado COCOMO (Constructive Cost Model). La palabra "constructive" se refiere a el hecho que el modelo ayuda a un estimador a comprender mejor la complejidad del software; este modelo es un ejemplo de variable simple estático y es usado por miles de administradores de proyecto de software .
COCOMO ayuda a estimar el esfuerzo, tiempo, gente y costos (ya sea estos de desarrollo, equipamiento y mantenimiento).
El modelo provee tres "niveles" de aplicación: básico, intermedio y avanzado, basados en los factores considerados por el modelo.
Básico, es un modelo estático simplemente evaluado que calcula el esfuerzo (y costo) del desarrollo del software como función del programa expresado en líneas de código (LDC estimados).
Intermedio, calcula el esfuerzo del desarrollo del software como función del tamaño del programa y un conjunto de "guías de costo" que incluye una evaluación subjetiva del producto, hardware, personal y de los atributos del proyecto.
Avanzado, incorpora todas las características de la versión intermedia con una evaluación del impacto de las vías de costo en cada fase (análisis, diseño, etc) del proceso de la ingeniería de software.
El modelo básico se extiende para considerar un conjunto de atributos de guías de costo que pueden agruparse en cuatro categorías principales:
Producto ( por ej. Requerimientos de software, confiabilidad, tamaño de la base de datos, y complejidad del producto).
Computadora (por ej. Restricciones en el tiempo de ejecución y almacenamiento).
Personal (por ej. Capacidad de análisis, experiencia en aplicaciones tanto en lenguajes de programación y capacidad del programador)
Proyecto (por ej. Uso de practicas modernas de programación, uso de herramientas de software y requerimiento de un plan de desarrollo).
En cada nivel de aplicación están definidos para tres tipos de proyectos de software:
Modo orgánico, proyectos de software relativamente pequeños y sencillos en los que pequeños equipos con buena experiencia en la aplicación trabajan en un conjunto de requerimiento poco rígidos.
Modo semi-acoplado(semi-detached), un proyecto de software intermedio en tamaño y complejidad en el cual equipos con distintos niveles de experiencia debe satisfacer requerimientos poco y medio rígidos
Modo acoplado(detached), un proyecto de software que debe ser desarrollado dentro un conjunto estricto de hardware, software y de restricciones operativas.
Modos que están basados en la complejidad de la aplicación y el desarrollo del ambiente. El modelo de esfuerzo general aplicable a todos los niveles de aplicación y modos está dado por :
Donde:
E = es el esfuerzo estimado expresado en hombres-mes
EDSI es el número estimado de líneas de código distribuidas en miles para el proyecto
a, h son constantes determinadas por el modo del desarrollo, ambos incrementados por la complejidad de la aplicación.
EAF es el factor de ajuste de esfuerzo, es igual a 1 para la modelo básica e igual al producto de 15 factores de costo para la modelo intermedia y avanzada. Cada factor de costo multiplicativo es reflexivo de un incremento proporcional (> 1) o decremento (<1) en costo.
A continuación veremos los coeficientes para el modelo intermedio que depende de modo de desarrollo:
MODO DE DESARROLLO
A
b
c
d
Organic
3.2
1.05
2.5
0.38
Semi-detached
3.0
1.12
2.5
0.35
Embedded
2.8
1.20
2.5
0.32

Modo básico utiliza el tamaño y el modo intermedio 15 manejadores de costo que son los siguientes:
Manejadores de Costo
Very Low
Low
Nominal
High
Very High
Extra High
ACAP Analyst Capability
1.46
1.19
1.00
0.86
0.71
-
AEXP Applications Experience
1.29
1.13
1.00
0.91
0.82
-
CPLX Product Complexity
0.70
0.85
1.00
1.15
1.30
1.65
DATA Database Size
-
0.94
1.00
1.08
1.16
-
LEXP Language Experience
1.14
1.07
1.00
0.95
-
-
MODP Modern Programming Practices
1.24
1.10
1.00
0.91
0.82
-
PCAP Programmer Capability
1.42
1.17
1.00
0.86
0.70
-
RELY Required Software Reliability
0.75
0.88
1.00
1.15
1.40
-
SCED Required Development Schedule
1.23
1.08
1.00
1.04
1.10
-
STOR Main Storage Constraint
-
-
1.00
1.06
1.21
1.56
TIME Execution Time Constraint
-
-
1.00
1.11
1.30
1.66
TOOL Use of Software Tools
1.24
1.10
1.00
0.91
0.83
-
TURN Computer Turnaround Time
-
0.87
1.00
1.07
1.15
-
VEXP Virtual Machine Experience
1.21
1.10
1.00
0.90
-
-
VIRT Virtual Machine Volatility
-
0.87
1.00
1.15
1.30
-