UNIVERSIDAD CATLICA DE CUENCA

UNIDAD ACADMICA DE INGENIERA DE SISTEMAS Y ELCTRICA

FACULTAD DE INGENIERA DE SISTEMAS

INGENIERIA DEL SOFTWARE

Ing. Leopoldo Pauta A.

CAPITULO I

EL PRODUCTO

LA EVOLUCION DEL SOFTWARE ENIAC aos 50 Las eras de la evolucin del software Profundos cambios a nivel de software y hardware Impacto a todo nivel casas, oficinas, instituciones, etc. El poder en la tecnologa Distribucin Limitada Software aadido Multiusuario, BD Producto de software Hardware a bajo costo, redes. Sistemas potentes, redes neuronales, IA

1950 Primeros aos 1960

1960 2da era 1970 1970 3ra era 1980 1990 4ta era.

CARACTERISTICAS DEL SOFTWARE

El software se desarrolla no se fabrica El Software no se estropea El software todava se construye a medida

APLICACIONES DEL SOFTWARE

Software de Sistemas. Apoyo a otros sistemas. Software de Tiempo Real. Software de Gestin. Software transaccional, inventarios, kardex, etc.

Software de Ingeniera y Cientfico. Calculo en modelos matemticos, investigacin, etc.

Software Empotrado. Control de teclas de un microondas, el tablero de un automvil, etc.

Software de Computadores Personales. Procesadores de palabras, hojas electrnicas, manejadores de BD, etc.
Software basado en Web Software de I.A

MITOS DEL SOFTWARE

MITOS A NIVEL DE GESTIN Mito de que basta con seguir instrucciones estandarizaciones para construir software. y

Con herramientas mas potentes y pcs de ultima generacin puedo realizar software de calidad.

Si fallamos en la planificacin, podemos aadir mas programadores y adelantar el tiempo perdido.

MITOS DEL SOFTWARE

MITOS A NIVEL DE CLIENTE Una declaracin general de los objetivos es suficiente para poder comenzar a escribir los programas.

Los requisitos del proyecto cambian continuamente, pero los cambios pueden acomodarse fcilmente.

MITOS A NIVEL DE DESARROLLADOR

Una vez escrito el programa y hacemos que funcione, nuestro trabajo a terminado.

La calidad se lo vera al final del proyecto.

Trabajo del Captulo I

Defina utilizando mentefactos las distintas reas del software

Contestar y resolver los siguientes ejercicios: Desarrolle los problemas 1.1 y 1.7 En el rea de tareas de su cuaderno

CAPITULO II

El PROCESO

LA INGENIERA DEL SOFTWARE es el establecimiento y uso de principios robustos de la ingeniera a fin de obtener econmicamente software que sea fiable y que funcione eficientemente sobre mquinas reales. La Ingeniera del Software es una tecnologa multicapa, la siguiente ilustracin puede indicarnos algo: HERRAMIENTAS MTODOS PROCESO UN ENFOQUE DE CALIDAD Proveen un soporte para el proceso y el mtodo Indican como construir tcnicamente el software: anlisis, diseo, desarrollo.. Fundamento de la Ingeniera del Software, proporciona el marco del trabajo

Una visin general de la Ingeniera del Software

Una parte de la ingeniera es la gestin de requisitos, el anlisis, el diseo, la implementacin, por lo cual debemos tener presente estas siguientes preguntas: Cul es el problema a resolver? Cuales son las caractersticas esenciales de organizacin que permitan resolver el problema? Cmo se realiza la solucin? Que enfoque se va ha dar? la FASE DE DESARROLLO (CMO) FASE DE DEFINICIN (QU)

Cmo se apoyar la entidad cuando usuarios soliciten correcciones, adaptaciones y mejoras de la entidad?, etc..
La siguiente ilustracin puede indicarnos algo:

FASE DE MANTENIMIENTO (EL CAMBIO)

El Proceso del Software

OBJETIVO.- Cuando se trata de desarrollar un producto o un sistema, es importante seguir una serie de pasos predecibles (un mapa de carreteras). El mapa de carreteras a seguir es el llamado proceso de software.

La Vision General de la Ingeniera del Software

MODELOS DEL PROCESO DE SOFTWARE

El desarrollo del software puede caracterizarse como el siguiente bucle:

Definicin de Problemas

Estado Actual de Sucesos

Desarrollo Tcnico

Status Quo
Integracin de Soluciones

Se lo puede analizar a nivel macro, medio y micro

Las fases de un bucle de resolucin de problemas

EL MODELO LINEAL SECUENCIAL TRADICIONALIngeniera de Sistemas de Informacin Anlisis Diseo Plasma el diseo Cdigo PLANTILLA Prueba

Estructura de datos Arquitectura del software Representaciones de interfaz Algoritmos INCONVENIENTES En proceso de desarrollo generalmente se presentan cambios que pueden romper la secuencialidad y generar confusin. Al inicio el cliente no expone todos y correctamente los requisitos. El cliente debe tener paciencia, una versin de este producto bajo este modelo, no estar disponible hasta que el proyecto este muy avanzado. Realizar el Mentefacto

EL MODELO DE CONSTRUCCION DE PROTOTIPOS

Utilizara este modelo, cuando el cliente tenga la necesidad del software, pero esta desorientado sobre los detalles. El Modelo comenzara con la recoleccin de requisitos , el desarrollador y cliente define los objetivos generales. Luego se realiza un diseo rpido centrndose en la representacin de aspectos visibles para el usuario, por ejemplo interfaces de pantallas, esto nos llevara al desarrollo de un prototipo. Lo ideal del prototipo es que permita encontrar los requisitos reales del sistema. Realizar el Mentefacto

...

Escuchar al cliente

Construir y revisar

El cliente aprueba

La clave de este modelo es definir claramente las reglas de juego al comienzo.

EL MODELO DE CONSTRUCCION DE PROTOTIPOS

INCONVENIENTES El cliente piensa que con el prototipo de software, ya tiene lo que necesita, sin darse cuenta que tiene la calidad necesaria. Cuando se le comunica que se debe desarrollar otra vez, el cliente solicita que se le haga pequeos ajustes. El desarrollador se compromete a realizar ajustes para que el prototipo cumpla con algunas prestaciones mas. La clave es definir las reglas del juego al comienzo, indicando al cliente que el prototipo es para poder obtener requisitos exactos de lo que se desea.
...

Escuchar al cliente

Construir y revisar

El cliente aprueba

EL MODELO DRA DESARROLLO RAPIDO DE APLICACIONESEquipo Nro. 2 Equipo Nro. 1

Modelado de gestin Modelado de datos Modelado de procesos Generacin de aplicaciones Pruebas y entrega
Modelado de gestin

Equipo Nro. 3 -

Modelado de datos

Modelado de procesos Generaci on de aplicacio

Pruebas y entrega

60 90 das

EL MODELO DRA DESARROLLO RAPIDO DE APLICACIONESEl modelo DRA es una adaptacin a alta velocidad del Modelo Lineal, pudiendo crear productos entre 60 y 90 dias. Modelado de Gestion. Qu informacin conduce al proceso de gestion?, Qu informacin se genera?, Quin la genera?, A donde va la informacin?, etc.. Modelado de Datos. Se definen las caractersticas (atributos) de cada objeto, sus relaciones. Modelado del Proceso. Se definen las funciones, procesos, se crean el aadir, modificar, suprimir o recuperar un objeto de datos. Generacion de Aplicaciones. El proceso de desarrollo del software como tal, enfatiza la reutilizacion de codigo. Pruebas y Entregas. INCONVENIENTES. Complejo manejar en proyectos grandes. Se requiere clientes y desarrolladores comprometidos. No se lo debe utilizar cuando se esta probando tecnologas nuevas.

EL MODELO INCREMENTAL
incremento 1
Anlisis Diseo Cdigo Prueba

Entrega del 1 incremento

incremento 2

Anlisis

Diseo

Cdigo

Prueba

Entrega del 1 incremento

Entrega del 1 incremento

incremento 3

Anlisis

Diseo

Cdigo

Prueba

incremento 4

Anlisis

Diseo

Cdigo

Prueba

Tiempo de calendario

EL MODELO INCREMENTAL
Este modelo entrega el software en partes pequeas, pero utilizables, llamadas incrementos. En general cada incremento se construye sobre aquel que ya ha sido entregado. Combina elementos del modelo lineal con el caractersticas del modelo de prototipos. Este modelo al igual que los anteriores es de carcter iterativo. Los primeros incrementos son versiones incompletas del producto final. Se lo recomienda utilizar cuando tenga un personal limitado y que no estarn disponibles hasta cierta fecha.

EL MODELO ESPIRAL

EL MODELO ESPIRAL NOTACIN UML - RUP

En este modelo, el software se desarrolla en una serie de versiones incrementales. Comunicacin con el cliente. Las tareas requeridas para establecer comunicacin entre el desarrollador y cliente. Planificacin. Las tareas requeridas para evaluar riesgos tcnicos y de gestin. Anlisis de Riesgos. Evaluacin de riesgos tcnicos y de gestin. Ingeniera. Las tareas requeridas para construir una o mas representaciones de aplicacin.

Construccin y Accin. Probar, instalar y proporcionar soporte al usuario.

Evaluacin del cliente. La reaccin del cliente segn la evaluacin del software por parte de el.

Trabajo del Captulo II Trabajo en Clase Construya una tabla que represente las caractersticas ms relevantes de los modelos Construya una tabla 1 1 que represente las semejanzas y diferencias esenciales de los modelos

CAPITULO III

CONCEPTOS BASE EN LA GESTIN DE PROYECTOS

Personas

Herramientas

Proceso

Las Personas
En cualesquier empresa que se trate de mejorar la productividad, primero debe ocuparse de temas relacionados con el personal, como la motivacin, equipos de trabajo, seleccin del personal y formacin. Motivacin Dbil Personal Mediocre Empleados Problemticos Incontrolados Hazaas, Ilusiones Aadir Personal a un Proyecto Retrasado Oficinas Repletas y Ruidosas Fricciones Entre Clientes y Desarrolladores

Equipos de Trabajo
Un equipo de trabajo es alga ms que un conjunto de personas que desean trabajar juntas para formar un equipo. Se podra definir como un nmero de personas pequeo, con habilidades complementarias, que estn comprometidas en un propsito, objetivos de rendimiento y con un enfoque comunes, en el que todos sean responsables ante todos.. Las caractersticas que deben tener los equipos de desarrollo: Una Alta Visin u Objetivo Compartido. Un Sentido de Identidad con el Equipo. Una Estructura Dirigida por Resultados. Miembros del Equipo Competentes. Un Compromiso con el Equipo. Confianza Mutua. Interdependencia entre Miembros del Equipo. Comunicacin Efectiva. Tamao del Equipo Pequeo Un Sentido de Autonoma.

El Proceso
Las fases genricas que caracterizan el proceso de software definicin, desarrollo y soporte son aplicables a todo software. El problema ser elegir el modelo de proceso adecuado para la ingeniera del software que debe aplicar el equipo de desarrollo. Como debemos actuar y llevar el desarrollo del producto, manteniendo el objetivo a la vista, evitando la repeticin del trabajo, gestionando constantemente la calidad, sin olvidar la gestin de riesgos. Luego viene el desarrollo de las actividades en funcin del modelo escogido (ejemplo espiral): Comunicacin con el cliente Planificacin, Anlisis de Riesgos Construccin y entrega Evaluacin del cliente Comunicacin con Cliente Gestin de Riesgos

El Proceso

Orden Item

ACTIVIDADES ESTRUCTURALES EN EL PROCESO 1. Comunicacin con el cliente 2. Planificacin 3. Anlisis de Riesgos 4. Ingeniera 5. Construccin y entrega 6. Evaluacin del cliente El modelado captura las partes esenciales (requisitos) del sistema

envo

Proceso de Negocios

Sistema Computacional

Las Herramientas
El hecho de adoptar una nueva herramienta para poder mejorar la productividad en el desarrollo debe ser analizada pausadamente y tcnicamente. Siempre tome en cuenta estas tres realidades crticas: Las herramientas para aumentar la productividad producen en raras ocasiones el ahorro de tiempo prometido por sus fabricantes. Aprender a usar una nueva herramienta o mtodo disminuye inicialmente la productividad. Las herramientas para productividad que han sido desacreditadas proporcionan en ciertos casos ahorros significativos en la planificacin, aunque no tanto como se prometa originalmente.

Trabajo del Captulo III Contestar y resolver los siguientes ejercicios: Lea y describa en media hoja: Personal, Proceso y Problema Resuelva el problema 3.6

CAPITULO V PLANIFICACIN DE PROYECTOS DE SOFTWARE

Objetivos de la planificacin de software
El objetivo es proporcionar un marco de trabajo q permita al gestor hacer estimaciones razonables de recursos, coste y planificacin. El objetivo de la planificacin se logra mediante un proceso de descubrimiento de la informacin.

Equipo de Desarrollo

Cliente Organizacin

.PLANIFICACIN DE PROYECTOS DE SOFTWARE

Que es?

Implica la estimacin de: cuanto dinero, esfuerzo, recursos, tiempo supondr construir el producto

Pasos:

Descripcin del mbito Descomposicin del problema en problemas de menor tamao Estimacin Basada en: Datos Histricos y Experiencia Gestin de Riesgos

Obtiene:

Tabla con las lista de tareas a desarrollar Las funciones a implementar Coste, esfuerzo y tiempo necesario para la realizacin de cada una

.PLANIFICACIN DE PROYECTOS DE SOFTWARE

La planificacin implica tratar de estimar cuanto dinero, esfuerzo, recursos y tiempo supondr construir un sistema o producto especifico de software. Toda planificacin debe incluir los siguientes aspectos: 1. Determinar el mbito del Software , describe el control y los datos a procesar, la funcin, el rendimiento, las restricciones, las interfaces y la fiabilidad. 1.1 Descomposicin en funciones mas pequeas. 1.2 Viabilidad. Es factible el desarrollo del proyecto?. Considerar los aspectos Tcnicos, de Financiacin, de Tiempo, de los Recursos.

Un Ejemplo de Ambito:

1. IDENTIFICACIN DEL MBITO

Caso de Uso: Sistema de Clasificacin de Cinta Transportadora SCCT

Es un sistema q clasifica cajas q se mueven por una cinta transportadora. Cada caja estar identificada por un cdigo de barras que contiene un numero de pieza y se clasifica en uno de los 6 compartimentos al final de la cinta. Las cajas pasaran por una estacin de clasificacin que consta de un lector de cdigo de barras y un Pc. Este esta conectado a un mecanismo que clasifica las cajas en los compartimentos.

Las cajas pasan en orden aleatorio y estn espaciadas uniformemente. La banda se mueve a 60 cms por minuto.

El software del SCCT debe recibir informacin de entrada de un lector de cdigo de barras a intervalos de tiempo que se ajusten a la velocidad de la cinta transportadora. El software llevara a cabo una inspeccin en la BD de nmeros de piezas que contiene para determinar su ubicacin por medio de la Estacin de Clasificacin y por medio del Mecanismo de Maniobra (se deben encontrar sincronizados) se sita a las caja en el lugar adecuado. Adems se generara una lista con la ubicacin de la caja para su posterior recuperacin. 2. EXTRACCIN DE LAS FUNCIONES IMPORTANTES El planificador del proyecto examina las especificaciones del mbito y extrae todas funciones importantes del software. A este proceso se le denomina tambin Descomposicin. Para el ejemplo anterior: Lectura del cdigo de barras Decodificacin de los datos del cdigo de pieza. Bsqueda en la BD Determinar la posicin del compartimento Produccin de la seal de control para el mecanismo de maniobra Mantener una lista de los destinos de las cajas

RECURSOS
1. El numero de personas requerido para un proyecto se lo realizara en funcin de la estimacin esfuerzo por ejemplo , personas-mes. 2. Se destaca la reutilizacin de componentes ya desarrollados. experimentados, nuevos. Considere las siguientes para adquirir un componente: Si los componentes cumplen con los requisitos del proyecto cmprelo. Si los componentes cumplen parcialmente los requisitos, analice y estime el costo de las modificaciones

1. Personas

2. Componentes de software reutilizable 3. Herramientas de Hardware Software

3. Cuando se desarrolla software se considera el equipo adicional que requiere para realizar pruebas de funcionamiento

Desarrollar o Comprar
Comprar todo el paquete Comprar ciertos mdulos Outsourcing

Considere: 1. Si el paquete se ajusta a las necesidades de la organizacin 2. Si al comprar determinados mdulos, el ajuste a las necesidades no es tan laborioso 3. Si el costo de mantenimiento exterior no excede el costo de mantenimiento interno

Trabajo del Captulo V Contestar y resolver los siguientes ejercicios: Resuelva el problema 5.1 1.A partir del ejercicio anterior obtenga las funciones esenciales del mbito del software.

2. Investigue en artculos sobre la decisin de contratar outsourcing. Por ejemplo: Referente el sistema informtico para las elecciones
Nota.- Obviar temas de ESTIMACIN DEL PROYECTO DE SOFTWARE

CAPITULO X
INGENIERIA DE SISTEMAS
La Ingeniera del software nace del proceso de la ingeniera de sistemas, que se centra en diversos elementos, analizando, diseando y organizando esos elementos en un sistema q pueden ser un producto, un servicio o una tecnologa para transformacin de informacin. Actividades Base de la Ingeniera de Sistemas Sistema: Es un conjunto o disposicin de elementos que estn organizados para realizar un objetivo predefinido procesando informacin. Antes de construir el sistema se deber: Identificar los objetivos generales del sistema: el papel del hardware, software, personas, bd, procedimientos, y otros elementos del sistema. Los requerimientos operacionales: Identificarlos, analizarlos, modelarlos, gestionarlos. Los arboles no dejan ver el bosque; El bosque es el sistema Los arboles son los elementos tecnolgicos

Un sistema basado en computadora hace uso de varios elementos del sistema: Software: Estructuras de datos, programas para pc, algoritmos, clases, etc. Hardware: Dispositivos que proporcionan capacidad de calculo, redes, conmutadores, motores, etc. Personas: Usuarios y operadores del hardware y software Documentacin : Manuales, formularios, que indican el funcionamiento del sistema Procedimientos: Los pasos que definen el empleo especifico de cada elemento del sistema. LOS ELEMENTOS SE COMBINAN TRANSFORMAR LA INFORMACION. DE VARIAS MANERAS PARA

El papel del ingeniero de sistemas es definir los elementos de un sistema especfico basado en computadora en el contexto de la jerarqua global de sistemas, como se ilustra a continuacin:

LA JERARQUA DE LA INGENIERA DE SISTEMAS

Actualmente los sistemas cada vez son mas complejos por lo que se expresan en jerarqua de elementos. Vista Global. Se examina el dominio global del negocio. Vista del Dominio. La visin global se refina y se centra en un dominio de inters especifico Vista del Elemento. Que se requiere informacin, hardware, software, personas.

Los buenos sistemas de ingeniera comienzan por clarificar el comportamiento de contexto la visin global y progresivamente se van estrechando hasta el nivel del detalle necesario. La Ingeniera de sistemas es un proceso de modelado, el ingeniero crear modelos que: Definan los procesos q satisfagan las necesidades de la visin en consideracin. Representen el comportamiento de los procesos Definan las entradas al modelo de informacin Pero tambin el ingeniero deber considerar las restricciones. Analice y plantee un ejemplo por cada restriccin. Pag. 167-168. La Ingeniera de Procesos de Negocios (IPN) El objetivo de esta ingeniera es definir las arquitecturas que permitan a las empresas emplear la informacin eficazmente. Tres arquitecturas se deben analizar:

Arquitectura de Datos: Se refiere a la definicin de los objetos con sus posibles atributos. Como estos se encuentra relacionados, envan sus mensajes, como fluye la informacin. Arquitectura de Aplicacin. Define como esta funcionara y el conjunto de objetos se orientan a cumplir ese objetivo, por ejemplo definir Arquitectura Cliente Servidor. Infraestructura Tecnolgica. Comprende el hardware y software empleado para dar soporte a las aplicaciones y datos. Por ejemplo redes, servidores, bases de datos, etc.

Diagrama de una IPN

Realice un Mentefacto que defina: Ingeniera de Procesos. Ingeniera de Producto. Ingeniera de Requisitos. Luego un anlisis comparativo entre este tipo de ingenieras.

INGENIERIA DE PROCESOS

CAPITULO XI
ANALISIS Y DISEO
Anlisis de Requisitos: permite al ingeniero de sistemas especificar las caractersticas operacionales del software funcin, datos y rendimientos-, indica la interfaz del software con otros elementos del sistema y establece las restricciones que debe cumplir. Identificacin de Requisitos: Empaparse del tema, Entrevistas generales , determinar a quien entrevistar. Observar el flujo de los procesos, la observacin como una muy buena recolectora de informacin. Tcnicas para facilitar las especificaciones de una aplicacin: fomentar el trabajo equipo

Una vez recopilada los requisitos que tambin se le conoce como la gestin del dominio se empezara a definir los CASOS DE USO.

DIAGRAMA DE CASOS DE USO

El modelo de Casos de Uso especifica la funcionalidad que el sistema ha de ofrecer desde la perspectiva de los usuarios y lo que el sistema realizara para satisfacer las necesidades del usuario. ACTOR.- Define los diferentes papeles que un usuario puede desempear. Implica el conjunto de actores que esta intercambiando informacin con el sistema que se esta desarrollando. CASOS DE USO.- Es la secuencia de transacciones que se realizan en un dilogo con el sistema. Cada caso de uso constituye una secuencia completa de mensajes.

RELACIONES. -Identifica la comunicacin existente entre actores, casos de uso, actorescasos de uso.

Relacin de Extension (extend).- Permite la utilizacion de otro caso de uso en determinadas ocasiones.

Relacin de Inclusin (include).- Significa que un caso de uso hace uso de otro caso de uso para completar su ejecucin.

INVESTIGACION DEFINICION DEL AMBITO

Juan Prez, es un renombrado corredor de arte, necesita un sistema de informacin que le ayude a comprar y vender cuadros. Prez se especializa en comprar y vender cuadros impresionistas. Sin embargo, comprara virtualmente cualquier cuadro si considera que puede obtener una ganancia cuando lo venda en su galera. Se le entrevistara con el fin de obtener informacin detallada sobre cada aspecto de su negocio. Pero antes de hacerlo SIEMPRE ES NECESARIO ADQUIRIR CONOCIMIENTO DEL MEDIO, para poder puntualizar en aspectos tcnicos que el maneje y as poder obtener informacin trascendental que nos ayude en la construccin del sistema que se est necesitando. En esta investigacin se descubri que existen algunas maneras de clasificar los cuadros.

Una es la TECNICA, es decir el material (al oleo, acuarela, lpiz, pastel) con el cual se pinto la obra de arte.
Una segunda manera de clasificar los cuadros es por TEMA. El tema ms popular es el retrato de una persona, otros temas son paisajes, objetos inanimados (florero, un frutero, etc.) a este se le llama Naturaleza Muerta. Una tercera forma es la CALIDAD DEL CUADRO. Un cuadro de excelencia indudable se le llama Obra Maestra. Tambin existe una Obra Representativa, la cual es una obra inferior al hecho por un artista que ha pintado una obra maestra. No obstante, la gran mayora de los cuadros no son del ningn tipo. A continuacin encontramos informacin obtenida luego de una serie de entrevistas a Juan Prez.

INVESTIGACION DEFINICION DEL AMBITO

La empresa de Juan Prez ha sido exitosa durante muchos aos. Sin embargo ltimamente Prez ha estado perdiendo dinero. Un consultor de administracin ha analizado los registros de negocio y ha concluido que Juan ha estado pagando dems por los cuadros. El consultor ha aconsejado a Prez que compre un sistema de informtico que le permita usar para determinar el precio mximo a pagar por una obra. El consultor de administracin ha derivado un algoritmo que el sistema debe usar para determinar el precio mximo que se debe pagar y de esta manera ayude a Prez a proponer el precio mximo que debe ofrecer para comprar un cuadro. A diferencia de otros corredores Juan no cree en el regateo, la cantidad que ofrece es su precio final. De manera similar, cuando vende un cuadro, no negocia, el precio que dice ese es el precio final. Adems a Prez le gustara que el sistema de informacin detectara nuevas tendencias en el mercado del arte tan pronto como sea posible para que de esta manera sepa cuanto debera pagar por un cuadro. Para esto el sistema necesitara mantener un registro de todas las ventas y compras. Adicionalmente a Prez le gustara tener informacin adicional de su negocio, especficamente un informe que muestre todas las ventas del ao pasado y otro que muestre las ventas en ese mismo periodo. En otras palabras Prez, lo que quiere es un sistema que calcule el precio ms que debe pagar por un cuadro y que tambin detecte nuevas tendencias de arte. Lo que necesita es un sistema informtico que genere reportes de compras y ventas.

PARA EL CASO DE ESTUDIO

CORREDOR DE ARTE
Casos De Uso General

Luego de una revisin ms detallada

Caso de Uso General

En cada Caso de Uso general se debe profundizar y a partir de ellos se generan los Casos de Uso Especficos. Como se indica siguiente recuadro. en el

Casos de Uso Detallado

Los Casos de Uso general tienen: Comprar Obras: Comprar O. Maestras Comprar O. Representativas Comprar O. Otro Tipo Vender Cuadro. Producir Informes: Informes de Compras Informes de Ventas

Actualizar coeficiente Moda

Tarjetas de Descripcin
Las tarjetas de descripcin detallan paso a paso la ejecucin del caso de uso, los datos que requiere, las acciones que va ejecutando, para conseguir el objetivo del Caso.

DEFINICION DE CLASES
El diagrama de clases modela la vista esttica del sistema, no describe el comportamiento del sistema en funcin del tiempo. Se encuentra conformado por CLASES y RELACIONES. OBJETO.- Es la abstraccin de un concepto, cosa bien definidas. Tiene 3 caractersticas fundamentales: 1. Estado.- Cuando se define con los valores de los atributos. 2. Comportamiento.- Indica todo lo que el objeto puede hacer y se define por las operaciones (mtodos). 3. Identidad.- Significa que cada objeto es nico. Los atributos y mtodos pueden ser Pblicos, Protegidos y Privados.

RELACIONES
1. Asociacin.- Son relaciones entre objetos de carcter bidireccional, no es un flujo de datos, sino mas bien existe un enlace entre objetos de clases asociadas. Por ejemplo una clase abogado con una clase radilogo. 2. Agregacin.- Un objeto esta compuesto por otro del mismo o diferentes tipos, es decir relaciones todo-parte. Por ejemplo un a Clase Automvil esta compuesto de Clase Motor, Clase Llantas, etc.

3. Herencia.- Define una relacin entre una Superclase y subclases obviamente con un mayor detalle que las Superclases. La Herencia se puede encontrar mediante 2 mtodos. 3.1. Generalizacin.3.2. Especializacin

Relaciones de Clases

Agregacin
Asociacin

PARA EL CASO DE ESTUDIO

CORREDOR DE ARTE Extraccin de Clases
Los informes se van a generar con el fin de mejorar la efectividad del proceso de toma de decisiones para la compra de obras de arte. Los informes contienen informacin de compra y venta de cuadros, los cuales se clasifican en obras maestras, obras representativas y de otro tipo.

Los sustantivos compra y venta son derivados de los verbos comprar y vender, por lo q pueden ser operaciones. Informe puede ser una clase externa. Efectividad, proceso e informacin son sustantivos abstractos y por lo tanto no se representan como clases. Esto nos queda 4 clases: clase cuadro, clase obra maestra, clase obra de arte, y clase otro tipo.

Relacin entre Clases Herencia (Generalizacin)

Analizando las clases podemos definir en una primera instancia las siguientes clases y su relacin: Debido a la naturaleza de la herencia, podemos indicar que de la clase Cuadro heredan todos los atributos en las restantes clases.

Otro aspecto que debemos tomar en cuenta es que para el caso de CUADROS DE OTRO TIPO se dice: El sistema de informacin calcula el precio de compra mximo mediante la formula F x A, donde F es una constante para ese artista (coeficiente de moda)

Posible Diagrama Final de Clases

Otras Posibles Clases

CLASES QUE SE RELACIONAN CON EL USUARIO Clase Interfaz de Usuario Clase Informe de Compras Clase Informe de Ventas CLASES QUE REALIZAN CALCULOS Clase Calcular Precio de Obra Maestra Clase Calcular Precio de Obra Representativa Clase Calcular Precio de Cuadro de Otro Tipo

Trabajo del Captulo XI

En funcin de lo aprehendido, encuentre el Caso de Uso General, Casos de Usos Detallados, Tarjetas de Descripcin y Escenarios para cada caso de uso detallado, extraccin de clases. El caso de estudio se encuentra en:

Elearning Universidad Catlica de Cuenca Facultades Caso de Estudio Entrar como Invitado

DIAGRAMAS DE COLABORACION
Los diagramas de colaboracin representa la realizacin de un escenario especifico del caso de uso. Para poder entender de mejor manera tomaremos el caso de uso COMPRAR UNA OBRA MAESTRA.

A continuacin se utilizan las clases encontradas para resolver el caso de uso: Clase Interfaz de Usuario Clase Calcular Precio Obra Maestra Clase Obra Maestra Clase Cuadro Subastado

CASO DE ESTUDIO
Diagrama de Colaboracin para Compra de Obra de Arte