Desarrollo de proyectos de software

Unidad 1: Temas:Conceptos introductorios 1.1 Arquitectura de 4+1 vistas

1.2 Desarrollo orientado a objetos1.3 Diagramación

Unidad 2 :Diseño orientado a objetos 2.1 Diseño de sistemas en base a procesos

2.1.1 Actividades y cambios del uso 2.1.2 Interfaces de usuario2.2 Diseño de la lógica 2.2.1 Clases y objetos 2.2.2 Interacciones 2.2.3 Estados y transiciones

Unidad 3:Construcción 3.1 Despliegue de componentes y

arquitectónico3.2 Técnicas de desarrollo de las arquitecturas de referencia en diferentes dominios 3.2.1 Los modelos de componentes 3.2.2Arquitectura de referencia para sistemas de tiempo real, fuente de alimentación. 3.2.3 Arquitecturas de referencia para sistemas móviles con conexión a internet 3.2.3 Arquitecturas de referencia para sistemas de información 3.2.4 Arquitectura de referencia para ambientes virtuales de aprendizaje 3.2.5 Arquitectura de referencia para líneas de productos

Unidad 4: Temas:Prueba del Software 4.1 Definiciones

4.1.1 Prueba, caso de prueba, defecto, falla , error, verificación y validación4.1.2 Relación entre defectos-falla-error- 4.1.3 pruebas estructurales, funcionales y aleatorias. 4.1.4 Documentación del diseño de las pruebas4.2 Proceso de pruebas4.2.1 Generar un plan de pruebas4.2.2 Diseñar pruebas específicas4.2.3Tomar configuración del software a probar4.2.4 Configurar las pruebas4.2.5 Evaluar resultados (depuración, evaluación de error)

4.3 Técnicas de diseño de casos de prueba4.4 Enfoque practico recomendado para el diseño de casos4.5 Estrategia de aplicación de las pruebas a) unidad de integración del sistema de aceptación.

Unidad V TemasImplementación y mantenimiento

Vista lógica: Describe el modelo de objetos que se van a utilizar.(ER)

Ej:

Entidad - Relación

Alumnos Clases

8vo Desarrollo proyecto

Ej:

Cliente Cuenta

La información que nos van a dar los usuarios finales, íntimamente relacionado con los escenarios. (Ejemplo consultorio de citas del Seguro Social)

Vista de procesos: Funcionalidad concurrencias y sincronización del diseño.

Ej: Tarjetas bancarias, debito y sus correspondientes comisiones en cada caso

Costos de espacios, tiempos de procesos humanos,

Vista física: Define un mapeo del SW en el HW y refleja los aspectos de distribución

Ej: Tomador de lecturas antiguo, comparado con los pads de ahora

Vista de Desarrollo: Describe la organización estática del SW en su ambiente de desarrollo

Tarea: escrito: Nombre, #control, semestre

Resumen del modelo del as cuatro vistas más 1

05/02/2011

De la vista lógica a la vista de diseño:

Características de la vista lógica:

Autonomía:

Los objetos son: Activos

Pasivos

Protegidos

Paréntesis: Objetos

Un objeto activo toma la iniciativa de invocar operaciones de otros objetos. Ej: Coche-Palanca-Llave-Frenos etc..

Un objeto pasivo solamente están a la espera de la llamada de los activos pero nunca hacen llamadas a otros objetos.

Un objeto protegido es aquel que no le puedes cambiar de forma, mas si de propiedades (gordo-flaco). Propiedades: lentes, maquillaje.

Persistencia:

Se habla de de la vida de un objeto si es permanente o temporal, sirve para ahorrar recursos.

Subordinación:

Tiene que ver con la autonomía de los objetos.

Distribución:

El creado de objetos debe de ser para todas las plataformas informáticas.

En la vista lógica de la arquitectura consideremos que cada objeto es activo y potencialmente concurrente.

Recapitulando: la vista lógica nos va a determinar cómo vemos las cosas de acuerdo a nuestra experiencia.

Vista de procesos de un banco:

A la vista de diseño:

No solamente hay que usar la vista 4+1.

La empresa X produce carrocerías que son enviadas a otra empresa para la fabricación de automóviles, la empresa está dividida en dos naves. La nave 1 produce puertas y la nave 2 produce el chasis, los obreros de la nave 1 son especialistas en hojalatería, os obreros de la nave 2 son especialistas en pintura automotriz. Al terminar el producto son enviados a una bodega para que

después se distribuya a la empresa que lo contrate. Realice un esquema lógico y una vista de diseño con dicha información.

Tarea:

Cuales son las interfaces de usuario

Que es una clase y objeto

Estados y transiciones

UML UNIFIED MODIFICATED LENGUAGE

Trabaja mediante:

Diagrama de estructura estática

Diagrama de casos de uso

Diagramas de secuencia

Diagramas de colaboración

Diagramas de estado

Elementos en común:

Notas: sirve para añadir comentarios a un elemento del diagrama

Símbolo:

Dependencias:La relación de dependencia de dos elementos de un diagrama significa que un cambio en el elemento destino puede implicar un cambio en el elemento origen

06/02/2011

Diagramas de estructura estática:

Se dividen en dos:

Modelo conceptual de la fase del análisis: Presenta los elementos de dominio

Diagrama de clases de de la fase de diseño. Solución de software

Una clase se representa mediante una caja subdividida en tres partes:

Superior: se muestra el nombre de la clase.

Medio: Los atributos o propiedades

Inferior: Operaciones. o funciones

Para los objetos es diferente solo se pone una raya abajo

Tarea: realizar 5 clases y 5 objetos de la clase

Asociaciones:

Las asociaciones se representan mediante una línea que une a las clases.

Nombre de la asociación y dirección:

Diferentes roles de la relaciónes:

Tarea: Investigar 5 superclases y buscar sus agregaciones

12/01/2011

HERENCIA:

La relación se representa mediante un triangulo en el extremo de la relación que corresponde a la clase mas general o a la clase Padre.

Elementos derivados: Un elemento derivado es aquel cuyo valor se puede calcular a partir de otros elementos presentes en el modelo, pero que se incluye en este por motivos de claridad o como decisión de diseño, se presenta por una “ \ “ que se deriva del elemento derivado

DIAGRAMA DE CASOS DE USO

Muestra la relación entre actores y los casos de uso del sistema. Representa la funcionalidad que ofrece al sistema. Entre los elementos que podemos encontrar en los casos de uso son:

-Actores

-Casos de uso

-Relaciones

Actor: entidad externa al sistema que realiza algún tipo de iteración con él mismo y se presenta como una figura humana

Caso de uso: Es la descripción de la secuencia de iteraciones que se realiza entre el actor y el sistema, se representa con una elipse con el nombre del caso de uso y debe representar la tarea especifica que debe llevar a cabo el actor usando el sistema

Relaciones: Entre dos casos de usos puede haber las siguientes relaciones:

Extiende: Un caso de uso se especializa y se le da funcionalidad a otro caso de uso (bodega aurrera compra-cobra)

Usa: cuando un caso de uso usa a otro (producción de automóvil). Se representan con una línea que une a los dos casos de uso relacionados con una flecha y con una etiqueta.

Ej

Diagramas de iteración

Los diagramas de iteración se dividen en 2:

Secuencia: Muestra una iteración ordenada, según la secuencia temporal de eventos.

El eje vertical representa el tiempo y el eje horizontal se colocan los actores y objetos participantes. Cada objeto o actor tiene una línea vertical y los objetos representan sus mensajes mediante flechas y el tiempo fluye de arriba abajo

Colaboración: Muestra una iteración ordenada basándose en los objetos que forman parte de la iteración y los enlaces entre los mismos. A diferencia de los diagramas de secuencia los diagramas de colaboración muestran las relaciones entre los roles de los objetos. Las secuencias de los mensajes deben determinarse mediante números de secuencia.

Diagramas de Estado

Muestra la secuencia de estados por los que pasa un diagrama de uso o un objeto a lo largo de su vida, indicando que objetos hacen que pasen de un estado a otro y cuáles son las respuestas y acciones que genera. La caja de estado puede tener uno o dos compartimentos, en el primero aparece el nombre del estado, en el segundo aparecen acciones de entrada y salida y acciones internas.

Ejercicio 1:

Ejercicio 2

Tarea: 2 diagramas de estado y un diagrama de tiempo o secuencia

1 diagrama con un caso de uso

Modelado Dinámico

Se representan los diagramas de actividades.

Va a contener:

Estado de actividad Estado de acción Transacciones Objetos

Estado de actividad: Tanto el estado de actividad como el de acción, son representados mediante un rectángulo con las puntas redondeadas y se podrá utilizar el lenguaje natural, una especificación formal de expresiones o un metalenguaje.

La idea central es la siguiente: “Un estado que represente una acción es atómico lo que significa que su ejecución se puede considerar instantánea y no puede ser interrumpida. Por ejemplo

En cambio un estado de actividad si se puede descomponer en más de una sub-actividad y estos si pueden ser interrumpidos y tardan cierto tiempo en completarse.

Las transiciones reflejan el paso de un estado a otro. Como todo flujo de control debe empezar y terminar, esto se puede indicar utilizando disparadores de inicio y fin.

Bifurcación:

Un flujo de control no tiene porque ser siempre secuencial, pueden presentar caminos alternativos y tener una transición de entrada y dos o más salidas, en cada transición de salida se colocara una transición booleana que será evaluada una vez llegada a la bifurcación

No solo existe el flujo secuencial y la bifurcación, también hay algunos casos en los que se requieren tareas concurrentes y el momento de la unión de un nuevo flujo de control secuencial

Calles:

Cuando se modelan flujos de trabajo de organizaciones, es especialmente útil dividir los estados de actividades en grupos, cada uno tiene un nombre completo y se denominan calles., cada calle representa la parte de la organización responsable de la actividad

Modelo físico de un sistema orientado a objetos

Componentes:

Pertenece al mundo físico, es decir, representa un bloque de construcción, y su característica básica es: definir una abstracción

Permitiéndole reemplazar a los componentes más viejos con otros más nuevos y compatibles. Todos los elementos físicos se modelan como componentes y deben tener un nombre que los distinga de los demás.

Terea: reseña de todo lo que llevamos a mano

19/02/2011

La diferencia entre componentes y clases:

Los componentes representan objetos físicos y las clases representan objetos abstractos (lógicos).

Los componentes solo tienen operaciones, pero no se pueden realizar si no tienen operaciones alcanzables por medio de una interfaz. Operaciones y atributos

Se parecen en:

Realizan interfaces

Pueden participar en relaciones, generalizaciones, asociaciones, interacciones, pueden anidarse, pueden instanciarse

Interfaz:

Tanto los servicios propios de una clase como lo de los componentes se especifican a través de una interfaz.

La relación entre un componente y su interfaz se puede representar de dos maneras, de forma icónica y de forma extendida

Diagrama de despliegue: Técnicas más comunes de modelado.

A) Modelado de un sistema empotrado.

El desarrollo de un sistema empotrado aparte del desarrollo del sistema de software implica manejar el mundo físico. Los diagramas de despliegue son útiles para facilitar la comunicación entre los ingenieros de hardware y de software y para ello es necesario:

1.- Identificar los dispositivos y no los propios de sistema

2.-Proporcionar detalles visuales sobre todo para los dispositivos poco usuales

3.-Modelar las relaciones entre los procesadores y dispositivos en un diagrama de despliegue

4.-Si es necesario hay que detallar cualquier dispositivo inteligente modelando su estructura en un diagrama de despliegue más pormenorizado.

Modelado de un sistema cliente-servidor

La división entre cliente servidor en un sistema es complicada debido a la toma de decisiones sobre donde colocar físicamente los componentes del software y qué cantidad de software debe residir en el cliente. Para modelar un sistema de cliente servidor, hay que hacer lo siguiente:

1.-Identificar los nodos que representan los procesadores cliente y servidor del sistema.

2.-Destacar los dispositivos relacionados con el comportamiento del sistema

3.-Proporcionar señales visuales para esos procesadores y dispositivos a través de estereotipos

4.-Modelar la tipología de esos diagramas de despliegue

ARQUITECTURA DEL SISTEMAARUQITECTURA DE TRES NIVELES.

Esta arquitectura es la más común debido a que contiene una interfaz de usuario y contempla la persistencia de los datos, los tres niveles que maneja son:

Nivel 1: Llamada PRESENTACIÓN que vienen siendo las ventanas e informes.

Nivel 2: LÓGICA DE APLICACIÓN que lo conforman las tareas y reglas que gobiernan el proceso.

Nivel 3: ALACENAMIENTO.

Arquitectura de tres niveles orientada a objetos.

En esta arquitectura la lógica de aplicación se dividen en los siguientes subniveles:

Objeto del dominio: Son clases que representan objetos del domino. Por ejemplo en un problema de ventas una venta seria el objeto del dominio.

Servicios: Se hace referencia a funciones de interacción con la base de datos, informes , comunicaciones, etc.

Domingo 6 de marzo entregar.

Tarea: reseña de ARQUITECTURA PARA TIEMPO REAL

Tarea: ARQUITECTURA DE REFERENCIA PARA sistemas móviles

Tarea: Arquitectura de referencia para ambientes virtuales de aprendizaje

: Arquitectura de referencia para líneas de productos.

Descargar visual paradig

Unidad IV: “Pruebas de software”

TIPOS DE PRUEBA DE SOFTWARE

Aunque no existe una clasificación oficial a cerca d los diversos tipos de prueba de software existen dos vertientes fundamentales:

Black-box testing: En donde se utiliza la interfaz externa generalmente GUI para probar la aplicación.

White box testing: Cuando la aplicación es comprobada desde su lógica.

En la primera prueba quien la realiza solo conoce las entradas apropiadas que deberá recibir la aplicación así como las correspondientes salidas sin llegar a saber como s realiza estén proceso.

En la caja blanca utiliza datos para realizar la tarea derivado de un análisis directo del código hacer probado.

Algunas de las clasificaciones que se hacen a cerca de las pruebas incluyen las siguientes:

1) De unidad2) De módulos3) De estrés4) De carga5) De rendimiento

Tipos de pruebas realizadas

Las pruebas unitarias: sirven para comprobar de módulos o códigos estas normalmente se realizan por el programador debido a que se necesita un conocimiento detallado de código y diseño.

La prueba incremental de integración: se realiza cuando se añade una funcionalidad al modulo.

Pruebas funcionales: están orientadas a las necesidades funcionales de una solicitud y se basa en especificaciones de requisitos generales.

Prueba de estrés: a menudo el termino se usa indistintamente con carga y rendimiento y al mismo tiempo para describir pruebas funcionales ya que mientras s trabaje bajo cargas inusualmente pesados o acciones repetitivas, los resultados d la entradas darán mayor información sobre los puntos de caos donde el sistema pueda fallar.

Tarea8: definición de prueba, defecto, falla, error, verificación, validación.

12/03/2011

Una tienda de alquiler de películas posee alrededor de 5000 videos en casete de los que quiere llevar registro. Cada uno de los videos tiene un número de cinta para cada película se necesita conocer: Titulo, duración, director y la categoría

En caso contrario se cobrara

El histórico de alquiler de video se requiere con el fin de analizar el comportamiento de los videos, con esto se pretende determinar cuántas cintas alquila un cliente y cuantas veces a regresado un cliente una cinta tarde. También necesitamos saber cuántas veces una cinta ha sido usada y saber cuándo retirar dicha cinta. Al mismo tiempo poder analizar las preferencias de nuestros clientes y conocer en valor de pesos el concepto de alquiler y multas por mora.

Próximamente la tienda de video casete empezara con el alquiler de DVD así que será importante llevar el registro del alquiler de películas en estos medios que será similar a las de los videocasetes.

Objetivos del sistema:

Primer objetivo: El sistema deberá gestionar las cintas y películas disponibles en este caso, adquisiciones, retiradas y disponibilidad,

Obj_1 Gestión de películasEstabilidad AltaDescripción Adquisición, retiros y disponiblescomentarios Ninguno

Segundo objetivo: El sistema deberá gestionar a los socios del videoclub en altas, bajas, modificaciones de datos, sanciones, personas autorizadas y cuentas

Tercer objetivo: El sistema deberá gestionar los alquileres de las cintas entregadas, devoluciones, devoluciones tardías, reclamaciones y disponibilidad

Los requisitos de almacenamiento de la información al igual deberán estar en plantillas de requisitos de información

Ri-01 Información sobre películasObjetivo asociado Gestión de películas y cintasRequisitos asociados Adquisiciones, retiros y disponibilidadDescripción El sistema deberá almacenar información

sobre las películas Datos específicos:Titulo de película PermanenteIntervalo TemporalEstabilidad Altacomentarios

Titulo de la películaCinta de películas alquiladasTipo de la películaNombre del directorNombre de los actores principalesTiempo de duraciónIdiomaAño de la película

Información sobre socios: el sistema deberá almacenar la información correspondiente a los socios, (no_conrol, fecha_alta,)

Información sobre cuenta de socios: el sistema deberá almacenar la información sobre cuentas sobre saldos de cuenta, ingresos de cuenta, indicando fecha y cantidad, cargos realizados a la cuenta indicando fecha y cantidad y motivo, pagos pendientes y motivo. Consulta para